[PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list

[Andrzej Hajda]

On 23.12.2019 10:55, Marek Szyprowski wrote:
> Hi Boris,
>
> On 16.12.2019 16:25, Boris Brezillon wrote:
>> On Mon, 16 Dec 2019 16:02:36 +0100
>> Marek Szyprowski <m.szyprowski at samsung.com> wrote:
>>> Hi Boris,
>>>
>>> On 16.12.2019 15:55, Boris Brezillon wrote:
>>>> On Mon, 16 Dec 2019 14:54:25 +0100
>>>> Marek Szyprowski <m.szyprowski at samsung.com> wrote:
>>>>> On 03.12.2019 15:15, Boris Brezillon wrote:
>>>>>> So that each element in the chain can easily access its predecessor.
>>>>>> This will be needed to support bus format negotiation between elements
>>>>>> of the bridge chain.
>>>>>>
>>>>>> Signed-off-by: Boris Brezillon <boris.brezillon at collabora.com>
>>>>>> Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
>>>>>> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>>>>> I've noticed that this patch got merged to linux-next as commit
>>>>> 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of
>>>>> Samsung Exynos5250-based Arndale board. Booting stops after following
>>>>> messages:
>>>>>
>>>>> [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations
>>>>> exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops)
>>>>> exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops)
>>>>> exynos-drm exynos-drm: bound 14500000.dsi (ops exynos_dsi_component_ops)
>>>>> exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_component_ops)
>>>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>>> [drm] No driver support for vblank timestamp query.
>>>>> [drm] Cannot find any crtc or sizes
>>>>> [drm] Cannot find any crtc or sizes
>>>>> [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
>>>>>
>>>>> I will try to debug this and provide more information soon.
>>>>>   
>>>> Can you try with this diff applied?
>>> This patch doesn't change anything.
>> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain
>> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and
>> after the list_splice_init() call?
> encoder->bridge_chain contains only one element. dsi->drive_chain is empty.
>
> Replacing that list_splice() with INIT_LIST_HEAD(&encoder->bridge_chain) 
> fixed the boot issue. It looks that this is related with the way the 
> Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej 
> will give a bit more detailed comment and spread some light on this.


Hi Marek, Boris,


I have not followed latest patches due to high work load, my bad. Marek
thanks from pointing

About ExynosDSI bridge handling:

The order of calling encoder, bridge (and consequently panel) ops
enforced by DRM core (bridge->pre_enable, encoder->enable,
bridge->enable) does not fit to ExynosDSI hardware initialization
sequence, if I remember correctly it does not fit to whole MIPI DSI
standard (I think similar situation is with eDP). As a result DSI
drivers must use some ugly workarounds, rely on HW properly coping with
incorrect sequences, or, as in case of ExynosDSI driver, just avoid
using encoder->bridge chaining and call bridge ops by itself when suitable.

So proper patch converting to double-linked list should not try to
splice ExynosDSI private bridge list with with encoder's, encoder's list
should be always empty, as Marek suggested.


Regards

Andrzej


>
> I can send a formal patch fixing this if You want.
>
>>>> --->8---
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> index 3955f84dc893..118ecedc7621 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> @@ -1523,7 +1523,7 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>>>>           if (out_bridge) {
>>>>                   drm_bridge_attach(encoder, out_bridge, NULL);
>>>>                   dsi->out_bridge = out_bridge;
>>>> -               list_splice(&encoder->bridge_chain, &dsi->bridge_chain);
>>>> +               list_splice_init(&encoder->bridge_chain, &dsi->bridge_chain);
>>>>           } else {
>>>>                   int ret = exynos_dsi_create_connector(encoder);
>>>>    
>>>> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
>>>> index 6c5b80ad6154..e1378d48210f 100644
>>>> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
>>>> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
>>>> @@ -1613,7 +1613,7 @@ static int vc4_dsi_bind(struct device *dev, struct device *master, void *data)
>>>>            * from our driver, since we need to sequence them within the
>>>>            * encoder's enable/disable paths.
>>>>            */
>>>> -       list_splice(&dsi->encoder->bridge_chain, &dsi->bridge_chain);
>>>> +       list_splice_init(&dsi->encoder->bridge_chain, &dsi->bridge_chain);
>>>>    
>>>>           if (dsi->port == 0)
>>>>                   vc4_debugfs_add_regset32(drm, "dsi0_regs", &dsi->regset);
>>>> @@ -1639,7 +1639,7 @@ static void vc4_dsi_unbind(struct device *dev, struct device *master,
>>>>            * Restore the bridge_chain so the bridge detach procedure can happen
>>>>            * normally.
>>>>            */
>>>> -       list_splice(&dsi->bridge_chain, &dsi->encoder->bridge_chain);
>>>> +       list_splice_init(&dsi->bridge_chain, &dsi->encoder->bridge_chain);
>>>>           vc4_dsi_encoder_destroy(dsi->encoder);
>>>>    
>>>>           if (dsi->port == 1)
>>>>
>>>>
> Best regards