summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/radeon
diff options
context:
space:
mode:
authorIlija Hadzic <ihadzic@research.bell-labs.com>2011-10-31 22:46:18 +0100
committerDave Airlie <airlied@redhat.com>2011-11-11 12:12:47 +0100
commit8f4ff2b06afcd6f151868474a432c603057eaf56 (patch)
tree5ca22d67a97f55184b04f2ac94c1d6362edbad65 /drivers/gpu/drm/radeon
parentMAINTAINERS: exynos: Add EXYNOS DRM maintainer entry (diff)
downloadlinux-8f4ff2b06afcd6f151868474a432c603057eaf56.tar.xz
linux-8f4ff2b06afcd6f151868474a432c603057eaf56.zip
drm: do not sleep on vblank while holding a mutex
drm_wait_vblank must be DRM_UNLOCKED because otherwise it will grab the drm_global_mutex and then go to sleep until the vblank event it is waiting for. That can wreck havoc in the windowing system because if one process issues this ioctl, it will block all other processes for the duration of all vblanks between the current and the one it is waiting for. In some cases it can block the entire windowing system. v2: incorporate comments received from Daniel Vetter and Michel Daenzer. v3/v4: after a lengty discussion with Daniel Vetter, it was concluded that the only thing not yet protected with locks and atomic ops is the write to dev->last_vblank_wait. It's only used in a debug file in proc, and the current code already employs no correct locking: the proc file only takes dev->struct_mutex, whereas drm_wait_vblank implicitly took the drm_global_mutex. Given all this, it's not worth bothering to try to fix the locks at this time. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'drivers/gpu/drm/radeon')
0 files changed, 0 insertions, 0 deletions