path: root/Documentation/DocBook
diff options
authorDaniel Vetter <daniel.vetter@ffwll.ch>2012-12-12 00:35:33 +0100
committerDaniel Vetter <daniel.vetter@ffwll.ch>2013-01-20 22:17:15 +0100
commit7b24056be6db7ce907baffdd4cf142ab774ea60c (patch)
tree63ecb8c4bc549e90d0ddf7b937537a392b3060a1 /Documentation/DocBook
parentb4d5e7d1dbdd6a758a4f7717beef7bd6b007bd66 (diff)
drm: don't hold crtc mutexes for connector ->detect callbacks
The coup de grace of the entire journey. No more dropped frames every 10s on my testbox! I've tried to audit all ->detect and ->get_modes callbacks, but things became a bit fuzzy after trying to piece together the umpteenth implemenation. Afaict most drivers just have bog-standard output register frobbing with a notch of i2c edid reading, nothing which could potentially race with the newly concurrent pageflip/set_cursor code. The big exception is load-detection code which requires a running pipe, but radeon/nouveau seem to to this without touching any state which can be observed from page_flip (e.g. disabled crtcs temporarily getting enabled and so a pageflip succeeding). The only special case I could find is the i915 load detect code. That uses the normal modeset interface to enable the load-detect crtc, and so userspace could try to squeeze in a pageflip on the load-detect pipe. So we need to grab the relevant crtc mutex in there, to avoid the temporary crtc enabling to sneak out and be visible to userspace. Note that the sysfs files already stopped grabbing the per-crtc locks, since I didn't want to bother with doing a interruptible modeset_lock_all. But since there's very little in-between breakage (essentially just the ability for userspace to pageflip on load-detect crtcs when it shouldn't on the i915 driver) I figured I don't need to bother. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'Documentation/DocBook')
0 files changed, 0 insertions, 0 deletions