public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Srinivas, Vidya" <vidya.srinivas@intel.com>
Cc: "Syrjala, Ville" <ville.syrjala@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Lankhorst, Maarten" <maarten.lankhorst@intel.com>
Subject: Re: [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
Date: Wed, 14 Mar 2018 17:35:54 +0200	[thread overview]
Message-ID: <20180314153554.GK5453@intel.com> (raw)
In-Reply-To: <F653A0A18852B74D88578FA2EB7094EAB6837404@BGSMSX108.gar.corp.intel.com>

On Wed, Mar 14, 2018 at 10:36:32AM +0000, Srinivas, Vidya wrote:
> 
> 
> > -----Original Message-----
> > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > Sent: Wednesday, March 14, 2018 4:03 PM
> > To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> > gfx@lists.freedesktop.org
> > Cc: Syrjala, Ville <ville.syrjala@intel.com>; Lankhorst, Maarten
> > <maarten.lankhorst@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale
> > for NV12
> > 
> > Op 14-03-18 om 11:31 schreef Srinivas, Vidya:
> > >
> > >> -----Original Message-----
> > >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > >> Sent: Wednesday, March 14, 2018 3:55 PM
> > >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> > >> gfx@lists.freedesktop.org
> > >> Cc: Syrjala, Ville <ville.syrjala@intel.com>; Lankhorst, Maarten
> > >> <maarten.lankhorst@intel.com>
> > >> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler
> > >> max scale for NV12
> > >>
> > >> Op 14-03-18 om 10:52 schreef Maarten Lankhorst:
> > >>> 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?
> > >> Hm we should probably reject this in that place anyway, but since
> > >> src_h >= SKL_MIN_YUV_420_SRC_H implies src_h >= SKL_MIN_SRC_H
> > we
> > >> don't need special handling, and can just do if (pixel_format == NV12
> > >> && src_h >= 16) return -EINVAL; and keep the existing checks.
> > >>
> > >> ~Maarten
> > > Thank you, I will make this change and float the patch.
> > >
> > > Regards
> > > Vidya
> > 
> > For the framebuffer creation also require minimum width then, since it
> > needs to be SKL_MIN_SRC_W too..
> 
> As such there is no restriction on width for YUV in Bspec. It only mentions
> about the height.

Do remember to consider 90/270 degree rotation. That's still supported
with NV12 is it not?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-14 15:35 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
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ä [this message]
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=20180314153554.GK5453@intel.com \
    --to=ville.syrjala@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