[PATCH v6 0/6] drm: exynos: dsi: Convert drm bridge

[Marek Szyprowski]

Dear All,

On 07.04.2022 13:24, Marek Szyprowski wrote:
> On 31.03.2022 16:22, Robert Foss wrote:
>> On Fri, 25 Mar 2022 at 17:04, Adam Ford <aford173 at gmail.com> wrote:
>>> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski
>>> <m.szyprowski at samsung.com> wrote:
>>>> On 03.03.2022 17:36, Jagan Teki wrote:
>>>>> Updated series about drm bridge conversion of exynos dsi.
>>>>>
>>>>> Previous version can be accessible, here [1].
>>>>>
>>>>> Patch 1: tc358764 panel_bridge API
>>>>>
>>>>> Patch 2: connector reset
>>>>>
>>>>> Patch 3: bridge attach in MIC
>>>>>
>>>>> Patch 4: panel_bridge API
>>>>>
>>>>> Patch 5: bridge conversion
>>>>>
>>>>> Patch 6: atomic functions
>>>>>
>>>>>
>>>>>
>>>>> Any inputs?
>>>>
>>>> I'm really sorry for the delay on my side. I was really busy with 
>>>> other
>>>> things and I was not able to check the display of the boards with 
>>>> remote
>>>> access.
>>>>
>>>>
>>>> Finally, this patchset works properly on all my Exynos-based test 
>>>> systems:
>>>>
>>>> 1. Exynos4210 Trats with Samsung s6e8aa0 DSI panel
>>>>
>>>> 2. Exynos4412 Trats2 with Samsung s6e8aa0 DSI panel
>>>>
>>>> 3. Exynos5250 Arndale with TC358764 DSI-LVDS bridge and LVDS panel
>>>>
>>>> 4. Exynos5433 TM2e with Samsung s6e3hf2 DSI panel and internal Exynos
>>>> MIC bridge
>>>>
>>>>
>>>> I will post my acked-by and tested-by tags for each patch.
>>> Thank you so much!  I think a lot of people will celebrate when this
>>> gets approved and merged.  ;-)
>>>
>>>
>> Applied to drm-misc-next.
>
>
> Thanks for merging this. Today (once the patches landed in linux-next) 
> I found that there is one more issue left to fix.
>
> On the Exynos4210-based Trats board I get the following error:
>
> # ./modetest -c -Mexynos
> could not get connector 56: No such file or directory
> Segmentation fault
>
> #
>
> Surprisingly, all other boards, even Exynos4412-based Trats2 with 
> exactly the same DSI controller and panel works fine:
>
> # ./modetest -c -Mexynos
> Connectors:
> id      encoder status          name            size (mm) modes encoders
> 71      70      connected       DSI-1           58x103 1       70

This is related to the asynchronous DSI driver registration and DSI 
device probe.

If the DSI driver has been registered before the DRM component device 
bind, everything is fine: the DRM connector is created by 
panel_bridge_attach() and then that connector is registered to userspace 
by the drm_modeset_register_all() in the last steps of initializing the 
compound DRM device.

However, when DSI driver is not yet registered during the DRM component 
bind, the DRM device finishes registration without any connector 
('exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes' message). 
Then, when DSI driver gets registered, the connector is created by 
panel_brige_attach(), but there is no code, which would call 
drm_connector_register() to make it available for userspace.

Exactly the same issue has been earlier fixed by the commit deee3284cba3 
("drm/exynos/dsi: register connector if it is created after drm bind").

The following patch fixes this with the current code:

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index ff1c37b2e6e5..2165f38989f1 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -86,6 +86,9 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
         if (connector->funcs->reset)
                 connector->funcs->reset(connector);

+       if (bridge->dev->registered)
+               drm_connector_register(connector);
+
         return 0;
  }

If this is okay, I will send it as a proper patch, tagged as a fix for 
934aef885f9d ("drm: bridge: panel: Reset the connector state pointer").

> modes:
>         name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
>   720x1280 60 720 725 730 735 1280 1293 1295 1296 57153 flags: ; type: 
> preferred, driver
>   props:
>         1 EDID:
>                 flags: immutable blob
>                 blobs:
>
>                 value:
>         2 DPMS:
>                 flags: enum
>                 enums: On=0 Standby=1 Suspend=2 Off=3
>                 value: 0
>         5 link-status:
>                 flags: enum
>                 enums: Good=0 Bad=1
>                 value: 0
>         6 non-desktop:
>                 flags: immutable range
>                 values: 0 1
>                 value: 0
>         4 TILE:
>                 flags: immutable blob
>                 blobs:
>
>                 value:
>         20 CRTC_ID:
>                 flags: object
>                 value: 54
> 73      0       connected       HDMI-A-1        0x0 0       72
>   props:
>         1 EDID:
>                 flags: immutable blob
>                 blobs:
>
>                 value:
>         2 DPMS:
>                 flags: enum
>                 enums: On=0 Standby=1 Suspend=2 Off=3
>                 value: 0
>         5 link-status:
>                 flags: enum
>                 enums: Good=0 Bad=1
>                 value: 0
>         6 non-desktop:
>                 flags: immutable range
>                 values: 0 1
>                 value: 0
>         4 TILE:
>                 flags: immutable blob
>                 blobs:
>
>                 value:
>         20 CRTC_ID:
>                 flags: object
>                 value: 0
>
> (the only difference between Trats and Trats2 is the fact that Trats2 
> has also HDMI output implemented).
>
> It looks that something is missing in the connector initialization, 
> but I didn't dig enough into it. The emulated framebuffer is properly 
> registered and displayed on the panel.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland