Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Nemesa Garg <nemesa.garg@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/display: Workaround for odd panning for planar yuv
Date: Fri, 6 Sep 2024 11:33:14 -0400	[thread overview]
Message-ID: <ZtsgupqnywP0icEk@intel.com> (raw)
In-Reply-To: <87plpgn9vy.fsf@intel.com>

On Fri, Sep 06, 2024 at 05:18:25PM +0300, Jani Nikula wrote:
> On Fri, 06 Sep 2024, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> > On Fri, Sep 06, 2024 at 11:51:50AM GMT, Jani Nikula wrote:
> >>
> >>Cc: Rodrigo and Lucas, note for you at the end.
> >>
> >>On Fri, 06 Sep 2024, Nemesa Garg <nemesa.garg@intel.com> wrote:
> >>> Disable the support for odd x pan for NV12 format as underrun
> >>> issue is seen.
> >>>
> >>> WA: 16024459452
> >>>
> >>> Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
> >>> ---
> >>>  .../gpu/drm/i915/display/intel_atomic_plane.c    | 16 ++++++++++++++--
> >>>  drivers/gpu/drm/i915/display/intel_display_wa.h  |  2 ++
> >>>  drivers/gpu/drm/xe/display/xe_display_wa.c       |  5 +++++
> >>>  3 files changed, 21 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>> index e979786aa5cf..9b17321f3477 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>> @@ -47,11 +47,13 @@
> >>>  #include "intel_display_rps.h"
> >>>  #include "intel_display_trace.h"
> >>>  #include "intel_display_types.h"
> >>> +#include "intel_display_wa.h"
> >>>  #include "intel_fb.h"
> >>>  #include "intel_fb_pin.h"
> >>>  #include "skl_scaler.h"
> >>>  #include "skl_watermark.h"
> >>>
> >>> +
> >>
> >>Superfluous newline.
> >>
> >>>  static void intel_plane_state_reset(struct intel_plane_state *plane_state,
> >>>  				    struct intel_plane *plane)
> >>>  {
> >>> @@ -1029,8 +1031,18 @@ int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state)
> >>>  		 * This allows NV12 and P0xx formats to have odd size and/or odd
> >>>  		 * source coordinates on DISPLAY_VER(i915) >= 20
> >>>  		 */
> >>> -		hsub = 1;
> >>> -		vsub = 1;
> >>> +
> >>> +		/*
> >>> +		 * Wa_16023981245 for display version 20.
> >>> +		 * Do not support odd x-panning for NV12.
> >>> +		 */
> >>> +		if (intel_display_needs_wa_16023981245(i915) &&
> >>> +		    fb->format->format == DRM_FORMAT_NV12) {
> >>> +			vsub = 1;
> >>> +		} else {
> >>> +			hsub = 1;
> >>> +			vsub = 1;
> >>> +		}
> >>
> >>Nitpick, the whole thing could be simplified to only touch hsub since
> >>the w/a is about x-panning and vsub is the same in both branches.
> >>
> >>>  	} else {
> >>>  		hsub = fb->format->hsub;
> >>>  		vsub = fb->format->vsub;
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_wa.h b/drivers/gpu/drm/i915/display/intel_display_wa.h
> >>> index be644ab6ae00..9be35a751503 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_display_wa.h
> >>> +++ b/drivers/gpu/drm/i915/display/intel_display_wa.h
> >>> @@ -14,8 +14,10 @@ void intel_display_wa_apply(struct drm_i915_private *i915);
> >>>
> >>>  #ifdef I915
> >>>  static inline bool intel_display_needs_wa_16023588340(struct drm_i915_private *i915) { return false; }
> >>> +static inline bool intel_display_needs_wa_16023981245(struct drm_i915_private *i915) { return false; }
> >>>  #else
> >>>  bool intel_display_needs_wa_16023588340(struct drm_i915_private *i915);
> >>> +bool intel_display_needs_wa_16023981245(struct drm_i915_private *i915);
> >>>  #endif
> >>>
> >>>  #endif
> >>> diff --git a/drivers/gpu/drm/xe/display/xe_display_wa.c b/drivers/gpu/drm/xe/display/xe_display_wa.c
> >>> index 68e3d1959ad6..fde4e09589a3 100644
> >>> --- a/drivers/gpu/drm/xe/display/xe_display_wa.c
> >>> +++ b/drivers/gpu/drm/xe/display/xe_display_wa.c
> >>> @@ -14,3 +14,8 @@ bool intel_display_needs_wa_16023588340(struct drm_i915_private *i915)
> >>>  {
> >>>  	return XE_WA(xe_root_mmio_gt(i915), 16023588340);
> >>>  }
> >>> +
> >>> +bool intel_display_needs_wa_16023981245(struct drm_i915_private *i915)
> >>> +{
> >>> +	return XE_WA(xe_root_mmio_gt(i915), 22019338487_display);
> >>
> >>16023981245 vs 22019338487 and not explained in the commit message?!?
> >>
> >>Rodrigo, Lucas, I think we're going to need to handle display
> >>workarounds separately in i915 display. I'm fine with merging this now,
> >>it's not a big deal, but this interface is not future compatible.
> >>
> >>The first step could be simply converting these two to the old style
> >>workarounds in i915 display, i.e. just checking for display version or
> >>platform directly, and later adding wa infrastructure similar to what xe
> >>has, but for display only.
> >
> > Do you expect any WA like this to be enabled for both xe and i915? There
> > are no platform with i915 and display_ver == 20.  I think for past
> > platforms, just following the display version and platform check is fine.
> > For newer ones, where there's only support in xe, we use the xe way.
> 
> Consider having an independent intel-display.ko that caters for display
> IP support, regardless of whether it's being used by i915 or xe.
> 
> >From that perspective, any interfaces like this become increasingly
> weird. Display code should depend on its own platform, display version
> and stepping identification, also for workarounds.
> 
> The xe_wa_oob.rules file doesn't have a single display version or
> stepping check. There's a single display w/a that looks at
> PLATFORM(LUNARLAKE). And that's all it can do. Nowadays xe core doesn't
> have the information on display version or stepping. It has no business
> looking at the guts of struct intel_display to figure it out.

Yeap, I agree with Jani here. Regardless of which platform is calling the
display side, intel_display should be in full control of its IP block
including the W/As.

Perhaps we could add a display wa infra similar to this nice xe one
there as well.

> 
> BR,
> Jani.
> 
> 
> >
> > Lucas De Marchi
> >
> >>
> >>BR,
> >>Jani.
> >>
> >>
> >>
> >>> +}
> >>
> >>
> >>
> >>
> >>
> >>-- 
> >>Jani Nikula, Intel
> 
> -- 
> Jani Nikula, Intel

  reply	other threads:[~2024-09-06 15:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06  7:01 [PATCH] drm/i915/display: Workaround for odd panning for planar yuv Nemesa Garg
2024-09-06  8:09 ` ✓ CI.Patch_applied: success for drm/i915/display: Workaround for odd panning for planar yuv (rev2) Patchwork
2024-09-06  8:09 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-06  8:10 ` ✓ CI.KUnit: success " Patchwork
2024-09-06  8:30 ` ✓ CI.Build: " Patchwork
2024-09-06  8:32 ` ✓ CI.Hooks: " Patchwork
2024-09-06  8:41 ` ✗ CI.checksparse: warning " Patchwork
2024-09-06  8:51 ` [PATCH] drm/i915/display: Workaround for odd panning for planar yuv Jani Nikula
2024-09-06  9:07   ` Jani Nikula
2024-09-06 13:51   ` Lucas De Marchi
2024-09-06 14:18     ` Jani Nikula
2024-09-06 15:33       ` Rodrigo Vivi [this message]
2024-09-06  9:46 ` ✗ CI.BAT: failure for drm/i915/display: Workaround for odd panning for planar yuv (rev2) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2024-09-30 11:21 [PATCH] drm/i915/display: Workaround for odd panning for planar yuv Nemesa Garg
2024-10-16  7:24 ` Nemesa Garg
2024-10-17  8:05   ` Kandpal, Suraj
2024-10-17 16:53     ` Pottumuttu, Sai Teja
2024-10-18  5:04       ` Garg, Nemesa
2024-10-18  5:05         ` Garg, Nemesa
2024-10-18  5:44         ` Chauhan, Shekhar
2024-10-18 17:36           ` Matt Roper
2024-09-25 12:25 Nemesa Garg
2024-09-25 13:09 ` Jani Nikula
2024-09-25 13:57 ` Pottumuttu, Sai Teja
2024-09-10 14:37 Nemesa Garg
2024-09-10 16:36 ` Pottumuttu, Sai Teja
2024-09-25  7:49   ` Garg, Nemesa
2024-07-24 13:06 Nemesa Garg
2024-07-24 17:01 ` Kandpal, Suraj
2024-07-25  2:59   ` Kandpal, Suraj
2024-08-12  5:18     ` Garg, Nemesa

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=ZtsgupqnywP0icEk@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=nemesa.garg@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