linux-kernel - Re: [PATCH v2] drm/bridge: adv7511: Attach to DSI host at probe time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7b7736ed-6cf1-d7ab-ae03-83b70b351261@samsung.com>
Date:   Wed, 28 Aug 2019 09:05:23 +0200
From:   Andrzej Hajda <a.hajda@...sung.com>
To:     John Stultz <john.stultz@...aro.org>,
        Matt Redfearn <matt.redfearn@...nci.com>
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 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.


Regards

Andrzej



>
> thanks
> -john
>
>