From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Vidya Srinivas <vidya.srinivas@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: ville.syrjala@intel.com, maarten.lankhorst@intel.com
Subject: Re: [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
Date: Wed, 14 Mar 2018 10:52:04 +0100 [thread overview]
Message-ID: <a736ece0-6f5a-1756-5de6-2e9111b3b0c1@linux.intel.com> (raw)
In-Reply-To: <1520585344-10094-13-git-send-email-vidya.srinivas@intel.com>
Op 09-03-18 om 09:48 schreef Vidya Srinivas:
> From: Chandra Konduru <chandra.konduru@intel.com>
>
> This patch updates scaler max limit support for NV12
>
> v2: Rebased (me)
>
> v3: Rebased (me)
>
> v4: Missed the Tested-by/Reviewed-by in the previous series
> Adding the same to commit message in this version.
>
> v5: Addressed review comments from Ville and rebased
> - calculation of max_scale to be made
> less convoluted by splitting it up a bit
> - Indentation errors to be fixed in the series
>
> v6: Rebased (me)
> Fixed review comments from Paauwe, Bob J
> Previous version, where a split of calculation
> was done, was wrong. Fixed that issue here.
>
> v7: Rebased (me)
>
> v8: Rebased (me)
>
> v9: Rebased (me)
>
> v10: Rebased (me)
>
> v11: Addressed review comments from Shashank Sharma
> Alignment issues fixed.
> When call to skl_update_scaler is made, 0 was being
> sent instead of pixel_format.
> When crtc update scaler is called, we dont have the
> fb to derive the pixel format. Added the function
> parameter bool plane_scaler_check to account for this.
>
> v12: Fixed failure in IGT debugfs_test.
> fb is NULL in skl_update_scaler_plane
> Due to this, accessing fb->format caused failure.
> Patch checks fb before using.
>
> v13: In the previous version there was a flaw.
> In skl_update_scaler during plane_scaler_check
> if the format was non-NV12, it would set need_scaling
> to false. This could reset the previously set need_scaling
> from a previous condition check. Patch fixes this.
> Patch also adds minimum src height for YUV 420 formats
> to 16 (as defined in BSpec) and adds for checking this
> range.
>
> Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
> Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
> Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
> Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> ---
> drivers/gpu/drm/i915/intel_display.c | 78 ++++++++++++++++++++++++++----------
> drivers/gpu/drm/i915/intel_drv.h | 4 +-
> drivers/gpu/drm/i915/intel_sprite.c | 3 +-
> 3 files changed, 61 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 34f7225..7fd8354 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
> case DRM_FORMAT_VYUY:
> return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
> + case DRM_FORMAT_NV12:
> + return PLANE_CTL_FORMAT_NV12;
> default:
> MISSING_CASE(pixel_format);
> }
> @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct drm_device *dev, int pipe)
> static int
> skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> unsigned int scaler_user, int *scaler_id,
> - int src_w, int src_h, int dst_w, int dst_h)
> + int src_w, int src_h, int dst_w, int dst_h,
> + bool plane_scaler_check,
> + uint32_t pixel_format)
> {
> struct intel_crtc_scaler_state *scaler_state =
> &crtc_state->scaler_state;
> @@ -4723,6 +4727,10 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> */
> need_scaling = src_w != dst_w || src_h != dst_h;
>
> + if (plane_scaler_check)
> + if (pixel_format == DRM_FORMAT_NV12)
> + need_scaling = true;
Seems redundant to add plane_scaler_check, if you can just check for scaler_user != SKL_CRTC_INDEX.
But since pixel_format is always 0 for crtc index, you can just check pixel_format == DRM_FORMAT_NV12 directly..
> if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
> need_scaling = true;
>
> @@ -4763,17 +4771,32 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> }
>
> /* range checks */
> - if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
> - dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
> -
> - src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
> - dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H) {
> - DRM_DEBUG_KMS("scaler_user index %u.%u: src %ux%u dst %ux%u "
> - "size is out of scaler range\n",
> - intel_crtc->pipe, scaler_user, src_w, src_h, dst_w, dst_h);
> - return -EINVAL;
> - }
> -
> + if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12) {
> + if (src_h > SKL_MIN_YUV_420_SRC_H)
> + goto check_scaler_range;
> + else
> + goto failed_range;
> + } else {
> + if (src_h >= SKL_MIN_SRC_H)
> + goto check_scaler_range;
> + else
> + goto failed_range;
> + }
Since nv12 always needs scaling, could we refuse to create NV12 fb's with height < 16 in intel_framebuffer_init?
This way we don't need to check in skl_update_scaler, and always do the right thing..
~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-14 9:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 8:48 [PATCH v13 00/17] Add NV12 support Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 01/17] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 02/17] drm/i915/skl+: refactor WM calculation for NV12 Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 03/17] drm/i915/skl+: add NV12 in skl_format_to_fourcc Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 04/17] drm/i915/skl+: support verification of DDB HW state for NV12 Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 05/17] drm/i915/skl+: NV12 related changes for WM Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 06/17] drm/i915/skl+: pass skl_wm_level struct to wm compute func Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 07/17] drm/i915/skl+: make sure higher latency level has higher wm value Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 08/17] drm/i915/skl+: nv12 workaround disable WM level 1-7 Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 09/17] drm/i915/skl: split skl_compute_ddb function Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 10/17] drm/i915: Set scaler mode for NV12 Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 11/17] drm/i915: Update format_is_yuv() to include NV12 Vidya Srinivas
2018-03-09 8:48 ` [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12 Vidya Srinivas
2018-03-14 9:52 ` Maarten Lankhorst [this message]
2018-03-14 10:25 ` Maarten Lankhorst
2018-03-14 10:31 ` Srinivas, Vidya
2018-03-14 10:32 ` Maarten Lankhorst
2018-03-14 10:36 ` Srinivas, Vidya
2018-03-14 15:35 ` Ville Syrjälä
2018-03-14 15:55 ` Maarten Lankhorst
2018-03-14 17:08 ` Ville Syrjälä
2018-03-14 19:03 ` Maarten Lankhorst
2018-03-15 2:30 ` Srinivas, Vidya
2018-03-15 2:35 ` Srinivas, Vidya
2018-03-09 8:49 ` [PATCH v13 13/17] drm/i915: Add NV12 as supported format for primary plane Vidya Srinivas
2018-03-09 8:49 ` [PATCH v13 14/17] drm/i915: Add NV12 as supported format for sprite plane Vidya Srinivas
2018-03-09 8:49 ` [PATCH v13 15/17] drm/i915: Add NV12 support to intel_framebuffer_init Vidya Srinivas
2018-03-09 8:49 ` [PATCH v13 16/17] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg Vidya Srinivas
2018-03-09 8:49 ` [PATCH v13 17/17] drm/i915: Display WA 827 Vidya Srinivas
2018-03-12 13:51 ` Juha-Pekka Heikkila
2018-03-14 9:12 ` Maarten Lankhorst
2018-03-14 10:33 ` Srinivas, Vidya
2018-03-09 9:12 ` ✗ Fi.CI.BAT: failure for Add NV12 support Patchwork
2018-03-09 17:59 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-09 23:23 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-03-12 13:51 ` [PATCH v13 00/17] " Juha-Pekka Heikkila
2018-03-13 2:28 ` Srinivas, Vidya
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=a736ece0-6f5a-1756-5de6-2e9111b3b0c1@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 \
--cc=ville.syrjala@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