From: Maxime Ripard <maxime@cerno.tech> To: Robert Foss <robert.foss@linaro.org>, Andrzej Hajda <a.hajda@samsung.com>, Daniel Vetter <daniel.vetter@intel.com>, David Airlie <airlied@linux.ie>, Sam Ravnborg <sam@ravnborg.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, Maxime Ripard <maxime@cerno.tech>, Neil Armstrong <narmstrong@baylibre.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Thierry Reding <thierry.reding@gmail.com>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 00/10] drm/bridge: Make panel and bridge probe order consistent Date: Tue, 20 Jul 2021 15:45:15 +0200 [thread overview] Message-ID: <20210720134525.563936-1-maxime@cerno.tech> (raw) Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. Since the RaspberryPi panel is the only driver in that situation, whereas it seems like there's a consensus in bridge drivers, it makes more sense to try to mimic the bridge pattern in the panel driver. However, panels don't have an attach hook, and adding more panel hooks would lead to more path to maintain in each and every driver, while the general push is towards bridges. We also have to make sure that each and every DSI host and device driver behaves the same in order to have expectations to rely on. The solution I'm proposing is thus done in several steps: - We get rid of the initial patch to make sure we support the bridge case, and not the odd-panel one. - Add a function that returns a bridge from a DT node, reducing the amount of churn in each and every driver and making it a real incentive to not care about panels in display drivers but only bridges. - Add an attach and detach hook into the panel operations, and make it called automatically by the DRM panel bridge. - Convert the VC4 DSI host to this new bridge function, and the RaspberryPi Panel to the new attach and detach hooks. If the general approach is agreed upon, other drivers will obviously be converted to drm_of_get_next. Let me know what you think, Maxime Maxime Ripard (10): Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" drm/bridge: Add a function to abstract away panels drm/bridge: Add documentation sections drm/bridge: Document the probe issue with MIPI-DSI bridges drm/panel: Create attach and detach callbacks drm/bridge: panel: Call attach and detach for the panel drm/vc4: dsi: Switch to drm_of_get_next drm/panel: raspberrypi-touchscreen: Prevent double-free drm/panel: raspberrypi-touchscreen: Use the attach hook drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/bridge/panel.c | 4 + drivers/gpu/drm/drm_bridge.c | 134 ++++++++++++++- drivers/gpu/drm/drm_of.c | 3 + drivers/gpu/drm/drm_panel.c | 20 +++ .../drm/panel/panel-raspberrypi-touchscreen.c | 159 +++++++++--------- drivers/gpu/drm/vc4/vc4_drv.c | 2 + drivers/gpu/drm/vc4/vc4_dsi.c | 53 +++--- include/drm/drm_bridge.h | 2 + include/drm/drm_panel.h | 6 + 10 files changed, 273 insertions(+), 122 deletions(-) -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech> To: Robert Foss <robert.foss@linaro.org>, Andrzej Hajda <a.hajda@samsung.com>, Daniel Vetter <daniel.vetter@intel.com>, David Airlie <airlied@linux.ie>, Sam Ravnborg <sam@ravnborg.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, Maxime Ripard <maxime@cerno.tech>, Neil Armstrong <narmstrong@baylibre.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Thierry Reding <thierry.reding@gmail.com>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: [PATCH 00/10] drm/bridge: Make panel and bridge probe order consistent Date: Tue, 20 Jul 2021 15:45:15 +0200 [thread overview] Message-ID: <20210720134525.563936-1-maxime@cerno.tech> (raw) Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. Since the RaspberryPi panel is the only driver in that situation, whereas it seems like there's a consensus in bridge drivers, it makes more sense to try to mimic the bridge pattern in the panel driver. However, panels don't have an attach hook, and adding more panel hooks would lead to more path to maintain in each and every driver, while the general push is towards bridges. We also have to make sure that each and every DSI host and device driver behaves the same in order to have expectations to rely on. The solution I'm proposing is thus done in several steps: - We get rid of the initial patch to make sure we support the bridge case, and not the odd-panel one. - Add a function that returns a bridge from a DT node, reducing the amount of churn in each and every driver and making it a real incentive to not care about panels in display drivers but only bridges. - Add an attach and detach hook into the panel operations, and make it called automatically by the DRM panel bridge. - Convert the VC4 DSI host to this new bridge function, and the RaspberryPi Panel to the new attach and detach hooks. If the general approach is agreed upon, other drivers will obviously be converted to drm_of_get_next. Let me know what you think, Maxime Maxime Ripard (10): Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" drm/bridge: Add a function to abstract away panels drm/bridge: Add documentation sections drm/bridge: Document the probe issue with MIPI-DSI bridges drm/panel: Create attach and detach callbacks drm/bridge: panel: Call attach and detach for the panel drm/vc4: dsi: Switch to drm_of_get_next drm/panel: raspberrypi-touchscreen: Prevent double-free drm/panel: raspberrypi-touchscreen: Use the attach hook drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/bridge/panel.c | 4 + drivers/gpu/drm/drm_bridge.c | 134 ++++++++++++++- drivers/gpu/drm/drm_of.c | 3 + drivers/gpu/drm/drm_panel.c | 20 +++ .../drm/panel/panel-raspberrypi-touchscreen.c | 159 +++++++++--------- drivers/gpu/drm/vc4/vc4_drv.c | 2 + drivers/gpu/drm/vc4/vc4_dsi.c | 53 +++--- include/drm/drm_bridge.h | 2 + include/drm/drm_panel.h | 6 + 10 files changed, 273 insertions(+), 122 deletions(-) -- 2.31.1
next reply other threads:[~2021-07-20 13:51 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-20 13:45 Maxime Ripard [this message] 2021-07-20 13:45 ` [PATCH 00/10] drm/bridge: Make panel and bridge probe order consistent Maxime Ripard 2021-07-20 13:45 ` [PATCH 01/10] Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 13:45 ` [PATCH 02/10] drm/bridge: Add a function to abstract away panels Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 17:34 ` Sam Ravnborg 2021-07-22 7:49 ` Jagan Teki 2021-07-22 7:49 ` Jagan Teki 2021-07-20 13:45 ` [PATCH 03/10] drm/bridge: Add documentation sections Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 19:51 ` Sam Ravnborg 2021-07-20 13:45 ` [PATCH 04/10] drm/bridge: Document the probe issue with MIPI-DSI bridges Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-21 12:05 ` Daniel Vetter 2021-07-21 12:05 ` Daniel Vetter 2021-07-21 12:06 ` Daniel Vetter 2021-07-26 15:16 ` Maxime Ripard 2021-07-27 9:20 ` Daniel Vetter 2021-07-27 9:20 ` Daniel Vetter 2021-07-28 13:27 ` Maxime Ripard 2021-07-27 9:42 ` Jagan Teki 2021-07-27 9:42 ` Jagan Teki 2021-07-28 13:35 ` Maxime Ripard 2021-07-28 13:35 ` Maxime Ripard 2021-08-05 12:19 ` Jagan Teki 2021-08-05 12:19 ` Jagan Teki 2021-07-20 13:45 ` [PATCH 05/10] drm/panel: Create attach and detach callbacks Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 19:53 ` Sam Ravnborg 2021-07-22 7:53 ` Jagan Teki 2021-07-22 7:53 ` Jagan Teki 2021-07-20 13:45 ` [PATCH 06/10] drm/bridge: panel: Call attach and detach for the panel Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 19:56 ` Sam Ravnborg 2021-07-20 13:45 ` [PATCH 07/10] drm/vc4: dsi: Switch to drm_of_get_next Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 13:45 ` [PATCH 08/10] drm/panel: raspberrypi-touchscreen: Prevent double-free Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 17:19 ` Sam Ravnborg 2021-07-22 9:38 ` Maxime Ripard 2021-07-22 9:38 ` Maxime Ripard 2021-07-20 13:45 ` [PATCH 09/10] drm/panel: raspberrypi-touchscreen: Use the attach hook Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard 2021-07-20 13:45 ` [PATCH 10/10] drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Maxime Ripard 2021-07-20 13:45 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210720134525.563936-1-maxime@cerno.tech \ --to=maxime@cerno.tech \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jernej.skrabec@gmail.com \ --cc=jonas@kwiboo.se \ --cc=linux-kernel@vger.kernel.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=narmstrong@baylibre.com \ --cc=robert.foss@linaro.org \ --cc=sam@ravnborg.org \ --cc=thierry.reding@gmail.com \ --cc=tzimmermann@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.