Re: [PATCH 1/3] drm/i915/skl: Allow universal planes to position

From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915/skl: Allow universal planes to position
Date: Mon, 9 Mar 2015 16:31:08 +0100	[thread overview]
Message-ID: <20150309153108.GN24485@phenom.ffwll.local> (raw)
In-Reply-To: <20150309152039.GU11371@intel.com>

On Mon, Mar 09, 2015 at 05:20:39PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 09:46:27AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote:
> > > 
> > > On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote:
> > > >On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote:
> > > >>Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
> > > >Imo this needs a little more commit message, and more important it needs
> > > >igt test coverage. Best approach there is probably to take the plane test
> > > >we have already and extend it to the primary plane.
> > > >-Daniel
> > > This is just to take care of the case when the size of the fb is smaller
> > > than the crtc.
> > > I have extended the rotation test (yet to be posted), to create a smaller
> > > primary plane fb to be used for 90/270 rotation.
> > > 
> > > Since we still set position to 0 for primary plane, I did not add any test
> > > case for positioning of primary plane.
> > > That can be added as a separate activity when positioning support is added.
> > > Right now this is just to allow smaller fb for primary plane which is
> > > possible with universal planes gen >=9.
> > 
> > Through universal planes it's already possible to position any plane
> > anywhere, and this code is all that makes sure this doesn't happen for the
> > primary plane. Since you've just changed that I think this needs a
> > testcase in igt.
> > 
> > Or maybe I missed something and it's indeed not yet possible to do this?
> 
> We're not ready to enable this just yet. First we need to change all the
> plane code to use the correct derived state (eg. clipped coordinates as
> opposed to the user requested ones). And to do that we must make sure
> the derived state is up to date at .crtc_enable() time.
> 
> This was one of the things I had on mind when Gustavo was reworking the
> primary/cursor plane code, but then Gustavo was pulled away and this
> task fell through the cracks. I've now cooked up something that should
> make this happen, but I haven't tested it yet. I'll give it a spin today
> and post the patch if all goes well...

Hm, is there a lot of derived state around (restricting just to skl+) once
we have the wm code converted over to always look at plane_state structs
instead of the add-hoc wm struct we currently use?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx