From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Vodapalli, Ravi Kumar" <ravi.kumar.vodapalli@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes
Date: Thu, 16 Jan 2025 21:50:19 +0200 [thread overview]
Message-ID: <Z4li-1CL5NGJ0b8E@intel.com> (raw)
In-Reply-To: <be79d5ff-a398-4907-94dc-309b45dd2a5b@intel.com>
On Tue, Dec 31, 2024 at 08:01:21PM +0530, Vodapalli, Ravi Kumar wrote:
>
>
>
> On 12/18/2024 11:06 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä<ville.syrjala@linux.intel.com>
> >
> > I'm seeing underruns with these 64bpp YUV formats on TGL.
> >
> > The weird details:
> > - only happens on pipe B/C/D SDR planes, pipe A SDR planes
> > seem fine, as do all HDR planes
> > - somehow CDCLK related, higher CDCLK allows for bigger plane
> > with these formats without underruns. With 300MHz CDCLK I
> > can only go up to 1200 pixels wide or so, with 650MHz even
> > a 3840 pixel wide plane was OK
> > - ICL and ADL so far appear unaffected
> >
> > So not really sure what's the deal with this, but bspec does
> > state "64-bit formats supported only on the HDR planes" so
> > let's just drop these formats from the SDR planes. We already
> > disallow 64bpp RGB formats.
> >
> > Cc:stable@vger.kernel.org
> > Signed-off-by: Ville Syrjälä<ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index ff9764cac1e7..80e558042d97 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -106,8 +106,6 @@ static const u32 icl_sdr_y_plane_formats[] = {
> > DRM_FORMAT_Y216,
> > DRM_FORMAT_XYUV8888,
> > DRM_FORMAT_XVYU2101010,
> > - DRM_FORMAT_XVYU12_16161616,
> > - DRM_FORMAT_XVYU16161616,
> > };
>
> If we are seeing underrun on TGL platform only then better would be if
> we define separate variable similar to
> icl_sdr_y_plane_formats since this variable is used for other platforms
> >= 11
Meh. Docs say this shouldn't really be supported in the first place
so I'm inclined to just nuke it across the board. I suspect no one
will actually notice.
>
> >
> > static const u32 icl_sdr_uv_plane_formats[] = {
> > @@ -134,8 +132,6 @@ static const u32 icl_sdr_uv_plane_formats[] = {
> > DRM_FORMAT_Y216,
> > DRM_FORMAT_XYUV8888,
> > DRM_FORMAT_XVYU2101010,
> > - DRM_FORMAT_XVYU12_16161616,
> > - DRM_FORMAT_XVYU16161616,
> > };
>
> same as above define separate variable
>
> Regards
> Ravi Kumar V
>
> >
> > static const u32 icl_hdr_plane_formats[] = {
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-01-16 19:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 17:36 [PATCH 0/4] drm/i915: Drop 64bpp YUV formats for SDR planes and improve tracepoints Ville Syrjala
2024-12-18 17:36 ` [PATCH 1/4] drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes Ville Syrjala
2024-12-31 14:31 ` Vodapalli, Ravi Kumar
2025-01-16 19:50 ` Ville Syrjälä [this message]
2024-12-18 17:36 ` [PATCH 2/4] drm/i915: Drop the extra "plane" from tracpoints Ville Syrjala
2024-12-18 17:36 ` [PATCH 3/4] drm/i915: Pass the plane state explicitly to tracpoints Ville Syrjala
2024-12-18 17:36 ` [PATCH 4/4] drm/i915: Include pixel format in plane tracpoints Ville Syrjala
2024-12-18 18:22 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Drop 64bpp YUV formats for SDR planes and improve tracepoints Patchwork
2024-12-18 18:22 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-12-18 18:39 ` ✗ i915.CI.BAT: failure " Patchwork
2025-01-13 14:56 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Drop 64bpp YUV formats for SDR planes and improve tracepoints (rev2) Patchwork
2025-01-13 14:56 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-01-13 15:25 ` ✓ i915.CI.BAT: success " Patchwork
2025-01-15 2:44 ` ✗ i915.CI.Full: failure " Patchwork
2025-01-22 16:34 ` [PATCH 0/4] drm/i915: Drop 64bpp YUV formats for SDR planes and improve tracepoints Juha-Pekka Heikkilä
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=Z4li-1CL5NGJ0b8E@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ravi.kumar.vodapalli@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.