On Thu, Dec 13, 2012 at 12:54:44PM +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrj?l?
> 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
On Wed, Dec 12, 2012 at 02:06:50PM +0100, Daniel Vetter wrote:
> *drumroll*
>
> The basic idea is to protect per-crtc state which can change without
> touching the output configuration with separate mutexes, i.e. all the
> input side state to a crtc like framebuffers, cursor settings or plane
>
On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrj?l?
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
On Wed, Dec 12, 2012 at 02:06:50PM +0100, Daniel Vetter wrote:
*drumroll*
The basic idea is to protect per-crtc state which can change without
touching the output configuration with separate mutexes, i.e. all the
input side state to a crtc like framebuffers, cursor settings or plane
On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä
ville.syrj...@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
On Thu, Dec 13, 2012 at 12:54:44PM +0100, Daniel Vetter wrote:
On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä
ville.syrj...@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
