From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: imxdrm issue on Hummingboard with LVDS enabled Date: Mon, 13 Feb 2017 09:17:49 +0100 Message-ID: <20170213081749.GA14776@ulmo.ba.sec> References: <20170212131854.GT27312@n2100.armlinux.org.uk> <20170212134238.GA28968@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0465942429==" Return-path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 24DCC6E347 for ; Mon, 13 Feb 2017 08:17:53 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id c85so17887037wmi.1 for ; Mon, 13 Feb 2017 00:17:53 -0800 (PST) In-Reply-To: <20170212134238.GA28968@n2100.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Russell King - ARM Linux Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0465942429== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > >=20 > > 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. > >=20 > > 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 interf= aces > > the drivers/gpu/ipu-v3 code with the capture code has not been loaded. > >=20 > > ------------[ cut here ]------------ > > WARNING: CPU: 1 PID: 1049 at /home/rmk/git/linux-rmk/drivers/gpu/drm/dr= m_atomic_helper.c:1149 drm_atomic_helper_wait_for_vblanks+0x218/0x224 > > [CRTC:29] vblank wait timed out >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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 --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAliha6sACgkQ3SOs138+ s6GHlxAAi5qBBZVfwdjDGaRN86ox9SBLaYCoEQtNQLRIkfHENU0BAXbGaSnMJ3Vb d1/rRtocIlljlDzLGsEz9JKpxSumREzJdU7BiGEKufvTGRZ+VQKxeIAFO1QHdbxd s2hJg0K+Zlz8jecyaiIvda8oeLIADKS3Khz4VZa3vzXEf8Sows60zuvI/p/RaQjT Dj7YUjdwOGAyG1iRTp1locVvjU+qEuaWOacaK4rEhMovciuP07BcWf7hm9WS1vPs Mwc1Q5pgsk08t15SPVeYKlUhVGHskladtJedmmCJxYWNC4Q0ikyys0hNA6uO6S4L C8zgSJqDK64n/FLjhXFmedgYRdBzznCORBbIhaXRq5eTzZWZAmJ6B6pNmWa9uJJg hB8Xk6wZ9cv5JpbuQDBKFCvMcxES1aoSqHD/bQnihaI+OTHuKYZ1eJIt0ab6zhG5 I9G3mseulb99b9K4s0vJlg2ayIDEQDB4dMONXoYhOFkMU+gBHyRfOKGEpHNu+pEt j9cmIDd0VvHyM2+2Kex+whgX21smv7GGT27fLLHhsqUWf0H8iB7dXWEdwR1sl5vC 8w9UCsgO5xCBzJ6A4Lq3BStsh5zuXJC6RiHl8A/li+tAisl7AKYMjnMttDDCi65z Ewy/8rKUQuCwBVIJn1nnPhJru58onJUooajGbq9uuCvpBvcNip8= =RUzq -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- --===============0465942429== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0465942429==--