On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 27 Jul 2011 02:21:24 -0700 > Keith Packard <keithp@xxxxxxxxxx> wrote: > > > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > > > > I'd like to amend my reviewed by and say the lock shouldn't be held > > > around the call to the drm helper function. It queues some work that > > > also takes the mode config lock, which will break. So you can drop it > > > before that... Previously I had only checked our internal driver > > > callbacks but missed that the lock was held across the helper too. > > > > So the work may get executed immediately rather than being run later at > > some point? > > It sure looks that way... but I don't remember any rule about work > queue items having inter dependencies like this. Sounds fine; I've stuck a fixup that moves the mutex_unlock: if (encoder->hot_plug) encoder->hot_plug(encoder); + mutex_unlock(&mode_config->mutex); + /* Just fire off a uevent and let userspace tell us what to do */ drm_helper_hpd_irq_event(dev); - - mutex_unlock(&mode_config->mutex); } -- keith.packard@xxxxxxxxx
Attachment:
pgpFvRx7n_Hmg.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
