[Intel-gfx] [PATCH 09/10] drm/i915: Get rid of glk_load_degamma_lut_linear()
Shankar, Uma
uma.shankar at intel.com
Wed Oct 19 07:49:36 UTC 2022
> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Sent: Wednesday, October 19, 2022 1:00 PM
> To: Shankar, Uma <uma.shankar at intel.com>
> Cc: intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 09/10] drm/i915: Get rid of
> glk_load_degamma_lut_linear()
>
> On Wed, Oct 19, 2022 at 07:20:13AM +0000, Shankar, Uma wrote:
> >
> >
> > > -----Original Message-----
> > > From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf
> > > Of Ville Syrjala
> > > Sent: Thursday, September 29, 2022 12:45 PM
> > > To: intel-gfx at lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 09/10] drm/i915: Get rid of
> > > glk_load_degamma_lut_linear()
> > >
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >
> > > Since we now have a place (pre_csc_lut) to stuff a purely internal
> > > LUT we can replace glk_load_degamma_lut_linear() with such a thing
> > > and just rely on the normal
> > > glk_load_degamma_lut() to load it as well.
> > >
> > > drm_mode_config_cleanup() will clean this up for us.
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 110 +++++++++++-------
> > > drivers/gpu/drm/i915/display/intel_color.h | 1 +
> > > drivers/gpu/drm/i915/display/intel_display.c | 4 +
> > > .../gpu/drm/i915/display/intel_display_core.h | 5 +
> > > 4 files changed, 79 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index 575d2a23682a..de530bf1aba1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -557,6 +557,32 @@ static void skl_color_commit_arm(const struct
> > > intel_crtc_state *crtc_state)
> > > crtc_state->csc_mode);
> > > }
> > >
> > > +static struct drm_property_blob *
> > > +create_linear_lut(struct drm_i915_private *i915, int lut_size) {
> > > + struct drm_property_blob *blob;
> > > + struct drm_color_lut *lut;
> > > + int i;
> > > +
> > > + blob = drm_property_create_blob(&i915->drm,
> > > + sizeof(struct drm_color_lut) * lut_size,
> > > + NULL);
> > > + if (IS_ERR(blob))
> > > + return NULL;
> > > +
> > > + lut = blob->data;
> > > +
> > > + for (i = 0; i < lut_size; i++) {
> > > + u16 val = 0xffff * i / (lut_size - 1);
> > > +
> > > + lut[i].red = val;
> > > + lut[i].green = val;
> > > + lut[i].blue = val;
> > > + }
> > > +
> > > + return blob;
> > > +}
> > > +
> > > static void i9xx_load_lut_8(struct intel_crtc *crtc,
> > > const struct drm_property_blob *blob) { @@ -871,53
> > > +897,14 @@ static void glk_load_degamma_lut(const struct
> > > +intel_crtc_state
> > > *crtc_state,
> > > intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0); }
> > >
> > > -static void glk_load_degamma_lut_linear(const struct
> > > intel_crtc_state *crtc_state) - {
> > > - struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > - enum pipe pipe = crtc->pipe;
> > > - int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
> > > -
> > > - /*
> > > - * When setting the auto-increment bit, the hardware seems to
> > > - * ignore the index bits, so we need to reset it to index 0
> > > - * separately.
> > > - */
> > > - intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
> > > - intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
> > > - PRE_CSC_GAMC_AUTO_INCREMENT);
> > > -
> > > - for (i = 0; i < lut_size; i++) {
> > > - u32 v = (i << 16) / (lut_size - 1);
> > > -
> > > - intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), v);
> > > - }
> > > -
> > > - /* Clamp values > 1.0. */
> > > - while (i++ < 35)
> > > - intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
> > > -
> > > - intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
> > > -}
> > > -
> > > static void glk_load_luts(const struct intel_crtc_state *crtc_state) {
> > > const struct drm_property_blob *pre_csc_lut = crtc_state->pre_csc_lut;
> > > const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > >
> > > - /*
> > > - * On GLK+ both pipe CSC and degamma LUT are controlled
> > > - * by csc_enable. Hence for the cases where the CSC is
> > > - * needed but degamma LUT is not we need to load a
> > > - * linear degamma LUT. In fact we'll just always load
> > > - * the degama LUT so that we don't have to reload
> > > - * it every time the pipe CSC is being enabled.
> > > - */
> > > if (pre_csc_lut)
> > > glk_load_degamma_lut(crtc_state, pre_csc_lut);
> > > - else
> > > - glk_load_degamma_lut_linear(crtc_state);
> > >
> > > switch (crtc_state->gamma_mode) {
> > > case GAMMA_MODE_MODE_8BIT:
> > > @@ -1360,11 +1347,17 @@ void intel_color_assert_luts(const struct
> > > intel_crtc_state *crtc_state)
> > > struct drm_i915_private *i915 =
> > > to_i915(crtc_state->uapi.crtc->dev);
> > >
> > > /* make sure {pre,post}_csc_lut were correctly assigned */
> > > - if (DISPLAY_VER(i915) >= 10 || HAS_GMCH(i915)) {
> > > + if (DISPLAY_VER(i915) >= 11 || HAS_GMCH(i915)) {
> > > drm_WARN_ON(&i915->drm,
> > > crtc_state->pre_csc_lut != crtc_state->hw.degamma_lut);
> > > drm_WARN_ON(&i915->drm,
> > > crtc_state->post_csc_lut != crtc_state->hw.gamma_lut);
> > > + } else if (DISPLAY_VER(i915) == 10) {
> > > + drm_WARN_ON(&i915->drm,
> > > + crtc_state->pre_csc_lut != crtc_state->hw.degamma_lut
> > > &&
> > > + crtc_state->pre_csc_lut != i915-
> > > >display.color.glk_linear_degamma_lut);
> > > + drm_WARN_ON(&i915->drm,
> > > + crtc_state->post_csc_lut != crtc_state->hw.gamma_lut);
> > > } else {
> > > drm_WARN_ON(&i915->drm,
> > > crtc_state->pre_csc_lut != crtc_state->hw.degamma_lut
> && @@
> > > -1619,6 +1612,25 @@ static u32 glk_gamma_mode(const struct
> > > intel_crtc_state *crtc_state)
> > > return GAMMA_MODE_MODE_10BIT;
> > > }
> > >
> > > +static void glk_assign_luts(struct intel_crtc_state *crtc_state) {
> > > + struct drm_i915_private *i915 =
> > > +to_i915(crtc_state->uapi.crtc->dev);
> > > +
> > > + intel_assign_luts(crtc_state);
> > > +
> > > + /*
> > > + * On GLK+ both pipe CSC and degamma LUT are controlled
> > > + * by csc_enable. Hence for the cases where the CSC is
> > > + * needed but degamma LUT is not we need to load a
> > > + * linear degamma LUT. In fact we'll just always load
> > > + * the degama LUT so that we don't have to reload
> > > + * it every time the pipe CSC is being enabled.
> > > + */
> > > + if (!crtc_state->pre_csc_lut)
> > > + drm_property_replace_blob(&crtc_state->pre_csc_lut,
> > > + i915-
> > > >display.color.glk_linear_degamma_lut);
> > > +}
> > > +
> > > static int glk_color_check(struct intel_crtc_state *crtc_state) {
> > > struct drm_i915_private *dev_priv =
> > > to_i915(crtc_state->uapi.crtc->dev);
> > > @@ -1653,7 +1665,7 @@ static int glk_color_check(struct
> > > intel_crtc_state
> > > *crtc_state)
> > > if (ret)
> > > return ret;
> > >
> > > - intel_assign_luts(crtc_state);
> > > + glk_assign_luts(crtc_state);
> > >
> > > crtc_state->preload_luts = glk_can_preload_luts(crtc_state);
> > >
> > > @@ -2283,6 +2295,22 @@ void intel_crtc_color_init(struct intel_crtc *crtc)
> > > INTEL_INFO(dev_priv)-
> > > >display.color.gamma_lut_size);
> > > }
> > >
> > > +int intel_color_init(struct drm_i915_private *i915) {
> > > + struct drm_property_blob *blob;
> > > +
> > > + if (DISPLAY_VER(i915) != 10)
> > > + return 0;
> >
> > This is very specific to Gen10. Should we rename intel_color_init
> > which sounds more global to a gen10 specific name.
>
> I guess I could have added a glk specific function for this and call it from
> intel_color_init(), but should be easy enough to do that refcatoring if/when
> someone needs to add more stuff to intel_color_init().
Yeah, fair enough.
Regards,
Uma Shankar
> >
> > Will leave that to your discretion, don't see any issues logically
> > Reviewed-by: Uma Shankar <uma.shankar at intel.com>
>
> Thanks.
>
> --
> Ville Syrjälä
> Intel
More information about the Intel-gfx
mailing list