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... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
