| Message ID | 20170212131854.GT27312@n2100.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Feb 12, 2017 at 01:18:54PM +0000, Russell King - ARM Linux wrote: > Hi, > > Here's another issue with imxdrm. I got this while trying to reproduce > Dan's problem by enabling the lvds output using the patch below > originally from Fabio, but updated a bit. This doesn't occur if I leave > LVDS disabled. > > The taint is due to the IMX capture modules from Steve, who chose to put > his code in drivers/staging/media rather than drivers/media. However, > the last module to make the capture stuff active (imx-csi) which interfaces > the drivers/gpu/ipu-v3 code with the capture code has not been loaded. > > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 1049 at /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+0x218/0x224 > [CRTC:29] vblank wait timed out Can someone please explain to me how you go from something like "[CRTC:29]" to something meaningful, such as identifying which exact CRTC failed here? Given that the ID numbers given out by DRM for individual components come from the dev->mode_config.crtc_idr IDR, without knowing in exact detail the precise registration order of these objects with drm_mode_object_get(), printing "[CRTC:29]" is utterly meaningless - it conveys zero useful information. DRM might as well be printing random numbers instead. At least the pre-atomic DRM code printed crtc->name as well, which would at least indicate which _CRTC_ in numeric order of registration was the cause, which is slightly easier to guess which hardware CRTC in question caused the problem. Some consistency in DRM land would be nice...
Hi Russell, On Sun, Feb 12, 2017 at 11:18 AM, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > Hi, > > Here's another issue with imxdrm. I got this while trying to reproduce > Dan's problem by enabling the lvds output using the patch below > originally from Fabio, but updated a bit. This doesn't occur if I leave > LVDS disabled. > > The taint is due to the IMX capture modules from Steve, who chose to put > his code in drivers/staging/media rather than drivers/media. However, > the last module to make the capture stuff active (imx-csi) which interfaces > the drivers/gpu/ipu-v3 code with the capture code has not been loaded. > > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 1049 at /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+0x218/0x224 > [CRTC:29] vblank wait timed out I am getting the same warning when trying to add HDMI support on imx6sx-udoo-neo board via TDA19988: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. tda998x 2-0070: Falling back to first CRTC random: fast init done tda998x 2-0070: found TDA19988 mxsfb 2220000.lcdif: bound 2-0070 (ops tda998x_ops) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+00 [CRTC:26] vblank wait timed out Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc7-00034-g2217172 #155 Hardware name: Freescale i.MX6 SoloX (Device Tree) Backtrace: [<c010c338>] (dump_backtrace) from [<c010c5e4>] (show_stack+0x18/0x1c) r7:00000000 r6:60000013 r5:00000000 r4:c0e29258 [<c010c5cc>] (show_stack) from [<c04004e0>] (dump_stack+0xb4/0xe8) [<c040042c>] (dump_stack) from [<c012590c>] (__warn+0xd8/0x104) r9:c04d63ac r8:0000047d r7:00000009 r6:c0c1f2b4 r5:00000000 r4:ef05f8c8 [<c0125834>] (__warn) from [<c0125974>] (warn_slowpath_fmt+0x3c/0x44) r9:ef350000 r8:ef037028 r7:00000000 r6:ef3bd600 r5:ef3d2c00 r4:c0c1f3d0 [<c012593c>] (warn_slowpath_fmt) from [<c04d63ac>] (drm_atomic_helper_wait_for_vblanks+0x230/0x240) r3:0000001a r2:c0c1f3d0 r4:00000000 [<c04d617c>] (drm_atomic_helper_wait_for_vblanks) from [<c04d64bc>] (drm_atomic_helper_commit_tail+0x50) r10:00000001 r9:ef3cd100 r8:ef350484 r7:ef350000 r6:00000000 r5:ef350000 r4:ef3d2c00 .... I haven't had a chance to debug this yet. If anyone makes any progress, please keep me on Cc. Thanks
On Sun, Feb 12, 2017 at 01:42:38PM +0000, Russell King - ARM Linux wrote: > On Sun, Feb 12, 2017 at 01:18:54PM +0000, Russell King - ARM Linux wrote: > > Hi, > > > > Here's another issue with imxdrm. I got this while trying to reproduce > > Dan's problem by enabling the lvds output using the patch below > > originally from Fabio, but updated a bit. This doesn't occur if I leave > > LVDS disabled. > > > > The taint is due to the IMX capture modules from Steve, who chose to put > > his code in drivers/staging/media rather than drivers/media. However, > > the last module to make the capture stuff active (imx-csi) which interfaces > > the drivers/gpu/ipu-v3 code with the capture code has not been loaded. > > > > ------------[ cut here ]------------ > > WARNING: CPU: 1 PID: 1049 at /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+0x218/0x224 > > [CRTC:29] vblank wait timed out > > Can someone please explain to me how you go from something like > "[CRTC:29]" to something meaningful, such as identifying which > exact CRTC failed here? > > Given that the ID numbers given out by DRM for individual components > come from the dev->mode_config.crtc_idr IDR, without knowing in > exact detail the precise registration order of these objects with > drm_mode_object_get(), printing "[CRTC:29]" is utterly meaningless - > it conveys zero useful information. DRM might as well be printing > random numbers instead. > > At least the pre-atomic DRM code printed crtc->name as well, which > would at least indicate which _CRTC_ in numeric order of registration > was the cause, which is slightly easier to guess which hardware CRTC > in question caused the problem. > > Some consistency in DRM land would be nice... I suppose we could add an optional struct device * to struct drm_crtc (and possibly struct drm_encoder, struct drm_connector, ...) and take the name from that to make it more obvious where this is coming from. Alternatively, you can use the "name" parameter when calling drm_crtc_init_with_planes() in order to provide a specific name rather than using the crtc-%d fallback. You could pass dev_name(&pdev->dev), or whatever, to make it clear. Of course, the above still requires that the core messages output the name along with the ID. Thierry
On Mon, Feb 13, 2017 at 09:17:49AM +0100, Thierry Reding wrote: > Of course, the above still requires that the core messages output the > name along with the ID. Thankfully, that's not a very big patch. I'll post it later today.
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts index d5c966031962..9f605d14c50f 100644 --- a/arch/arm/boot/dts/imx6dl-hummingboard.dts +++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts @@ -48,3 +48,10 @@ model = "SolidRun HummingBoard Solo/DualLite"; compatible = "solidrun,hummingboard/dl", "fsl,imx6dl"; }; + +&clks { + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>, + <&clks IMX6QDL_CLK_LDB_DI1_SEL>; + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>, + <&clks IMX6QDL_CLK_PLL3_USB_OTG>; +}; diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi index d6c2358ffad4..258107246d64 100644 --- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi @@ -302,3 +302,28 @@ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; status = "okay"; }; + +&ldb { + status = "okay"; + + lvds-channel@1 { + fsl,data-mapping = "spwg"; + fsl,data-width = <18>; + status = "okay"; + + display-timings { + native-mode = <&timing0>; + timing0: hsd100pxn1 { + clock-frequency = <65000000>; + hactive = <1024>; + vactive = <768>; + hback-porch = <220>; + hfront-porch = <40>; + vback-porch = <21>; + vfront-porch = <7>; + hsync-len = <60>; + vsync-len = <10>; + }; + }; + }; +}; diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c index 45bf9e330eca..bb0cf4cd3370 100644 --- a/drivers/clk/imx/clk-imx6q.c +++ b/drivers/clk/imx/clk-imx6q.c @@ -864,7 +864,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node) clk_set_parent(clk[IMX6QDL_CLK_IPU2_DI0_SEL], clk[IMX6QDL_CLK_IPU2_DI0_PRE]); clk_set_parent(clk[IMX6QDL_CLK_IPU2_DI1_SEL], clk[IMX6QDL_CLK_IPU2_DI1_PRE]); - if (cpu_is_imx6dl()) + if (clk_on_imx6dl()) clk_set_parent(clk[IMX6QDL_CLK_IPU1_SEL], clk[IMX6QDL_CLK_PLL3_PFD1_540M]); /*