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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel