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
next prev parent 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