linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent
@ 2021-07-28 13:32 Maxime Ripard
  2021-07-28 13:32 ` [PATCH v2 1/8] Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" Maxime Ripard
                   ` (8 more replies)
  0 siblings, 9 replies; 13+ messages in thread
From: Maxime Ripard @ 2021-07-28 13:32 UTC (permalink / raw)
  To: Sam Ravnborg, Daniel Vetter, David Airlie, Thierry Reding,
	Laurent Pinchart, Maarten Lankhorst, Thomas Zimmermann,
	Maxime Ripard, Jernej Skrabec, Neil Armstrong, Andrzej Hajda,
	Jonas Karlman, Robert Foss
  Cc: linux-kernel, dri-devel

Hi,\r
\r
We've encountered an issue with the RaspberryPi DSI panel that prevented the\r
whole display driver from probing.\r
\r
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:\r
Only register our component once a DSI device is attached"), but the basic idea\r
is that since the panel is probed through i2c, there's no synchronization\r
between its probe and the registration of the MIPI-DSI host it's attached to.\r
\r
We initially moved the component framework registration to the MIPI-DSI Host\r
attach hook to make sure we register our component only when we have a DSI\r
device attached to our MIPI-DSI host, and then use lookup our DSI device in our\r
bind hook.\r
\r
However, all the DSI bridges controlled through i2c are only registering their\r
associated DSI device in their bridge attach hook, meaning with our change\r
above, we never got that far, and therefore ended up in the same situation than\r
the one we were trying to fix for panels.\r
\r
Since the RaspberryPi panel is the only driver in that situation, whereas it\r
seems like there's a consensus in bridge drivers, it makes more sense to try to\r
mimic the bridge pattern in the panel driver.\r
\r
However, panels don't have an attach hook, and adding more panel hooks would\r
lead to more path to maintain in each and every driver, while the general push\r
is towards bridges. We also have to make sure that each and every DSI host and\r
device driver behaves the same in order to have expectations to rely on.\r
\r
The solution I'm proposing is thus done in several steps:\r
\r
  - We get rid of the initial patch to make sure we support the bridge case,\r
    and not the odd-panel one.\r
\r
  - Add a function that returns a bridge from a DT node, reducing the amount of\r
    churn in each and every driver and making it a real incentive to not care\r
    about panels in display drivers but only bridges.\r
\r
  - Add an attach and detach hook into the panel operations, and make it called\r
    automatically by the DRM panel bridge.\r
\r
  - Convert the VC4 DSI host to this new bridge function, and the RaspberryPi\r
    Panel to the new attach and detach hooks.\r
\r
If the general approach is agreed upon, other drivers will obviously be\r
converted to drm_of_get_next.\r
\r
Let me know what you think,\r
Maxime\r
\r
---\r
\r
Changes from v1:\r
  - Change the name of drm_of_get_next function to drm_of_get_bridge\r
  - Mention the revert of 87154ff86bf6 and squash the two patches that were\r
    reverting that commit\r
  - Add some documentation\r
  - Make drm_panel_attach and _detach succeed when no callback is there\r
\r
Maxime Ripard (8):\r
  Revert "drm/vc4: dsi: Only register our component once a DSI device is\r
    attached"\r
  drm/bridge: Add a function to abstract away panels\r
  drm/bridge: Add documentation sections\r
  drm/bridge: Document the probe issue with MIPI-DSI bridges\r
  drm/panel: Create attach and detach callbacks\r
  drm/vc4: dsi: Switch to drm_of_get_bridge\r
  drm/panel: raspberrypi-touchscreen: Use the attach hook\r
  drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver\r
\r
 Documentation/gpu/drm-kms-helpers.rst         |  12 ++\r
 drivers/gpu/drm/bridge/panel.c                |   6 +\r
 drivers/gpu/drm/drm_bridge.c                  | 114 ++++++++++++-\r
 drivers/gpu/drm/drm_of.c                      |   3 +\r
 drivers/gpu/drm/drm_panel.c                   |  47 ++++++\r
 .../drm/panel/panel-raspberrypi-touchscreen.c | 158 +++++++++---------\r
 drivers/gpu/drm/vc4/vc4_drv.c                 |   2 +\r
 drivers/gpu/drm/vc4/vc4_dsi.c                 |  53 +++---\r
 include/drm/drm_bridge.h                      |   2 +\r
 include/drm/drm_panel.h                       |  27 +++\r
 10 files changed, 303 insertions(+), 121 deletions(-)\r
\r
-- \r
2.31.1\r
\r

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-08-20 16:52 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-28 13:32 [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 1/8] Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 2/8] drm/bridge: Add a function to abstract away panels Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 3/8] drm/bridge: Add documentation sections Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 4/8] drm/bridge: Document the probe issue with MIPI-DSI bridges Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 5/8] drm/panel: Create attach and detach callbacks Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 6/8] drm/vc4: dsi: Switch to drm_of_get_bridge Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 7/8] drm/panel: raspberrypi-touchscreen: Use the attach hook Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 8/8] drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Maxime Ripard
     [not found] ` <CGME20210804140941eucas1p2d4d4ec491074530c714797523aec05ea@eucas1p2.samsung.com>
2021-08-04 14:09   ` [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent a.hajda
2021-08-09  8:00     ` Jagan Teki
2021-08-09 12:03       ` Andrzej Hajda
2021-08-20 16:49     ` Maxime Ripard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).