[Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position

[Daniel Vetter]

On Mon, Apr 06, 2015 at 10:50:51AM +0530, Jindal, Sonika wrote:
> 
> 
> On 4/2/2015 9:18 PM, Matt Roper wrote:
> >On Thu, Apr 02, 2015 at 10:08:27AM +0530, Jindal, Sonika wrote:
> >>
> >>
> >>On 4/1/2015 11:51 PM, Matt Roper wrote:
> >>>On Mon, Mar 30, 2015 at 02:04:56PM +0530, Sonika Jindal wrote:
> >>>>Signed-off-by: Sonika Jindal <sonika.jindal at intel.com>
> >>>
> >>>It looks like this is dependent on Ville's patch
> >>>
> >>>   [PATCH v2 6/9] drm/i915: Pass the primary plane position to .update_primary_plane()
> >>>
> >>>to actually let us do something sensible with the destination rectangle
> >>>at the hardware level.  Looks like that patch has a r-b, but hasn't made
> >>>it into di-nightly yet.
> >>>
> >>Right now, can_position is used to check for the scenarios where the
> >>primary plane is not covering the complete crtc. This could be due
> >>to positioning or a smaller fb on primary plane.
> >>With Ville's patch, we would be able to allow positioning to happen.
> >>But I need it here, to create a smaller fb for 90/270 rotation.
> >>
> >>I agree that, until Ville's patch is there, we won't be entertaining
> >>any positioning requests on the primary plane and we will not be
> >>throwing any error also.
> >
> >Right...and I think failing to throw an error would be seen as a bug,
> >which is why I think Ville's patch needs to go in first.  Since it's
> >already been reviewed, I'm not aware of anything holding that up from
> >happening.
> >
> Agree, will check with Daniel on this.
> 
> >>But for the 90/270 testcase in kms_rotation_crc to go through, we
> >>would need this to create a smaller fb so that we can rotate it.
> >
> >So is your worry here that drm_plane_helper_check_update() doesn't
> >understand rotation and winds up mixing up width/height?  If so, I think
> >the proper course of action is to write a patch for the helper function
> >that makes it rotation-aware.
> >
> No, the worry is that it rejects a smaller fb for primary plane for all the
> platforms. I mentioned 90/270 rotation, because I create a smaller fb
> (rather than the full screen fb), so that the rotated plane fits into the
> screen. If it is lets say 1920x1080, and the pipe is set at 1920x1080, after
> rotation the plane becomes 1080x1920 and the height of the plane surpasses
> that of crtc.
> For gen >=9 , we can have smaller fb for primary plane which might not cover
> the entire crtc.

That sounds like a bug in the helper though if it rejects such a
framebuffer.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch