Re: [PATCH v0 00/10] i.MX8MP HDMI support

[Lucas Stach <l.stach@pengutronix.de>]

Hi Alexander,

Am Dienstag, dem 12.04.2022 um 11:18 +0200 schrieb Alexander Stein:
> Hello Lucas,
> 
> Am Mittwoch, 6. April 2022, 18:01:13 CEST schrieb Lucas Stach:
> > Hi all,
> > 
> > this adds support for the HDMI output pipeline on the i.MX8MP.
> > It currently depends on the i.MX8MP HDMI power domain series [1]
> > and support for the new LCDIF [2] in the i.MX8MP. I guess the
> > implementation presented here also still has some warts that
> > require fixing and the individual patches most likely need to go
> > through different maintainer trees, so I don't expect this series
> > to be applied right away.
> > 
> > However this complete series should allow people to test it more
> > easily and provide feedback on the implementation with the full
> > picture available.
> > 
> > Compared to downstream this implementation actually allows to
> > power down the separate HDMI PHY power domain when the display
> > is inactive or no HDMI cable is connected.
> 
> Thanks for these patches.
> I tried using them on my imx8mp based board (TQMa8MPxL + MBa8MPxL) but failed 
> to get the display showing anything. I noticed several things though:
> 
> * For some reason the HDMI PHY PLL does not lock. I get the error
> > fsl-samsung-hdmi-phy 32fdff00.phy: PLL failed to lock
> Increasing timeout does not change anything.
> 
> * The HDMI bridge wants to use bus format 0x200f which is not supported by 
> lcdif.
> > lcdif 32fc6000.display-controller: Unknown media bus format 0x200f
> I wonder which part in the DRM chain choses to use this.

Do have a 4k HDMI display connected that wants to do YUV input? That's
something I have to admit I didn't test yet and would be likely to
cause this bus format selection.

> But even hard limiting to 0x100a the screen stayed in suspend
> 
> * If the drivers are built as modules I get a hard lockup during boot. Using 
> built-in drivers or 'clk_ignore_unused' workarounds this.
> 
> * DDC does actually work. The display is detected and EDID can be read.
> 
> * Sometimes I get the following error:
> ------------[ cut here ]------------
> [CRTC:33:crtc-0] vblank wait timed out
> WARNING: CPU: 2 PID: 151 at drivers/gpu/drm/drm_atomic_helper.c:1529 
> drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc
> Modules linked in: caamhash_desc caamalg_desc crypto_engine rng_core mcp320x 
> dw_hdmi_cec authenc libdes dw100 videobuf2_dma_contig lcdif crct10dif_ce 
> phy_fsl_samsung_hdmi v4l2_mem2mem imx_sdma flexcan imx8mm_thermal can_dev caam 
> error pwm_fan fuse ipv6
> CPU: 2 PID: 151 Comm: kworker/u8:7 Not tainted 5.18.0-rc2-next-20220412+ #165 
> d226098cac46ded24901c7090f909ca8f5098eb0
> Hardware name: TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MPxL (DT)
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc
> lr : drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc
> sp : ffff80000a133430
> x29: ffff80000a133430 x28: 0000000000000000 x27: 0000000000000000
> x26: 0000000000000000 x25: 0000000000000001 x24: ffff80000935f030
> x23: ffff00000433e000 x22: ffff0000029e7000 x21: 0000000000000001
> x20: ffff000002e7fb48 x19: 0000000000000000 x18: 0000000000000001
> x17: 4d554e5145530065 x16: 6c75646f6d3d4d45 x15: 5453595342555300
> x14: 0000000000000000 x13: 0a74756f2064656d x12: 6974207469617720
> x11: 0000000000000000 x10: 000000000000003a x9 : ffff80000a133430
> x8 : 00000000ffffffff x7 : 6974207469617720 x6 : 6b6e616c6276205d
> x5 : ffff00007fb91b00 x4 : 0000000000000000 x3 : 0000000000000027
> x2 : 0000000000000023 x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
>  drm_atomic_helper_wait_for_vblanks.part.0+0x2ac/0x2fc
>  drm_atomic_helper_commit_tail_rpm+0x80/0xa0
>  commit_tail+0xcc/0x1f0
>  drm_atomic_helper_commit+0x13c/0x370
>  drm_atomic_commit+0xa4/0xe0
>  drm_client_modeset_commit_atomic+0x1fc/0x250
>  drm_client_modeset_commit_locked+0x58/0xa0
>  drm_client_modeset_commit+0x2c/0x50
>  __drm_fb_helper_restore_fbdev_mode_unlocked+0xec/0x140
>  drm_fb_helper_set_par+0x38/0x6c
>  fbcon_init+0x264/0x5e4
>  visual_init+0xc8/0x15c
>  do_bind_con_driver.isra.0+0x20c/0x470
>  do_take_over_console+0x44/0x60
>  do_fbcon_takeover+0x80/0x140
>  fbcon_fb_registered+0x1c4/0x260
>  do_register_framebuffer+0x1e0/0x2d0
>  register_framebuffer+0x2c/0x50
>  __drm_fb_helper_initial_config_and_unlock+0x9c/0x130
>  drm_fbdev_client_hotplug+0x1a8/0x20c
>  drm_fbdev_generic_setup+0xc0/0x1d0
>  lcdif_probe+0x7c/0xa0 [lcdif e756925430e957a7bc9e6376ad5964e4b1cb143e]
>  platform_probe+0x64/0x100
>  call_driver_probe+0x28/0x130
>  really_probe+0x178/0x310
>  __driver_probe_device+0xfc/0x144
>  driver_probe_device+0x38/0x12c
>  __device_attach_driver+0xd4/0x180
>  bus_for_each_drv+0x74/0xc4
>  __device_attach+0xd8/0x1e0
>  device_initial_probe+0x10/0x20
>  bus_probe_device+0x90/0xa0
>  deferred_probe_work_func+0x9c/0xf0
>  process_one_work+0x1d0/0x330
>  worker_thread+0x68/0x390
>  kthread+0xec/0xfc
>  ret_from_fork+0x10/0x20
> ---[ end trace 0000000000000000 ]---
> 
> But given that the PLL did not lock I assume this is not too surprising.
> 
Yes, that's just the fallout of the LCDIF not seeing any pixel clock.

You could aid me in diagnosing this by posting the output of
/sys/kernel/debug/clk/clk_summary and
/sys/kernel/debug/pm_genpd/pm_genpd_summary when the system is in this
failed state.

Regards,
Lucas