On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote: >> And if we _really_ want such semantics, we can always get them by >> introducing another pageflip mutex between the mode_config.mutex and >> the individual crtc locks. Pageflips crossing more than one crtc >> would then need to take that lock first, to lock out concurrent >> multi-crtc pageflips. > > I'm actually concerned with multi CRTC page flips, not for moving planes > between CRTCs, but mainly for updating content on genlocked displays > atomically. We need to avoid deadlocks between multiple CRTC locks. Trying > to take the CRTC locks in the same order would be a solution, but since > user space can send the props in any order, it's going to require extra > of work.
Ordering CRTC locks should also work - modeset_lock_all takes them always in the same order, and as long as you only take a single crtc nested within the modeset lock that's still ok (e.g. the load-detect code). We don't have many CRTCs, so even the dumbest sort will be fast enough. A bit of work will be required to make lockdep happy. But we can achieve this by nesting CRTCs within a fake lock encapsulated by the lock/unlock helper functions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
