Re: imxdrm issue on Hummingboard with LVDS enabled

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel