From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Sharma, Shashank" <shashank.sharma@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Syrjala, Ville" <ville.syrjala@intel.com>,
"Lankhorst, Maarten" <maarten.lankhorst@intel.com>
Subject: Re: [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
Date: Thu, 2 May 2019 14:51:27 +0300 [thread overview]
Message-ID: <20190502115127.GL24299@intel.com> (raw)
In-Reply-To: <FF3DDC77922A8A4BB08A3BC48A1EA8CB8DEC4281@BGSMSX101.gar.corp.intel.com>
On Thu, May 02, 2019 at 10:40:39AM +0000, Sharma, Shashank wrote:
>
>
> > -----Original Message-----
> > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > Sent: Thursday, May 2, 2019 3:45 PM
> > To: Sharma, Shashank <shashank.sharma@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville <ville.syrjala@intel.com>; Lankhorst,
> > Maarten <maarten.lankhorst@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for
> > BT2020 framebuffers
> >
> > On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> > > Framebuffer formats P01x are supported by GLK, but the function which
> > > handles CSC on plane color control register, still expectes the input
> > > buffer to be REC709. This can cause inaccurate output for direct P01x
> > > flips.
> > >
> > > This patch checks if the color_encoding property is set to YCBCR_2020,
> > > and enables the corresponding color conversion mode on plane CSC.
> > >
> > > PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
> > >
> > > Cc: Ville Syrjala <ville.syrjala@intel.com>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
> > > Cc: Uma Shankar <uma.shankar@intel.com>
> > > Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 26 ++++++++++++++++----------
> > > 1 file changed, 16 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index dd65d7c521c1..2d4d3128bf1f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> > *crtc_state,
> > > to_i915(plane_state->base.plane->dev);
> > > const struct drm_framebuffer *fb = plane_state->base.fb;
> > > struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > > - u32 plane_color_ctl = 0;
> > > + u32 color_ctl = 0;
> > >
> > > - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > - plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > > + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > >
> > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > > - if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
> > > - plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > - else
> > > - plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > + switch (plane_state->base.color_encoding) {
> > > + case DRM_COLOR_YCBCR_BT709:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > + break;
> > > + case DRM_COLOR_YCBCR_BT2020:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > + break;
> > > + default:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > + }
> >
> > This isn't going to do anything without adjusting the property supported encodings as
> > well.
> >
> I might have not understood this comment properly, but, AFAIK, if userspace sets this property well, and we set this color_ctl bit properly, driver is setting PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020 bits in GLK color control register. As GLK has a fix function plane CSC, HW will apply a different matrix internally to convert input buffer to RGB_2020 from YCBCR_2020 (earlier this would have been YCBCR_709). So I think we should see visible changes in output. Do you think otherwise ?
The property won't accept the BT2020 value. Or if it does we have a bug
somewhere.
I guess tests would be nice. Maybe we should extend the kms_plane pixel
format tests to check different YCbCr encodings as well? Or maybe
Maarten's kms_yuv already tests this?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-05-02 11:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-02 9:49 [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers Shashank Sharma
2019-05-02 10:15 ` Ville Syrjälä
2019-05-02 10:40 ` Sharma, Shashank
2019-05-02 11:51 ` Ville Syrjälä [this message]
2019-05-02 14:32 ` Lankhorst, Maarten
2019-05-02 14:08 ` ✓ Fi.CI.BAT: success for " Patchwork
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=20190502115127.GL24299@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@intel.com \
--cc=shashank.sharma@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 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.