[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <83dbc355-790a-3940-9fc3-fa9567d4c3bf@thinci.com>
Date: Thu, 29 Aug 2019 13:55:58 +0000
From: Matt Redfearn <matt.redfearn@...nci.com>
To: Andrzej Hajda <a.hajda@...sung.com>,
John Stultz <john.stultz@...aro.org>
CC: Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Neil Armstrong <narmstrong@...libre.com>,
Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Thierry Reding <thierry.reding@...il.com>,
David Airlie <airlied@...ux.ie>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Matthew Redfearn <matthew.redfearn@...nci.com>,
Sean Paul <seanpaul@...omium.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH v2] drm/bridge: adv7511: Attach to DSI host at probe time
On 28/08/2019 08:05, Andrzej Hajda wrote:
> On 27.08.2019 22:03, John Stultz wrote:
>> On Mon, Aug 19, 2019 at 3:27 PM John Stultz <john.stultz@...aro.org> wrote:
>>> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn <matt.redfearn@...nci.com> wrote:
>>>> In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
>>>> which attach to the DSI host via mipi_dsi_attach() at probe time, the
>>>> ADV7533 bridge device does not. Instead it defers this to the point that
>>>> the upstream device connects to its bridge via drm_bridge_attach().
>>>> The generic Synopsys MIPI DSI host driver does not register it's own
>>>> drm_bridge until the MIPI DSI has attached. But it does not call
>>>> drm_bridge_attach() on the downstream device until the upstream device
>>>> has attached. This leads to a chicken and the egg failure and the DRM
>>>> pipeline does not complete.
>>>> Since all other mipi_dsi_device drivers call mipi_dsi_attach() in
>>>> probe(), make the adv7533 mipi_dsi_device do the same. This ensures that
>>>> the Synopsys MIPI DSI host registers it's bridge such that it is
>>>> available for the upstream device to connect to.
>>>>
>>>> Signed-off-by: Matt Redfearn <matt.redfearn@...nci.com>
>>>>
>>>> ---
>>> As a heads up, I just did some testing on drm-misc-next and this patch
>>> seems to be breaking the HiKey board. On bootup, I'm seeing:
>>> [ 4.209615] adv7511 2-0039: 2-0039 supply avdd not found, using
>>> dummy regulator
>>> [ 4.217075] adv7511 2-0039: 2-0039 supply dvdd not found, using
>>> dummy regulator
>>> [ 4.224453] adv7511 2-0039: 2-0039 supply pvdd not found, using
>>> dummy regulator
>>> [ 4.231804] adv7511 2-0039: 2-0039 supply a2vdd not found, using
>>> dummy regulator
>>> [ 4.239242] adv7511 2-0039: 2-0039 supply v3p3 not found, using
>>> dummy regulator
>>> [ 4.246615] adv7511 2-0039: 2-0039 supply v1p2 not found, using
>>> dummy regulator
>>> [ 4.272970] adv7511 2-0039: failed to find dsi host
>>>
>>> over and over. The dummy regulator messages are normal, but usually
>>> [ 4.444315] kirin-drm f4100000.ade: bound f4107800.dsi (ops dsi_ops)
>>>
>>> Starts up right afterward.
>> Hey Matt, Andrzej,
>> I just wanted to follow up on this as this patch is breaking a
>> couple of boards. Any sense of what might be missing, or is this
>> something we should revert?
>>
>> I'm happy to test any patch ideas you have.
>
>
> I guess this is circular dependency issue:
>
> - adv waits for dsi-host, then it creates drm_bridge,
>
> - dsi-driver waits for drm_bridge, then it creates dsi host.
>
>
> The patch introduces proper order:
>
> - 1st we should register devices buses,
>
> - then we should wait for drm components.
>
>
> So the best solution would be to fix f4107800.dsi driver - it shouldn't
> look for drm_bridge in probe, instead it should register dsi_host, and
> in dsi host attach callback look for drm_bridge, then call component_add
> (if all required resources are gathered), see
> dw_mipi_dsi_rockchip_host_attach for example.
Hi all,
Sorry that my patch seems to have broken things. It was using the
generic synopsys dsi driver
(drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c) that I found the
circular dependency fixed by my patch.
It appears that the patch has broken things for the platform specific
synopsys dsi driver for Kirin. So another approach (though a lot more
work) would be to switch Kirin over to using the generic synopsys dsi
driver so that we have less redundancy in the tree.
Thanks,
Matt
>
>
> Regards
>
> Andrzej
>
>
>
>>
>> thanks
>> -john
>>
>>
>
Powered by blists - more mailing lists