[Intel-gfx] [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers
Daniel Vetter
daniel at ffwll.ch
Mon Apr 13 02:46:30 PDT 2015
On Thu, Apr 09, 2015 at 10:14:36PM +0000, Konduru, Chandra wrote:
>
>
> > -----Original Message-----
> > From: Roper, Matthew D
> > Sent: Thursday, April 09, 2015 2:52 PM
> > To: Konduru, Chandra
> > Cc: intel-gfx at lists.freedesktop.org; Vetter, Daniel; Conselvan De Oliveira, Ander
> > Subject: Re: [PATCH 13/14] drm/i915: skylake primary plane scaling using shared
> > scalers
> >
> > On Tue, Apr 07, 2015 at 03:28:46PM -0700, Chandra Konduru wrote:
> > > This patch enables skylake primary plane scaling using shared scalers
> > > atomic desgin.
> > >
> > > v2:
> > > -use single copy of scaler limits (Matt)
> > >
> > > v3:
> > > -move detach_scalers to crtc commit path (Matt) -use values in
> > > plane_state->src as regular integers (me)
> > >
> > > v4:
> > > -changes to align with updated scaler structures (Matt, me) -keep
> > > plane src rect in 16.16 format (Matt, Daniel)
> >
> > See comments on patch #6 that relate to this. If you want to take the approach
> > here (perform the unshift in skl_update_plane) then you also need to do the
> > same for all other platforms (ivb, ilk, vlv, etc.). But my suggestion on the other
> > patch (do the unshifting in commit_plane and leave skl_update_plane alone)
> > might be a bit simpler.
>
> Above v4: comment is saying that the change done in v3 was undone to keep
> primary_plane src rect in 16.16 format.
>
> As I responded to your patch #6 comment, moving unshift hunk (which is for
> sprite plane) from #14 to #6 will avoid any potential bisect issue that you mentioned.
>
> For other than skylake, primary planes platform level update functions doesn't use
> src_rect instead operate based on passed parameters which are in regular ints.
> Only for skylake primary plane update function, src rect is used for windowing,
> scaling purposes.
I merged up to patch 12, but this one here doesn't apply any more and I'm
not sure whether there's any changes still needed to it (it sounds like
not, but chasing that unshifting business is tricky). Chandra, can you
please resend rebased patches (with Matt's r-b added)?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list