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@xxxxxxxxx>
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.
Regards,
Sonika
Matt
Assuming Ville's patch lands first, this is
Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
Matt
---
drivers/gpu/drm/i915/intel_display.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61..f0bbc22 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12150,16 +12150,21 @@ intel_check_primary_plane(struct drm_plane *plane,
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ bool can_position = false;
int ret;
crtc = crtc ? crtc : plane->crtc;
intel_crtc = to_intel_crtc(crtc);
+ if (INTEL_INFO(dev)->gen >= 9)
+ can_position = true;
+
ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
- false, true, &state->visible);
+ can_position, true,
+ &state->visible);
if (ret)
return ret;
--
1.7.10.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
