[Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Maarten Lankhorst]

Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> Lets move this to intel-gfx to get more eyes on it. 
>
>> -----Original Message-----
>> From: Srinivas, Vidya
>> Sent: tiistai 17. huhtikuuta 2018 5.47
>> To: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>; intel-gfx-
>> trybot at lists.freedesktop.org
>> Cc: Kamath, Sunil <sunil.kamath at intel.com>; Saarinen, Jani
>> <jani.saarinen at intel.com>
>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
>>
>>
>>
>>> -----Original Message-----
>>> From: Maarten Lankhorst [mailto:maarten.lankhorst at linux.intel.com]
>>> Sent: Monday, April 16, 2018 8:00 PM
>>> To: Srinivas, Vidya <vidya.srinivas at intel.com>; intel-gfx-
>>> trybot at lists.freedesktop.org
>>> Cc: Kamath, Sunil <sunil.kamath at intel.com>; Saarinen, Jani
>>> <jani.saarinen at intel.com>
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>>> NV12
>>>
>>> Hmm, more thought about src adjustments...
>>>
>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>>> We skip src trunction/adjustments for
>>>> NV12 case and handle the sizes directly.
>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>
>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>
>>>> Credits-to: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas at intel.com>
>>>> ---
>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>>>>  2 files changed, 26 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>> index bc83f10..f64708f 100644
>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>> intel_plane *plane,
>>>>  	bool can_position = false;
>>>>  	int ret;
>>>>  	uint32_t pixel_format = 0;
>>>> +	struct drm_plane_state *plane_state = &state->base;
>>>> +	struct drm_rect *src = &plane_state->src;
>>>> +
>>>> +	*src = drm_plane_state_src(plane_state);
>>>>
>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
>>>>  		/* use scaler when colorkey is not required */ @@ -13001,6
>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
>>>>  	if (!state->base.fb)
>>>>  		return 0;
>>>>
>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>>> +	}
>>> Lets reject non multiple of 4 coordinates for plane_state's src_x and
>>> src_y, and before adjustment also reject non multiple of 4
>>> src_w/src_h.fter that we can also reject clipping to the right/bottom
>>> edge of the screen, if the pipe_src_w/h is not a multiple of 4. That
>>> way an application trying to go beyond the screen.
>> kms_plane_scaling and some other tests during execution generate lots of
>> non mult of 4 buffer width/height. All these tests will show fail in the IGT
>> BAT.
>> In some cases, even thought the width and height will be multiple of 4
>> before the Adjustment (say our 16x16 buffer), this after adjustment
>> becomes a 15 in intel_check_sprite_plane.
>> This again would cause underrun. If we reject non multiple of 4s in our
>> skl_update_scaler also, then even simple tests with 16x16 like rotation will
>> fail due to it getting adjusted.

Correct. This is why we fix up to a multiple of 4 after adjustments, and
reject user passed coordinates before adjustment.. plane_state->src_x/y/w/h
is the property set by the user, while the plane_state->src rect is set and
fixed up in the kernel.

Rejecting clipping with positive coordinates if pipe_src w/h
is not a multiple of 4 will fix a border case that shouldn't affect most modes,
where the plane wouldn't extend to the crtc borders, which is what userspace wants there.