From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Maxime Ripard <maxime@cerno.tech>,
Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Marek Vasut <marex@denx.de>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
Eric Anholt <eric@anholt.net>,
Tim Gover <tim.gover@raspberrypi.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Andrzej Hajda <a.hajda@samsung.com>,
bcm-kernel-feedback-list@broadcom.com,
linux-rpi-kernel@lists.infradead.org,
Phil Elwell <phil@raspberrypi.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached
Date: Sun, 20 Jun 2021 04:44:33 +0300 [thread overview]
Message-ID: <YM6dgVb12oITNfc0@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200707101912.571531-1-maxime@cerno.tech>
Hi Maxime,
I'm testing this, and I'm afraid it causes an issue with all the
I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83
driver at the moment, but other are affected the same way.
With this patch, the DSI component is only added when the DSI device is
attached to the host with mipi_dsi_attach(). In the ti-sn65dsi83 driver,
this happens in the bridge attach callback, which is called when the
bridge is attached by a call to drm_bridge_attach() in vc4_dsi_bind().
This creates a circular dependency, and the DRM/KMS device is never
created.
How should this be solved ? Dave, I think you have shown an interest in
the sn65dsi83 recently, any help would be appreciated. On a side note,
I've tested the ti-sn65dsi83 driver on a v5.10 RPi kernel, without much
success (on top of commit e1499baa0b0c I get a very weird frame rate -
147 fps of 99 fps instead of 60 fps - and nothing on the screen, and on
top of the latest v5.10 RPi branch, I get lock-related warnings at every
page flip), which is why I tried v5.12 and noticed this patch. Is it
worth trying to bring up the display on the v5.10 RPi kernel in parallel
to fixing the issue introduced in this patch, or is DSI known to be
broken there ?
On Tue, Jul 07, 2020 at 12:19:12PM +0200, Maxime Ripard wrote:
> If the DSI driver is the last to probe, component_add will try to run all
> the bind callbacks straight away and return the error code.
>
> However, since we depend on a power domain, we're pretty much guaranteed to
> be in that case on the BCM2711, and are just lucky on the previous SoCs
> since the v3d also depends on that power domain and is further in the probe
> order.
>
> In that case, the DSI host will not stick around in the system: the DSI
> bind callback will be executed, will not find any DSI device attached and
> will return EPROBE_DEFER, and we will then remove the DSI host and ask to
> be probed later on.
>
> But since that host doesn't stick around, DSI devices like the RaspberryPi
> touchscreen whose probe is not linked to the DSI host (unlike the usual DSI
> devices that will be probed through the call to mipi_dsi_host_register)
> cannot attach to the DSI host, and we thus end up in a situation where the
> DSI host cannot probe because the panel hasn't probed yet, and the panel
> cannot probe because the DSI host hasn't yet.
>
> In order to break this cycle, let's wait until there's a DSI device that
> attaches to the DSI host to register the component and allow to progress
> further.
>
> Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/vc4/vc4_dsi.c | 25 ++++++++-----------------
> 1 file changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index eaf276978ee7..19aab4e7e209 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -1246,10 +1246,12 @@ static ssize_t vc4_dsi_host_transfer(struct mipi_dsi_host *host,
> return ret;
> }
>
> +static const struct component_ops vc4_dsi_ops;
> static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
> struct mipi_dsi_device *device)
> {
> struct vc4_dsi *dsi = host_to_dsi(host);
> + int ret;
>
> dsi->lanes = device->lanes;
> dsi->channel = device->channel;
> @@ -1284,6 +1286,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
> return 0;
> }
>
> + ret = component_add(&dsi->pdev->dev, &vc4_dsi_ops);
> + if (ret) {
> + mipi_dsi_host_unregister(&dsi->dsi_host);
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -1662,7 +1670,6 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct vc4_dsi *dsi;
> - int ret;
>
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> if (!dsi)
> @@ -1670,26 +1677,10 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
> dev_set_drvdata(dev, dsi);
>
> dsi->pdev = pdev;
> -
> - /* Note, the initialization sequence for DSI and panels is
> - * tricky. The component bind above won't get past its
> - * -EPROBE_DEFER until the panel/bridge probes. The
> - * panel/bridge will return -EPROBE_DEFER until it has a
> - * mipi_dsi_host to register its device to. So, we register
> - * the host during pdev probe time, so vc4 as a whole can then
> - * -EPROBE_DEFER its component bind process until the panel
> - * successfully attaches.
> - */
> dsi->dsi_host.ops = &vc4_dsi_host_ops;
> dsi->dsi_host.dev = dev;
> mipi_dsi_host_register(&dsi->dsi_host);
>
> - ret = component_add(&pdev->dev, &vc4_dsi_ops);
> - if (ret) {
> - mipi_dsi_host_unregister(&dsi->dsi_host);
> - return ret;
> - }
> -
> return 0;
> }
>
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2021-06-20 1:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 10:19 [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached Maxime Ripard
2020-07-07 16:48 ` Eric Anholt
2020-07-09 7:33 ` Maxime Ripard
2021-06-20 1:44 ` Laurent Pinchart [this message]
2021-06-20 14:29 ` Dave Stevenson
2021-06-20 18:42 ` Laurent Pinchart
2021-06-20 22:48 ` Laurent Pinchart
2021-06-21 11:49 ` Dave Stevenson
2021-06-21 12:56 ` Laurent Pinchart
2021-06-21 13:09 ` Laurent Pinchart
2021-06-21 13:59 ` Laurent Pinchart
2021-07-02 16:47 ` Laurent Pinchart
2021-07-02 17:44 ` Dave Stevenson
2021-07-02 20:18 ` Laurent Pinchart
2021-07-05 15:50 ` Dave Stevenson
2021-06-21 14:11 ` Jagan Teki
2021-06-21 14:14 ` Laurent Pinchart
2021-06-21 17:24 ` Jagan Teki
2021-06-21 16:06 ` Maxime Ripard
2021-06-21 16:05 ` Maxime Ripard
2021-06-21 16:18 ` Dave Stevenson
2021-06-28 10:11 ` 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=YM6dgVb12oITNfc0@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=marex@denx.de \
--cc=maxime@cerno.tech \
--cc=nsaenzjulienne@suse.de \
--cc=phil@raspberrypi.com \
--cc=tim.gover@raspberrypi.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox