kernel.git/drivers/gpu/drm/panel/panel-simple.c, branch linux-5.14.y

drm/panel: panel-simple: Fix proper bpc for ytc700tlag_05_201c

2021-07-25T20:12:14Z

ytc700tlag_05_201c panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Fixes: 7a1f4fa4a629 ("drm/panel: simple: Add YTC700TLAG-05-201C") Signed-off-by: Jagan Teki Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210725174737.891106-1-jagan@amarulasolutions.com

drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() calls

2021-05-24T21:04:55Z

The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe(): > Drivers in ->remove() callback should undo the runtime PM changes done > in ->probe(). Usually this means calling pm_runtime_disable(), > pm_runtime_dont_use_autosuspend() etc. We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove(). Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by: Douglas Anderson Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210517130450.v7.1.I9e947183e95c9bd067c9c1d51208ac6a96385139@changeid

drm/panel: panel-simple: Cache the EDID as long as we retain power

2021-05-03T20:21:09Z

It doesn't make sense to go out to the bus and read the EDID over and over again. Let's cache it and throw away the cache when we turn power off from the panel. Autosuspend means that even if there are several calls to read the EDID before we officially turn the power on then we should get good use out of this cache. Signed-off-by: Douglas Anderson Reviewed-by: Bjorn Andersson Reviewed-by: Sean Paul Acked-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.18.If050957eaa85cf45b10bcf61e6f7fa61c9750ebf@changeid

drm/panel: panel-simple: Power the panel when reading the EDID

2021-05-03T20:21:09Z

I don't believe that it ever makes sense to read the EDID when a panel is not powered and the powering on of the panel is the job of prepare(). Let's make sure that this happens before we try to read the EDID. We use the pm_runtime functions directly rather than directly calling the normal prepare() function because the pm_runtime functions are definitely refcounted whereas it's less clear if the prepare() one is. NOTE: I'm not 100% sure how EDID reading was working for folks in the past, but I can only assume that it was failing on the initial attempt and then working only later. This patch, presumably, will fix that. If some panel out there really can read the EDID without powering up and it's a big advantage to preserve the old behavior we can add a per-panel flag. It appears that providing the DDC bus to the panel in the past was somewhat uncommon in any case. Signed-off-by: Douglas Anderson Reviewed-by: Bjorn Andersson Reviewed-by: Sean Paul Acked-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.17.Ibd31b8f7c73255d68c5c9f5b611b4bfaa036f727@changeid

drm/panel: panel-simple: Remove extra call: drm_connector_update_edid_property()

2021-05-03T20:21:08Z

As of commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") the drm_get_edid() function calls drm_connector_update_edid_property() for us. There's no reason for us to call it again. Signed-off-by: Douglas Anderson Reviewed-by: Bjorn Andersson Reviewed-by: Sean Paul Acked-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.16.Icb581b0273d95cc33ca38676c61ae6d7d2e75357@changeid

drm/panel: panel-simple: Get rid of hacky HPD chicken-and-egg code

2021-05-03T20:21:08Z

When I added support for the hpd-gpio to simple-panel in commit 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying prepare()"), I added a special case to handle a circular dependency I was running into on the ti-sn65dsi86 bridge chip. On my board the hpd-gpio is actually provided by the bridge chip. That was causing some circular dependency problems that I had to work around by getting the hpd-gpio late. I've now reorganized the ti-sn65dsi86 bridge chip driver to be a collection of sub-drivers. Now the GPIO part can probe separately and that breaks the chain. Let's get rid of the old code to clean things up. Signed-off-by: Douglas Anderson Reviewed-by: Bjorn Andersson Reviewed-by: Sean Paul Acked-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.10.I40eeedc23459d1e3fc96fa6cdad775d88c6e706c@changeid

drm/panel: panel-simple: Add missing pm_runtime_disable() calls

2021-04-30T20:24:30Z

In commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") we started using pm_runtime, but my patch neglected to add the proper pm_runtime_disable(). Doh! Add them now. Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Reported-by: Bjorn Andersson Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul Reviewed-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.1.I9e6af2529d6c61e5daf86a15a1211121c5223b9a@changeid

drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare

2021-04-20T16:05:24Z

Unpreparing and re-preparing a panel can be a really heavy operation. Panels datasheets often specify something on the order of 500ms as the delay you should insert after turning off the panel before turning it on again. In addition, turning on a panel can have delays on the order of 100ms - 200ms before the panel will assert HPD (AKA "panel ready"). The above means that we should avoid turning a panel off if we're going to turn it on again shortly. The above becomes a problem when we want to read the EDID of a panel. The way that ordering works is that userspace wants to read the EDID of the panel _before_ fully enabling it so that it can set the initial mode correctly. However, we can't read the EDID until we power it up. This leads to code that does this dance (like ps8640_bridge_get_edid()): 1. When userspace requests EDID / the panel modes (through an ioctl), we power on the panel just enough to read the EDID and then power it off. 2. Userspace then turns the panel on. There's likely not much time between step #1 and #2 and so we want to avoid powering the panel off and on again between those two steps. Let's use Runtime PM to help us. We'll move the existing prepare() and unprepare() to be runtime resume() and runtime suspend(). Now when we want to prepare() or unprepare() we just increment or decrement the refcount. We'll default to a 1 second autosuspend delay which seems sane given the typical delays we see for panels. A few notes: - It seems the existing unprepare() and prepare() are defined to be no-ops if called extra times. We'll preserve that behavior but may try to remove it in a future patch. - This is a slight change in the ABI of simple panel. If something was absolutely relying on the unprepare() to happen instantly that simply won't be the case anymore. I'm not aware of anyone relying on that behavior, but if there is someone then we'll need to figure out how to enable (or disable) this new delayed behavior selectively. - In order for this to work we now have a hard dependency on "PM". From memory this is a legit thing to assume these days and we don't have to find some fallback to keep working if someone wants to build their system without "PM". Signed-off-by: Douglas Anderson Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid

drm: panel: simple: Set enable delay for BOE NV110WTM-N61

2021-03-11T16:19:52Z

Panel power sequence says timing T8 (time from link idle to turn on the backlight) should be at least 50 ms. This is what the .enable delay in simple-panel is for, so set it. NOTE: this overlaps with the 80 ms .prepare_to_enable delay on purpose. The data sheet says that at least 80 ms needs to pass between HPD going high and turning on the backlight and that at least 50 ms needs to pass between the link idle and the backlight going on. Thus it works like this on the system in front of me: * In bridge chip pre_enable call drm_panel_prepare() * drm_panel_prepare() -> panel_simple_prepare() * Wait for HPD GPIO to go high. * Start counting for 80 ms (store in prepared_time) * In bridge chip enable, train link then call drm_panel_enable() * drm_panel_enable() -> panel_simple_enable() * panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms from HPD going high (in case the bridge took less than 30 ms to enable / link train). * drm_panel_enable() -> backlight_enable(). Signed-off-by: Douglas Anderson Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid

drm/panel-simple: Add N116BCA-EA1

2021-03-11T16:14:43Z

This panel is quite similar to the similarly named N116BGE panel (the nominal timings are, in fact identical). However, let's add a new entry because the full range of clocks listed for N116BGE aren't supported for N116BCA-EA1, at least according to the datasheet. Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.5.I3c01f3aab8335cb509da7009d8938c1a27a266dc@changeid