On 17/02/2023 09.18, Alexander Stein wrote: > Hi Liu, > > Am Freitag, 17. Februar 2023, 07:54:01 CET schrieb Liu Ying: >> Hi, >> >> This patch set aims to add i.MX93 LCDIF display controller support >> in the existing LCDIF DRM driver. The LCDIF embedded in i.MX93 SoC >> is essentially the same to those embedded in i.MX8mp SoC. Through >> internal bridges, i.MX93 LCDIF may drive a MIPI DSI display or a LVDS >> display or a parallel display. >> >> Patch 1/6 adds device tree binding support for i.MX93 LCDIF in the >> existing fsl,lcdif.yaml. >> >> Patch 2/6 drops lcdif->bridge NULL pointer check as a cleanup patch. >> >> Patch 3/6~5/6 prepare for adding i.MX93 LCDIF support step by step. >> >> Patch 6/6 adds i.MX93 LCDIF compatible string as the last step of >> adding i.MX93 LCDIF support. > > Thanks for the series. I could test this on my TQMa93xxLA/MBa93xxCA with a > single LVDS display attached, so no DSI or parallel display. Hence I could not > test the bus format and flags checks, but they look okay. > So you can add > Tested-by: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx> > to the whole series as well. > > One thing I noticed is that, sometimes it seems that before probing lcdif my > system completely freezes. Adding some debug output it seems that's during > powering up the IMX93_MEDIABLK_PD_LCDIF power domain there is some race > condition. But adding more more detailed output made the problem go away. > Did you notice something similar? It might be a red hering though. Interesting. Sounds similar to what I encountered on several imx8mp-based boards, both the NXP EVK and our custom design, running a mainline U-Boot and downstream NXP kernel: https://lore.kernel.org/u-boot/20220823133645.4046432-1-rasmus.villemoes@xxxxxxxxx/ I never really found a real solution, but as the hack I ended up applying in U-Boot does involve some clock settings, and you apparently now figured out some connection to "overclocking", I do think these issues are related. Rasmus
