[v2,00/12] drm: bridge: Add Samsung MIPI DSIM bridge

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?
Jagan.

Jagan Teki (12):
  drm: bridge: Add Samsung DSIM bridge driver
  drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
  drm: bridge: samsung-dsim: Handle platform init via driver_data
  drm: bridge: samsung-dsim: Mark PHY as optional
  drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()
  drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset
  drm: bridge: samsung-dsim: Add module init, exit
  drm: bridge: samsung-dsim: Add atomic_check
  drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
  drm: bridge: samsung-dsim: Add input_bus_flags
  dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support
  drm: bridge: samsung-dsim: Add i.MX8MM support

 .../bindings/display/exynos/exynos_dsim.txt   |    1 +
 MAINTAINERS                                   |    8 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1847 +++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1724 +--------------
 include/drm/bridge/samsung-dsim.h             |   99 +
 8 files changed, 2032 insertions(+), 1661 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h
  

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