On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä ville.syrjala@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