lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Nov 2015 13:16:55 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...ux.ie>,
	Rob Clark <robdclark@...il.com>,
	DRI devel <dri-devel@...ts.freedesktop.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: drm: Bogus WARN() in
 drm_atomic_helper_update_legacy_modeset_state() ?

On Wed, Nov 11, 2015 at 04:09:42PM +0000, Liviu Dudau wrote:
> On Tue, Nov 10, 2015 at 05:56:15PM +0100, Thierry Reding wrote:
> > On Tue, Nov 10, 2015 at 03:01:03PM +0000, Liviu Dudau wrote:
> > > Hello,
> > > 
> > > When booting my Juno board with the HDLCD driver that I have converted to
> > > atomic operations I'm getting the following warning:
> > 
> > Perhaps you can provide pointers to the source code, that might make it
> > easier for people to spot what's going wrong.
> > 
> > Thierry
> 
> Hi Thierry,
> 
> I have just pushed to the mailing lists my patch series. [1] [2]
> 
> If you want to checkout the code I also have a branch here:
> 
> git://git://linux-arm.org/linux-ld testing/hdlcd

Okay, so if I understand correctly you're using the tda998x as encoder/
connector attached to your new HDLCD driver. I think the problem isn't
so much that nothing has set up the CRTC for the encoder, but rather
that the tda998x encoder tries to statically associate the encoder with
the connector. While that might be correct in that it represents the
hardware state (i.e. there is no way to physically route it anywhere
else), the DRM logical state is that it's not connected until a complete
pipeline has been set up, in which case a CRTC would have been assigned
to the encoder.

If your setup were working correctly you'd never reach the WARN_ON
because the

	if (connector->encoder) {

conditional (on line 673 in drivers/gpu/drm/drm_atomic_helper.c) would
have evaluated to false already, since logically there'd be no encoder
associated with the connector yet.

Does the patch below help? Let me know and I can produce a proper patch.

Thierry

--- >8 ---
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 896b6aaf8c4d..8b0a402190eb 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1453,7 +1453,6 @@ static int tda998x_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		goto err_sysfs;
 
-	priv->connector.encoder = &priv->encoder;
 	drm_mode_connector_attach_encoder(&priv->connector, &priv->encoder);
 
 	return 0;

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ