imxdrm issue on Hummingboard with LVDS enabled
Thierry Reding
thierry.reding at gmail.com
Mon Feb 13 08:17:49 UTC 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170213/9acab017/attachment.sig>
More information about the dri-devel
mailing list