diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2013-11-03 20:27:05 +0100 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2014-04-22 11:41:12 +0200 |
commit | e090c53b21e97864a25ada5c8437d9776978a050 (patch) | |
tree | 123bc619a4f92c72f483f95358517140f35291e1 /drivers/gpu/drm/radeon/radeon_state.c | |
parent | 22471cf638bab5d78ee1e6c465c9d7c1971ebbf5 (diff) | |
download | talos-op-linux-e090c53b21e97864a25ada5c8437d9776978a050.tar.gz talos-op-linux-e090c53b21e97864a25ada5c8437d9776978a050.zip |
drm/irq: remove cargo-culted locking from irq_install/uninstall
The dev->struct_mutex locking in drm_irq.c only protects
dev->irq_enabled. Which isn't really much at all and only prevents
especially nasty ums userspace from concurrently installing the
interrupt handling a few times. Or at least trying.
There are tons of unlocked readers of dev->irqs_enabled in the vblank
wait code (and by extension also in the pageflip code since that uses
the same vblank timestamp engine).
Real modesetting drivers should ensure that nothing can go haywire
with a sane setup teardown sequence. So we only really need this for
the drm_control ioctl, everywhere else this will just paper over
nastiness.
Note that drm/i915 is a bit specially due to the gem+ums combination.
So there we also need to properly protect the entervt and leavevt
ioctls. But it's definitely saner to do everything in one go than to
drop the lock in-between.
Finally there's the gpu reset code in drm/i915. That one's just race
(concurrent userspace calls to for vblank waits of pageflips could
spuriously fail). So wrap it up in with a nice comment since fixing
this is more involved.
v2: Rebase and fix commit message (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/radeon/radeon_state.c')
0 files changed, 0 insertions, 0 deletions