| Message ID | 20220406160123.1272911-1-l.stach@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | i.MX8MP HDMI support | expand |
On Wed, Apr 6, 2022 at 9:01 AM Lucas Stach <l.stach@pengutronix.de> wrote: > > 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. > > Regards, > Lucas > > [1] https://lore.kernel.org/all/20220406153402.1265474-1-l.stach@pengutronix.de/ > [2] https://lore.kernel.org/all/20220322142853.125880-1-marex@denx.de/ > > Lucas Stach (10): > drm/bridge: dw-hdmi: add low-active PHY reset > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > drm/imx: add bridge wrapper driver for i.MX8MP DWC HDMI > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > drm/imx: add driver for HDMI TX Parallel Video Interface > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > phy: freescale: add Samsung HDMI PHY > arm64: dts: imx8mp: add HDMI irqsteer > arm64: dts: imx8mp: add HDMI display pipeline > arm64: dts: imx8mp-evk: enable HDMI > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 83 ++ > .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 72 ++ > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 19 + > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 93 ++ > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 + > drivers/gpu/drm/imx/Kconfig | 1 + > drivers/gpu/drm/imx/Makefile | 2 + > drivers/gpu/drm/imx/bridge/Kconfig | 18 + > drivers/gpu/drm/imx/bridge/Makefile | 4 + > drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c | 209 +++ > drivers/gpu/drm/imx/bridge/imx-hdmi.c | 128 ++ > drivers/phy/freescale/Kconfig | 7 + > drivers/phy/freescale/Makefile | 1 + > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1145 +++++++++++++++++ > include/drm/bridge/dw_hdmi.h | 1 + > 16 files changed, 1852 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml > create mode 100644 drivers/gpu/drm/imx/bridge/Kconfig > create mode 100644 drivers/gpu/drm/imx/bridge/Makefile > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi.c > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c > > -- > 2.30.2 > Lucas, Thanks for consolidating this - It's been difficult to try to merge these for testing. I still have not been able to apply these to origin/master or imx/master - what are you basing off of here? Best Regards, Tim I
Hi Tim, Am Mittwoch, dem 06.04.2022 um 09:10 -0700 schrieb Tim Harvey: > On Wed, Apr 6, 2022 at 9:01 AM Lucas Stach <l.stach@pengutronix.de> wrote: > > > > 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. > > > > Regards, > > Lucas > > > > [1] https://lore.kernel.org/all/20220406153402.1265474-1-l.stach@pengutronix.de/ > > [2] https://lore.kernel.org/all/20220322142853.125880-1-marex@denx.de/ > > > > Lucas Stach (10): > > drm/bridge: dw-hdmi: add low-active PHY reset > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > > drm/imx: add bridge wrapper driver for i.MX8MP DWC HDMI > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > > drm/imx: add driver for HDMI TX Parallel Video Interface > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > > phy: freescale: add Samsung HDMI PHY > > arm64: dts: imx8mp: add HDMI irqsteer > > arm64: dts: imx8mp: add HDMI display pipeline > > arm64: dts: imx8mp-evk: enable HDMI > > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 83 ++ > > .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 72 ++ > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > > arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 19 + > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 93 ++ > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 + > > drivers/gpu/drm/imx/Kconfig | 1 + > > drivers/gpu/drm/imx/Makefile | 2 + > > drivers/gpu/drm/imx/bridge/Kconfig | 18 + > > drivers/gpu/drm/imx/bridge/Makefile | 4 + > > drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c | 209 +++ > > drivers/gpu/drm/imx/bridge/imx-hdmi.c | 128 ++ > > drivers/phy/freescale/Kconfig | 7 + > > drivers/phy/freescale/Makefile | 1 + > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1145 +++++++++++++++++ > > include/drm/bridge/dw_hdmi.h | 1 + > > 16 files changed, 1852 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml > > create mode 100644 drivers/gpu/drm/imx/bridge/Kconfig > > create mode 100644 drivers/gpu/drm/imx/bridge/Makefile > > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c > > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi.c > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c > > > > -- > > 2.30.2 > > > > Lucas, > > Thanks for consolidating this - It's been difficult to try to merge > these for testing. > > I still have not been able to apply these to origin/master or > imx/master - what are you basing off of here? This HDMI series depends on the HDMI blk-ctrl ([1] in this cover letter), which in turn depends on the GPCv2 i.MX8MP support series ([1] in the HDMI blk-ctrl cover letter), which should apply cleanly or with minimal fuzz to 5.18-rc1. Regards, Lucas
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. 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. Best regards, Alexander
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