Re: [RFC 2/3] drm/i915: create intel_update_pipe_size()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 09, 2014 at 02:43:14PM -0300, Gustavo Padovan wrote:
> 2014-09-09 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>:
> 
> > On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
> > > 
> > > Factor out a piece of code from intel_pipe_set_base() that updates
> > > the pipe size and adjust fitter.
> > > 
> > > This will help refactor the update primary plane path.
> > > 
> > > Signed-off-by: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 71 +++++++++++++++++++++---------------
> > >  1 file changed, 41 insertions(+), 30 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 2ccf7c0..e7e7184 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2779,6 +2779,46 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
> > >  	return pending;
> > >  }
> > >  
> > > +static void intel_update_pipe_size(struct drm_crtc *crtc)
> > 
> > These days we usually prefer to pass intel_crtc instead of drm_crtc. You
> > can still call it 'crtc' since that's shorter and because we don't need
> > anything from drm_crtc in this function there won't be any confusion
> > between the two.
> 
> Actually we need the drm_crtc 3 times in this function, that is why I left it
> as an argument. We could just do the other way around and get it from
> &intel_crtc->base.

Yeah I prefer we use the intel_foo types internally without an intel_
prefix in the local variable name. Adding the foo->base. prefix isn't
really much longer than just foo.

Imo upcasting should only be done in interface hooks where we have a
reason for the paramater to have the more generic type, everywhere else it
just looks a bit brittle. And yes I know that we're not there at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux