Message ID | 20220303163654.3381470-1-jagan@amarulasolutions.com |
---|---|
Headers | show |
Series |
|
Related | show |
Hi Jagan, Am 03.03.22 um 17:36 schrieb Jagan Teki: > 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 > > [1] https://patchwork.amarulasolutions.com/cover/1839 > > Any inputs? Thanks for your efforts. I didn't follow the whole history, but I'm looking forward and hope to see upstream support for the i.MX8MM DSIM in the not too distant future. Can you give me a short update about the state of this patchset? Are there still any major obstacles? I can't help with testing on Exynos, but if you have the matching follow-up patches for i.MX8MM support somewhere around I could do some tests with those on i.MX8MM. Thanks Frieder
Hi Frieder, On Wed, Mar 9, 2022 at 6:54 PM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > > Hi Jagan, > > Am 03.03.22 um 17:36 schrieb Jagan Teki: > > 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 > > > > [1] https://patchwork.amarulasolutions.com/cover/1839 > > > > Any inputs? > > Thanks for your efforts. I didn't follow the whole history, but I'm > looking forward and hope to see upstream support for the i.MX8MM DSIM in > the not too distant future. > > Can you give me a short update about the state of this patchset? Are > there still any major obstacles? > > I can't help with testing on Exynos, but if you have the matching > follow-up patches for i.MX8MM support somewhere around I could do some > tests with those on i.MX8MM. Unfortunately, it is getting slow due to existing exynos dsi drivers. Idea is to push exynos and then move the bridge as per Mailing-list discussion. I have initial series to support i.MX8MM on linux-next [1] which is working on my setup. However I'm waiting for this series to move further to send those on the mailing list. Indeed I'm solely relaying on Marek testing to move further as I too don't have Exynos hardware to validate. [1] https://github.com/openedev/kernel/tree/imx8mm-dsi Thanks, Jagan.
Hi Jagan, Am 09.03.22 um 15:01 schrieb Jagan Teki: > Hi Frieder, > > On Wed, Mar 9, 2022 at 6:54 PM Frieder Schrempf > <frieder.schrempf@kontron.de> wrote: >> >> Hi Jagan, >> >> Am 03.03.22 um 17:36 schrieb Jagan Teki: >>> 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 >>> >>> [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1839&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7Cc99f637dd67444dfc38208da01d55963%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637824313083236643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qF5bVwelZ35cQQygW3PvPUZkQlyFalUDsyDVjDnngiU%3D&reserved=0 >>> >>> Any inputs? >> >> Thanks for your efforts. I didn't follow the whole history, but I'm >> looking forward and hope to see upstream support for the i.MX8MM DSIM in >> the not too distant future. >> >> Can you give me a short update about the state of this patchset? Are >> there still any major obstacles? >> >> I can't help with testing on Exynos, but if you have the matching >> follow-up patches for i.MX8MM support somewhere around I could do some >> tests with those on i.MX8MM. > > Unfortunately, it is getting slow due to existing exynos dsi drivers. > Idea is to push exynos and then move the bridge as per Mailing-list > discussion. I have initial series to support i.MX8MM on linux-next [1] > which is working on my setup. However I'm waiting for this series to > move further to send those on the mailing list. Indeed I'm solely > relaying on Marek testing to move further as I too don't have Exynos > hardware to validate. Thanks for the status update. Let's hope Marek or others with access to the hardware can provide further testing. And thanks for providing the git tree for i.MX8MM. I will try to do some tests on our hardware. Thanks Frieder
Am 10.03.22 um 14:03 schrieb Frieder Schrempf: > Hi Jagan, > > Am 09.03.22 um 15:01 schrieb Jagan Teki: >> Hi Frieder, >> >> On Wed, Mar 9, 2022 at 6:54 PM Frieder Schrempf >> <frieder.schrempf@kontron.de> wrote: >>> >>> Hi Jagan, >>> >>> Am 03.03.22 um 17:36 schrieb Jagan Teki: >>>> 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 >>>> >>>> [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1839&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7Cc99f637dd67444dfc38208da01d55963%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637824313083236643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qF5bVwelZ35cQQygW3PvPUZkQlyFalUDsyDVjDnngiU%3D&reserved=0 >>>> >>>> Any inputs? >>> >>> Thanks for your efforts. I didn't follow the whole history, but I'm >>> looking forward and hope to see upstream support for the i.MX8MM DSIM in >>> the not too distant future. >>> >>> Can you give me a short update about the state of this patchset? Are >>> there still any major obstacles? >>> >>> I can't help with testing on Exynos, but if you have the matching >>> follow-up patches for i.MX8MM support somewhere around I could do some >>> tests with those on i.MX8MM. >> >> Unfortunately, it is getting slow due to existing exynos dsi drivers. >> Idea is to push exynos and then move the bridge as per Mailing-list >> discussion. I have initial series to support i.MX8MM on linux-next [1] >> which is working on my setup. However I'm waiting for this series to >> move further to send those on the mailing list. Indeed I'm solely >> relaying on Marek testing to move further as I too don't have Exynos >> hardware to validate. > > Thanks for the status update. Let's hope Marek or others with access to > the hardware can provide further testing. > > And thanks for providing the git tree for i.MX8MM. I will try to do some > tests on our hardware. Sorry, forgot to say that if you could cc me on future iterations of this patchset and the upcoming i.MX8MM patches, that would be great, thanks!
On Wed, Mar 9, 2022 at 6:01 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > Hi Frieder, > > On Wed, Mar 9, 2022 at 6:54 PM Frieder Schrempf > <frieder.schrempf@kontron.de> wrote: > > > > Hi Jagan, > > > > Am 03.03.22 um 17:36 schrieb Jagan Teki: > > > 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 > > > > > > [1] https://patchwork.amarulasolutions.com/cover/1839 > > > > > > Any inputs? > > > > Thanks for your efforts. I didn't follow the whole history, but I'm > > looking forward and hope to see upstream support for the i.MX8MM DSIM in > > the not too distant future. > > > > Can you give me a short update about the state of this patchset? Are > > there still any major obstacles? > > > > I can't help with testing on Exynos, but if you have the matching > > follow-up patches for i.MX8MM support somewhere around I could do some > > tests with those on i.MX8MM. > > Unfortunately, it is getting slow due to existing exynos dsi drivers. > Idea is to push exynos and then move the bridge as per Mailing-list > discussion. I have initial series to support i.MX8MM on linux-next [1] > which is working on my setup. However I'm waiting for this series to > move further to send those on the mailing list. Indeed I'm solely > relaying on Marek testing to move further as I too don't have Exynos > hardware to validate. > > [1] https://github.com/openedev/kernel/tree/imx8mm-dsi > > Thanks, > Jagan. Marek, Have you had any time to test Jagan's latest series? There are several of us waiting for the exynos series so as to gain support for imx8m MIPI DSI on top of it. What hardware is required to test this and where can it be found? Best regards, Tim
Hi Jagan, 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. > Jagan. > > Jagan Teki (6): > drm: bridge: tc358764: Use drm panel_bridge API > drm: bridge: panel: Reset the connector state pointer > exynos: drm: dsi: Attach in_bridge in MIC driver > drm: exynos: dsi: Use drm panel_bridge API > drm: exynos: dsi: Convert to bridge driver > drm: exynos: dsi: Switch to atomic funcs > > drivers/gpu/drm/bridge/panel.c | 3 + > drivers/gpu/drm/bridge/tc358764.c | 104 +--------- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 241 ++++++------------------ > drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +++ > 4 files changed, 93 insertions(+), 277 deletions(-) > Best regards
On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi Jagan, > > 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. ;-) adam > > > > Jagan. > > > > Jagan Teki (6): > > drm: bridge: tc358764: Use drm panel_bridge API > > drm: bridge: panel: Reset the connector state pointer > > exynos: drm: dsi: Attach in_bridge in MIC driver > > drm: exynos: dsi: Use drm panel_bridge API > > drm: exynos: dsi: Convert to bridge driver > > drm: exynos: dsi: Switch to atomic funcs > > > > drivers/gpu/drm/bridge/panel.c | 3 + > > drivers/gpu/drm/bridge/tc358764.c | 104 +--------- > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 241 ++++++------------------ > > drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +++ > > 4 files changed, 93 insertions(+), 277 deletions(-) > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >
On Fri, 25 Mar 2022 at 17:04, Adam Ford <aford173@gmail.com> wrote: > > On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > > > Hi Jagan, > > > > 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.
Dear All, On 31.03.2022 16:22, Robert Foss wrote: > On Fri, 25 Mar 2022 at 17:04, Adam Ford <aford173@gmail.com> wrote: >> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski >> <m.szyprowski@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 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
Hi Marek, On Thu, Apr 7, 2022 at 4:54 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Dear All, > > On 31.03.2022 16:22, Robert Foss wrote: > > On Fri, 25 Mar 2022 at 17:04, Adam Ford <aford173@gmail.com> wrote: > >> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski > >> <m.szyprowski@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 > 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. Can you please share the full dmesg? Thanks, Jagan.
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@gmail.com> wrote: >>> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski >>> <m.szyprowski@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