From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: "Srinivas, Vidya" <vidya.srinivas@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Lankhorst, Maarten" <maarten.lankhorst@intel.com>
Subject: Re: [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12
Date: Wed, 4 Apr 2018 10:47:52 +0200 [thread overview]
Message-ID: <3953ae75-f15f-a2e9-d422-b5d048ecd1b8@linux.intel.com> (raw)
In-Reply-To: <F653A0A18852B74D88578FA2EB7094EAB684CEDF@BGSMSX108.gar.corp.intel.com>
Op 04-04-18 om 10:04 schreef Srinivas, Vidya:
>
>> -----Original Message-----
>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>> Sent: Wednesday, April 4, 2018 1:28 PM
>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
>> gfx@lists.freedesktop.org
>> Cc: Lankhorst, Maarten <maarten.lankhorst@intel.com>
>> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
>> for NV12
>>
>> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
>>> As per display WA 1106, to avoid corruption issues
>>> NV12 plane height needs to be multiplier of 4 We expect the src
>>> dimensions to be multiplier of 4 We fail the case where src width or
>>> height is not multiple of 4 for NV12.
>>> We also set the scaler destination height and width to be multiple of
>>> 4. Without this, pipe fifo underruns were seen on APL and KBL. We also
>>> skip src trunction/adjustments for NV12 case and handle the sizes
>>> directly in skl_update_plane
>>>
>>> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>>> drivers/gpu/drm/i915/intel_sprite.c | 19 ++++++++++++++++---
>>> 2 files changed, 18 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 9c58da0..a1f718d 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -159,6 +159,8 @@
>>> #define INTEL_I2C_BUS_DVO 1
>>> #define INTEL_I2C_BUS_SDVO 2
>>>
>>> +#define MULT4(x) ((x + 3) & ~0x03)
>>> +
>>> /* these are outputs from the chip - integrated only
>>> external chips are via DVO or SDVO output */ enum
>>> intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>>> b/drivers/gpu/drm/i915/intel_sprite.c
>>> index d5dad44..b2292dd 100644
>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
>>> uint32_t src_h = drm_rect_height(&plane_state->base.src) >> 16;
>>> unsigned long irqflags;
>>>
>>> + if (fb->format->format == DRM_FORMAT_NV12 &&
>>> + ((src_h % 4) != 0 || (src_w % 4) != 0)) {
>>> + DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
>>> + return;
>>> + }
>>> +
>> You can't do this check in skl_update_plane, it's way too late. It should be
>> rejected in the plane check with -EINVAL, or perhaps in skl_update_scaler.
> Have done it right from intel_framebuffer_init onwards, have done it in skl_update_scaler also
> In fact it will get rejected in framebuffer init and all these are duplicate checks, can remove them.
>>> /* Sizes are 0 based */
>>> src_w--;
>>> src_h--;
>>> @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
>>> PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
>> scaler->mode);
>>> I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
>>> I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
>> << 16) | crtc_y);
>>> - I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
>>> - ((crtc_w + 1) << 16)|(crtc_h + 1));
>>> -
>>> + if (fb->format->format == DRM_FORMAT_NV12)
>>> + I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
>>> + (MULT4(crtc_w) << 16) |
>> MULT4(crtc_h));
>> See the comment above, sizes are 0 based. This will add 1 to the size, so the
>> size is always 1 more than requested.
>> I don't think it would pass plane CRC tests..
> When I align it to mult of 4, 1919 (which was 1920-1) becomes 1920 back.
> If we don’t do this, I see fifo underruns. The destination width and height
> If not mult of 4, I am seeing underruns.
What you see as 1920 is 1921, which should be underrunning even more and is out of FB bounds.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-04-04 8:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-02 9:51 [PATCH v19 00/18] Add NV12 support Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 01/18] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 02/18] drm/i915/skl+: refactor WM calculation for NV12 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 03/18] drm/i915/skl+: add NV12 in skl_format_to_fourcc Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 04/18] drm/i915/skl+: support verification of DDB HW state for NV12 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 05/18] drm/i915/skl+: NV12 related changes for WM Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 06/18] drm/i915/skl+: pass skl_wm_level struct to wm compute func Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 07/18] drm/i915/skl+: make sure higher latency level has higher wm value Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 08/18] drm/i915/skl+: nv12 workaround disable WM level 1-7 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 09/18] drm/i915/skl: split skl_compute_ddb function Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 10/18] drm/i915: Display WA 827 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 11/18] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 12/18] drm/i915: Set scaler mode for NV12 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 13/18] drm/i915: Update format_is_yuv() to include NV12 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 14/18] drm/i915: Upscale scaler max scale for NV12 Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 15/18] drm/i915: Add NV12 as supported format for primary plane Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 16/18] drm/i915: Add NV12 as supported format for sprite plane Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 17/18] drm/i915: Add NV12 support to intel_framebuffer_init Vidya Srinivas
2018-04-02 9:51 ` [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12 Vidya Srinivas
2018-04-04 7:57 ` Maarten Lankhorst
2018-04-04 8:04 ` Srinivas, Vidya
2018-04-04 8:47 ` Maarten Lankhorst [this message]
2018-04-04 8:51 ` Srinivas, Vidya
2018-04-04 9:06 ` Maarten Lankhorst
2018-04-05 5:18 ` Srinivas, Vidya
2018-04-05 10:02 ` Maarten Lankhorst
2018-04-05 10:37 ` Srinivas, Vidya
2018-04-04 8:03 ` Maarten Lankhorst
2018-04-04 8:06 ` Srinivas, Vidya
2018-04-04 8:09 ` Maarten Lankhorst
2018-04-04 8:13 ` Srinivas, Vidya
2018-04-04 8:29 ` Srinivas, Vidya
2018-04-04 8:31 ` Maarten Lankhorst
2018-04-04 8:34 ` Srinivas, Vidya
2018-04-02 10:00 ` ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev7) Patchwork
2018-04-02 10:16 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-02 10:58 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-04-03 12:24 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2018-04-03 12:39 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-03 15:05 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-04-03 15:09 ` Saarinen, Jani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3953ae75-f15f-a2e9-d422-b5d048ecd1b8@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@intel.com \
--cc=vidya.srinivas@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox