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.