| Message ID | 20220504114021.33265-1-jagan@amarulasolutions.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Hello Jagan, thanks for the second version of this patchset. Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > This series supports common bridge support for Samsung MIPI DSIM > which is used in Exynos and i.MX8MM SoC's. > > Previous v1 can be available here [1]. > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > On, summary this patch-set break the entire DSIM driver into > - platform specific glue code for platform ops, component_ops. > - common bridge driver which handle platform glue init and invoke. > > Patch 0000: Samsung DSIM bridge > > Patch 0001: Common lookup code for OF-graph or child > > Patch 0002: platform init flag via driver_data > > Patch 0003/10: bridge fixes, atomic API's > > Patch 0011: document fsl,imx8mm-mipi-dsim > > Patch 0012: add i.MX8MM DSIM support > > Tested in Engicam i.Core MX8M Mini SoM. > > Anyone interested, please have a look on this repo [2] > > [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v2 > [1] > https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.184583-> 1-jagan@amarulasolutions.com/ > > Any inputs? I was able to get my LVDS display running using this driver and an LVDS bridge. Actually my setup is similar to yours. My chain is like this: MIPI-DSI -> sn65dsi83 -> LVDS panel I noticed some things though: My setup only works if I use less than 4 lanes. See [1]. When using 4 lanes the image is flickering, but the content is "visible". Your DT has only 2 lanes configured, do you have the possibility to use 4 lanes? I have no idea how to tackle this. It might be the DSIM side or the bridge side. Apparently the downstream kernel from NXP supports 4 lanes, if I can trust the config. I have no way to verify this though. Another thing is I get the following warning > sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check output bridge driver. Falling back to SPWG24. This seems to be caused by a wrong bridge chain. Using commit 81e80429 at [2] I get the following output: > bridge chain: /soc@0/bus@30800000/i2c@30a40000/dsi-lvds-bridge@2d -> / panel_lvds0 -> /soc@0/bus@32c00000/dsi@32e10000 -> Which seems weird. I would have expected something like dsi@32e10000 -> dsi-lvds-bridge@2d -> panel_lvds0 Do you happen to see somthing similar? But this is completely unrelated to your patchset though. Also unloading the samsung_dsim driver raises a regulator warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 381 at drivers/regulator/core.c:2275 _regulator_put.part. 0+0x38/0x40 Modules linked in: caam_jr caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes hantro_vpu(C) v4l2_vp9 v4l2_h264 snd_soc_ fsl_asoc_card crct10dif_ce snd_soc_tlv320aic32x4_spi videobuf2_dma_contig phy_fsl_imx8m_pcie v4l2_mem2mem samsung_dsim(-) snd_soc_tlv 320aic32x4_i2c snd_soc_tlv320aic32x4 caam error imx8mm_thermal imx_sdma pwm_beeper fuse ipv6 CPU: 2 PID: 381 Comm: modprobe Tainted: G C 5.18.0-rc5- next-20220504+ #204 03c84d7b1600b734091c3159e797071c8f65061c Hardware name: TQ-Systems GmbH i.MX8MM TQMa8MxML on MBa8Mx (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _regulator_put.part.0+0x38/0x40 lr : regulator_bulk_free+0x58/0x80 sp : ffff80000aeb3af0 x29: ffff80000aeb3af0 x28: ffff00000360bb00 x27: 0000000000000000 x26: ffff800009bad438 x25: ffff000000276890 x24: 0000000000000009 x23: ffff00000360bb00 x22: ffff000003543268 x21: ffff800009b85280 x20: ffff000005587800 x19: ffff000003543238 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 6d3d4d4554535953 x14: 42555300302e6973 x13: 4553003338697364 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000ab0 x9 : ffff80000aeb38f0 x8 : ffff00000360c610 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff8000092dc468 x4 : ffff00000360bb00 x3 : 0000000000000000 x2 : ffff00000360bb00 x1 : 0000000000000001 x0 : ffff000005587800 Call trace: _regulator_put.part.0+0x38/0x40 regulator_bulk_free+0x58/0x80 devm_regulator_bulk_release+0x18/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 device_release_driver_internal+0x214/0x2b4 driver_detach+0x4c/0xe0 bus_remove_driver+0x68/0x120 driver_unregister+0x2c/0x5c platform_driver_unregister+0x10/0x20 samsung_mipi_dsim_exit+0x18/0xd20 [samsung_dsim f08bbdb06ba3e4aef07da9615e8193297aa99358] __do_sys_delete_module.constprop.0+0x134/0x1e4 __arm64_sys_delete_module+0x10/0x1c invoke_syscall+0x6c/0xf0 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x24/0x30 el0_svc+0x3c/0xfc el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c ---[ end trace 0000000000000000 ]--- Best regards, Alexander [1] https://github.com/tq-steina/linux/blob/imx8mm-dsi-lvds/arch/arm64/boot/ dts/freescale/imx8mm-tqma8mqml-mba8mx-lvds.dts#L45-L46 [2] https://github.com/tq-steina/linux/commit/ 81e80429341cd0a4f119ec9cf50839498915443b
On Thu, May 5, 2022 at 12:57 PM Alexander Stein <alexander.stein@ew.tq-group.com> wrote: > > Hello Jagan, > > thanks for the second version of this patchset. > > Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > > This series supports common bridge support for Samsung MIPI DSIM > > which is used in Exynos and i.MX8MM SoC's. > > > > Previous v1 can be available here [1]. > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > On, summary this patch-set break the entire DSIM driver into > > - platform specific glue code for platform ops, component_ops. > > - common bridge driver which handle platform glue init and invoke. > > > > Patch 0000: Samsung DSIM bridge > > > > Patch 0001: Common lookup code for OF-graph or child > > > > Patch 0002: platform init flag via driver_data > > > > Patch 0003/10: bridge fixes, atomic API's > > > > Patch 0011: document fsl,imx8mm-mipi-dsim > > > > Patch 0012: add i.MX8MM DSIM support > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > Anyone interested, please have a look on this repo [2] > > > > [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v2 > > [1] > > https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.184583-> 1-jagan@amarulasolutions.com/ > > > > Any inputs? > > I was able to get my LVDS display running using this driver and an LVDS > bridge. Actually my setup is similar to yours. My chain is like this: > MIPI-DSI -> sn65dsi83 -> LVDS panel > I noticed some things though: > My setup only works if I use less than 4 lanes. See [1]. When using 4 lanes > the image is flickering, but the content is "visible". Your DT has only 2 > lanes configured, do you have the possibility to use 4 lanes? I have no idea > how to tackle this. It might be the DSIM side or the bridge side. > Apparently the downstream kernel from NXP supports 4 lanes, if I can trust the > config. I have no way to verify this though. What is dsi_lvds_bridge node? have you added your dts changes on top of imx8mm-dsi-v2 branch I'm pointing it. I will check 4 lanes and let you know. > > Another thing is I get the following warning > > sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check output > bridge driver. Falling back to SPWG24. This couldn't be much affected but will fix it. > > This seems to be caused by a wrong bridge chain. Using commit 81e80429 at [2] > I get the following output: > > bridge chain: /soc@0/bus@30800000/i2c@30a40000/dsi-lvds-bridge@2d -> / > panel_lvds0 -> /soc@0/bus@32c00000/dsi@32e10000 -> > Which seems weird. I would have expected something like > dsi@32e10000 -> dsi-lvds-bridge@2d -> panel_lvds0 > Do you happen to see somthing similar? But this is completely unrelated to > your patchset though. Can you share the link to the exact commit? Thanks, Jagan.
Hello Jagan, thanks for the quick response. Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: > On Thu, May 5, 2022 at 12:57 PM Alexander Stein > > <alexander.stein@ew.tq-group.com> wrote: > > Hello Jagan, > > > > thanks for the second version of this patchset. > > > > Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > > > This series supports common bridge support for Samsung MIPI DSIM > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > Previous v1 can be available here [1]. > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > On, summary this patch-set break the entire DSIM driver into > > > - platform specific glue code for platform ops, component_ops. > > > - common bridge driver which handle platform glue init and invoke. > > > > > > Patch 0000: Samsung DSIM bridge > > > > > > Patch 0001: Common lookup code for OF-graph or child > > > > > > Patch 0002: platform init flag via driver_data > > > > > > Patch 0003/10: bridge fixes, atomic API's > > > > > > Patch 0011: document fsl,imx8mm-mipi-dsim > > > > > > Patch 0012: add i.MX8MM DSIM support > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > Anyone interested, please have a look on this repo [2] > > > > > > [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v2 > > > [1] > > > https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.1845 > > > 83-> 1-jagan@amarulasolutions.com/ > > > > > > Any inputs? > > > > I was able to get my LVDS display running using this driver and an LVDS > > bridge. Actually my setup is similar to yours. My chain is like this: > > MIPI-DSI -> sn65dsi83 -> LVDS panel > > I noticed some things though: > > My setup only works if I use less than 4 lanes. See [1]. When using 4 > > lanes > > the image is flickering, but the content is "visible". Your DT has only 2 > > lanes configured, do you have the possibility to use 4 lanes? I have no > > idea how to tackle this. It might be the DSIM side or the bridge side. > > Apparently the downstream kernel from NXP supports 4 lanes, if I can trust > > the config. I have no way to verify this though. > > What is dsi_lvds_bridge node? have you added your dts changes on top > of imx8mm-dsi-v2 branch I'm pointing it. I cherry-picked your commits and applied them on (currently) next-20220504. Maybe you missed the links at the end of my mail. The branch I am talking about is https://github.com/tq-steina/linux/commits/imx8mm-dsi-lvds This includes your commits as well as my additions. > I will check 4 lanes and let you know. Great, thanks. > > Another thing is I get the following warning > > > > > sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check > > > output > > > > bridge driver. Falling back to SPWG24. > > This couldn't be much affected but will fix it. > > > This seems to be caused by a wrong bridge chain. Using commit 81e80429 at > > [2]> > > I get the following output: > > > bridge chain: /soc@0/bus@30800000/i2c@30a40000/dsi-lvds-bridge@2d -> / > > > > panel_lvds0 -> /soc@0/bus@32c00000/dsi@32e10000 -> > > Which seems weird. I would have expected something like > > dsi@32e10000 -> dsi-lvds-bridge@2d -> panel_lvds0 > > Do you happen to see somthing similar? But this is completely unrelated to > > your patchset though. > > Can you share the link to the exact commit? This is the commit introducing this output: https://github.com/tq-steina/linux/commit/ 81e80429341cd0a4f119ec9cf50839498915443b Best regards, Alexander
Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: > On Thu, May 5, 2022 at 12:57 PM Alexander Stein > > <alexander.stein@ew.tq-group.com> wrote: > > Hello Jagan, > > > > thanks for the second version of this patchset. > > > > Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > > > This series supports common bridge support for Samsung MIPI DSIM > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > Previous v1 can be available here [1]. > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > On, summary this patch-set break the entire DSIM driver into > > > - platform specific glue code for platform ops, component_ops. > > > - common bridge driver which handle platform glue init and invoke. > > > > > > Patch 0000: Samsung DSIM bridge > > > > > > Patch 0001: Common lookup code for OF-graph or child > > > > > > Patch 0002: platform init flag via driver_data > > > > > > Patch 0003/10: bridge fixes, atomic API's > > > > > > Patch 0011: document fsl,imx8mm-mipi-dsim > > > > > > Patch 0012: add i.MX8MM DSIM support > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > Anyone interested, please have a look on this repo [2] > > > > > > [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v2 > > > [1] > > > https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.1845 > > > 83-> 1-jagan@amarulasolutions.com/ > > > > > > Any inputs? > > > > I was able to get my LVDS display running using this driver and an LVDS > > bridge. Actually my setup is similar to yours. My chain is like this: > > MIPI-DSI -> sn65dsi83 -> LVDS panel > > I noticed some things though: > > My setup only works if I use less than 4 lanes. See [1]. When using 4 > > lanes > > the image is flickering, but the content is "visible". Your DT has only 2 > > lanes configured, do you have the possibility to use 4 lanes? I have no > > idea how to tackle this. It might be the DSIM side or the bridge side. > > Apparently the downstream kernel from NXP supports 4 lanes, if I can trust > > the config. I have no way to verify this though. > > What is dsi_lvds_bridge node? have you added your dts changes on top > of imx8mm-dsi-v2 branch I'm pointing it. > > I will check 4 lanes and let you know. > > > Another thing is I get the following warning > > > > > sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check > > > output > > > > bridge driver. Falling back to SPWG24. > > This couldn't be much affected but will fix it. I found the cause. You need the following diff: ----8<----- diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/ samsung-dsim.c index 138323dec0eb..7fb96dc7bb2e 100644 --- a/drivers/gpu/drm/bridge/samsung-dsim.c +++ b/drivers/gpu/drm/bridge/samsung-dsim.c @@ -1427,7 +1427,7 @@ static int samsung_dsim_attach(struct drm_bridge *bridge, { struct samsung_dsim *dsi = bridge_to_dsi(bridge); - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags); + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge, flags); } static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = { ----8<----- Best regards, Alexander
Hi Alexander, On 05.05.2022 13:55, Alexander Stein wrote: > Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: >> On Thu, May 5, 2022 at 12:57 PM Alexander Stein >> >> <alexander.stein@ew.tq-group.com> wrote: >>> Hello Jagan, >>> >>> thanks for the second version of this patchset. >>> >>> Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: >>>> This series supports common bridge support for Samsung MIPI DSIM >>>> which is used in Exynos and i.MX8MM SoC's. >>>> >>>> Previous v1 can be available here [1]. >>>> >>>> The final bridge supports both the Exynos and i.MX8MM DSI devices. >>>> >>>> On, summary this patch-set break the entire DSIM driver into >>>> - platform specific glue code for platform ops, component_ops. >>>> - common bridge driver which handle platform glue init and invoke. >>>> >>>> Patch 0000: Samsung DSIM bridge >>>> >>>> Patch 0001: Common lookup code for OF-graph or child >>>> >>>> Patch 0002: platform init flag via driver_data >>>> >>>> Patch 0003/10: bridge fixes, atomic API's >>>> >>>> Patch 0011: document fsl,imx8mm-mipi-dsim >>>> >>>> Patch 0012: add i.MX8MM DSIM support >>>> >>>> Tested in Engicam i.Core MX8M Mini SoM. >>>> >>>> Anyone interested, please have a look on this repo [2] >>>> >>>> [2] https://protect2.fireeye.com/v1/url?k=569d5207-09066afa-569cd948-000babff317b-7f7572918a36c54e&q=1&e=1305c5cc-33c8-467e-a498-6862a854cf94&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v2 >>>> [1] >>>> https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.1845 >>>> 83-> 1-jagan@amarulasolutions.com/ >>>> >>>> Any inputs? >>> I was able to get my LVDS display running using this driver and an LVDS >>> bridge. Actually my setup is similar to yours. My chain is like this: >>> MIPI-DSI -> sn65dsi83 -> LVDS panel >>> I noticed some things though: >>> My setup only works if I use less than 4 lanes. See [1]. When using 4 >>> lanes >>> the image is flickering, but the content is "visible". Your DT has only 2 >>> lanes configured, do you have the possibility to use 4 lanes? I have no >>> idea how to tackle this. It might be the DSIM side or the bridge side. >>> Apparently the downstream kernel from NXP supports 4 lanes, if I can trust >>> the config. I have no way to verify this though. >> What is dsi_lvds_bridge node? have you added your dts changes on top >> of imx8mm-dsi-v2 branch I'm pointing it. >> >> I will check 4 lanes and let you know. >> >>> Another thing is I get the following warning >>> >>>> sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check >>>> output >>> bridge driver. Falling back to SPWG24. >> This couldn't be much affected but will fix it. > I found the cause. You need the following diff: > ----8<----- > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/ > samsung-dsim.c > index 138323dec0eb..7fb96dc7bb2e 100644 > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1427,7 +1427,7 @@ static int samsung_dsim_attach(struct drm_bridge > *bridge, > { > struct samsung_dsim *dsi = bridge_to_dsi(bridge); > > - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, > flags); > + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge, > flags); > } > > static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = { > ----8<----- Well, basically, the above change breaks DSI panels. :( I've spent another evening playing with that code and I have some more thoughts... I agree that logically this should be like you pointed. However the the code has been hacked in such a way, that it forces a proper order of pre-enable operations of the DSI and the client (panel, next bridge). This works somehow with a chain of 2 entities (Trats board: DSI and a panel) or even 3 entities (Arndale board: DSI, TC358764 bridge, panel), but probably it fails in your case. I really have no clue how to fix this mess. It has been pointed many times that this insane per-order call chain of the pre_enable() operations is completely useless for the DSI hardware and noone pointed how to solve this. Exynos DSI (and VC4) called those operations directly to achieve proper order. So what happened? Now Exynos DSI got converted to the generic bridge call chain. To get it working with existing hw, the order of the bridges has been hacked. Probably in the next few releases more mess will come to get around this known issue, especially when support for the next set of imx boards is added. I'm really open to help fixing this issue. I've spent a lot of time analyzing this code and I have boards to test. Just please give me some advice how to avoid this reverse-order call chain of the pre_enable() operations in the widely accepted, non-hacky way. Best regards
Hi Marek, Am Freitag, 6. Mai 2022, 10:57:05 CEST schrieb Marek Szyprowski: > Hi Alexander, > > On 05.05.2022 13:55, Alexander Stein wrote: > > Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: > >> On Thu, May 5, 2022 at 12:57 PM Alexander Stein > >> > >> <alexander.stein@ew.tq-group.com> wrote: > >>> Hello Jagan, > >>> > >>> thanks for the second version of this patchset. > >>> > >>> Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > >>>> This series supports common bridge support for Samsung MIPI DSIM > >>>> which is used in Exynos and i.MX8MM SoC's. > >>>> > >>>> Previous v1 can be available here [1]. > >>>> > >>>> The final bridge supports both the Exynos and i.MX8MM DSI devices. > >>>> > >>>> On, summary this patch-set break the entire DSIM driver into > >>>> - platform specific glue code for platform ops, component_ops. > >>>> - common bridge driver which handle platform glue init and invoke. > >>>> > >>>> Patch 0000: Samsung DSIM bridge > >>>> > >>>> Patch 0001: Common lookup code for OF-graph or child > >>>> > >>>> Patch 0002: platform init flag via driver_data > >>>> > >>>> Patch 0003/10: bridge fixes, atomic API's > >>>> > >>>> Patch 0011: document fsl,imx8mm-mipi-dsim > >>>> > >>>> Patch 0012: add i.MX8MM DSIM support > >>>> > >>>> Tested in Engicam i.Core MX8M Mini SoM. > >>>> > >>>> Anyone interested, please have a look on this repo [2] > >>>> > >>>> [2] > >>>> https://protect2.fireeye.com/v1/url?k=569d5207-09066afa-569cd948-000ba > >>>> bff317b-7f7572918a36c54e&q=1&e=1305c5cc-33c8-467e-a498-6862a854cf94&u=h > >>>> ttps%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v2 [1] > >>>> https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.184 > >>>> 5 > >>>> 83-> 1-jagan@amarulasolutions.com/ > >>>> > >>>> Any inputs? > >>> > >>> I was able to get my LVDS display running using this driver and an LVDS > >>> bridge. Actually my setup is similar to yours. My chain is like this: > >>> MIPI-DSI -> sn65dsi83 -> LVDS panel > >>> I noticed some things though: > >>> My setup only works if I use less than 4 lanes. See [1]. When using 4 > >>> lanes > >>> the image is flickering, but the content is "visible". Your DT has only > >>> 2 > >>> lanes configured, do you have the possibility to use 4 lanes? I have no > >>> idea how to tackle this. It might be the DSIM side or the bridge side. > >>> Apparently the downstream kernel from NXP supports 4 lanes, if I can > >>> trust > >>> the config. I have no way to verify this though. > >> > >> What is dsi_lvds_bridge node? have you added your dts changes on top > >> of imx8mm-dsi-v2 branch I'm pointing it. > >> > >> I will check 4 lanes and let you know. > >> > >>> Another thing is I get the following warning > >>> > >>>> sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check > >>>> output > >>> > >>> bridge driver. Falling back to SPWG24. > >> > >> This couldn't be much affected but will fix it. > > > > I found the cause. You need the following diff: > > ----8<----- > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > > b/drivers/gpu/drm/bridge/ samsung-dsim.c > > index 138323dec0eb..7fb96dc7bb2e 100644 > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > @@ -1427,7 +1427,7 @@ static int samsung_dsim_attach(struct drm_bridge > > *bridge, > > > > { > > > > struct samsung_dsim *dsi = bridge_to_dsi(bridge); > > > > - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, > > flags); > > + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge, > > flags); > > > > } > > > > static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = { > > > > ----8<----- > > Well, basically, the above change breaks DSI panels. :( That's too bad :( I wonder why actually this breaks DSI setups. From my understanding, the diff above seems correct, even for DSI panels. But I don't know a DSI setup in detail or the bridge/panel code involved or which part breaks with this change. > I've spent another evening playing with that code and I have some more > thoughts... > > I agree that logically this should be like you pointed. However the the > code has been hacked in such a way, that it forces a proper order of > pre-enable operations of the DSI and the client (panel, next bridge). > This works somehow with a chain of 2 entities (Trats board: DSI and a > panel) or even 3 entities (Arndale board: DSI, TC358764 bridge, panel), > but probably it fails in your case. Well, setting e.g. the bus format from panel -> bridge -> bridge ->... -> encoder seems sensible to me. It should be similar for both names setups as well. Essentially the Arndale is quite a similar setup to my and Jagan's one. The actual reason it fails for me is that this list is created incorrectly, which should also be the case for Arndale. > I really have no clue how to fix this mess. It has been pointed many > times that this insane per-order call chain of the pre_enable() > operations is completely useless for the DSI hardware and noone pointed > how to solve this. Exynos DSI (and VC4) called those operations directly > to achieve proper order. So what happened? Now Exynos DSI got converted > to the generic bridge call chain. To get it working with existing hw, > the order of the bridges has been hacked. Probably in the next few > releases more mess will come to get around this known issue, especially > when support for the next set of imx boards is added. > > I'm really open to help fixing this issue. I've spent a lot of time > analyzing this code and I have boards to test. Just please give me some > advice how to avoid this reverse-order call chain of the pre_enable() > operations in the widely accepted, non-hacky way. In the first place I'm inclined to raise a warning in drm_bridge_attach() if previous is NULL and encoder->bridge_chain is not empty. This means that you are adding two "root"-bridges which seems wrong to me. There is also some documentation regarding 'special care dsi' in drivers/gpu/ drm/drm_bridge.c. There is some distinction between a DSI host using components or not. But I have no knowledge about those components. That being said, I would assume that the Exynos conversion using a DRM bridge now might needs some additional changes. Best regards, Alexander
Hi Marek On Fri, 6 May 2022 at 09:57, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi Alexander, > > On 05.05.2022 13:55, Alexander Stein wrote: > > Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: > >> On Thu, May 5, 2022 at 12:57 PM Alexander Stein > >> > >> <alexander.stein@ew.tq-group.com> wrote: > >>> Hello Jagan, > >>> > >>> thanks for the second version of this patchset. > >>> > >>> Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: > >>>> This series supports common bridge support for Samsung MIPI DSIM > >>>> which is used in Exynos and i.MX8MM SoC's. > >>>> > >>>> Previous v1 can be available here [1]. > >>>> > >>>> The final bridge supports both the Exynos and i.MX8MM DSI devices. > >>>> > >>>> On, summary this patch-set break the entire DSIM driver into > >>>> - platform specific glue code for platform ops, component_ops. > >>>> - common bridge driver which handle platform glue init and invoke. > >>>> > >>>> Patch 0000: Samsung DSIM bridge > >>>> > >>>> Patch 0001: Common lookup code for OF-graph or child > >>>> > >>>> Patch 0002: platform init flag via driver_data > >>>> > >>>> Patch 0003/10: bridge fixes, atomic API's > >>>> > >>>> Patch 0011: document fsl,imx8mm-mipi-dsim > >>>> > >>>> Patch 0012: add i.MX8MM DSIM support > >>>> > >>>> Tested in Engicam i.Core MX8M Mini SoM. > >>>> > >>>> Anyone interested, please have a look on this repo [2] > >>>> > >>>> [2] https://protect2.fireeye.com/v1/url?k=569d5207-09066afa-569cd948-000babff317b-7f7572918a36c54e&q=1&e=1305c5cc-33c8-467e-a498-6862a854cf94&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v2 > >>>> [1] > >>>> https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.1845 > >>>> 83-> 1-jagan@amarulasolutions.com/ > >>>> > >>>> Any inputs? > >>> I was able to get my LVDS display running using this driver and an LVDS > >>> bridge. Actually my setup is similar to yours. My chain is like this: > >>> MIPI-DSI -> sn65dsi83 -> LVDS panel > >>> I noticed some things though: > >>> My setup only works if I use less than 4 lanes. See [1]. When using 4 > >>> lanes > >>> the image is flickering, but the content is "visible". Your DT has only 2 > >>> lanes configured, do you have the possibility to use 4 lanes? I have no > >>> idea how to tackle this. It might be the DSIM side or the bridge side. > >>> Apparently the downstream kernel from NXP supports 4 lanes, if I can trust > >>> the config. I have no way to verify this though. > >> What is dsi_lvds_bridge node? have you added your dts changes on top > >> of imx8mm-dsi-v2 branch I'm pointing it. > >> > >> I will check 4 lanes and let you know. > >> > >>> Another thing is I get the following warning > >>> > >>>> sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check > >>>> output > >>> bridge driver. Falling back to SPWG24. > >> This couldn't be much affected but will fix it. > > I found the cause. You need the following diff: > > ----8<----- > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/ > > samsung-dsim.c > > index 138323dec0eb..7fb96dc7bb2e 100644 > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > @@ -1427,7 +1427,7 @@ static int samsung_dsim_attach(struct drm_bridge > > *bridge, > > { > > struct samsung_dsim *dsi = bridge_to_dsi(bridge); > > > > - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, > > flags); > > + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge, > > flags); > > } > > > > static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = { > > ----8<----- > > Well, basically, the above change breaks DSI panels. :( > > I've spent another evening playing with that code and I have some more > thoughts... > > I agree that logically this should be like you pointed. However the the > code has been hacked in such a way, that it forces a proper order of > pre-enable operations of the DSI and the client (panel, next bridge). > This works somehow with a chain of 2 entities (Trats board: DSI and a > panel) or even 3 entities (Arndale board: DSI, TC358764 bridge, panel), > but probably it fails in your case. > > I really have no clue how to fix this mess. It has been pointed many > times that this insane per-order call chain of the pre_enable() > operations is completely useless for the DSI hardware and noone pointed > how to solve this. Exynos DSI (and VC4) called those operations directly > to achieve proper order. So what happened? Now Exynos DSI got converted > to the generic bridge call chain. To get it working with existing hw, > the order of the bridges has been hacked. Probably in the next few > releases more mess will come to get around this known issue, especially > when support for the next set of imx boards is added. > > I'm really open to help fixing this issue. I've spent a lot of time > analyzing this code and I have boards to test. Just please give me some > advice how to avoid this reverse-order call chain of the pre_enable() > operations in the widely accepted, non-hacky way. I sent [1] to try and offer a solution for DSI back in March, but no one has responded to it at all. Care to review it? As noted in the cover letter for that series, splitting the bridge_chain (as Exynos and vc4 do) does not work with atomic operations due to the bridges beyond the split never being added to the state. That approach is a dead end, and I'm trying to move vc4 away from it. That's not possible until the framework issue is resolved, unless you adopt the hack done by dw-mipi and msm to power up the DSI host in mode_set. Thanks. Dave [1] https://patchwork.kernel.org/project/dri-devel/cover/cover.1646406653.git.dave.stevenson@raspberrypi.com/ > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >
Hi Dave, On 06.05.2022 12:50, Dave Stevenson wrote: > On Fri, 6 May 2022 at 09:57, Marek Szyprowski <m.szyprowski@samsung.com> wrote: >> On 05.05.2022 13:55, Alexander Stein wrote: >>> Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki: >>>> On Thu, May 5, 2022 at 12:57 PM Alexander Stein >>>> >>>> <alexander.stein@ew.tq-group.com> wrote: >>>>> Hello Jagan, >>>>> >>>>> thanks for the second version of this patchset. >>>>> >>>>> Am Mittwoch, 4. Mai 2022, 13:40:09 CEST schrieb Jagan Teki: >>>>>> This series supports common bridge support for Samsung MIPI DSIM >>>>>> which is used in Exynos and i.MX8MM SoC's. >>>>>> >>>>>> Previous v1 can be available here [1]. >>>>>> >>>>>> The final bridge supports both the Exynos and i.MX8MM DSI devices. >>>>>> >>>>>> On, summary this patch-set break the entire DSIM driver into >>>>>> - platform specific glue code for platform ops, component_ops. >>>>>> - common bridge driver which handle platform glue init and invoke. >>>>>> >>>>>> Patch 0000: Samsung DSIM bridge >>>>>> >>>>>> Patch 0001: Common lookup code for OF-graph or child >>>>>> >>>>>> Patch 0002: platform init flag via driver_data >>>>>> >>>>>> Patch 0003/10: bridge fixes, atomic API's >>>>>> >>>>>> Patch 0011: document fsl,imx8mm-mipi-dsim >>>>>> >>>>>> Patch 0012: add i.MX8MM DSIM support >>>>>> >>>>>> Tested in Engicam i.Core MX8M Mini SoM. >>>>>> >>>>>> Anyone interested, please have a look on this repo [2] >>>>>> >>>>>> [2] https://protect2.fireeye.com/v1/url?k=569d5207-09066afa-569cd948-000babff317b-7f7572918a36c54e&q=1&e=1305c5cc-33c8-467e-a498-6862a854cf94&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v2 >>>>>> [1] >>>>>> https://patchwork.kernel.org/project/dri-devel/cover/20220408162108.1845 >>>>>> 83-> 1-jagan@amarulasolutions.com/ >>>>>> >>>>>> Any inputs? >>>>> I was able to get my LVDS display running using this driver and an LVDS >>>>> bridge. Actually my setup is similar to yours. My chain is like this: >>>>> MIPI-DSI -> sn65dsi83 -> LVDS panel >>>>> I noticed some things though: >>>>> My setup only works if I use less than 4 lanes. See [1]. When using 4 >>>>> lanes >>>>> the image is flickering, but the content is "visible". Your DT has only 2 >>>>> lanes configured, do you have the possibility to use 4 lanes? I have no >>>>> idea how to tackle this. It might be the DSIM side or the bridge side. >>>>> Apparently the downstream kernel from NXP supports 4 lanes, if I can trust >>>>> the config. I have no way to verify this though. >>>> What is dsi_lvds_bridge node? have you added your dts changes on top >>>> of imx8mm-dsi-v2 branch I'm pointing it. >>>> >>>> I will check 4 lanes and let you know. >>>> >>>>> Another thing is I get the following warning >>>>> >>>>>> sn65dsi83 2-002d: Unsupported LVDS bus format 0x100a, please check >>>>>> output >>>>> bridge driver. Falling back to SPWG24. >>>> This couldn't be much affected but will fix it. >>> I found the cause. You need the following diff: >>> ----8<----- >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/ >>> samsung-dsim.c >>> index 138323dec0eb..7fb96dc7bb2e 100644 >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c >>> @@ -1427,7 +1427,7 @@ static int samsung_dsim_attach(struct drm_bridge >>> *bridge, >>> { >>> struct samsung_dsim *dsi = bridge_to_dsi(bridge); >>> >>> - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, >>> flags); >>> + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge, >>> flags); >>> } >>> >>> static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = { >>> ----8<----- >> Well, basically, the above change breaks DSI panels. :( >> >> I've spent another evening playing with that code and I have some more >> thoughts... >> >> I agree that logically this should be like you pointed. However the the >> code has been hacked in such a way, that it forces a proper order of >> pre-enable operations of the DSI and the client (panel, next bridge). >> This works somehow with a chain of 2 entities (Trats board: DSI and a >> panel) or even 3 entities (Arndale board: DSI, TC358764 bridge, panel), >> but probably it fails in your case. >> >> I really have no clue how to fix this mess. It has been pointed many >> times that this insane per-order call chain of the pre_enable() >> operations is completely useless for the DSI hardware and noone pointed >> how to solve this. Exynos DSI (and VC4) called those operations directly >> to achieve proper order. So what happened? Now Exynos DSI got converted >> to the generic bridge call chain. To get it working with existing hw, >> the order of the bridges has been hacked. Probably in the next few >> releases more mess will come to get around this known issue, especially >> when support for the next set of imx boards is added. >> >> I'm really open to help fixing this issue. I've spent a lot of time >> analyzing this code and I have boards to test. Just please give me some >> advice how to avoid this reverse-order call chain of the pre_enable() >> operations in the widely accepted, non-hacky way. > I sent [1] to try and offer a solution for DSI back in March, but no > one has responded to it at all. Care to review it? Thanks, I will post my comments there soon. It finally resolves all the issues I found with the Exynos DSI driver converted to DRM bridge. > As noted in the cover letter for that series, splitting the > bridge_chain (as Exynos and vc4 do) does not work with atomic > operations due to the bridges beyond the split never being added to > the state. That approach is a dead end, and I'm trying to move vc4 > away from it. That's not possible until the framework issue is > resolved, unless you adopt the hack done by dw-mipi and msm to power > up the DSI host in mode_set. Well, it is the first time one has pointed me WHY moving the bridge chain management to DRM core is really needed and what are the drawbacks of the old approach! Thanks again! Best regards