On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote: > On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote: > > Nouveau, in normal circumstances, does not need device lock for every ioctl, > > but incoming "gpu reset" code needs exclusive access to the device. > > This commit adds drm_driver flag which turns on read lock ioctl encapsulation. > > > > Signed-off-by: Marcin Slusarz <marcin.slusarz@xxxxxxxxx> > > Why can't we just move this down to nouveau driver code? I can't wrap drm core ioctls this way and adding locks at driver entry points would be at best unmaintainable, at worst - impossible (some of them are probably called in atomic context). > I really hate adding random stuff to drm core that other drivers can't opt > out of - all the dri1 nightmares are made of these essentially. It's enabled only when driver requested it. I'm not sure what dri1 nightmares you are talking about - I wasn't involved in dri1. Can you elaborate? > And radeon > and i915 seem to be able to reset without adding anything to drm core. Both radeon and i915 take per-device locks (radeon_device->cs_mutex for radeon, drm_device->struct_mutex for i915), which nouveau does not need. They might be bottlenecks some day. > So why can't nouveau do the same? Also, if this is indeed necessary and we > add this as some mandatory core infrastructure, it's not good enough: In > i915 we go to great lengths to ensure that all processes waiting for gpu > reset are still interruptible, in case the gpu reset dies unexpectedly > (which happens), so this would need to be improved. Well, I don't like non-interruptability of rwsems too, but I don't see any other locking primitive which is both interruptible and have read-write semantics. I was hoping someone would point me at one. How gpu reset can "die unexpectedly"? Marcin _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
