[Intel-gfx] [PATCH 3/9] drm/i915: Use plane->state->fb instead of plane->fb in intel_plane_restore()

[Daniel Vetter]

On Wed, Mar 11, 2015 at 10:41:30AM +0100, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 07:48:39PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 10, 2015 at 10:01:47AM -0700, Matt Roper wrote:
> > > On Tue, Mar 10, 2015 at 01:15:23PM +0200, ville.syrjala at linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > plane->fb is not as reliable as plane->state->fb so let's convert
> > > > intel_plane_restore() over the the new way of thinking as well.
> > > > 
> > > > Cc: Matt Roper <matthew.d.roper at intel.com>
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > > > index 7051da7..a828736 100644
> > > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > > @@ -1361,10 +1361,10 @@ out_unlock:
> > > >  
> > > >  int intel_plane_restore(struct drm_plane *plane)
> > > >  {
> > > > -	if (!plane->crtc || !plane->fb)
> > > > +	if (!plane->crtc || !plane->state->fb)
> > > >  		return 0;
> > > >  
> > > > -	return plane->funcs->update_plane(plane, plane->crtc, plane->fb,
> > > > +	return plane->funcs->update_plane(plane, plane->crtc, plane->state->fb,
> > > 
> > > While we're at it, should we s/plane->crtc/plane->state->crtc/ as well?
> > 
> > I tried to make that change everywhere and it blew up. But I think that
> > was simply because I changed it some .commit hook as well, and currently
> > we don't have the old state around there, so the 'crtc ? crtc : state->crtc'
> > just ended up as 'crtc' effectively and that of course didn't work as well
> > as I'd hoped ;)
> > 
> > But yeah maybe we should make that change. Would just need to pass the
> > old state to commit instead of the new state, I think.
> 
> Not sure we should be too agressive with mass-conversion. E.g. for the
> plane restore I expect that we'll do some overall atomic helper to
> snapshot/restore all the state for suspend/resume and similar cases.
> -Daniel
> > 
> > > 
> > > Otherwise, 1-3 are
> > > 
> > > Reviewed-by: Matt Roper <matthew.d.roper at intel.com>

Oh and: Merged first three, thanks for review&patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch