On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes <jbar...@virtuousgeek.org> wrote: > On Wed, 27 Jul 2011 02:21:24 -0700 > Keith Packard <kei...@keithp.com> wrote: > > > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes <jbar...@virtuousgeek.org> > > 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.pack...@intel.com
pgpNWPHfP4boK.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
