kernel/linux.git/drivers/gpu/drm/drm_panel.c, branch v6.6.149

drm/bridge: panel: forbid initializing a panel with unknown connector type

2025-04-25T08:45:18+00:00

[ Upstream commit b296955b3a740ecc8b3b08e34fd64f1ceabb8fb4 ] Having an DRM_MODE_CONNECTOR_Unknown connector type is considered bad, and drm_panel_bridge_add_typed() and derivatives are deprecated for this. drm_panel_init() won't prevent initializing a panel with a DRM_MODE_CONNECTOR_Unknown connector type. Luckily there are no in-tree users doing it, so take this as an opportinuty to document a valid connector type must be passed. Returning an error if this rule is violated is not possible because drm_panel_init() is a void function. Add at least a warning to make any violations noticeable, especially to non-upstream drivers. Reviewed-by: Dmitry Baryshkov Signed-off-by: Luca Ceresoli Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250214-drm-assorted-cleanups-v7-5-88ca5827d7af@bootlin.com Signed-off-by: Sasha Levin

drm/panel: do not return negative error codes from drm_panel_get_modes()

2024-04-03T13:28:33+00:00

[ Upstream commit fc4e97726530241d96dd7db72eb65979217422c9 ] None of the callers of drm_panel_get_modes() expect it to return negative error codes. Either they propagate the return value in their struct drm_connector_helper_funcs .get_modes() hook (which is also not supposed to return negative codes), or add it to other counts leading to bogus values. On the other hand, many of the struct drm_panel_funcs .get_modes() hooks do return negative error codes, so handle them gracefully instead of propagating further. Return 0 for no modes, whatever the reason. Cc: Neil Armstrong Cc: Jessica Zhang Cc: Sam Ravnborg Cc: stable@vger.kernel.org Reviewed-by: Neil Armstrong Reviewed-by: Jessica Zhang Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/79f559b72d8c493940417304e222a4b04dfa19c4.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin

drm/panel: Add a way for other devices to follow panel state

2023-08-01T14:38:13+00:00

These days, it's fairly common to see panels that have touchscreens attached to them. The panel and the touchscreen can somewhat be thought of as totally separate devices and, historically, this is how Linux has treated them. However, treating them as separate isn't necessarily the best way to model the two devices, it was just that there was no better way. Specifically, there is little practical reason to have the touchscreen powered on when the panel is turned off, but if we model the devices separately we have no way to keep the two devices' power states in sync with each other. The issue described above makes it sound as if the problem here is just about efficiency. We're wasting power keeping the touchscreen powered up when the screen is off. While that's true, the problem can go deeper. Specifically, hardware designers see that there's no reason to have the touchscreen on while the screen is off and then build hardware assuming that software would never turn the touchscreen on while the screen is off. In the very simplest case of hardware designs like this, the touchscreen and the panel share some power rails. In most cases, this turns out not to be terrible and is, again, just a little less efficient. Specifically if we tell Linux that the touchscreen and the panel are using the same rails then Linux will keep the rails on when _either_ device is turned on. That ends to work OK-ish, but now if you turn the panel off not only will the touchscreen remain powered, but the power rails for the panel itself won't be switched off, burning extra power. The above two inefficiencies are _extra_ minor when you consider the fact that laptops rarely spend much time with the screen off. The main use case would be when an external screen (and presumably a power supply) is attached. Unfortunately, it gets worse from here. On sc7180-trogdor-homestar, for instance, the display's TCON (timing controller) sometimes crashes if you don't power cycle it whenever you stop and restart the video stream (like during a modeset). The touchscreen keeping the power rails on causes real problems. One proposal in the homestar timeframe was to move the touchscreen to an always-on rail, dedicating the main power rail to the panel. That caused _different_ problems as talked about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to the regulator"). The end result of all of this was to add an extra regulator to the board, increasing cost. Recently, Cong Yang posted a patch [1] where things are even worse. The panel and touch controller on that system seem even more intimately tied together and really can't be thought of separately. To address this issue, let's start allowing devices to register themselves as "panel followers". These devices will get called after a panel has been powered on and before a panel is powered off. This makes the panel the primary device in charge of the power state, which matches how userspace uses it. The panel follower API should be fairly straightforward to use. The current code assumes that panel followers are using device tree and have a "panel" property pointing to the panel to follow. More flexibility and non-DT implementations could be added as needed. Right now, panel followers can follow the prepare/unprepare functions. There could be arguments made that, instead, they should follow enable/disable. I've chosen prepare/unprepare for now since those functions are guaranteed to power up/power down the panel and it seems better to start the process earlier. A bit of explaining about why this is a roll-your-own API instead of using something more standard: 1. In standard APIs in Linux, parent devices are automatically powered on when a child needs power. Applying that here, it would mean that we'd force the panel on any time someone was listening to the touchscreen. That, unfortunately, would have broken homestar's need (if we hadn't changed the hardware, as per above) where the panel absolutely needs to be able to power cycle itself. While one could argue that homestar is broken hardware and we shouldn't have the API do backflips for it, _officially_ the eDP timing guidelines agree with homestar's needs and the panel power sequencing diagrams show power going off. It's nice to be able to support this. 2. We could, conceibably, try to add a new flag to device_link causing the parent to be in charge of power. Then we could at least use normal pm_runtime APIs. This sounds great, except that we run into problems with initial probe. As talked about in the later patch ("HID: i2c-hid: Support being a panel follower") the initial power on of a panel follower might need to do things (like add sub-devices) that aren't allowed in a runtime_resume function. The above complexities explain why this API isn't using common functions. That being said, this patch is very small and self-contained, so if someone was later able to adapt it to using more common APIs while solving the above issues then that could happen in the future. [1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com Reviewed-by: Maxime Ripard Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid

drm/panel: Check for already prepared/enabled in drm_panel

2023-08-01T14:35:36+00:00

In a whole pile of panel drivers, we have code to make the prepare/unprepare/enable/disable callbacks behave as no-ops if they've already been called. It's silly to have this code duplicated everywhere. Add it to the core instead so that we can eventually delete it from all the drivers. Note: to get some idea of the duplicated code, try: git grep 'if.*>prepared' -- drivers/gpu/drm/panel git grep 'if.*>enabled' -- drivers/gpu/drm/panel NOTE: arguably, the right thing to do here is actually to skip this patch and simply remove all the extra checks from the individual drivers. Perhaps the checks were needed at some point in time in the past but maybe they no longer are? Certainly as we continue transitioning over to "panel_bridge" then we expect there to be much less variety in how these calls are made. When we're called as part of the bridge chain, things should be pretty simple. In fact, there was some discussion in the past about these checks [1], including a discussion about whether the checks were needed and whether the calls ought to be refcounted. At the time, I decided not to mess with it because it felt too risky. Looking closer at it now, I'm fairly certain that nothing in the existing codebase is expecting these calls to be refcounted. The only real question is whether someone is already doing something to ensure prepare()/unprepare() match and enabled()/disable() match. I would say that, even if there is something else ensuring that things match, there's enough complexity that adding an extra bool and an extra double-check here is a good idea. Let's add a drm_warn() to let people know that it's considered a minor error to take advantage of drm_panel's double-checking but we'll still make things work fine. We'll also add an entry to the official DRM todo list to remove the now pointless check from the panels after this patch lands and, eventually, fixup anyone who is triggering the new warning. [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid Acked-by: Neil Armstrong Reviewed-by: Maxime Ripard Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid

drm/panel: Add helper for reading DT rotation

2020-08-16T15:12:18+00:00

This adds a helper function for reading the rotation (panel orientation) from the device tree. Reviewed-by: Sam Ravnborg Tested-by: Dmitry Osipenko Signed-off-by: Derek Basehore Signed-off-by: Dmitry Osipenko Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200813215609.28643-2-digetx@gmail.com

drm: Remove unnecessary drm_panel_attach and drm_panel_detach

2020-08-08T07:06:33+00:00

These functions are now empty and no longer useful so remove the functions and their uses. Signed-off-by: Joe Perches Cc: Bernard Zhao Cc: Maarten Lankhorst Cc: Maxime Ripard , Cc: Thomas Zimmermann Cc: Thierry Reding Cc: David Airlie Cc: Daniel Vetter Cc: Linus Walleij Cc: Icenowy Zheng , Cc: Jagan Teki Cc: Laurent Pinchart Cc: Robert Chiras Cc: dri-devel@lists.freedesktop.org, Cc: linux-kernel@vger.kernel.org Cc: opensource.kernel@vivo.com Signed-off-by: Sam Ravnborg # Fixed build and a few warnings Link: https://patchwork.freedesktop.org/patch/msgid/9e13761020750b1ce2f1fabee23ef6e2a2942882.camel@perches.com

drm/panel: remove return value of function drm_panel_add

2020-08-02T06:59:06+00:00

The function "int drm_panel_add(struct drm_panel *panel)" always returns 0, this return value is meaningless. Also, there is no need to check return value which calls "drm_panel_add and", error branch code will never run. Signed-off-by: Bernard Zhao Reviewed-by: Linus Walleij Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200801120216.8488-1-bernard@vivo.com

drm/drm_panel: Fix EXPORT of drm_panel_of_backlight() one more time

2019-12-17T19:39:33+00:00

The initial commit followed by the fix didn't take into consideration the case: CONFIG_DRM_PANEL=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_DRM_I915=y where symbol devm_of_find_backlight() is not reachable from DRM subsystem. Quick fix is to avoid drm_panel_of_backlight() from exporting in such case. Fixes: 907aa265fde6 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight") Reported-by: Randy Dunlap Acked-by: Randy Dunlap # build-tested Cc: Linus Walleij Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: Thierry Reding Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Signed-off-by: Andy Shevchenko Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20191217140721.42432-1-andriy.shevchenko@linux.intel.com

drm/drm_panel: fix EXPORT of drm_panel_of_backlight

2019-12-11T00:13:07+00:00

Fix link failure for module builds of panels. The conditional compilation around drm_panel_of_backlight() was wrong for a module build. Fix it using IS_ENABLED(). Signed-off-by: Sam Ravnborg Reviewed-by: Linus Walleij Fixes: 152dbdeab1b2 ("drm/panel: add backlight support") Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: Thierry Reding Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20191210194758.24087-1-sam@ravnborg.org

drm/panel: drop drm_device from drm_panel

2019-12-09T21:57:26+00:00

The panel drivers used drm_panel.drm for two purposes: 1) Argument to drm_mode_duplicate() 2) drm->dev was used in error messages The first usage is replaced with drm_connector.dev - drm_connector is already connected to a drm_device and we have a valid connector The second usage is replaced with drm_panel.dev - this makes drivers more consistent in their dev argument used for dev_err() and friends With these replacements there are no more uses of drm_panel.drm, so it is removed from struct drm_panel. With this change drm_panel_attach() and drm_panel_detach() no longer have any use as they are empty functions. v2: - editorial correction in changelog (Laurent) Signed-off-by: Sam Ravnborg Reviewed-by: Laurent Pinchart Reviewed-by: Linus Walleij Cc: Thierry Reding Cc: Laurent Pinchart Cc: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: Linus Walleij Cc: Jagan Teki Cc: Stefan Mavrodiev Cc: Robert Chiras Cc: "Guido Günther" Cc: Purism Kernel Team Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-8-sam@ravnborg.org