On Fri, Aug 29, 2014 at 12:09:39PM -0300, Gustavo Padovan wrote:
> 2014-08-29 Ville Syrj?l? :
>
> > On Thu, Aug 28, 2014 at 02:40:08PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Due to the upcoming atomic modesetting feature we need to separate
> > > some update functi
On Fri, Aug 29, 2014 at 5:38 PM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:
> > Would grabbing
> > struct drm_plane_state from the atomic branch fix this for you?
>
> That looks like it's meant to house the user requested coordinates
> rather than the clipped ones. What you could do
On Fri, Aug 29, 2014 at 10:55:41AM +0300, Ville Syrj?l? wrote:
> On Thu, Aug 28, 2014 at 02:40:08PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Due to the upcoming atomic modesetting feature we need to separate
> > some update functions into a check step that can fail and a co
2014-08-29 Ville Syrj?l? :
> On Thu, Aug 28, 2014 at 02:40:08PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Due to the upcoming atomic modesetting feature we need to separate
> > some update functions into a check step that can fail and a commit
> > step that should, ideally,
On Thu, Aug 28, 2014 at 02:40:08PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Due to the upcoming atomic modesetting feature we need to separate
> some update functions into a check step that can fail and a commit
> step that should, ideally, never fail.
>
> This commit splits int
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning proc
