Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Maxime Ripard <maxime@cerno.tech>
To:     Jonas Karlman <jonas@kwiboo.se>, Sam Ravnborg <sam@ravnborg.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        Daniel Vetter <daniel.vetter@intel.com>,
        David Airlie <airlied@linux.ie>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Maxime Ripard <maxime@cerno.tech>,
        Neil Armstrong <narmstrong@baylibre.com>,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        Robert Foss <robert.foss@linaro.org>,
        Andrzej Hajda <a.hajda@samsung.com>
Cc:     linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: [PATCH v3 0/8] drm/bridge: Make panel and bridge probe order consistent
Date:   Mon, 23 Aug 2021 10:47:15 +0200
Message-Id: <20210823084723.1493908-1-maxime@cerno.tech>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,=0D
=0D
We've encountered an issue with the RaspberryPi DSI panel that prevented th=
e=0D
whole display driver from probing.=0D
=0D
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:=
=0D
Only register our component once a DSI device is attached"), but the basic =
idea=0D
is that since the panel is probed through i2c, there's no synchronization=0D
between its probe and the registration of the MIPI-DSI host it's attached t=
o.=0D
=0D
We initially moved the component framework registration to the MIPI-DSI Hos=
t=0D
attach hook to make sure we register our component only when we have a DSI=
=0D
device attached to our MIPI-DSI host, and then use lookup our DSI device in=
 our=0D
bind hook.=0D
=0D
However, all the DSI bridges controlled through i2c are only registering th=
eir=0D
associated DSI device in their bridge attach hook, meaning with our change=
=0D
above, we never got that far, and therefore ended up in the same situation =
than=0D
the one we were trying to fix for panels.=0D
=0D
The best practice to avoid those issues is to register its functions only a=
fter=0D
all its dependencies are live. We also shouldn't wait any longer than we sh=
ould=0D
to play nice with the other components that are waiting for us, so in our c=
ase=0D
that would mean moving the DSI device registration to the bridge probe.=0D
=0D
If the general approach is agreed upon, other bridge drivers will obviously=
 be=0D
converted.=0D
=0D
Let me know what you think,=0D
Maxime=0D
=0D
---=0D
=0D
Changes from v2:=0D
  - Changed the approach as suggested by Andrzej, and aligned the bridge on=
 the=0D
    panel this time.=0D
  - Fixed some typos=0D
=0D
Changes from v1:=0D
  - Change the name of drm_of_get_next function to drm_of_get_bridge=0D
  - Mention the revert of 87154ff86bf6 and squash the two patches that were=
=0D
    reverting that commit=0D
  - Add some documentation=0D
  - Make drm_panel_attach and _detach succeed when no callback is there=0D
=0D
Maxime Ripard (8):=0D
  drm/bridge: Add documentation sections=0D
  drm/bridge: Document the probe issue with MIPI-DSI bridges=0D
  drm/mipi-dsi: Create devm device registration=0D
  drm/mipi-dsi: Create devm device attachment=0D
  drm/bridge: ps8640: Switch to devm MIPI-DSI helpers=0D
  drm/bridge: ps8640: Register and attach our DSI device at probe=0D
  drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers=0D
  drm/bridge: sn65dsi83: Register and attach our DSI device at probe=0D
=0D
 Documentation/gpu/drm-kms-helpers.rst  | 12 ++++=0D
 drivers/gpu/drm/bridge/parade-ps8640.c | 97 ++++++++++++++------------=0D
 drivers/gpu/drm/bridge/ti-sn65dsi83.c  | 82 +++++++++++-----------=0D
 drivers/gpu/drm/drm_bridge.c           | 70 +++++++++++++++++--=0D
 drivers/gpu/drm/drm_mipi_dsi.c         | 81 +++++++++++++++++++++=0D
 include/drm/drm_mipi_dsi.h             |  4 ++=0D
 6 files changed, 256 insertions(+), 90 deletions(-)=0D
=0D
-- =0D
2.31.1=0D
=0D