RE: [PATCHv2 2/5] drm/i915/display: histogram interrupt handling

[Kulkarni, Vandita]

> -Original Message-
> From: Murthy, Arun R 
> Sent: Thursday, September 12, 2024 3:22 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCHv2 2/5] drm/i915/display: histogram interrupt handling
> 
> > > +static void intel_histogram_handle_int_work(struct work_struct *work)
> {
> > > + struct intel_histogram *histogram = container_of(work,
> > > + struct intel_histogram, handle_histogram_int_work.work);
> > > + struct drm_i915_private *i915 = histogram->i915;
> > > + struct intel_crtc *intel_crtc = histogram->crtc;
> > > + char *histogram_event[] = {"HISTOGRAM=1", NULL};
> > > + u32 dpstbin;
> > > + int i, try = 0;
> > > +
> > If we have PSR enabled looks like this code might straight away break,
> > and PSR being enabled is a common scenario Can we have some checks on
> > enabling this feature if no PSR until we handle this scenario?
> 
> With PSR enabled histogram event will not be generated as there wont be
> any statistics.
> This should have no impact to user and user is not time bound with the
> histogram event.

Just to get some clarity, does this mean the tests for histogram wont  fail on 
PSR enabled panel with this series ?

Thanks,
Vandita
> 
> This TODO is to handle the histogram generation even in case of PSR enabled
> with some additional settings.
> 
> Thanks and Regards,
> Arun R Murthy
> ---

RE: [PATCHv2 1/5] drm/i915/display: Add support for histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Murthy, Arun R 
> Sent: Thursday, September 12, 2024 2:39 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCHv2 1/5] drm/i915/display: Add support for histogram
> 
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Arun R Murthy
> > > Sent: Wednesday, August 21, 2024 3:54 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Murthy, Arun R 
> > > Subject: [PATCHv2 1/5] drm/i915/display: Add support for histogram
> > >
> > > Statistics is generated from the image frame that is coming to
> > > display and an event is sent to user after reading this histogram data.
> > > This statistics/histogram is then shared with the user upon getting
> > > a request from user. User can then use this histogram and generate
> > > an enhancement factor. This enhancement factor can be
> > > multiplied/added with the incoming pixel data frame.
> > >
> > > v2: forward declaration in header file along with error handling
> > > (Jani)
> > >
> > > Signed-off-by: Arun R Murthy 
> > > ---
> > >  drivers/gpu/drm/i915/Makefile |   1 +
> > >  .../drm/i915/display/intel_display_types.h|   2 +
> > >  .../gpu/drm/i915/display/intel_histogram.c| 205
> ++
> > >  .../gpu/drm/i915/display/intel_histogram.h|  78 +++
> > >  drivers/gpu/drm/xe/Makefile   |   1 +
> > >  5 files changed, 287 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.c
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.h
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > b/drivers/gpu/drm/i915/Makefile index c63fa2133ccb..03caf3a24966
> > > 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -264,6 +264,7 @@ i915-y += \
> > >   display/intel_hdcp.o \
> > >   display/intel_hdcp_gsc.o \
> > >   display/intel_hdcp_gsc_message.o \
> > > + display/intel_histogram.o \
> > >   display/intel_hotplug.o \
> > >   display/intel_hotplug_irq.o \
> > >   display/intel_hti.o \
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index bd290536a1b7..79d34d6d537d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1537,6 +1537,8 @@ struct intel_crtc {
> > >   /* for loading single buffered registers during vblank */
> > >   struct pm_qos_request vblank_pm_qos;
> > >
> > > + struct intel_histogram *histogram;
> > > +
> > >  #ifdef CONFIG_DEBUG_FS
> > >   struct intel_pipe_crc pipe_crc;
> > >  #endif
> > > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> > > b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > new file mode 100644
> > > index ..45e968e00af6
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > @@ -0,0 +1,205 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2024 Intel Corporation  */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include "i915_reg.h"
> > > +#include "i915_drv.h"
> > > +#include "intel_display.h"
> > > +#include "intel_histogram.h"
> > > +#include "intel_display_types.h"
> > > +#include "intel_de.h"
> > > +
> > > +#define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300//
> 3.0% of
> > > the pipe's current pixel count.
> > > +#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 1   //
> Precision
> > > factor for threshold guardband.
> > > +#define HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> > > +
> > > +struct intel_histogram {
> > > + struct drm_i915_private *i915;
> > > + bool enable;
> > > + bool can_enable;
> > > + enum pipe pipe;
> > > + u32 bindata[HISTOGRAM_BIN_COUNT];
> > > +};
> > > +
> > > +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) {
> > > + struct intel_histogram *histogram = intel_crtc->histogram;
> > > +
> > > + /* TODO: Restrictions for enabling histogram */
&

RE: [PATCH 3/5] Add crtc properties for global histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Kulkarni, Vandita 
> Sent: Wednesday, September 11, 2024 2:20 PM
> To: Kulkarni, Vandita ; Murthy, Arun R
> ; intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: RE: [PATCH 3/5] Add crtc properties for global histogram
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Kulkarni, Vandita
> > Sent: Wednesday, September 11, 2024 10:46 AM
> > To: Murthy, Arun R ; intel-
> > g...@lists.freedesktop.org
> > Cc: Murthy, Arun R 
> > Subject: RE: [PATCH 3/5] Add crtc properties for global histogram
> >
> >
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Arun R Murthy
> > > Sent: Friday, July 5, 2024 3:26 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Murthy, Arun R 
> > > Subject: [PATCH 3/5] Add crtc properties for global histogram
> > >
> > > CRTC properties have been added for enable/disable histogram,
> > > reading the histogram data and writing the IET data.
> > > "HISTOGRAM_EN" is the crtc property to enable/disable the global
> > > histogram and takes a value 0/1 accordingly.
> > > "Histogram" is a crtc property to read the binary histogram data.
> > > "Global IET" is a crtc property to write the IET binary LUT data.
> > >
> > > Signed-off-by: Arun R Murthy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_atomic.c   |   5 +
> > >  drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
> > >  drivers/gpu/drm/i915/display/intel_crtc.h |   5 +
> > >  drivers/gpu/drm/i915/display/intel_display.c  |  13 ++
> > >  .../drm/i915/display/intel_display_types.h|  17 ++
> > >  .../gpu/drm/i915/display/intel_histogram.c|   1 +
> > >  6 files changed, 242 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index 76aa10b6f647..693a22089937 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc
> > > *crtc)
> > >
> > >   __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state- uapi);
> > >
> > > + if (crtc_state->global_iet)
> > > + drm_property_blob_get(crtc_state->global_iet);
> > >   /* copy color blobs */
> > >   if (crtc_state->hw.degamma_lut)
> > >   drm_property_blob_get(crtc_state->hw.degamma_lut);
> > > @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > >   crtc_state->fb_bits = 0;
> > >   crtc_state->update_planes = 0;
> > >   crtc_state->dsb = NULL;
> > > + crtc_state->histogram_en_changed = false;
> > >
> > >   return &crtc_state->uapi;
> > >  }
> > > @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> > >
> > >   drm_WARN_ON(crtc->dev, crtc_state->dsb);
> > >
> > > + if (crtc_state->global_iet)
> > > + drm_property_blob_put(crtc_state->global_iet);
> > >   __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> > >   intel_crtc_free_hw_state(crtc_state);
> > >   if (crtc_state->dp_tunnel_ref.tunnel)
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index 1b578cad2813..24f160359422 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -10,6 +10,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "i915_vgpu.h"
> > >  #include "i9xx_plane.h"
> > > @@ -26,6 +27,7 @@
> > >  #include "intel_drrs.h"
> > >  #include "intel_dsi.h"
> > >  #include "intel_fifo_underrun.h"
> > > +#include "intel_histogram.h"
> > >  #include "intel_pipe_crc.h"
> > >  #include "intel_psr.h"
> > >  #include "intel_sprite.h"
> > > @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void)
> > > static void intel_crtc_free(struct intel_crtc *crtc)  {
> > >   intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> > >

RE: [PATCH 3/5] Add crtc properties for global histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Wednesday, September 11, 2024 10:46 AM
> To: Murthy, Arun R ; intel-
> g...@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: RE: [PATCH 3/5] Add crtc properties for global histogram
> 
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Arun R Murthy
> > Sent: Friday, July 5, 2024 3:26 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Murthy, Arun R 
> > Subject: [PATCH 3/5] Add crtc properties for global histogram
> >
> > CRTC properties have been added for enable/disable histogram, reading
> > the histogram data and writing the IET data.
> > "HISTOGRAM_EN" is the crtc property to enable/disable the global
> > histogram and takes a value 0/1 accordingly.
> > "Histogram" is a crtc property to read the binary histogram data.
> > "Global IET" is a crtc property to write the IET binary LUT data.
> >
> > Signed-off-by: Arun R Murthy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |   5 +
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
> >  drivers/gpu/drm/i915/display/intel_crtc.h |   5 +
> >  drivers/gpu/drm/i915/display/intel_display.c  |  13 ++
> >  .../drm/i915/display/intel_display_types.h|  17 ++
> >  .../gpu/drm/i915/display/intel_histogram.c|   1 +
> >  6 files changed, 242 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 76aa10b6f647..693a22089937 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> >
> > __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state-
> >uapi);
> >
> > +   if (crtc_state->global_iet)
> > +   drm_property_blob_get(crtc_state->global_iet);
> > /* copy color blobs */
> > if (crtc_state->hw.degamma_lut)
> > drm_property_blob_get(crtc_state->hw.degamma_lut);
> > @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > crtc_state->fb_bits = 0;
> > crtc_state->update_planes = 0;
> > crtc_state->dsb = NULL;
> > +   crtc_state->histogram_en_changed = false;
> >
> > return &crtc_state->uapi;
> >  }
> > @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> >
> > drm_WARN_ON(crtc->dev, crtc_state->dsb);
> >
> > +   if (crtc_state->global_iet)
> > +   drm_property_blob_put(crtc_state->global_iet);
> > __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> > intel_crtc_free_hw_state(crtc_state);
> > if (crtc_state->dp_tunnel_ref.tunnel)
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 1b578cad2813..24f160359422 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_vgpu.h"
> >  #include "i9xx_plane.h"
> > @@ -26,6 +27,7 @@
> >  #include "intel_drrs.h"
> >  #include "intel_dsi.h"
> >  #include "intel_fifo_underrun.h"
> > +#include "intel_histogram.h"
> >  #include "intel_pipe_crc.h"
> >  #include "intel_psr.h"
> >  #include "intel_sprite.h"
> > @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void)
> > static void intel_crtc_free(struct intel_crtc *crtc)  {
> > intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> > +   intel_histogram_deinit(crtc);
> > kfree(crtc);
> >  }
> >
> > @@ -220,6 +223,100 @@ static int intel_crtc_late_register(struct
> > drm_crtc
> > *crtc)
> > return 0;
> >  }
> >
> > +static int intel_crtc_get_property(struct drm_crtc *crtc,
> > +  const struct drm_crtc_state *state,
> > +  struct drm_property *property,
> > +  uint64_t *val)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(crtc->dev);
> > +   const struct intel_crtc_state *intel_crtc_state =
> > +   to_intel_crtc_state(state);
> &

RE: [PATCHv2 2/5] drm/i915/display: histogram interrupt handling

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun
> R Murthy
> Sent: Wednesday, August 21, 2024 3:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCHv2 2/5] drm/i915/display: histogram interrupt handling
> 
> Upon enabling histogram an interrupt is trigerred after the generation of the
> statistics. This patch registers the histogram interrupt and handles the
> interrupt.
> 
> v2: Added intel_crtc backpointer to intel_histogram struct (Jani)
> Removed histogram_wq and instead use dev_priv->unodered_eq (Jani)
> 
> Signed-off-by: Arun R Murthy 
> ---
>  .../gpu/drm/i915/display/intel_display_irq.c  |  6 +-
>  .../gpu/drm/i915/display/intel_histogram.c| 80 ++-
>  .../gpu/drm/i915/display/intel_histogram.h|  3 +
>  drivers/gpu/drm/i915/i915_reg.h   |  5 +-
>  4 files changed, 89 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index afcd2af82942..0178595102bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -17,6 +17,7 @@
>  #include "intel_fdi_regs.h"
>  #include "intel_fifo_underrun.h"
>  #include "intel_gmbus.h"
> +#include "intel_histogram.h"
>  #include "intel_hotplug_irq.h"
>  #include "intel_pipe_crc_regs.h"
>  #include "intel_pmdemand.h"
> @@ -1170,6 +1171,9 @@ void gen8_de_irq_handler(struct
> drm_i915_private *dev_priv, u32 master_ctl)
>   if (iir & gen8_de_pipe_underrun_mask(dev_priv))
>   intel_cpu_fifo_underrun_irq_handler(dev_priv,
> pipe);
> 
> + if (iir & GEN9_PIPE_HISTOGRAM_EVENT)
> + intel_histogram_irq_handler(dev_priv, pipe);
> +
>   fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
>   if (fault_errors)
>   drm_err_ratelimited(&dev_priv->drm,
> @@ -1701,7 +1705,7 @@ void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
>   struct intel_uncore *uncore = &dev_priv->uncore;
> 
>   u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) |
> - GEN8_PIPE_CDCLK_CRC_DONE;
> + GEN8_PIPE_CDCLK_CRC_DONE |
> GEN9_PIPE_HISTOGRAM_EVENT;
>   u32 de_pipe_enables;
>   u32 de_port_masked = gen8_de_port_aux_mask(dev_priv);
>   u32 de_port_enables;
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index 45e968e00af6..83ba826a7a89 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -19,12 +19,83 @@
> 
>  struct intel_histogram {
>   struct drm_i915_private *i915;
> + struct intel_crtc *crtc;
> + struct delayed_work handle_histogram_int_work;
>   bool enable;
>   bool can_enable;
> - enum pipe pipe;
>   u32 bindata[HISTOGRAM_BIN_COUNT];
>  };
> 
> +static void intel_histogram_handle_int_work(struct work_struct *work) {
> + struct intel_histogram *histogram = container_of(work,
> + struct intel_histogram, handle_histogram_int_work.work);
> + struct drm_i915_private *i915 = histogram->i915;
> + struct intel_crtc *intel_crtc = histogram->crtc;
> + char *histogram_event[] = {"HISTOGRAM=1", NULL};
> + u32 dpstbin;
> + int i, try = 0;
> +
If we have PSR enabled looks like this code might straight away break, and PSR 
being enabled is a common scenario
Can we have some checks on enabling this feature if no PSR until we handle this 
scenario?
> + /*
> +  * TODO: PSR to be exited while reading the Histogram data
> +  * Set DPST_CTL Bin Reg function select to TC
> +  * Set DPST_CTL Bin Register Index to 0
> +  */
> +retry:
> + intel_de_rmw(i915, DPST_CTL(intel_crtc->pipe),
> +  DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
> + for (i = 0; i < HISTOGRAM_BIN_COUNT; i++) {
> + dpstbin = intel_de_read(i915, DPST_BIN(intel_crtc->pipe));
> + if (dpstbin & DPST_BIN_BUSY) {
> + /*
> +  * If DPST_BIN busy bit is set, then set the
> +  * DPST_CTL bin reg index to 0 and proceed
> +  * from beginning.
> +  */
> + if (try++ >= 5) {
> + drm_err(&i915->drm,
> + "Histogram block is busy, failed to
> read\n");
> + intel_de_rmw(i915, DPST_GUARD(intel_crtc-
> >pipe),
> +
> DPST_GUARD_HIST_EVENT_STATUS, 1);
> + return;
> + }
> + goto retry;
> + }
> + histogram->bindata[i] = dpstbin & DPST_BIN_DATA_MASK;
> + drm_dbg_atomic(&i915->drm, "Histogram[%d]=%x\n",
> +i, histogram->bindata[i]);
> + }
> +
> +

RE: [PATCH 3/5] Add crtc properties for global histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun
> R Murthy
> Sent: Friday, July 5, 2024 3:26 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCH 3/5] Add crtc properties for global histogram
> 
> CRTC properties have been added for enable/disable histogram, reading the
> histogram data and writing the IET data.
> "HISTOGRAM_EN" is the crtc property to enable/disable the global histogram
> and takes a value 0/1 accordingly.
> "Histogram" is a crtc property to read the binary histogram data.
> "Global IET" is a crtc property to write the IET binary LUT data.
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   5 +
>  drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
>  drivers/gpu/drm/i915/display/intel_crtc.h |   5 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  13 ++
>  .../drm/i915/display/intel_display_types.h|  17 ++
>  .../gpu/drm/i915/display/intel_histogram.c|   1 +
>  6 files changed, 242 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 76aa10b6f647..693a22089937 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> 
>   __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
> 
> + if (crtc_state->global_iet)
> + drm_property_blob_get(crtc_state->global_iet);
>   /* copy color blobs */
>   if (crtc_state->hw.degamma_lut)
>   drm_property_blob_get(crtc_state->hw.degamma_lut);
> @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->fb_bits = 0;
>   crtc_state->update_planes = 0;
>   crtc_state->dsb = NULL;
> + crtc_state->histogram_en_changed = false;
> 
>   return &crtc_state->uapi;
>  }
> @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> 
>   drm_WARN_ON(crtc->dev, crtc_state->dsb);
> 
> + if (crtc_state->global_iet)
> + drm_property_blob_put(crtc_state->global_iet);
>   __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
>   intel_crtc_free_hw_state(crtc_state);
>   if (crtc_state->dp_tunnel_ref.tunnel)
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1b578cad2813..24f160359422 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "i915_vgpu.h"
>  #include "i9xx_plane.h"
> @@ -26,6 +27,7 @@
>  #include "intel_drrs.h"
>  #include "intel_dsi.h"
>  #include "intel_fifo_underrun.h"
> +#include "intel_histogram.h"
>  #include "intel_pipe_crc.h"
>  #include "intel_psr.h"
>  #include "intel_sprite.h"
> @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void)  static
> void intel_crtc_free(struct intel_crtc *crtc)  {
>   intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> + intel_histogram_deinit(crtc);
>   kfree(crtc);
>  }
> 
> @@ -220,6 +223,100 @@ static int intel_crtc_late_register(struct drm_crtc
> *crtc)
>   return 0;
>  }
> 
> +static int intel_crtc_get_property(struct drm_crtc *crtc,
> +const struct drm_crtc_state *state,
> +struct drm_property *property,
> +uint64_t *val)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc->dev);
> + const struct intel_crtc_state *intel_crtc_state =
> + to_intel_crtc_state(state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (property == intel_crtc->histogram_en_property) {
> + *val = intel_crtc_state->histogram_en;
> + } else if (property == intel_crtc->global_iet_property) {
> + *val = (intel_crtc_state->global_iet) ?
> + intel_crtc_state->global_iet->base.id : 0;
> + } else if (property == intel_crtc->histogram_property) {
> + *val = (intel_crtc_state->histogram) ?
> + intel_crtc_state->histogram->base.id : 0;
> + } else {
> + drm_err(&i915->drm,
> + "Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +intel_atomic_replace_property_blob_from_id(struct drm_device *dev,
> +struct drm_property_blob **blob,
> +u64 blob_id,
> +ssize_t expected_size,
> +ssize_t expected_elem_size,
> +bool *replaced)
> +{
> + struct drm_property_

RE: [PATCHv2 5/5] drm/i915/display/histogram: Histogram changes for Display LNL+

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Arun R Murthy
> Sent: Wednesday, August 21, 2024 3:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCHv2 5/5] drm/i915/display/histogram: Histogram changes for
> Display LNL+
> 
> In LNL+, histogram/IE data and index registers are added which was included
> in the control registers in the legacy platforms. The new registers are used
> for reading histogram and writing the IET LUT data.
> 
> v2: Removed duplicate code (Jani)
> 
> Signed-off-by: Arun R Murthy 
> ---
>  .../gpu/drm/i915/display/intel_histogram.c| 138 --
>  .../gpu/drm/i915/display/intel_histogram.h|  25 
>  2 files changed, 122 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index 189f7ccd6df8..9c31a7d83362 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -26,38 +26,41 @@ struct intel_histogram {
>   u32 bindata[HISTOGRAM_BIN_COUNT];
>  };
> 
> -static void intel_histogram_handle_int_work(struct work_struct *work)
> +static void intel_histogram_read_data(struct intel_histogram
> +*histogram)
>  {
> - struct intel_histogram *histogram = container_of(work,
> - struct intel_histogram, handle_histogram_int_work.work);
>   struct drm_i915_private *i915 = histogram->i915;
>   struct intel_crtc *intel_crtc = histogram->crtc;
> - char *histogram_event[] = {"HISTOGRAM=1", NULL};
>   u32 dpstbin;
>   int i, try = 0;
> 
> - /* Wa: 14014889975 */
> - if (IS_DISPLAY_VER(i915, 12, 13))
> +retry:
> + if (DISPLAY_VER(i915) >= 20) {
> + /* Set index to zero */
> + intel_de_rmw(i915, DPST_HIST_INDEX(intel_crtc->pipe),
> +  DPST_HIST_BIN_INDEX_MASK,
> DPST_HIST_BIN_INDEX(0));
> + } else {
>   intel_de_rmw(i915, DPST_CTL(intel_crtc->pipe),
> -  DPST_CTL_RESTORE, 0);
> +  DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
> + }
> 
> - /*
> -  * TODO: PSR to be exited while reading the Histogram data
> -  * Set DPST_CTL Bin Reg function select to TC
> -  * Set DPST_CTL Bin Register Index to 0
> -  */
> -retry:
> - intel_de_rmw(i915, DPST_CTL(intel_crtc->pipe),
> -  DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
>   for (i = 0; i < HISTOGRAM_BIN_COUNT; i++) {
> - dpstbin = intel_de_read(i915, DPST_BIN(intel_crtc->pipe));
> + dpstbin = intel_de_read(i915, DPST_HIST_BIN(intel_crtc-
> >pipe));
>   if (dpstbin & DPST_BIN_BUSY) {
>   /*
>* If DPST_BIN busy bit is set, then set the
>* DPST_CTL bin reg index to 0 and proceed
>* from beginning.
>*/
> - if (try++ >= 5) {
> + if (DISPLAY_VER(i915) >= 20) {
> + intel_de_rmw(i915,
> DPST_HIST_INDEX(intel_crtc->pipe),
> +  DPST_HIST_BIN_INDEX_MASK,
> +  DPST_HIST_BIN_INDEX(0));
> + } else {
> + intel_de_rmw(i915, DPST_CTL(intel_crtc-
> >pipe),
> +  DPST_CTL_BIN_REG_MASK, 0);
> + }
> +
> + if (try++ == 5) {
>   drm_err(&i915->drm,
>   "Histogram block is busy, failed to
> read\n");
>   intel_de_rmw(i915, DPST_GUARD(intel_crtc-
> >pipe), @@ -66,10 +69,37 @@ static void
> intel_histogram_handle_int_work(struct work_struct *work)
>   }
>   goto retry;
>   }
> - histogram->bindata[i] = dpstbin & DPST_BIN_DATA_MASK;
> + histogram->bindata[i] = dpstbin &
> DPST_HIST_BIN_DATA_MASK;
>   drm_dbg_atomic(&i915->drm, "Histogram[%d]=%x\n",
>  i, histogram->bindata[i]);
>   }
> +}
> +
> +static void intel_histogram_get_data(struct intel_histogram *histogram)
> +{
> +
> + /*
> +  * TODO: PSR to be exited while reading the Histogram data
> +  * Set DPST_CTL Bin Reg function select to TC
> +  * Set DPST_CTL Bin Register Index to 0
> +  */
> + intel_histogram_read_data(histogram);
> +}
> +
> +static void intel_histogram_handle_int_work(struct work_struct *work) {
> + struct intel_histogram *histogram = container_of(work,
> + struct intel_histogram, handle_histogram_int_work.work);
> + struct drm_i915_private *i915 = histogram->i915;
> + struct intel_crtc *intel_crtc = histogram->crtc;
> + char *histogram_event[] = {"HISTOGRAM=1", NULL};
> +
> + /* W

RE: [PATCHv2 1/5] drm/i915/display: Add support for histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun
> R Murthy
> Sent: Wednesday, August 21, 2024 3:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCHv2 1/5] drm/i915/display: Add support for histogram
> 
> Statistics is generated from the image frame that is coming to display and an
> event is sent to user after reading this histogram data.
> This statistics/histogram is then shared with the user upon getting a request
> from user. User can then use this histogram and generate an enhancement
> factor. This enhancement factor can be multiplied/added with the incoming
> pixel data frame.
> 
> v2: forward declaration in header file along with error handling (Jani)
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  .../drm/i915/display/intel_display_types.h|   2 +
>  .../gpu/drm/i915/display/intel_histogram.c| 205 ++
>  .../gpu/drm/i915/display/intel_histogram.h|  78 +++
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  5 files changed, 287 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c63fa2133ccb..03caf3a24966 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -264,6 +264,7 @@ i915-y += \
>   display/intel_hdcp.o \
>   display/intel_hdcp_gsc.o \
>   display/intel_hdcp_gsc_message.o \
> + display/intel_histogram.o \
>   display/intel_hotplug.o \
>   display/intel_hotplug_irq.o \
>   display/intel_hti.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index bd290536a1b7..79d34d6d537d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1537,6 +1537,8 @@ struct intel_crtc {
>   /* for loading single buffered registers during vblank */
>   struct pm_qos_request vblank_pm_qos;
> 
> + struct intel_histogram *histogram;
> +
>  #ifdef CONFIG_DEBUG_FS
>   struct intel_pipe_crc pipe_crc;
>  #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> new file mode 100644
> index ..45e968e00af6
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "intel_display.h"
> +#include "intel_histogram.h"
> +#include "intel_display_types.h"
> +#include "intel_de.h"
> +
> +#define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300// 3.0% of
> the pipe's current pixel count.
> +#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 1   // Precision
> factor for threshold guardband.
> +#define HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> +
> +struct intel_histogram {
> + struct drm_i915_private *i915;
> + bool enable;
> + bool can_enable;
> + enum pipe pipe;
> + u32 bindata[HISTOGRAM_BIN_COUNT];
> +};
> +
> +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) {
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + /* TODO: Restrictions for enabling histogram */
> + histogram->can_enable = true;
> +
> + return 0;
> +}
> +
Looks like we are totally bypassing crtc_state->dither.
Also I see some comments on dither not being enabled on anything which is not 
6bpc. Is that constraint resolved now?

> +static void intel_histogram_enable_dithering(struct drm_i915_private
> *dev_priv,
> +  enum pipe pipe)
> +{
> + intel_de_rmw(dev_priv, PIPE_MISC(pipe),
> PIPE_MISC_DITHER_ENABLE,
> +  PIPE_MISC_DITHER_ENABLE);
> +}
> +
> +static int intel_histogram_enable(struct intel_crtc *intel_crtc) {
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> + u64 res;
> + u32 gbandthreshold;
> +
> + if (!histogram)
> + return -EINVAL;
> +
> + if (!histogram->can_enable) {
> + return -EINVAL;
> + }
> +
> + if (histogram->enable)
> + return 0;
> +
I don't see in the spec that dither should be enabled, any quick bspec 
references?
> + /* Pipe Dithering should be enabled with GLOBAL_HIST */
> + intel_histogram_enable_dithering(i915, pipe);
> +
> + /*
> +  * enable DPST_CTL Histogram mode
> +  * Clear DPST_CTL Bin Reg function select to TC
> +  */
> + intel_de_rmw(i915, DPST_CTL(pipe),
> +  DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> +  DPST_CTL_HIST_MODE |
>

RE: [PATCH] drm/i915/bios: fix printk format width

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Thursday, September 5, 2024 4:55 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; sta...@vger.kernel.org
> Subject: [PATCH] drm/i915/bios: fix printk format width
> 
> s/0x04%x/0x%04x/ to use 0 prefixed width 4 instead of printing 04 verbatim.
> 
> Fixes: 51f5748179d4 ("drm/i915/bios: create fake child devices on missing
> VBT")
> Cc:  # v5.13+
> Signed-off-by: Jani Nikula 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

Thanks.
>  drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index cd32c9cd38a9..daa4b9535123 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2949,7 +2949,7 @@ init_vbt_missing_defaults(struct intel_display
> *display)
>   list_add_tail(&devdata->node, &display-
> >vbt.display_devices);
> 
>   drm_dbg_kms(display->drm,
> - "Generating default VBT child device with type
> 0x04%x on port %c\n",
> + "Generating default VBT child device with type
> 0x%04x on port
> +%c\n",
>   child->device_type, port_name(port));
>   }
> 
> --
> 2.39.2

RE: [PATCHv2 3/5] Add crtc properties for global histogram

[Kulkarni, Vandita]

+dri-devel

> -Original Message-
> From: Kulkarni, Vandita
> Sent: Tuesday, September 3, 2024 10:54 AM
> To: Arun R Murthy ; intel-
> g...@lists.freedesktop.org; drm-devel@lists.freedesktop
> Cc: Murthy, Arun R 
> Subject: RE: [PATCHv2 3/5] Add crtc properties for global histogram
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Arun R Murthy
> > Sent: Wednesday, August 21, 2024 3:54 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Murthy, Arun R 
> > Subject: [PATCHv2 3/5] Add crtc properties for global histogram
> >
> > CRTC properties have been added for enable/disable histogram, reading
> > the histogram data and writing the IET data.
> > "HISTOGRAM_EN" is the crtc property to enable/disable the global
> > histogram and takes a value 0/1 accordingly.
> > "Histogram" is a crtc property to read the binary histogram data.
> > "Global IET" is a crtc property to write the IET binary LUT data.
> >
> > v2: Read the histogram blob data before sending uevent (Jani)
> >
> > Signed-off-by: Arun R Murthy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |   5 +
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
> >  drivers/gpu/drm/i915/display/intel_crtc.h |   5 +
> >  drivers/gpu/drm/i915/display/intel_display.c  |  13 ++
> >  .../drm/i915/display/intel_display_types.h|  17 ++
> >  .../gpu/drm/i915/display/intel_histogram.c|   7 +
> >  6 files changed, 248 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 76aa10b6f647..693a22089937 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> >
> > __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
> >
> > +   if (crtc_state->global_iet)
> > +   drm_property_blob_get(crtc_state->global_iet);
> > /* copy color blobs */
> > if (crtc_state->hw.degamma_lut)
> > drm_property_blob_get(crtc_state->hw.degamma_lut);
> > @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > crtc_state->fb_bits = 0;
> > crtc_state->update_planes = 0;
> > crtc_state->dsb = NULL;
> > +   crtc_state->histogram_en_changed = false;
> >
> > return &crtc_state->uapi;
> >  }
> > @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> >
> > drm_WARN_ON(crtc->dev, crtc_state->dsb);
> >
> > +   if (crtc_state->global_iet)
> > +   drm_property_blob_put(crtc_state->global_iet);
> > __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
> > intel_crtc_free_hw_state(crtc_state);
> > if (crtc_state->dp_tunnel_ref.tunnel)
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 1b578cad2813..24f160359422 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_vgpu.h"
> >  #include "i9xx_plane.h"
> > @@ -26,6 +27,7 @@
> >  #include "intel_drrs.h"
> >  #include "intel_dsi.h"
> >  #include "intel_fifo_underrun.h"
> > +#include "intel_histogram.h"
> >  #include "intel_pipe_crc.h"
> >  #include "intel_psr.h"
> >  #include "intel_sprite.h"
> > @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void)
> > static void intel_crtc_free(struct intel_crtc *crtc)  {
> > intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> > +   intel_histogram_deinit(crtc);
> > kfree(crtc);
> >  }
> >
> > @@ -220,6 +223,100 @@ static int intel_crtc_late_register(struct
> > drm_crtc
> > *crtc)
> > return 0;
> >  }
> >
> > +static int intel_crtc_get_property(struct drm_crtc *crtc,
> > +  const struct drm_crtc_state *state,
> > +  struct drm_property *property,
> > +  uint64_t *val)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(crtc->dev);
> > +   const stru

RE: [PATCHv2 3/5] Add crtc properties for global histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun
> R Murthy
> Sent: Wednesday, August 21, 2024 3:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCHv2 3/5] Add crtc properties for global histogram
> 
> CRTC properties have been added for enable/disable histogram, reading the
> histogram data and writing the IET data.
> "HISTOGRAM_EN" is the crtc property to enable/disable the global histogram
> and takes a value 0/1 accordingly.
> "Histogram" is a crtc property to read the binary histogram data.
> "Global IET" is a crtc property to write the IET binary LUT data.
> 
> v2: Read the histogram blob data before sending uevent (Jani)
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   5 +
>  drivers/gpu/drm/i915/display/intel_crtc.c | 202 +-
>  drivers/gpu/drm/i915/display/intel_crtc.h |   5 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  13 ++
>  .../drm/i915/display/intel_display_types.h|  17 ++
>  .../gpu/drm/i915/display/intel_histogram.c|   7 +
>  6 files changed, 248 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 76aa10b6f647..693a22089937 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -246,6 +246,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> 
>   __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
> 
> + if (crtc_state->global_iet)
> + drm_property_blob_get(crtc_state->global_iet);
>   /* copy color blobs */
>   if (crtc_state->hw.degamma_lut)
>   drm_property_blob_get(crtc_state->hw.degamma_lut);
> @@ -277,6 +279,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->fb_bits = 0;
>   crtc_state->update_planes = 0;
>   crtc_state->dsb = NULL;
> + crtc_state->histogram_en_changed = false;
> 
>   return &crtc_state->uapi;
>  }
> @@ -312,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
> 
>   drm_WARN_ON(crtc->dev, crtc_state->dsb);
> 
> + if (crtc_state->global_iet)
> + drm_property_blob_put(crtc_state->global_iet);
>   __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
>   intel_crtc_free_hw_state(crtc_state);
>   if (crtc_state->dp_tunnel_ref.tunnel)
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1b578cad2813..24f160359422 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "i915_vgpu.h"
>  #include "i9xx_plane.h"
> @@ -26,6 +27,7 @@
>  #include "intel_drrs.h"
>  #include "intel_dsi.h"
>  #include "intel_fifo_underrun.h"
> +#include "intel_histogram.h"
>  #include "intel_pipe_crc.h"
>  #include "intel_psr.h"
>  #include "intel_sprite.h"
> @@ -201,6 +203,7 @@ static struct intel_crtc *intel_crtc_alloc(void)  static
> void intel_crtc_free(struct intel_crtc *crtc)  {
>   intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> + intel_histogram_deinit(crtc);
>   kfree(crtc);
>  }
> 
> @@ -220,6 +223,100 @@ static int intel_crtc_late_register(struct drm_crtc
> *crtc)
>   return 0;
>  }
> 
> +static int intel_crtc_get_property(struct drm_crtc *crtc,
> +const struct drm_crtc_state *state,
> +struct drm_property *property,
> +uint64_t *val)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc->dev);
> + const struct intel_crtc_state *intel_crtc_state =
> + to_intel_crtc_state(state);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +
> + if (property == intel_crtc->histogram_en_property) {
> + *val = intel_crtc_state->histogram_en;
> + } else if (property == intel_crtc->global_iet_property) {
> + *val = (intel_crtc_state->global_iet) ?
> + intel_crtc_state->global_iet->base.id : 0;
> + } else if (property == intel_crtc->histogram_property) {
> + *val = (intel_crtc_state->histogram) ?
> + intel_crtc_state->histogram->base.id : 0;
> + } else {
> + drm_err(&i915->drm,
> + "Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +intel_atomic_replace_property_blob_from_id(struct drm_device *dev,
> +struct drm_property_blob **blob,
> +u64 blob_id,
> +ssize_t expected_size,
> +ssize_t expected_elem_size,
> + 

RE: [PATCH 1/5] drm/i915/display: Add support for histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Murthy, Arun R 
> Sent: Thursday, August 22, 2024 4:30 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH 1/5] drm/i915/display: Add support for histogram
> 
> > -Original Message-
> > From: Kulkarni, Vandita 
> > Sent: Thursday, August 22, 2024 4:24 PM
> > To: Murthy, Arun R ;
> > intel-gfx@lists.freedesktop.org
> > Subject: RE: [PATCH 1/5] drm/i915/display: Add support for histogram
> >
> > > -Original Message-
> > > From: Murthy, Arun R 
> > > Sent: Thursday, August 22, 2024 12:07 PM
> > > To: Kulkarni, Vandita ; intel-
> > > g...@lists.freedesktop.org
> > > Subject: RE: [PATCH 1/5] drm/i915/display: Add support for histogram
> > >
> > >
> > > > -Original Message-
> > > > From: Kulkarni, Vandita 
> > > > Sent: Monday, August 5, 2024 12:16 PM
> > > > To: Murthy, Arun R ;
> > > > intel-gfx@lists.freedesktop.org
> > > > Cc: Murthy, Arun R 
> > > > Subject: RE: [PATCH 1/5] drm/i915/display: Add support for
> > > > histogram
> > > >
> > > > > -Original Message-
> > > > > From: Intel-gfx  On
> > > > > Behalf Of Arun R Murthy
> > > > > Sent: Friday, July 5, 2024 3:26 PM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Murthy, Arun R 
> > > > > Subject: [PATCH 1/5] drm/i915/display: Add support for histogram
> > > > >
> > > > > Statistics is generated from the image frame that is coming to
> > > > > display and an event is sent to user after reading this histogram 
> > > > > data.
> > > > > This statistics/histogram is then shared with the user upon
> > > > > getting a request from user. User can then use this histogram
> > > > > and generate an enhancement factor. This enhancement factor can
> > > > > be multiplied/added with the incoming pixel data frame.
> > > > >
> > > > > Signed-off-by: Arun R Murthy 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/Makefile |   1 +
> > > > >  .../drm/i915/display/intel_display_types.h|   3 +
> > > > >  .../gpu/drm/i915/display/intel_histogram.c| 187
> > > ++
> > > > >  .../gpu/drm/i915/display/intel_histogram.h|  91 +
> > > > >  drivers/gpu/drm/xe/Makefile   |   1 +
> > > > >  5 files changed, 283 insertions(+)  create mode 100644
> > > > > drivers/gpu/drm/i915/display/intel_histogram.c
> > > > >  create mode 100644
> > > > > drivers/gpu/drm/i915/display/intel_histogram.h
> > > > >
> > > > I see that this patch is doing 3 things, histogram enable, setting
> > > > lut and also enable dithering.
> > > > See if they can be split into sub patches.
> > > >
> > > > Also on a generic note, there are a lot of TODO comments, are they
> > > > waiting on something or you have newer Version of these patches.
> > > > Otherwise it will be better to make a note in the comments what
> > > > will be the corner cases that would be hit with these TODO
> > > > comments not
> > > fixed.
> > >
> > > TODO has been added in places where we don’t need them for now but
> > > required. As of now we are enabling just the basic histogram, going
> > > forward we will need to have this TODO implemented as the driver
> > > enhances. So just to keep an eye and we don’t loose track on this
> > > TODO has been added in the code itself.
> > >
> > > >
> > > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > > b/drivers/gpu/drm/i915/Makefile index c63fa2133ccb..03caf3a24966
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > > @@ -264,6 +264,7 @@ i915-y += \
> > > > >   display/intel_hdcp.o \
> > > > >   display/intel_hdcp_gsc.o \
> > > > >   display/intel_hdcp_gsc_message.o \
> > > > > + display/intel_histogram.o \
> > > > >   display/intel_hotplug.o \
> > > > >   display/intel_hotplug_irq.o \
> > > > >   display/intel_hti.o \
> > > > > diff --git a/drivers/gpu/drm/i915/displ

RE: [PATCH 1/5] drm/i915/display: Add support for histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Murthy, Arun R 
> Sent: Thursday, August 22, 2024 12:07 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH 1/5] drm/i915/display: Add support for histogram
> 
> 
> > -Original Message-----
> > From: Kulkarni, Vandita 
> > Sent: Monday, August 5, 2024 12:16 PM
> > To: Murthy, Arun R ;
> > intel-gfx@lists.freedesktop.org
> > Cc: Murthy, Arun R 
> > Subject: RE: [PATCH 1/5] drm/i915/display: Add support for histogram
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Arun R Murthy
> > > Sent: Friday, July 5, 2024 3:26 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Murthy, Arun R 
> > > Subject: [PATCH 1/5] drm/i915/display: Add support for histogram
> > >
> > > Statistics is generated from the image frame that is coming to
> > > display and an event is sent to user after reading this histogram data.
> > > This statistics/histogram is then shared with the user upon getting
> > > a request from user. User can then use this histogram and generate
> > > an enhancement factor. This enhancement factor can be
> > > multiplied/added with the incoming pixel data frame.
> > >
> > > Signed-off-by: Arun R Murthy 
> > > ---
> > >  drivers/gpu/drm/i915/Makefile |   1 +
> > >  .../drm/i915/display/intel_display_types.h|   3 +
> > >  .../gpu/drm/i915/display/intel_histogram.c| 187
> ++
> > >  .../gpu/drm/i915/display/intel_histogram.h|  91 +
> > >  drivers/gpu/drm/xe/Makefile   |   1 +
> > >  5 files changed, 283 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.c
> > >  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.h
> > >
> > I see that this patch is doing 3 things, histogram enable, setting lut
> > and also enable dithering.
> > See if they can be split into sub patches.
> >
> > Also on a generic note, there are a lot of TODO comments, are they
> > waiting on something or you have newer Version of these patches.
> > Otherwise it will be better to make a note in the comments what will
> > be the corner cases that would be hit with these TODO comments not
> fixed.
> 
> TODO has been added in places where we don’t need them for now but
> required. As of now we are enabling just the basic histogram, going forward
> we will need to have this TODO implemented as the driver enhances. So just
> to keep an eye and we don’t loose track on this TODO has been added in the
> code itself.
> 
> >
> > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > b/drivers/gpu/drm/i915/Makefile index c63fa2133ccb..03caf3a24966
> > > 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -264,6 +264,7 @@ i915-y += \
> > >   display/intel_hdcp.o \
> > >   display/intel_hdcp_gsc.o \
> > >   display/intel_hdcp_gsc_message.o \
> > > + display/intel_histogram.o \
> > >   display/intel_hotplug.o \
> > >   display/intel_hotplug_irq.o \
> > >   display/intel_hti.o \
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 8713835e2307..e0a9c6d8c9b2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1537,6 +1537,9 @@ struct intel_crtc {
> > >   /* for loading single buffered registers during vblank */
> > >   struct pm_qos_request vblank_pm_qos;
> > >
> > > + /* histogram data */
> > > + struct intel_histogram *histogram;
> > > +
> > >  #ifdef CONFIG_DEBUG_FS
> > >   struct intel_pipe_crc pipe_crc;
> > >  #endif
> > > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> > > b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > new file mode 100644
> > > index ..1a603445fc29
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > @@ -0,0 +1,187 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2024 Intel Corporation  */
> > > +
> > > +#include 
> > > +#include 
> > > +#include "i915_reg.h"
> > > +#include "i915_drv.h"
> > > +#include "int

RE: [PATCH 1/5] drm/i915/display: Add support for histogram

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Arun
> R Murthy
> Sent: Friday, July 5, 2024 3:26 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Murthy, Arun R 
> Subject: [PATCH 1/5] drm/i915/display: Add support for histogram
> 
> Statistics is generated from the image frame that is coming to display and an
> event is sent to user after reading this histogram data.
> This statistics/histogram is then shared with the user upon getting a request
> from user. User can then use this histogram and generate an enhancement
> factor. This enhancement factor can be multiplied/added with the incoming
> pixel data frame.
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  .../drm/i915/display/intel_display_types.h|   3 +
>  .../gpu/drm/i915/display/intel_histogram.c| 187 ++
>  .../gpu/drm/i915/display/intel_histogram.h|  91 +
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  5 files changed, 283 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_histogram.h
> 
I see that this patch is doing 3 things, histogram enable, setting lut and also 
enable dithering.
See if they can be split into sub patches.

Also on a generic note, there are a lot of TODO comments, are they waiting on 
something or you have newer
Version of these patches.
Otherwise it will be better to make a note in the comments what will be the 
corner cases that would be hit with these
TODO comments not fixed.

> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c63fa2133ccb..03caf3a24966 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -264,6 +264,7 @@ i915-y += \
>   display/intel_hdcp.o \
>   display/intel_hdcp_gsc.o \
>   display/intel_hdcp_gsc_message.o \
> + display/intel_histogram.o \
>   display/intel_hotplug.o \
>   display/intel_hotplug_irq.o \
>   display/intel_hti.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8713835e2307..e0a9c6d8c9b2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1537,6 +1537,9 @@ struct intel_crtc {
>   /* for loading single buffered registers during vblank */
>   struct pm_qos_request vblank_pm_qos;
> 
> + /* histogram data */
> + struct intel_histogram *histogram;
> +
>  #ifdef CONFIG_DEBUG_FS
>   struct intel_pipe_crc pipe_crc;
>  #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> new file mode 100644
> index ..1a603445fc29
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -0,0 +1,187 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "intel_display_types.h"
> +#include "intel_de.h"
> +#include "intel_histogram.h"
> +
> +int intel_histogram_can_enable(struct intel_crtc *intel_crtc) {
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + /* TODO: Restrictions for enabling histogram */
More info on what kind of restrictions we are talking about here, will be 
helpful.

> + histogram->can_enable = true;
> +
> + return 0;
> +}
> +
> +static void intel_histogram_enable_dithering(struct drm_i915_private
> *dev_priv,
> +  enum pipe pipe)
> +{
> + intel_de_rmw(dev_priv, PIPE_MISC(pipe),
> PIPE_MISC_DITHER_ENABLE,
> +  PIPE_MISC_DITHER_ENABLE);
> +}
> +
> +static int intel_histogram_enable(struct intel_crtc *intel_crtc) {
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> + u64 res;
> + u32 gbandthreshold;
> +
> + if (!histogram->can_enable) {
> + drm_err(&i915->drm,
> + "Histogram not supported, compute config
> failed\n");
> + return -EINVAL;
> + }
> +
> + if (histogram->enable)
> + return 0;
> +
> + /* Pipe Dithering should be enabled with GLOBAL_HIST */
> + intel_histogram_enable_dithering(i915, pipe);
> +
> + /*
> +  * enable DPST_CTL Histogram mode
> +  * Clear DPST_CTL Bin Reg function select to TC
> +  */
> + intel_de_rmw(i915, DPST_CTL(pipe),
> +  DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> +  DPST_CTL_HIST_MODE |
> DPST_CTL_IE_TABLE_VALUE_FORMAT,
> +  DPST_CTL_BIN_REG_FUNC_TC | DPST_CTL_IE_HIST_EN |
> +  DPST_CTL_HIST_MODE_HSV |
> +  DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC);
> +
> + /* Re-Visi

RE: [PATCH] drm/i915/bios: remove stale and useless comments

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, July 29, 2024 11:03 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: [PATCH] drm/i915/bios: remove stale and useless comments
> 
> The comments do not add any value. Remove.
> 
> Signed-off-by: Jani Nikula 
> ---
LGTM.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
>  drivers/gpu/drm/i915/display/intel_bios.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 02443462bec3..460e83f0d5a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1692,14 +1692,6 @@ parse_mipi_config(struct drm_i915_private *i915,
>   /* Initialize this to undefined indicating no generic MIPI support */
>   panel->vbt.dsi.panel_id = MIPI_DSI_UNDEFINED_PANEL_ID;
> 
> - /* Block #40 is already parsed and panel_fixed_mode is
> -  * stored in i915->lfp_vbt_mode
> -  * resuse this when needed
> -  */
> -
> - /* Parse #52 for panel index used from panel_type already
> -  * parsed
> -  */
>   start = bdb_find_section(i915, BDB_MIPI_CONFIG);
>   if (!start) {
>   drm_dbg_kms(&i915->drm, "No MIPI config BDB found");
> --
> 2.39.2

RE: [PATCH 2/6] drm/i915: Reject async flips if we need to change DDB/watermarks

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 20, 2024 9:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 2/6] drm/i915: Reject async flips if we need to change
> DDB/watermarks
> 
> From: Ville Syrjälä 
> 
> DDB/watermarks are always double buffered on the vblank, so we can't
> safely change them during async flips. Currently this never happens, but we'll
> be making changing between sync and async flips a bit more flexible, in which
> case we can actually end up here.
> 
> Signed-off-by: Ville Syrjälä 
> ---
Looks good to me.
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/skl_watermark.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index bc341abcab2f..1fa416a70d51 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -2540,6 +2540,12 @@ skl_ddb_add_affected_planes(const struct
> intel_crtc_state *old_crtc_state,
>   &new_crtc_state-
> >wm.skl.plane_ddb_y[plane_id]))
>   continue;
> 
> + if (new_crtc_state->do_async_flip) {
> + drm_dbg_kms(&i915->drm, "[PLANE:%d:%s] Can't
> change DDB during async flip\n",
> + plane->base.base.id, plane->base.name);
> + return -EINVAL;
> + }
> +
>   plane_state = intel_atomic_get_plane_state(state, plane);
>   if (IS_ERR(plane_state))
>   return PTR_ERR(plane_state);
> @@ -2906,6 +2912,12 @@ static int skl_wm_add_affected_planes(struct
> intel_atomic_state *state,
>&new_crtc_state-
> >wm.skl.optimal))
>   continue;
> 
> + if (new_crtc_state->do_async_flip) {
> + drm_dbg_kms(&i915->drm, "[PLANE:%d:%s] Can't
> change watermarks during async flip\n",
> + plane->base.base.id, plane->base.name);
> + return -EINVAL;
> + }
> +
>   plane_state = intel_atomic_get_plane_state(state, plane);
>   if (IS_ERR(plane_state))
>   return PTR_ERR(plane_state);
> --
> 2.43.2

RE: [PATCH 3/6] drm/i915: Allow the initial async flip to change modifier

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 20, 2024 9:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 3/6] drm/i915: Allow the initial async flip to change modifier
> 
> From: Ville Syrjälä 
> 
> With Xorg+modesetting on skl+ we see the following behaviour:
> 1. root pixmap is X-tiled
> 2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"') 3.
> we try to switch from the X-tiled buffer to the Y-tiled buffer
>using an async flip (when vsync is disabled).
> 4. the async flip will be rejected by i915 due to the modifier change
> 
> Relax the rules a bit by turning the first async flip into a sync flip so 
> that we
> can change the modifier if necessary. Note that we already convert the first
> async flip into a sync flip on adl+ in order to reprogram the watermarks.
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

>  .../gpu/drm/i915/display/intel_atomic_plane.c| 16 +---
>  drivers/gpu/drm/i915/display/intel_display.c |  7 +++
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 76d77d5a0409..769010d0ebc4 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -429,10 +429,20 @@ static bool intel_plane_do_async_flip(struct
> intel_plane *plane,
>* In platforms after DISPLAY13, we might need to override
>* first async flip in order to change watermark levels
>* as part of optimization.
> -  * So for those, we are checking if this is a first async flip.
> -  * For platforms earlier than DISPLAY13 we always do async flip.
> +  *
> +  * And let's do this for all skl+ so that we can eg. change the
> +  * modifier as well.
> +  *
> +  * TODO: For older platforms there is less reason to do this as
> +  * only X-tile is supported with async flips, though we could
> +  * extend this so other scanout parameters (stride/etc) could
> +  * be changed as well...
> +  *
> +  * FIXME: Platforms with need_async_flip_disable_wa==true will
> +  * now end up doing two sync flips initially. Would be nice to
> +  * combine those into just the one sync flip...
>*/
> - return DISPLAY_VER(i915) < 13 || old_crtc_state->uapi.async_flip;
> + return DISPLAY_VER(i915) < 9 || old_crtc_state->uapi.async_flip;
>  }
> 
>  static bool i9xx_must_disable_cxsr(const struct intel_crtc_state
> *new_crtc_state, diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d366a103a707..dbcda79cf53c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6061,6 +6061,13 @@ static int intel_async_flip_check_hw(struct
> intel_atomic_state *state, struct in
>   return -EINVAL;
>   }
> 
> + /*
> +  * We turn the first async flip request into a sync flip
> +  * so that we can reconfigure the plane (eg. change
> modifier).
> +  */
> + if (!new_crtc_state->do_async_flip)
> + continue;
> +
>   if (old_plane_state->view.color_plane[0].mapping_stride !=
>   new_plane_state->view.color_plane[0].mapping_stride) {
>   drm_dbg_kms(&i915->drm,
> --
> 2.43.2

RE: [PATCH v2 01/17] drm/i915: Update pipes in reverse order for bigjoiner

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, April 5, 2024 3:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v2 01/17] drm/i915: Update pipes in reverse order for
> bigjoiner
> 
> From: Ville Syrjälä 
> 
> With bigjoiner the master crtc is the one that will send out the uapi
> event/etc. We want that to happen after all the slaves are done, so let's try
> to do the commits in reverse order so that the master comes last.
> 
> Even worse, the modeset helper will simply complete the commit on the
> slave pipe immediately as it consider the crtc to be inactive (it can't see 
> our
> crtc_state->hw.active/etc.).
> 
> With regular sync updates this generally doesn't matter all that much as the
> slave pipe should typically finish its work during the same frame as the
> master pipe. However in case the slave pipe's commit slips into the next
> frame we end up in a bit of trouble. This is most visible with either async 
> flips
> (currently disabled with bigjoiner exactly for this reason), and DSB gamma
> updates. With DSB the problem happens because the DSB itself will wait until
> the next start vblank before starting to execute. So if the master pipe 
> already
> finished its commit and the DSB on the slave pipe is still waiting for the 
> next
> vblank we will assume the DSB as gotten stuck and terminate it.
> 
> Reversing the commit order should ameliarate this for the most part as the
> master pipe is guaranteed to start its commit after the slave pipe started. 
> The
> one thing that can still screw us over is the fact that we aren't necessarily
> going to commit the pipes in the reverse order as the actual order is dictated
> by the DDB overlap avoidance.
> But that can only happen while other pipes are being enabled/disabled, and
> so in the normal steady state we should be safe.
> 
> The full fix will involve making the commit machinery aware of the slave
> pipes and not finish their commits prematurely. But that will involve a bit
> more work than this. And this commit order reversal will still be beneficial 
> to
> avoid userspace getting an -EBUSY from the following page flip if the second
> pipe's commit does stretch into the next frame.
> 

LGTM.
Reviewed-by: Vandita Kulkarni 

I had just one query though,
Will there be a case where we can get vblank between slave update and master 
update,
if so do you think there will be any problem due to that?

Thanks,
Vandita

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
> drivers/gpu/drm/i915/display/intel_display.h |  8 
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a481c9218138..0086a7422e86 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6956,8 +6956,12 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
>   intel_dbuf_mbus_pre_ddb_update(state);
> 
>   while (update_pipes) {
> - for_each_oldnew_intel_crtc_in_state(state, crtc,
> old_crtc_state,
> - new_crtc_state, i) {
> + /*
> +  * Commit in reverse order to make bigjoiner master
> +  * send the uapi events after slaves are done.
> +  */
> + for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> old_crtc_state,
> + new_crtc_state, i) {
>   enum pipe pipe = crtc->pipe;
> 
>   if ((update_pipes & BIT(pipe)) == 0) @@ -7036,7
> +7040,11 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
>   intel_pre_update_crtc(state, crtc);
>   }
> 
> - for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + /*
> +  * Commit in reverse order to make bigjoiner master
> +  * send the uapi events after slaves are done.
> +  */
> + for_each_new_intel_crtc_in_state_reverse(state, crtc,
> new_crtc_state,
> +i) {
>   enum pipe pipe = crtc->pipe;
> 
>   if ((update_pipes & BIT(pipe)) == 0)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 986ec77490de..423074d6947a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -344,6 +344,14 @@ enum phy_fia {
>(__i)++) \
>   for_each_if(crtc)
> 
> +#define for_each_new_intel_crtc_in_state_reverse(__state, crtc,
> new_crtc_state, __i) \
> + for ((__i) = (__state)->base.dev->mode_config.num_crtc - 1; \
> +  (__i) >= 0  && \
> +  ((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \
> +   (new_crtc_state) = to_intel_crtc_state((__sta

RE: [PATCH 05/22] drm/i915: Remove DRM_MODE_FLAG_DBLSCAN checks from .mode_valid() hooks

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 05/22] drm/i915: Remove DRM_MODE_FLAG_DBLSCAN
> checks from .mode_valid() hooks
> 
> From: Ville Syrjälä 
> 
> We never set connector->doublescan_allowed, so the probe helper already
> filters out all doublescan modes for us.
> 
> Sadly we still need to keep the explicit doublescan checks in .compute_config
> as outlined in commit e4dd27aadd20
> ("drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI")
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_crt.c| 3 ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 -
>  drivers/gpu/drm/i915/display/intel_dsi.c| 3 ---
>  drivers/gpu/drm/i915/display/intel_dvo.c| 3 ---
>  drivers/gpu/drm/i915/display/intel_lvds.c   | 3 ---
>  drivers/gpu/drm/i915/display/intel_sdvo.c   | 3 ---
>  drivers/gpu/drm/i915/display/intel_tv.c | 3 ---
>  7 files changed, 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 93479db0f89f..2e95093aa4d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -356,9 +356,6 @@ intel_crt_mode_valid(struct drm_connector
> *connector,
>   if (status != MODE_OK)
>   return status;
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   if (mode->clock < 25000)
>   return MODE_CLOCK_LOW;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 53aec023ce92..9a7c75039989 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1302,11 +1302,6 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>   if (*status != MODE_OK)
>   return 0;
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> - *status = MODE_NO_DBLESCAN;
> - return 0;
> - }
> -
>   max_link_clock = intel_dp_max_link_rate(intel_dp);
>   max_lanes = intel_dp_max_lane_count(intel_dp);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.c
> b/drivers/gpu/drm/i915/display/intel_dsi.c
> index d3cf6a652221..2dfc60e4b615 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi.c
> @@ -69,9 +69,6 @@ enum drm_mode_status intel_dsi_mode_valid(struct
> drm_connector *connector,
> 
>   drm_dbg_kms(&dev_priv->drm, "\n");
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   status = intel_panel_mode_valid(intel_connector, mode);
>   if (status != MODE_OK)
>   return status;
> diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
> b/drivers/gpu/drm/i915/display/intel_dvo.c
> index c076da75b066..060328c0df7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_dvo.c
> @@ -231,9 +231,6 @@ intel_dvo_mode_valid(struct drm_connector
> *_connector,
>   if (status != MODE_OK)
>   return status;
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   /* XXX: Validate clock range */
> 
>   if (fixed_mode) {
> diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
> b/drivers/gpu/drm/i915/display/intel_lvds.c
> index 221f5c6c871b..24860945f2e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/display/intel_lvds.c
> @@ -399,9 +399,6 @@ intel_lvds_mode_valid(struct drm_connector
> *_connector,
>   if (status != MODE_OK)
>   return status;
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   status = intel_panel_mode_valid(connector, mode);
>   if (status != MODE_OK)
>   return status;
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 50f0557d9ca2..df76044a739a 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1952,9 +1952,6 @@ intel_sdvo_mode_valid(struct drm_connector
> *connector,
>   if (status != MODE_OK)
>   return status;
> 
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   if (clock > max_dotclk)
>   return MODE_CLOCK_HIGH;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index ba5d2b7174b7..79d35c1b3c81 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -969,9 +969,6 @@ intel_tv_mode_valid(struct drm_connector
> *connector,
>   if (status != MODE_OK)
>   return status;
> 
> - if 

RE: [PATCH 08/22] drm/i915: Extract glk_need_scaler_clock_gating_wa()

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 08/22] drm/i915: Extract glk_need_scaler_clock_gating_wa()
> 
> From: Ville Syrjälä 
> 
> Simplify our life by extracting the "do we need the glk scaler clock gating
> w/a?" check into a small helper.
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_display.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 83474fcf4131..6197b62dac55 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1551,6 +1551,14 @@ static void ilk_crtc_enable(struct
> intel_atomic_state *state,
>   intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);  }
> 
> +/* Display WA #1180: WaDisableScalarClockGating: glk */ static bool
> +glk_need_scaler_clock_gating_wa(const struct intel_crtc_state
> +*crtc_state) {
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + return DISPLAY_VER(i915) == 10 && crtc_state->pch_pfit.enabled; }
> +
>  static void glk_pipe_scaler_clock_gating_wa(struct intel_crtc *crtc, bool
> enable)  {
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev); @@ -1635,7
> +1643,6 @@ static void hsw_crtc_enable(struct intel_atomic_state *state,
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
>   enum pipe hsw_workaround_pipe;
> - bool psl_clkgate_wa;
> 
>   if (drm_WARN_ON(&dev_priv->drm, crtc->active))
>   return;
> @@ -1668,10 +1675,7 @@ static void hsw_crtc_enable(struct
> intel_atomic_state *state,
> 
>   crtc->active = true;
> 
> - /* Display WA #1180: WaDisableScalarClockGating: glk */
> - psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10 &&
> - new_crtc_state->pch_pfit.enabled;
> - if (psl_clkgate_wa)
> + if (glk_need_scaler_clock_gating_wa(new_crtc_state))
>   glk_pipe_scaler_clock_gating_wa(crtc, true);
> 
>   if (DISPLAY_VER(dev_priv) >= 9)
> @@ -1702,7 +1706,7 @@ static void hsw_crtc_enable(struct
> intel_atomic_state *state,
> 
>   intel_encoders_enable(state, crtc);
> 
> - if (psl_clkgate_wa) {
> + if (glk_need_scaler_clock_gating_wa(new_crtc_state)) {
>   intel_crtc_wait_for_next_vblank(crtc);
>   glk_pipe_scaler_clock_gating_wa(crtc, false);
>   }
> --
> 2.43.2

RE: [PATCH 07/22] drm/i915: Clean up glk_pipe_scaler_clock_gating_wa()

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 07/22] drm/i915: Clean up
> glk_pipe_scaler_clock_gating_wa()
> 
> From: Ville Syrjälä 
> 
> glk_pipe_scaler_clock_gating_wa() is messy. Clean it up via intel_de_rmw(),
> and also just pass in the whole crtc so the caller doesn't dance around so
> much.
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM,
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_display.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 08705042b4f8..83474fcf4131 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1551,18 +1551,13 @@ static void ilk_crtc_enable(struct
> intel_atomic_state *state,
>   intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);  }
> 
> -static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private
> *dev_priv,
> - enum pipe pipe, bool apply)
> +static void glk_pipe_scaler_clock_gating_wa(struct intel_crtc *crtc,
> +bool enable)
>  {
> - u32 val = intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe));
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   u32 mask = DPF_GATING_DIS | DPF_RAM_GATING_DIS |
> DPFR_GATING_DIS;
> 
> - if (apply)
> - val |= mask;
> - else
> - val &= ~mask;
> -
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe), val);
> + intel_de_rmw(i915, CLKGATE_DIS_PSL(crtc->pipe),
> +  mask, enable ? mask : 0);
>  }
> 
>  static void hsw_set_linetime_wm(const struct intel_crtc_state *crtc_state)
> @@ -1638,8 +1633,8 @@ static void hsw_crtc_enable(struct
> intel_atomic_state *state,
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
>   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> + enum pipe hsw_workaround_pipe;
>   bool psl_clkgate_wa;
> 
>   if (drm_WARN_ON(&dev_priv->drm, crtc->active)) @@ -1677,7
> +1672,7 @@ static void hsw_crtc_enable(struct intel_atomic_state *state,
>   psl_clkgate_wa = DISPLAY_VER(dev_priv) == 10 &&
>   new_crtc_state->pch_pfit.enabled;
>   if (psl_clkgate_wa)
> - glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
> + glk_pipe_scaler_clock_gating_wa(crtc, true);
> 
>   if (DISPLAY_VER(dev_priv) >= 9)
>   skl_pfit_enable(new_crtc_state);
> @@ -1709,7 +1704,7 @@ static void hsw_crtc_enable(struct
> intel_atomic_state *state,
> 
>   if (psl_clkgate_wa) {
>   intel_crtc_wait_for_next_vblank(crtc);
> - glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
> + glk_pipe_scaler_clock_gating_wa(crtc, false);
>   }
> 
>   /* If we change the relative order between pipe/planes enabling, we
> need
> --
> 2.43.2

RE: [PATCH 06/22] drm/i915: Shuffle DP .mode_valid() checks

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 06/22] drm/i915: Shuffle DP .mode_valid() checks
> 
> From: Ville Syrjälä 
> 
> Move some of the more trivial checks in the DP .mode_valid() hooks upwards
> to lessen the noise amongst the more complex checks.
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_dp.c |  6 +++---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 21 ++---
>  2 files changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index bc9d6efc99ee..2490ce32da50 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1229,6 +1229,9 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
> 
> + if (mode->clock < 1)
> + return MODE_CLOCK_LOW;
> +
>   fixed_mode = intel_panel_fixed_mode(connector, mode);
>   if (intel_dp_is_edp(intel_dp) && fixed_mode) {
>   status = intel_panel_mode_valid(connector, mode); @@ -
> 1238,9 +1241,6 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
>   target_clock = fixed_mode->clock;
>   }
> 
> - if (mode->clock < 1)
> - return MODE_CLOCK_LOW;
> -
>   if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock))
> {
>   bigjoiner = true;
>   max_dotclk *= 2;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 9a7c75039989..1405ab5e3acc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1302,6 +1302,16 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>   if (*status != MODE_OK)
>   return 0;
> 
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> + *status = MODE_H_ILLEGAL;
> + return 0;
> + }
> +
> + if (mode->clock < 1) {
> + *status = MODE_CLOCK_LOW;
> + return 0;
> + }
> +
>   max_link_clock = intel_dp_max_link_rate(intel_dp);
>   max_lanes = intel_dp_max_lane_count(intel_dp);
> 
> @@ -1330,17 +1340,6 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
>   *status = MODE_CLOCK_HIGH;
>   return 0;
>   }
> -
> - if (mode->clock < 1) {
> - *status = MODE_CLOCK_LOW;
> - return 0;
> - }
> -
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> - *status = MODE_H_ILLEGAL;
> - return 0;
> - }
> -
>   if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock))
> {
>   bigjoiner = true;
>   max_dotclk *= 2;
> --
> 2.43.2

RE: [PATCH 04/22] drm/i915/vrr: Disable VRR when using bigjoiner

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 04/22] drm/i915/vrr: Disable VRR when using bigjoiner
> 
> From: Ville Syrjälä 
> 
> All joined pipes share the same transcoder/timing generator.
> Currently we just do the commits per-pipe, which doesn't really work if we
> need to change switch between non-VRR and VRR timings generators on the
> fly, or even when sending the push to the transcoder. For now just disable
> VRR when bigjoiner is needed.
> 
> Signed-off-by: Ville Syrjälä 
> ---

LGTM.
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_vrr.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index eb5bd0743902..f542ee1db1d9 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -117,6 +117,13 @@ intel_vrr_compute_config(struct intel_crtc_state
> *crtc_state,
>   const struct drm_display_info *info = &connector-
> >base.display_info;
>   int vmin, vmax;
> 
> + /*
> +  * FIXME all joined pipes share the same transcoder.
> +  * Need to account for that during VRR toggle/push/etc.
> +  */
> + if (crtc_state->bigjoiner_pipes)
> + return;
> +
>   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   return;
> 
> --
> 2.43.2

RE: [PATCH 09/22] drm/i915: s/intel_dp_can_bigjoiner()/intel_dp_can_bigjoiner()/

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 09/22] drm/i915:
> s/intel_dp_can_bigjoiner()/intel_dp_can_bigjoiner()/
> 
> From: Ville Syrjälä 
> 
> Rename intel_dp_can_bigjoiner() to intel_dp_has_bigjoiner() to better reflect
> its function.
> 
> Signed-off-by: Ville Syrjälä 
> ---

Typo in the commit header.
With that fixed
Reviewed-by: Vandita Kulkarni 

>  drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2490ce32da50..402b3b8f6382 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -425,7 +425,7 @@ int intel_dp_max_link_data_rate(struct intel_dp
> *intel_dp,
>   return max_rate;
>  }
> 
> -bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
> +bool intel_dp_has_bigjoiner(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct intel_encoder *encoder = &intel_dig_port->base; @@ -1199,7
> +1199,7 @@ bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   struct intel_connector *connector = intel_dp->attached_connector;
> 
> - if (!intel_dp_can_bigjoiner(intel_dp))
> + if (!intel_dp_has_bigjoiner(intel_dp))
>   return false;
> 
>   return clock > i915->max_dotclk_freq || hdisplay > 5120 || diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c540d3a73fe7..4a4b39f2748b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -119,7 +119,7 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
>int bw_overhead);
>  int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
>   int max_dprx_rate, int max_dprx_lanes); -
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);
> +bool intel_dp_has_bigjoiner(struct intel_dp *intel_dp);
>  bool intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state *conn_state);
> void intel_dp_set_infoframes(struct intel_encoder *encoder, bool enable,
> --
> 2.43.2

RE: [PATCH 02/22] drm/i915: Fix intel_modeset_pipe_config_late() for bigjoiner

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 02/22] drm/i915: Fix intel_modeset_pipe_config_late() for
> bigjoiner
> 
> From: Ville Syrjälä 
> 
> Currently intel_modeset_pipe_config_late() is called after the bigjoiner state
> copy, and it will actually not do anything for bigjoiner slaves. This can 
> lead to
> a mismatched state between the master and slave.
> 
> The two things that we do in the encoder .compute_config_late() hook are
> mst master transcoder and port sync master transcoder elections. So if either
> of either MST or port sync is combined with bigjoiner then we can see the
> mismatch.
> 
> Currently this problem is more or less theoretical; MST+bigjoiner has not
> been implemented yet, and port sync+bigjoiner would require a tiled display
> with >5k tiles (or a very high dotclock per tile). Although we do have
> kms_tiled_display in igt which can fake a tiled display, and we can now force
> bigjoiner via debugfs, so it is possible to trigger this if you try hard 
> enough.
> 
> Reorder the code such that intel_modeset_pipe_config_late() will be called
> before the bigjoiner state copy happens so that both pipes will end up with
> the same state.
> 
> Signed-off-by: Ville Syrjälä 

As we are already calling out on not being able to support port sync + 
bigjoiner  not being able  to support as of now in the patch 1, this change 
looks good to me.

Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 46 ++--
>  1 file changed, 32 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 614e60420a29..08705042b4f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4753,8 +4753,6 @@ intel_modeset_pipe_config_late(struct
> intel_atomic_state *state,
>   struct drm_connector *connector;
>   int i;
> 
> - intel_bigjoiner_adjust_pipe_src(crtc_state);
> -
>   for_each_new_connector_in_state(&state->base, connector,
>   conn_state, i) {
>   struct intel_encoder *encoder =
> @@ -6248,27 +6246,37 @@ static int intel_atomic_check_config(struct
> intel_atomic_state *state,
>   continue;
>   }
> 
> - if (intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> - drm_WARN_ON(&i915->drm, new_crtc_state-
> >uapi.enable);
> + if (drm_WARN_ON(&i915->drm,
> +intel_crtc_is_bigjoiner_slave(new_crtc_state)))
>   continue;
> - }
> 
>   ret = intel_crtc_prepare_cleared_state(state, crtc);
>   if (ret)
> - break;
> + goto fail;
> 
>   if (!new_crtc_state->hw.enable)
>   continue;
> 
>   ret = intel_modeset_pipe_config(state, crtc, limits);
>   if (ret)
> - break;
> + goto fail;
> + }
> 
> - ret = intel_atomic_check_bigjoiner(state, crtc);
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (!intel_crtc_needs_modeset(new_crtc_state))
> + continue;
> +
> + if (drm_WARN_ON(&i915->drm,
> intel_crtc_is_bigjoiner_slave(new_crtc_state)))
> + continue;
> +
> + if (!new_crtc_state->hw.enable)
> + continue;
> +
> + ret = intel_modeset_pipe_config_late(state, crtc);
>   if (ret)
> - break;
> + goto fail;
>   }
> 
> +fail:
>   if (ret)
>   *failed_pipe = crtc->pipe;
> 
> @@ -6364,16 +6372,26 @@ int intel_atomic_check(struct drm_device *dev,
>   if (ret)
>   goto fail;
> 
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (!intel_crtc_needs_modeset(new_crtc_state))
> + continue;
> +
> + if (intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> + drm_WARN_ON(&dev_priv->drm, new_crtc_state-
> >uapi.enable);
> + continue;
> + }
> +
> + ret = intel_atomic_check_bigjoiner(state, crtc);
> + if (ret)
> + goto fail;
> + }
> +
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>   new_crtc_state, i) {
>   if (!intel_crtc_needs_modeset(new_crtc_state))
>   continue;
> 
> - if (new_crtc_state->hw.enable) {
> - ret = intel_modeset_pipe_config_late(state, crtc);
> - if (ret)
> - goto fail;
> - }
> +  

RE: [PATCH 01/22] drm/i915: Disable port sync when bigjoiner is used

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 29, 2024 6:43 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 01/22] drm/i915: Disable port sync when bigjoiner is used
> 
> From: Ville Syrjälä 
> 
> The current modeset sequence can't handle port sync and bigjoiner at the
> same time. Refuse port sync when bigjoiner is needed, at least until we fix
> the modeset sequence.
> 
> Signed-off-by: Ville Syrjälä 

Like you have said in the second patch in the series " port sync+bigjoiner 
would require a tiled display with >5k tiles (or a very high dotclock per 
tile)." this would be a rare case, since it needs to be fixed later, a todo 
comment would be helpful, to take care of it for later.
With that
Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a3d3d4942eb1..fa6fe9ec8027 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4244,6 +4244,7 @@ static bool crtcs_port_sync_compatible(const
> struct intel_crtc_state *crtc_state
>  const struct intel_crtc_state 
> *crtc_state2)
> {
>   return crtc_state1->hw.active && crtc_state2->hw.active &&
> + !crtc_state1->bigjoiner_pipes && !crtc_state2-
> >bigjoiner_pipes &&
>   crtc_state1->output_types == crtc_state2->output_types &&
>   crtc_state1->output_format == crtc_state2->output_format
> &&
>   crtc_state1->lane_count == crtc_state2->lane_count &&
> --
> 2.43.2

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915: Adding the new registers for DSC

[Kulkarni, Vandita]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, January 11, 2023 11:09 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kulkarni, Vandita
> ; Navare, Manasi D
> ; Kandpal, Suraj 
> Subject: [PATCH v6 3/9] drm/i915: Adding the new registers for DSC
> 
> Adding new DSC register which are introducted MTL onwards
> 
> Signed-off-by: Suraj Kandpal 
Reviewed-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 8b2cf980f323..69a645ce0fe8
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7766,6 +7766,8 @@ enum skl_power_gate {
>  #define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe)
>   _MMIO_PIPE((pipe) - PIPE_B, \
> 
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
> 
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
> +#define  DSC_NATIVE_422_ENABLE   BIT(23)
> +#define  DSC_NATIVE_420_ENABLE   BIT(22)
>  #define  DSC_ALT_ICH_SEL (1 << 20)
>  #define  DSC_VBR_ENABLE  (1 << 19)
>  #define  DSC_422_ENABLE  (1 << 18)
> @@ -8010,6 +8012,32 @@ enum skl_power_gate {
>  #define  DSC_SLICE_PER_LINE(slice_per_line)  ((slice_per_line) <<
> 16)
>  #define  DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
>   ((slice_chunk_size) << 0)
> 
> +/* MTL Display Stream Compression registers */
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB0x782B4
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB0x783B4
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC0x784B4
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC0x785B4
> +#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)
>   _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
> +#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)
>   _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
> +#define DSC_SL_BPG_OFFSET(offset)((offset) << 27)
> +
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB0x782B8
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB0x783B8
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC0x784B8
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC0x785B8
> +#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)
>   _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
> +#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)
>   _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
> +#define DSC_NSL_BPG_OFFSET(offset)   ((offset) << 16)
> +#define DSC_SL_OFFSET_ADJ(offset)((offset) << 0)
> +
>  /* Icelake Rate Control Buffer Threshold Registers */
>  #define DSCA_RC_BUF_THRESH_0 _MMIO(0x6B230)
>  #define DSCA_RC_BUF_THRESH_0_UDW _MMIO(0x6B230 + 4)
> --
> 2.25.1

Re: [Intel-gfx] [PATCH v6 4/9] drm/i915: Enable YCbCr420 for VDSC

[Kulkarni, Vandita]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, January 11, 2023 11:09 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kulkarni, Vandita
> ; Navare, Manasi D
> ; Kandpal, Suraj 
> Subject: [PATCH v6 4/9] drm/i915: Enable YCbCr420 for VDSC
> 
> Implementation of VDSC for YCbCr420.
Some more description on from where the tables that are added in this patch were
taken from and spec reference will be good to have here.

With that added the patch looks good to me.
Reviewed-by: Vandita Kulkarni 
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
>  .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
>  drivers/gpu/drm/i915/display/intel_vdsc.c |   4 +-
>  3 files changed, 180 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> index 6f8e4ec5c0fb..6e86c0971d24 100644
> --- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> +++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> @@ -17,6 +17,15 @@
>  /* from BPP 6 to 36 in steps of 0.5 */
>  #define RC_RANGE_QP444_12BPC_MAX_NUM_BPP 61
> 
> +/* from BPP 6 to 24 in steps of 0.5 */
> +#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP  17
> +
> +/* from BPP 6 to 30 in steps of 0.5 */
> +#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP 23
> +
> +/* from BPP 6 to 36 in steps of 0.5 */
> +#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP 29
> +
>  /*
>   * These qp tables are as per the C model
>   * and it has the rows pointing to bpps which increment @@ -283,26
> +292,182 @@ static const u8
> rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_
> 12BPC
> 11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5, 
> 5, 4 }  };
> 
> -#define PARAM_TABLE(_minmax, _bpc, _row, _col)  do { \
> - if (bpc == (_bpc)) \
> - return
> rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
> +static const u8
> rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8B
> PC_MAX_NUM_BPP] = {
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
> + { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
> + { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
> + { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
> + { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
> + { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
> + { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 } };
> +
> +static const u8
> rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8
> BPC_MAX_NUM_BPP] = {
> + { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
> + { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
> + { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
> + { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
> + { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
> + { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
> + { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
> + { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
> + { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
> + { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
> + { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
> + { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
> + { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
> + { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 } };
> +
> +static const u8
> rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_1
> 0BPC_MAX_NUM_BPP] = {
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
> + { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
> + { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1

Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: Fill in native_420 field

[Kulkarni, Vandita]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, September 21, 2022 4:25 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kulkarni, Vandita
> ; Navare, Manasi D
> ; Kandpal, Suraj 
> Subject: [PATCH 3/3] drm/i915/display: Fill in native_420 field
> 
> From: Suraj Kandpal 
> 
> Now that we have laid the groundwork for YUV420 Enablement we fill up
> native_420 field in vdsc_cfg and add appropriate checks wherever required.
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c|  2 --
>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 16 +++-
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ed4d93942dbd..9d2710edd27e 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1625,8 +1625,6 @@ static int gen11_dsi_dsc_compute_config(struct
> intel_encoder *encoder,
>   if (crtc_state->dsc.slice_count > 1)
>   crtc_state->dsc.dsc_split = true;
> 
> - vdsc_cfg->convert_rgb = true;
> -
>   /* FIXME: initialize from VBT */
>   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f2f77856df83..50f8e121 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1440,9 +1440,6 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
>   min(intel_dp_source_dsc_version_minor(intel_dp),
>   intel_dp_sink_dsc_version_minor(intel_dp));
> 
> - vdsc_cfg->convert_rgb = intel_dp-
> >dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
> - DP_DSC_RGB;
> -
>   line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp-
> >dsc_dpcd);
>   if (!line_buf_depth) {
>   drm_dbg_kms(&i915->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index a642975a1b61..1ab2a2286c74 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -462,14 +462,28 @@ int intel_dsc_compute_params(struct
> intel_crtc_state *pipe_config)
>   vdsc_cfg->pic_width = pipe_config-
> >hw.adjusted_mode.crtc_hdisplay;
>   vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
>pipe_config->dsc.slice_count);
> + /*
> +  * According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
> is 0
> +  * else 1
> +  */
> + vdsc_cfg->convert_rgb = !(pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ||
> +   pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR444);
> 
> - /* Gen 11 does not support YCbCr */
> + if (pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> + vdsc_cfg->native_420 = true;
> + /* Gen 11 does not support YCbCr422 */
>   vdsc_cfg->simple_422 = false;

>From 1.2 onwards we have native_422 as well, so we need to configure it based 
>on the output format.
Also, I see that PPS configuration is missing for all 420 and 422 , PPS0 
register, please add that.

Thanks,
Vandita

>   /* Gen 11 does not support VBR */
>   vdsc_cfg->vbr_enable = false;
> 
>   /* Gen 11 only supports integral values of bpp */
>   vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> + /*
> +  * According to DSC 1.2 specs if native_420 is set we need to double
> the current bpp
> +  */
> + if (vdsc_cfg->native_420)
> + vdsc_cfg->bits_per_pixel <<= 1;
> +
>   vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
> 
>   for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> --
> 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/vdsc: Set VDSC PIC_HEIGHT before using for DP DSC

[Kulkarni, Vandita]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Friday, September 2, 2022 4:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Navare, Manasi D ; Kulkarni, Vandita
> ; Roper, Matthew D
> 
> Subject: [PATCH] drm/i915/vdsc: Set VDSC PIC_HEIGHT before using for DP
> DSC
> 
> Currently, pic_height of vdsc_cfg structure is being used to calculate
> slice_height, before it is set for DP.
> 
> So taking out the lines to set pic_height from the helper
> intel_dp_dsc_compute_params() to individual encoders, and setting
> pic_height, before it is used to calculate slice_height for DP.
> 
> Fixes: 5a6d866f8e1b ("drm/i915: Get slice height before computing rc
> params")
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Cc: Matt Roper 
> 
> Signed-off-by: Ankit Nautiyal 

Looks good to me. Thanks for fixing this.

Reviewed-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c| 2 ++
>  drivers/gpu/drm/i915/display/intel_dp.c   | 1 +
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 1 -
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 3e20b2f65887..ed4d93942dbd 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1630,6 +1630,8 @@ static int gen11_dsi_dsc_compute_config(struct
> intel_encoder *encoder,
>   /* FIXME: initialize from VBT */
>   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> 
> + vdsc_cfg->pic_height = crtc_state-
> >hw.adjusted_mode.crtc_vdisplay;
> +
>   ret = intel_dsc_compute_params(crtc_state);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d4e037450ac5..8dd346800112 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1406,6 +1406,7 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
>* DP_DSC_RC_BUF_SIZE for this.
>*/
>   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> + vdsc_cfg->pic_height = crtc_state-
> >hw.adjusted_mode.crtc_vdisplay;
> 
>   /*
>* Slice Height of 8 works for all currently available panels. So start 
> diff
> --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index d7eb1af328e7..269f9792390d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -460,7 +460,6 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
>   u8 i = 0;
> 
>   vdsc_cfg->pic_width = pipe_config-
> >hw.adjusted_mode.crtc_hdisplay;
> - vdsc_cfg->pic_height = pipe_config-
> >hw.adjusted_mode.crtc_vdisplay;
>   vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
>pipe_config->dsc.slice_count);
> 
> --
> 2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Tuesday, January 11, 2022 11:42 AM
> To: Kulkarni, Vandita 
> Cc: Nikula, Jani ; Lisovskiy, Stanislav
> ; Ville Syrjälä 
> ;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> On Mon, Jan 10, 2022 at 08:24:54PM -0800, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Navare, Manasi D 
> > > Sent: Tuesday, January 11, 2022 1:07 AM
> > > To: Kulkarni, Vandita 
> > > Cc: Nikula, Jani ; Lisovskiy, Stanislav
> > > ; Ville Syrjälä
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > VDSC engine for higher moderates
> > >
> > > Thankf for revisiting this thread. The use of max_cdclk is currently
> > > in 2 places in DSC code 1. . if (adjusted_mode->crtc_clock >
> > > dev_priv->max_cdclk_freq) {
> > > if (pipe_config->dsc.slice_count > 1) {
> > > pipe_config->dsc.dsc_split = true; 2. if 
> > > (bigjoiner) {
> > > u32 max_bpp_bigjoiner =
> > > i915->max_cdclk_freq * 48 /
> > > intel_dp_mode_to_fec_clock(mode_clock);
> > >
> > > DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> > > max_bpp_bigjoiner);
> > > bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> > > }
> > >
> > > In both these places, using max_cdclk can cause problems, like for
> > > compressed bpp it can give a higher bpp based on max_cdclk and we
> > > might actually end up chosing lower cdclk at what point this will cause
> underruns.
> > >
> > > So when I was discussing with Ville on this, my first thought was
> > > also to use the cdclk_state->actual_cdclk but like Ville mentioned
> > > later in the review comments the challenge there was that actual
> > > cdclk does get computed much later than dsc_compute_config.
> > >
> > > So I think as suggested in one of the reviews we just to check if
> > > DSC is enabled then we dont allow lowering the cdclk which would
> > > also prevent underruns caused by possibly setting up higher bpp based
> on max cdclk.
> >
> > Thanks for the review.
> > This is taken care now, in case if we cannot split, then we already are 
> > using
> max_cdclk.
> > Regarding the bigjoiner_bpp, you may need to make the change if you
> need it to be set to max cdclk.
> > As we all of us here agree that we do not have computed cd clk at that
> time.
> >
> 

Just to clarify this patch doesn’t do anything wrt the big  joiner bpp 
calclulation.

> So the resolution was to keep it at max_cdclock when we set the dsc.split
> and decide to use 2 VDSC engines? 
 
The solution was to keep it at max_cdclk when we dsc.split is false.
>Is this change merged upstream now?
Yes
> For bpp calculation, that was pointed out by Srikanth that they were seeing
> underruns and was a bug they had found in their code.
> And infact there we dont want to set it to max_cdclk because if we lower the
> cdclk later then that bpp will cause underuns.

I am guessing you are talking about big joiner cases, this patch was made for 
addressing pure dsc cases
Where we were seeing underruns. Due to 1 ppc limitation.
> One of the comments in here was to then check if DSC enabled in function
> that tries to lower the cdclk and not allow if DSC enabled.
The suggestion was to check if we are not using split = true  (2 dsc engines), 
then use max cdclk.
PS : intel_crtc_compute_min_cdclk

This whole patch was to make sure that when we cannot use 2 dsc engine, to 
increase the cdclk.
Or use 2 engines based on the current cdclk, which is not possible.
And we were checking against max cdclk to enable second engine.

This got resolved with the change that is merged now, sets cdclk to max if we 
cannot enable the second vdsc engine.

The suggestion from the bspec is directing to use 2 vdsc engines based on the 
condition that I have mentioned below,
And that means we really do not need the check if (adjusted_mode->crtc_clock > 
dev_priv- max_cdclk_freq) to set split = true.

> Are you already working on that change or do I need to follow up on that
> with Ville/ Jani?

Here in this patch we are not talking about the bpp calculation based on cd clk 
at all, which comes into picture with big joiner.
If you want to make changes wrt bigjoiner, you may need to make another patch, 
which I am not working on.

As p

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Tuesday, January 11, 2022 1:07 AM
> To: Kulkarni, Vandita 
> Cc: Nikula, Jani ; Lisovskiy, Stanislav
> ; Ville Syrjälä 
> ;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> Thankf for revisiting this thread. The use of max_cdclk is currently in 2 
> places
> in DSC code 1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq)
> {
> if (pipe_config->dsc.slice_count > 1) {
> pipe_config->dsc.dsc_split = true; 2. if (bigjoiner) {
> u32 max_bpp_bigjoiner =
> i915->max_cdclk_freq * 48 /
> intel_dp_mode_to_fec_clock(mode_clock);
> 
> DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> max_bpp_bigjoiner);
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
> 
> In both these places, using max_cdclk can cause problems, like for
> compressed bpp it can give a higher bpp based on max_cdclk and we might
> actually end up chosing lower cdclk at what point this will cause underruns.
> 
> So when I was discussing with Ville on this, my first thought was also to use
> the cdclk_state->actual_cdclk but like Ville mentioned later in the review
> comments the challenge there was that actual cdclk does get computed
> much later than dsc_compute_config.
> 
> So I think as suggested in one of the reviews we just to check if DSC is
> enabled then we dont allow lowering the cdclk which would also prevent
> underruns caused by possibly setting up higher bpp based on max cdclk.

Thanks for the review.
This is taken care now, in case if we cannot split, then we already are using 
max_cdclk.
Regarding the bigjoiner_bpp, you may need to make the change if you need it to 
be set to max cdclk.
As we all of us here agree that we do not have computed cd clk at that time.

> 
> @Ville @Jani does this sound like a good approach. Then @Vandita we can
> pursue that change.
> 
> Regards
> Manasi
> 
> On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> > Revisiting this thread after update from the bspec.
> >
> > > -Original Message-
> > > From: Nikula, Jani 
> > > Sent: Tuesday, September 14, 2021 8:40 PM
> > > To: Kulkarni, Vandita ; Lisovskiy,
> > > Stanislav 
> > > Cc: Ville Syrjälä ; intel-
> > > g...@lists.freedesktop.org; Navare, Manasi D
> > > 
> > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > VDSC engine for higher moderates
> > >
> > > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > > 
> > > wrote:
> > > >> -Original Message-
> > > >> From: Nikula, Jani 
> > > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > > >> To: Lisovskiy, Stanislav 
> > > >> Cc: Ville Syrjälä ; Kulkarni,
> > > >> Vandita ;
> > > >> intel-gfx@lists.freedesktop.org; Navare, Manasi D
> > > >> 
> > > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > >> VDSC engine for higher moderates
> > > >>
> > > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > >> 
> > > >> wrote:
> > > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> > > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > >>  wrote:
> > > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni,
> > > >> >> > >> Vandita
> > > wrote:
> > > >> >> > >> > > -Original Message-
> > > >> >> > >> > > From: Ville Syrjälä 
> > > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > >> >> > >> > > To: Kulkarni, Vandita 
> > > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > >> >> > >> > > ; Navare, Manasi D
> > > >> >> > >> > > 
> > > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display:
> > &

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

Revisiting this thread after update from the bspec.

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, September 14, 2021 8:40 PM
> To: Kulkarni, Vandita ; Lisovskiy, Stanislav
> 
> Cc: Ville Syrjälä ; intel-
> g...@lists.freedesktop.org; Navare, Manasi D 
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> On Tue, 14 Sep 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Tuesday, September 14, 2021 7:33 PM
> >> To: Lisovskiy, Stanislav 
> >> Cc: Ville Syrjälä ; Kulkarni, Vandita
> >> ; intel-gfx@lists.freedesktop.org;
> >> Navare, Manasi D 
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> >> engine for higher moderates
> >>
> >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> >> 
> >> wrote:
> >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> >>  wrote:
> >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita
> wrote:
> >> >> > >> > > -Original Message-
> >> >> > >> > > From: Ville Syrjälä 
> >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> >> >> > >> > > To: Kulkarni, Vandita 
> >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> >> >> > >> > > ; Navare, Manasi D
> >> >> > >> > > 
> >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> >> >> > >> > > second VDSC engine for higher moderates
> >> >> > >> > >
> >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> >> >> > >> > > Kulkarni
> >> wrote:
> >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable
> >> >> > >> > > > the second VDSC engine when moderate is higher that the
> >> >> > >> > > > current
> >> cdclk.
> >> >> > >> > > >
> >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> >> >> > >> > > > 
> >> >> > >> > > > ---
> >> >> > >> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 12
> >> >> > >> > > > ++--
> >> >> > >> > > >  1 file changed, 10 insertions(+), 2 deletions(-)
> >> >> > >> > > >
> >> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > @@ -70,6 +70,7 @@
> >> >> > >> > > >  #include "intel_tc.h"
> >> >> > >> > > >  #include "intel_vdsc.h"
> >> >> > >> > > >  #include "intel_vrr.h"
> >> >> > >> > > > +#include "intel_cdclk.h"
> >> >> > >> > > >
> >> >> > >> > > >  #define DP_DPRX_ESI_LEN 14
> >> >> > >> > > >
> >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> >> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> >> > >> > > intel_dp *intel_dp,
> >> >> > >> > > > struct
> drm_connector_state
> >> *conn_state,
> >> >> > >> > > > struct link_config_limits
> *limits)  {
> >> >> > >> > > > +struct intel_cdclk_state *cdclk_state;
&g

Re: [Intel-gfx] [PATCH v3] drm/i915/dsi: let HW maintain the HS-TRAIL timing

[Kulkarni, Vandita]

> -Original Message-
> From: Tseng, William 
> Sent: Friday, December 17, 2021 3:39 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Tseng, William ; Ville Syrjala
> ; Jani Nikula ;
> Kulkarni, Vandita ; Lee, Shawn C
> ; Chiou, Cooper 
> Subject: [PATCH v3] drm/i915/dsi: let HW maintain the HS-TRAIL timing
> 
> This change is to avoid over-specification of the TEOT timing parameter,
> which is derived from software in current design.
> 
> Supposed that THS-TRAIL and THS-EXIT have the minimum values, i.e., 60 and
> 100 in ns. If SW is overriding the HW default, the TEOT value becomes 150 ns,
> approximately calculated by the following formula.
> 
>   DIV_ROUND_UP(60/50)*50 + DIV_ROUND_UP(100/50))*50/2, where 50
>   is LP Escape Clock time in ns.
> 
> The TEOT value 150 ns is larger than the maximum value, around 136 ns if UI
> is 1.8ns, (105 ns + 12*UI, defined by MIPI DPHY specification).
> 
> However, the TEOT value will meet the specification if THS-TRAIL is set to the
> HW default, instead of software overriding.
> 
> The timing change is made for both data lane and clock lane.
> 

Looks like when we try to convert to esc clocks needed, the value gets rounded 
( due to register limitation) and ends up being higher than expected.
Leading to TEOT higher than needed, though we are in limits for individual 
values.
Right now, in such cases I do not see any option from spec to calculate in a 
different way like it provided in case of clk_prepare.
This patch is needed until we have proper way to update the trail_cnt in the 
register.
Until then lets not override the HW defaults.

Acked-by: Vandita Kulkarni 

> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Cc: Cooper Chiou 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 19 +++
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 168c84a74d30..992e357e3f44 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1863,14 +1863,13 @@ static void icl_dphy_param_init(struct intel_dsi
> *intel_dsi)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
>   u32 tlpx_ns;
> - u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
> - u32 ths_prepare_ns, tclk_trail_ns;
> + u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt;
> + u32 ths_prepare_ns;
>   u32 hs_zero_cnt;
>   u32 tclk_pre_cnt, tclk_post_cnt;
> 
>   tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
> 
> - tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
>   ths_prepare_ns = max(mipi_config->ths_prepare,
>mipi_config->tclk_prepare);
> 
> @@ -1897,14 +1896,6 @@ static void icl_dphy_param_init(struct intel_dsi
> *intel_dsi)
>   clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
>   }
> 
> - /* trail cnt in escape clocks*/
> - trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
> - if (trail_cnt > ICL_TRAIL_CNT_MAX) {
> - drm_dbg_kms(&dev_priv->drm, "trail_cnt out of range
> (%d)\n",
> - trail_cnt);
> - trail_cnt = ICL_TRAIL_CNT_MAX;
> - }
> -
>   /* tclk pre count in escape clocks */
>   tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
>   if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) { @@ -1948,17 +1939,13
> @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
>  CLK_PRE_OVERRIDE |
>  CLK_PRE(tclk_pre_cnt) |
>  CLK_POST_OVERRIDE |
> -CLK_POST(tclk_post_cnt) |
> -CLK_TRAIL_OVERRIDE |
> -CLK_TRAIL(trail_cnt));
> +CLK_POST(tclk_post_cnt));
> 
>   /* data lanes dphy timings */
>   intel_dsi->dphy_data_lane_reg = (HS_PREPARE_OVERRIDE |
>HS_PREPARE(prepare_cnt) |
>HS_ZERO_OVERRIDE |
>HS_ZERO(hs_zero_cnt) |
> -  HS_TRAIL_OVERRIDE |
> -  HS_TRAIL(trail_cnt) |
>HS_EXIT_OVERRIDE |
>HS_EXIT(exit_zero_cnt));
> 
> --
> 2.17.1

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Tuesday, November 2, 2021 5:13 PM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling 
> the
> phy
> 
> > -Original Message-
> > From: Nikula, Jani 
> > Sent: Tuesday, November 2, 2021 3:13 PM
> > To: Kulkarni, Vandita ; intel-
> > g...@lists.freedesktop.org
> > Cc: Deak, Imre ; Roper, Matthew D
> > ; ville.syrj...@linux.intel.com
> > Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the
> > phy
> >
> > On Tue, 02 Nov 2021, "Kulkarni, Vandita" 
> > wrote:
> > >> -Original Message-
> > >> From: Nikula, Jani 
> > >> Sent: Monday, November 1, 2021 5:37 PM
> > >> To: Kulkarni, Vandita ; intel-
> > >> g...@lists.freedesktop.org
> > >> Cc: Deak, Imre ; Roper, Matthew D
> > >> ; ville.syrj...@linux.intel.com
> > >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> > >> the phy
> > >>
> > >> On Thu, 28 Oct 2021, "Kulkarni, Vandita"
> > >> 
> > >> wrote:
> > >> >> -Original Message-
> > >> >> From: Nikula, Jani 
> > >> >> Sent: Thursday, October 28, 2021 8:06 PM
> > >> >> To: Kulkarni, Vandita ; intel-
> > >> >> g...@lists.freedesktop.org
> > >> >> Cc: Deak, Imre ; Roper, Matthew D
> > >> >> ; ville.syrj...@linux.intel.com
> > >> >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> > >> >> the phy
> > >> >>
> > >> >> On Thu, 28 Oct 2021, "Kulkarni, Vandita"
> > >> >> 
> > >> >> wrote:
> > >> >> >> -Original Message-
> > >> >> >> From: Nikula, Jani 
> > >> >> >> Sent: Thursday, October 28, 2021 5:13 PM
> > >> >> >> To: Kulkarni, Vandita ; intel-
> > >> >> >> g...@lists.freedesktop.org
> > >> >> >> Cc: Deak, Imre ; Roper, Matthew D
> > >> >> >> ; ville.syrj...@linux.intel.com;
> > >> >> >> Kulkarni, Vandita 
> > >> >> >> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before
> > >> >> >> enabling the phy
> > >> >> >>
> > >> >> >> On Tue, 19 Oct 2021, Vandita Kulkarni
> > >> >> >> 
> > >> >> wrote:
> > >> >> >> > For the PHY enable/disable signalling to propagate between
> > >> >> >> > Dispaly and PHY, DDI clocks need to be running when
> > >> >> >> > enabling the
> > >> PHY.
> > >> >> >> >
> > >> >> >> > Bspec: 49188 says gate the clocks after enabling the
> > >> >> >> >DDI Buffer.
> > >> >> >> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi:
> > >> >> >> > Gate the
> > >> >> ddi
> > >> >> >> >clocks after pll mapping") which gates the clocks much 
> > >> >> >> > before,
> > >> >> >> >as per the older spec. This commit nullifies its
> > >> >> >> > effect and
> > makes
> > >> >> >> >sure that the clocks are not gated while we enable the DDI
> > >> >> >> >buffer.
> > >> >> >> > v2: Bspec ref, add a comment wrt earlier clock gating
> > >> >> >> > sequence
> > >> >> >> > (Jani)
> > >> >> >> >
> > >> >> >> > Signed-off-by: Vandita Kulkarni
> > >> >> >> > 
> > >> >> >> > ---
> > >> >> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> > >> >> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > >> >> >> >
> > >> >> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > >> >> >> > index 63dd75c6448a..e5ef5c4a32d7 100644
> > >> >> 

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, November 2, 2021 3:13 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; ville.syrj...@linux.intel.com
> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Tue, 02 Nov 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Monday, November 1, 2021 5:37 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Deak, Imre ; Roper, Matthew D
> >> ; ville.syrj...@linux.intel.com
> >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the
> >> phy
> >>
> >> On Thu, 28 Oct 2021, "Kulkarni, Vandita" 
> >> wrote:
> >> >> -Original Message-
> >> >> From: Nikula, Jani 
> >> >> Sent: Thursday, October 28, 2021 8:06 PM
> >> >> To: Kulkarni, Vandita ; intel-
> >> >> g...@lists.freedesktop.org
> >> >> Cc: Deak, Imre ; Roper, Matthew D
> >> >> ; ville.syrj...@linux.intel.com
> >> >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> >> >> the phy
> >> >>
> >> >> On Thu, 28 Oct 2021, "Kulkarni, Vandita"
> >> >> 
> >> >> wrote:
> >> >> >> -Original Message-
> >> >> >> From: Nikula, Jani 
> >> >> >> Sent: Thursday, October 28, 2021 5:13 PM
> >> >> >> To: Kulkarni, Vandita ; intel-
> >> >> >> g...@lists.freedesktop.org
> >> >> >> Cc: Deak, Imre ; Roper, Matthew D
> >> >> >> ; ville.syrj...@linux.intel.com;
> >> >> >> Kulkarni, Vandita 
> >> >> >> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before
> >> >> >> enabling the phy
> >> >> >>
> >> >> >> On Tue, 19 Oct 2021, Vandita Kulkarni
> >> >> >> 
> >> >> wrote:
> >> >> >> > For the PHY enable/disable signalling to propagate between
> >> >> >> > Dispaly and PHY, DDI clocks need to be running when enabling
> >> >> >> > the
> >> PHY.
> >> >> >> >
> >> >> >> > Bspec: 49188 says gate the clocks after enabling the
> >> >> >> >DDI Buffer.
> >> >> >> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi:
> >> >> >> > Gate the
> >> >> ddi
> >> >> >> >clocks after pll mapping") which gates the clocks much 
> >> >> >> > before,
> >> >> >> >as per the older spec. This commit nullifies its effect and
> makes
> >> >> >> >sure that the clocks are not gated while we enable the DDI
> >> >> >> >buffer.
> >> >> >> > v2: Bspec ref, add a comment wrt earlier clock gating
> >> >> >> > sequence
> >> >> >> > (Jani)
> >> >> >> >
> >> >> >> > Signed-off-by: Vandita Kulkarni 
> >> >> >> > ---
> >> >> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >> >> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >> >> >
> >> >> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> >> > index 63dd75c6448a..e5ef5c4a32d7 100644
> >> >> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> >> > @@ -1135,8 +1135,6 @@ static void
> >> >> >> > gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >> >> >> >  const struct intel_crtc_state *crtc_state)
> >> {
> >> >> >> > -  struct drm_i915_private *dev_priv = to_i915(encoder-
> >> >base.dev);
> >> >> >> > -
> >> >> >> >/* step 4a: power up all lanes of the DDI used by DSI */
> >> >> >> >gen11_dsi_power_up_lanes(encoder);
> >> >> >> >
> &g

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Monday, November 1, 2021 5:37 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; ville.syrj...@linux.intel.com
> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Thu, 28 Oct 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Thursday, October 28, 2021 8:06 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Deak, Imre ; Roper, Matthew D
> >> ; ville.syrj...@linux.intel.com
> >> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the
> >> phy
> >>
> >> On Thu, 28 Oct 2021, "Kulkarni, Vandita" 
> >> wrote:
> >> >> -Original Message-
> >> >> From: Nikula, Jani 
> >> >> Sent: Thursday, October 28, 2021 5:13 PM
> >> >> To: Kulkarni, Vandita ; intel-
> >> >> g...@lists.freedesktop.org
> >> >> Cc: Deak, Imre ; Roper, Matthew D
> >> >> ; ville.syrj...@linux.intel.com;
> >> >> Kulkarni, Vandita 
> >> >> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before enabling
> >> >> the phy
> >> >>
> >> >> On Tue, 19 Oct 2021, Vandita Kulkarni 
> >> wrote:
> >> >> > For the PHY enable/disable signalling to propagate between
> >> >> > Dispaly and PHY, DDI clocks need to be running when enabling the
> PHY.
> >> >> >
> >> >> > Bspec: 49188 says gate the clocks after enabling the
> >> >> >DDI Buffer.
> >> >> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi:
> >> >> > Gate the
> >> ddi
> >> >> >clocks after pll mapping") which gates the clocks much before,
> >> >> >as per the older spec. This commit nullifies its effect and 
> >> >> > makes
> >> >> >sure that the clocks are not gated while we enable the DDI
> >> >> >buffer.
> >> >> > v2: Bspec ref, add a comment wrt earlier clock gating sequence
> >> >> > (Jani)
> >> >> >
> >> >> > Signed-off-by: Vandita Kulkarni 
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> > index 63dd75c6448a..e5ef5c4a32d7 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> >> > @@ -1135,8 +1135,6 @@ static void
> >> >> > gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >> >> > const struct intel_crtc_state *crtc_state)
> {
> >> >> > - struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> >> >> > -
> >> >> >   /* step 4a: power up all lanes of the DDI used by DSI */
> >> >> >   gen11_dsi_power_up_lanes(encoder);
> >> >> >
> >> >> > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> >> >> intel_encoder *encoder,
> >> >> >   /* step 4c: configure voltage swing and skew */
> >> >> >   gen11_dsi_voltage_swing_program_seq(encoder);
> >> >> >
> >> >> > + gen11_dsi_ungate_clocks(encoder);
> >> >> > +
> >> >>
> >> >> What about the changes to gen11_dsi_map_pll() in commit
> >> >> 991d9557b0c4
> >> >> ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")? It
> >> >> starts off with clocks gated for gen12+, ungated otherwise.
> >> >
> >> > Now the same spec is updated with the gate step after ddi buffer
> enable.
> >> > And the one before is marked with remove tag.
> >> > That makes all gen12+ align with gen 11.
> >> > You suggested to update the same in the commit message on v1.
> >> > Should I still consider just reverting that commit?
> >>
> >> I'm just royally confused abou

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Tuesday, November 2, 2021 10:11 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> 
> On Mon, Nov 01, 2021 at 09:45:23AM -0700, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Navare, Manasi D 
> > > Sent: Saturday, October 30, 2021 4:43 AM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > 
> > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> > >
> > > On Wed, Oct 27, 2021 at 09:37:10PM -0700, Kulkarni, Vandita wrote:
> > > > > -Original Message-----
> > > > > From: Navare, Manasi D 
> > > > > Sent: Thursday, October 28, 2021 12:57 AM
> > > > > To: Kulkarni, Vandita 
> > > > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > > > 
> > > > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed
> > > > > bpp
> > > > >
> > > > > On Wed, Oct 27, 2021 at 03:23:16PM +0530, Vandita Kulkarni wrote:
> > > > > > DP 1.4 spec limits max compression bpp to uncompressed bpp -1,
> > > > > > which is supported from XELPD onwards.
> > > > > > Instead of uncompressed bpp, max dsc input bpp was being used
> > > > > > to limit the max compression bpp.
> > > > >
> > > > > So the input Pipe BPP which is the uncompressed bpp is decided
> > > > > by the input bpc and when this was initially written, we had
> > > > > designed it to respect the max_req_bpc by the user.
> > > > > So that is what we use to decide the input bpc and hence the
> > > > > pipe_bpp This input pipe_bpp decides the compressed bpp that we
> > > > > calculate based on all the supported output bpps which are
> > > > > supported all the way upto uncompressed_output_bpp - 1.
> > > > >
> > > > > So I dont see the need to change the logic here. Moreover I dont
> > > > > see any change in the dsc_compute_bpp function So I dont
> > > > > understand the purpose of introducing the new max_dsc_pipe_bpp
> > > > > variable here
> > > >
> > > > Thanks for the comments, I had few more opens around this along
> > > > with
> > > this patch.
> > > >
> > > > AFAIU about max_requested_bpc it is to limit the max_bpc
> > > > "drm: Add connector property to limit max bpc"
> > > > And the driver is supposed to program the default bpc as per the
> > > > connector
> > > limitation.
> > > > Which is 12 as per the current driver implementation.
> > > >
> > > > I had few queries around this design:
> > > > So it means that max_dsc_input_bpp would be set to 36 if supported
> > > > by the
> > > sink and the platform.
> > > > And now we make this as our pipe_bpp, 1. Does this mean that we
> > > > are assuming 12bpc as i/p always?
> > > > 2. What happens to those with formats 8bpc, 10 bpc?
> > > >
> > >
> > > Yes so this driver policy was decided based on some feedback that I
> > > had got from the community as well as internal feedback from Ville
> > > that the decision of input_bpc should be based on max_bpc requested
> > > by the user through the connector property and max_bpc supported by
> the platform.
> > > Here we take the min of the two so that we dont violate either of
> > > the max constrains.
> > > This was primarily suggested by Ville since he said that we should
> > > always respect what user has set as the upper limit in the bpc
> > > because this could be for example driven by the fact that OEM's
> > > panel has a limitation or issues with higher bpcs or a display requirement
> for certain use case.
> > > Hence while we want to support as high bpc as supported by the
> > > platform and sink to have better display quality, it should not
> > > exceed the max limit set by the user through the property.
> > >
> > > 8 and 10bpc will be supported but we want to start with supporting
> > > the max we can, going down from there if needed.
> > > So for compression, we chose the maximum input bpc and determine the
> > > compressed bpp for that.
> > >
> > >
> > >

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Saturday, October 30, 2021 4:43 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> 
> On Wed, Oct 27, 2021 at 09:37:10PM -0700, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Navare, Manasi D 
> > > Sent: Thursday, October 28, 2021 12:57 AM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > 
> > > Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> > >
> > > On Wed, Oct 27, 2021 at 03:23:16PM +0530, Vandita Kulkarni wrote:
> > > > DP 1.4 spec limits max compression bpp to uncompressed bpp -1,
> > > > which is supported from XELPD onwards.
> > > > Instead of uncompressed bpp, max dsc input bpp was being used to
> > > > limit the max compression bpp.
> > >
> > > So the input Pipe BPP which is the uncompressed bpp is decided by
> > > the input bpc and when this was initially written, we had designed
> > > it to respect the max_req_bpc by the user.
> > > So that is what we use to decide the input bpc and hence the
> > > pipe_bpp This input pipe_bpp decides the compressed bpp that we
> > > calculate based on all the supported output bpps which are supported
> > > all the way upto uncompressed_output_bpp - 1.
> > >
> > > So I dont see the need to change the logic here. Moreover I dont see
> > > any change in the dsc_compute_bpp function So I dont understand the
> > > purpose of introducing the new max_dsc_pipe_bpp variable here
> >
> > Thanks for the comments, I had few more opens around this along with
> this patch.
> >
> > AFAIU about max_requested_bpc it is to limit the max_bpc
> > "drm: Add connector property to limit max bpc"
> > And the driver is supposed to program the default bpc as per the connector
> limitation.
> > Which is 12 as per the current driver implementation.
> >
> > I had few queries around this design:
> > So it means that max_dsc_input_bpp would be set to 36 if supported by the
> sink and the platform.
> > And now we make this as our pipe_bpp,
> > 1. Does this mean that we are assuming 12bpc as i/p always?
> > 2. What happens to those with formats 8bpc, 10 bpc?
> >
> 
> Yes so this driver policy was decided based on some feedback that I had got
> from the community as well as internal feedback from Ville that the decision
> of input_bpc should be based on max_bpc requested by the user through the
> connector property and max_bpc supported by the platform.
> Here we take the min of the two so that we dont violate either of the max
> constrains.
> This was primarily suggested by Ville since he said that we should always
> respect what user has set as the upper limit in the bpc because this could be
> for example driven by the fact that OEM's panel has a limitation or issues
> with higher bpcs or a display requirement for certain use case.
> Hence while we want to support as high bpc as supported by the platform
> and sink to have better display quality, it should not exceed the max limit 
> set
> by the user through the property.
> 
> 8 and 10bpc will be supported but we want to start with supporting the max
> we can, going down from there if needed.
> So for compression, we chose the maximum input bpc and determine the
> compressed bpp for that.
> 
> 
> > We do not consider the actual pipe_bpp while computing the
> > compression_bpp, We reverse calculate it from the link_rate,  and small
> joiner bpp limits.
> > In cases of forcing dsc, we might have a situation where the link can
> actually support the current bpp, or even more.
> > But we are forcing the dsc enable.
> > In such cases we might end up with a compression bpp which is higher than
> the actual i/p bpp.
> 
> Well the only time we force the dsc_enable is for IGT DSC tests and thats
> okay for compression bpp to be higher since there we are just validation the
> functionality and its not for actual user/use case.

We are having these test cases as part of CI. We hit FIFO underrun in such 
cases and that's  treated as a fail.

> 
> In the actual use case we will only enable DSC when the available max link
> rate/lane count does not support the minimum bpp of 18 (min bpc of 6 * 3)
> So then in that case we say that lets keep the pipe_bpp or input bpp as
> max_supported_input_bpc * 3
> >
> > Now, even if we take a min of  higher compression bpp against
> > max_requested_bpc

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, October 28, 2021 8:06 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; ville.syrj...@linux.intel.com
> Subject: RE: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Thu, 28 Oct 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Thursday, October 28, 2021 5:13 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Deak, Imre ; Roper, Matthew D
> >> ; ville.syrj...@linux.intel.com; Kulkarni,
> >> Vandita 
> >> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the
> >> phy
> >>
> >> On Tue, 19 Oct 2021, Vandita Kulkarni 
> wrote:
> >> > For the PHY enable/disable signalling to propagate between Dispaly
> >> > and PHY, DDI clocks need to be running when enabling the PHY.
> >> >
> >> > Bspec: 49188 says gate the clocks after enabling the
> >> >DDI Buffer.
> >> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the
> ddi
> >> >clocks after pll mapping") which gates the clocks much before,
> >> >as per the older spec. This commit nullifies its effect and makes
> >> >sure that the clocks are not gated while we enable the DDI
> >> >buffer.
> >> > v2: Bspec ref, add a comment wrt earlier clock gating sequence
> >> > (Jani)
> >> >
> >> > Signed-off-by: Vandita Kulkarni 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > index 63dd75c6448a..e5ef5c4a32d7 100644
> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > @@ -1135,8 +1135,6 @@ static void
> >> >  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >> >const struct intel_crtc_state 
> >> > *crtc_state)  {
> >> > -struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >> > -
> >> >  /* step 4a: power up all lanes of the DDI used by DSI */
> >> >  gen11_dsi_power_up_lanes(encoder);
> >> >
> >> > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> >> intel_encoder *encoder,
> >> >  /* step 4c: configure voltage swing and skew */
> >> >  gen11_dsi_voltage_swing_program_seq(encoder);
> >> >
> >> > +gen11_dsi_ungate_clocks(encoder);
> >> > +
> >>
> >> What about the changes to gen11_dsi_map_pll() in commit 991d9557b0c4
> >> ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")? It
> >> starts off with clocks gated for gen12+, ungated otherwise.
> >
> > Now the same spec is updated with the gate step after ddi buffer enable.
> > And the one before is marked with remove tag.
> > That makes all gen12+ align with gen 11.
> > You suggested to update the same in the commit message on v1.
> > Should I still consider just reverting that commit?
> 
> I'm just royally confused about the sequence myself, so I'm asking you. ;)
> 
> It doesn't help that the code has step references to gen 11 mode set that are
> completely different from the steps in gen 12 sequence.

Right, they have lot of different steps coming in.
As per gen11 sequence, we were gating pll after enabling ddi buffer.

Initially when there was only gen12 in the bspec, it stated to gate the pll 
after mapping.
Hence we had that commit  991d9557b0c4.
Then Gen12's mipi dsi sequence was carried fwd for all later platforms as well.
 with the modification saying that
Do not gate the pll until we enable the ddi buffer. 
And this applies to gen 12 as well because they have marked the earlier 
mentioned step of gating pll
after pll mapping as removed on all gen12 and later platforms.

This patch now is keeping the older step as is, but making sure that clocks are 
ungated while enabling ddi buffer.

Thanks
Vandita
> 
> BR,
> Jani.
> 
> 
> 
> >
> > Thanks,
> > Vandita
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >  /* enable DDI buffer */
> >> >  gen11_dsi_enable_ddi_buffer(encoder);
> >> >
> >> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
> >> intel_encoder *encoder,
> >> >  /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> >> >  gen11_dsi_configure_transcoder(encoder, crtc_state);
> >> >
> >> > -/* Step 4l: Gate DDI clocks */
> >> > -if (DISPLAY_VER(dev_priv) == 11)
> >> > -gen11_dsi_gate_clocks(encoder);
> >> > +gen11_dsi_gate_clocks(encoder);
> >> >  }
> >> >
> >> >  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [V2 3/4] drm/i915/dsi/xelpd: Disable DC states in Video mode

[Kulkarni, Vandita]

> -Original Message-
> From: Deak, Imre 
> Sent: Saturday, October 23, 2021 1:53 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Roper, Matthew D ;
> ville.syrj...@linux.intel.com
> Subject: Re: [V2 3/4] drm/i915/dsi/xelpd: Disable DC states in Video mode
> 
> On Tue, Oct 19, 2021 at 08:44:34PM +0530, Vandita Kulkarni wrote:
> > MIPI DSI transcoder cannot be in video mode to support any of the
> > display C states.
> >
> > Bspec: 49195 (For DC*co DSI transcoders cannot be in video mode)
> > Bspec: 49193 (Hardware does not support DC5 or DC6 with MIPI DSI
> > enabled)
> > Bspec: 49188 (desc of DSI_DCSTATE_CTL talks about cmd mode PM control
> 
> So none of the DC states (except DC6v which the driver doesn't support) are
> supported in DSI video mode and DC3co is supported in command mode.
> The selection between video vs. command mode happens using a VBT flag
> and I can't see anything that would prevent using command mode on XELPD.
> If the support for it is missing, should it be disabled explicitly or at 
> least a
> notice printed that DC states are not yet supported?

Since we haven't enabled and tried dsi cmd mode on xelpd and in DC3co DMC
Would monitor the idleness of the transcoder, until that is enabled, we can 
disable
Cmd mode for now.
Will send out a patch to disable cmd mode on xelpd, as it would by default 
depend on
Vbt like you have mentioned above.

Thanks,
Vandita
 
> 
> > v2: Align to the power domain ordering (Jani)
> > Add bspec references (Imre)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index d88da0d0f05a..b989ddd3d023 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -3106,6 +3106,7 @@ intel_display_power_put_mask_in_set(struct
> drm_i915_private *i915,
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > BIT_ULL(POWER_DOMAIN_AUX_B) |   \
> > +   BIT_ULL(POWER_DOMAIN_PORT_DSI) |\
> > BIT_ULL(POWER_DOMAIN_INIT))
> >
> >  #define XELPD_AUX_IO_D_XELPD_POWER_DOMAINS
>   BIT_ULL(POWER_DOMAIN_AUX_D_XELPD)
> > --
> > 2.32.0
> >

Re: [Intel-gfx] [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, October 28, 2021 5:13 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; ville.syrj...@linux.intel.com; Kulkarni,
> Vandita 
> Subject: Re: [V2 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Tue, 19 Oct 2021, Vandita Kulkarni  wrote:
> > For the PHY enable/disable signalling to propagate between Dispaly and
> > PHY, DDI clocks need to be running when enabling the PHY.
> >
> > Bspec: 49188 says gate the clocks after enabling the
> >DDI Buffer.
> >We also have a commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi
> >clocks after pll mapping") which gates the clocks much before,
> >as per the older spec. This commit nullifies its effect and makes
> >sure that the clocks are not gated while we enable the DDI
> >buffer.
> > v2: Bspec ref, add a comment wrt earlier clock gating sequence (Jani)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 63dd75c6448a..e5ef5c4a32d7 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1135,8 +1135,6 @@ static void
> >  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >   const struct intel_crtc_state *crtc_state)  {
> > -   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -
> > /* step 4a: power up all lanes of the DDI used by DSI */
> > gen11_dsi_power_up_lanes(encoder);
> >
> > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> intel_encoder *encoder,
> > /* step 4c: configure voltage swing and skew */
> > gen11_dsi_voltage_swing_program_seq(encoder);
> >
> > +   gen11_dsi_ungate_clocks(encoder);
> > +
> 
> What about the changes to gen11_dsi_map_pll() in commit 991d9557b0c4
> ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")? It starts off 
> with
> clocks gated for gen12+, ungated otherwise.

Now the same spec is updated with the gate step after ddi buffer enable.
And the one before is marked with remove tag.
That makes all gen12+ align with gen 11.
You suggested to update the same in the commit message on v1.
Should I still consider just reverting that commit?

Thanks,
Vandita

> 
> BR,
> Jani.
> 
> 
> > /* enable DDI buffer */
> > gen11_dsi_enable_ddi_buffer(encoder);
> >
> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
> intel_encoder *encoder,
> > /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> > gen11_dsi_configure_transcoder(encoder, crtc_state);
> >
> > -   /* Step 4l: Gate DDI clocks */
> > -   if (DISPLAY_VER(dev_priv) == 11)
> > -   gen11_dsi_gate_clocks(encoder);
> > +   gen11_dsi_gate_clocks(encoder);
> >  }
> >
> >  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Thursday, October 28, 2021 12:57 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> 
> On Wed, Oct 27, 2021 at 03:23:16PM +0530, Vandita Kulkarni wrote:
> > DP 1.4 spec limits max compression bpp to uncompressed bpp -1, which
> > is supported from XELPD onwards.
> > Instead of uncompressed bpp, max dsc input bpp was being used to limit
> > the max compression bpp.
> 
> So the input Pipe BPP which is the uncompressed bpp is decided by the input
> bpc and when this was initially written, we had designed it to respect the
> max_req_bpc by the user.
> So that is what we use to decide the input bpc and hence the pipe_bpp This
> input pipe_bpp decides the compressed bpp that we calculate based on all
> the supported output bpps which are supported all the way upto
> uncompressed_output_bpp - 1.
> 
> So I dont see the need to change the logic here. Moreover I dont see any
> change in the dsc_compute_bpp function So I dont understand the purpose
> of introducing the new max_dsc_pipe_bpp variable here

Thanks for the comments, I had few more opens around this along with this patch.

AFAIU about max_requested_bpc it is to limit the max_bpc
"drm: Add connector property to limit max bpc"
And the driver is supposed to program the default bpc as per the connector 
limitation.
Which is 12 as per the current driver implementation.

I had few queries around this design:
So it means that max_dsc_input_bpp would be set to 36 if supported by the sink 
and the platform.
And now we make this as our pipe_bpp,
1. Does this mean that we are assuming 12bpc as i/p always?
2. What happens to those with formats 8bpc, 10 bpc?

We do not consider the actual pipe_bpp while computing the compression_bpp, 
We reverse calculate it from the link_rate,  and small joiner bpp limits.
In cases of forcing dsc, we might have a situation where the link can actually 
support the current bpp, or even more.
But we are forcing the dsc enable.
In such cases we might end up with a compression bpp which is higher than the 
actual i/p bpp.

Now, even if we take a min of  higher compression bpp against max_requested_bpc 
*3 -1, we still have
Compression bpp > actual pipe_bpp 

As per the spec when they say uncompressed bpp, they actually mean 3 * bpc
If we go ahead with this approach of using max_requested_bpc , which is 12 
always we cannot
adhere to the spec.

Thanks,
Vandita

> Manasi
> 
> >
> > Fixes: 831d5aa96c97 ("drm/i915/xelpd: Support DP1.4 compression BPPs")
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 9d8132dd4cc5..1f7e666ae490 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1322,7 +1322,7 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &pipe_config->hw.adjusted_mode;
> > -   int pipe_bpp;
> > +   int pipe_bpp, max_dsc_pipe_bpp;
> > int ret;
> >
> > pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) && @@ -
> 1331,7
> > +1331,8 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> > if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> > return -EINVAL;
> >
> > -   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state-
> >max_requested_bpc);
> > +   pipe_bpp = pipe_config->pipe_bpp;
> > +   max_dsc_pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> > +conn_state->max_requested_bpc);
> >
> > /* Min Input BPC for ICL+ is 8 */
> > if (pipe_bpp < 8 * 3) {
> > @@ -1345,7 +1346,7 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >  * Optimize this later for the minimum possible link rate/lane count
> >  * with DSC enabled for the requested mode.
> >  */
> > -   pipe_config->pipe_bpp = pipe_bpp;
> > +   pipe_config->pipe_bpp = max_dsc_pipe_bpp;
> > pipe_config->port_clock = limits->max_rate;
> > pipe_config->lane_count = limits->max_lane_count;
> >
> > --
> > 2.32.0
> >

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, October 19, 2021 5:16 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> 
> Subject: RE: [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Tue, 19 Oct 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Tuesday, October 19, 2021 3:48 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Deak, Imre ; Roper, Matthew D
> >> ; Kulkarni, Vandita
> >> 
> >> Subject: Re: [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling
> >> the phy
> >>
> >> On Mon, 18 Oct 2021, Vandita Kulkarni 
> wrote:
> >> > For the PHY enable/disable signalling to propagate between Dispaly
> >> > and PHY, DDI clocks need to be running when enabling the PHY.
> >> >
> >>
> >> A bspec reference would be useful:
> >>
> >> Bspec: NNN
> >>
> >> > Signed-off-by: Vandita Kulkarni 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > index 8c166f92f8bd..77cd01ecfa80 100644
> >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >> > @@ -1135,8 +1135,6 @@ static void
> >> >  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >> >const struct intel_crtc_state 
> >> > *crtc_state)  {
> >> > -struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >> > -
> >> >  /* step 4a: power up all lanes of the DDI used by DSI */
> >> >  gen11_dsi_power_up_lanes(encoder);
> >> >
> >> > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> >> intel_encoder *encoder,
> >> >  /* step 4c: configure voltage swing and skew */
> >> >  gen11_dsi_voltage_swing_program_seq(encoder);
> >> >
> >> > +gen11_dsi_ungate_clocks(encoder);
> >> > +
> >> >  /* enable DDI buffer */
> >> >  gen11_dsi_enable_ddi_buffer(encoder);
> >> >
> >> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
> >> intel_encoder *encoder,
> >> >  /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> >> >  gen11_dsi_configure_transcoder(encoder, crtc_state);
> >> >
> >> > -/* Step 4l: Gate DDI clocks */
> >> > -if (DISPLAY_VER(dev_priv) == 11)
> >> > -gen11_dsi_gate_clocks(encoder);
> >> > +gen11_dsi_gate_clocks(encoder);
> >>
> >> So how does this relate to
> >> 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll
> >> mapping")
> >
> > As per the latest bspec, this change doesn't seem to be valid anymore.
> > It is marked with removed tag.
> > When TGL got added this change came in.
> >
> > But now with ADL the whole thing is marked as removed.
> > So, Do you suggest that I submit a revert for this change ?
> 
> No, just an explanation and maybe that commit reference in the commit
> message.

Okay, will do that.

Thanks,
Vandita 
> 
> BR,
> Jani.
> 
> >
> > Thanks,
> > Vandita
> >>
> >> >  }
> >> >
> >> >  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Tuesday, October 19, 2021 5:03 PM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> 
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/dsi: Ungate clock before
> enabling the phy
> 
> > -Original Message-
> > From: Nikula, Jani 
> > Sent: Tuesday, October 19, 2021 3:48 PM
> > To: Kulkarni, Vandita ; intel-
> > g...@lists.freedesktop.org
> > Cc: Deak, Imre ; Roper, Matthew D
> > ; Kulkarni, Vandita
> > 
> > Subject: Re: [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling
> > the phy
> >
> > On Mon, 18 Oct 2021, Vandita Kulkarni 
> wrote:
> > > For the PHY enable/disable signalling to propagate between Dispaly
> > > and PHY, DDI clocks need to be running when enabling the PHY.
> > >
> >
> > A bspec reference would be useful:
> >
> > Bspec: NNN

Bspec: 49187

> >
> > > Signed-off-by: Vandita Kulkarni 
> > > ---
> > >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> > >  1 file changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > index 8c166f92f8bd..77cd01ecfa80 100644
> > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > @@ -1135,8 +1135,6 @@ static void
> > >  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> > > const struct intel_crtc_state *crtc_state)  {
> > > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > -
> > >   /* step 4a: power up all lanes of the DDI used by DSI */
> > >   gen11_dsi_power_up_lanes(encoder);
> > >
> > > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> > intel_encoder *encoder,
> > >   /* step 4c: configure voltage swing and skew */
> > >   gen11_dsi_voltage_swing_program_seq(encoder);
> > >
> > > + gen11_dsi_ungate_clocks(encoder);
> > > +
> > >   /* enable DDI buffer */
> > >   gen11_dsi_enable_ddi_buffer(encoder);
> > >
> > > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
> > intel_encoder *encoder,
> > >   /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> > >   gen11_dsi_configure_transcoder(encoder, crtc_state);
> > >
> > > - /* Step 4l: Gate DDI clocks */
> > > - if (DISPLAY_VER(dev_priv) == 11)
> > > - gen11_dsi_gate_clocks(encoder);
> > > + gen11_dsi_gate_clocks(encoder);
> >
> > So how does this relate to
> > 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll
> > mapping")
> 
> As per the latest bspec, this change doesn't seem to be valid anymore.
> It is marked with removed tag.
> When TGL got added this change came in.
> 
> But now with ADL the whole thing is marked as removed.

And the gating is now added after enabling DDI Buffer 

> So, Do you suggest that I submit a revert for this change ?
> 
> Thanks,
> Vandita
> >
> > >  }
> > >
> > >  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/4] drm/i915/dsi/xelpd: Add DSI transcoder support

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, October 19, 2021 3:44 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; Kulkarni, Vandita
> 
> Subject: Re: [PATCH 2/4] drm/i915/dsi/xelpd: Add DSI transcoder support
> 
> On Mon, 18 Oct 2021, Vandita Kulkarni  wrote:
> > Update ADL_P device info to support DSI0, DSI1
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 31 -
> --
> >  1 file changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index 169837de395d..a2dd5a38fdf5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -932,8 +932,6 @@ static const struct intel_device_info adl_s_info =
> > {  #define XE_LPD_FEATURES \
> > .abox_mask = GENMASK(1, 0),
>   \
> > .color = { .degamma_lut_size = 0, .gamma_lut_size = 0 },
>   \
> > -   .cpu_transcoder_mask = BIT(TRANSCODER_A) |
> BIT(TRANSCODER_B) |   \
> > -   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
>   \
> > .dbuf.size = 4096,
>   \
> > .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) |
>   \
> > BIT(DBUF_S4),
>   \
> > @@ -950,23 +948,49 @@ static const struct intel_device_info adl_s_info = {
> > .display.has_psr = 1,
>   \
> > .display.ver = 13,
>   \
> > .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
>   \
> > +   XE_LPD_CURSOR_OFFSETS
> > +
> > +#define ADLP_TRANSCODERS \
> > +   .cpu_transcoder_mask = BIT(TRANSCODER_A) |
> BIT(TRANSCODER_B) |   \
> > +   BIT(TRANSCODER_C) | BIT(TRANSCODER_D) |
>   \
> > +   BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1),
>   \
> > .pipe_offsets = {
>   \
> > [TRANSCODER_A] = PIPE_A_OFFSET,
>   \
> > [TRANSCODER_B] = PIPE_B_OFFSET,
>   \
> > [TRANSCODER_C] = PIPE_C_OFFSET,
>   \
> > [TRANSCODER_D] = PIPE_D_OFFSET,
>   \
> > +   [TRANSCODER_DSI_0] = PIPE_DSI0_OFFSET,
>   \
> > +   [TRANSCODER_DSI_1] = PIPE_DSI1_OFFSET,
>   \
> > },
>   \
> > .trans_offsets = {
>   \
> > [TRANSCODER_A] = TRANSCODER_A_OFFSET,
>   \
> > [TRANSCODER_B] = TRANSCODER_B_OFFSET,
>   \
> > [TRANSCODER_C] = TRANSCODER_C_OFFSET,
>   \
> > [TRANSCODER_D] = TRANSCODER_D_OFFSET,
>   \
> > +   [TRANSCODER_DSI_0] = TRANSCODER_DSI0_OFFSET,
>   \
> > +   [TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET,
>   \
> 
> I think you could just add these changes to XE_LPD_FEATURES, and have
> separate .cpu_transcoder_mask initialization for ADLP and DG2.

Okay got it. So its ok to have the pipe_offsets  or transcoder offsets added 
unless we are not defining it in the .cpu_transcoder_mask
Will make this change.

Thanks,
Vandita
> 
> Compare GEN12_FEATURES.
> 
> BR,
> Jani.
> 
> > +   }
>   \
> > +
> > +#define DG2_TRANSCODERS \
> > +   .cpu_transcoder_mask = BIT(TRANSCODER_A) |
> BIT(TRANSCODER_B) |   \
> > +   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
>   \
> > +   .pipe_offsets = {
>   \
> > +   [TRANSCODER_A] = PIPE_A_OFFSET,
>   \
> > +   [TRANSCODER_B] = PIPE_B_OFFSET,
>   \
> > +   [TRANSCODER_C] = PIPE_C_OFFSET,
>   \
> > +   [TRANSCODER_D] = PIPE_D_OFFSET,
>   \
> > },
>   \
> > -   XE_LPD_CURSOR_OFFSETS
> > +   .trans_offsets = {
>   \
> > +   [TRANSCODER_A] = TRANSCODER_A_OFFSET,
>   \
> > +   [TRANSCODER_B] = TRANSCODER_B_OFFSET,
>   \
> > +   [TRANSCODER_C] = TRANSCODER_C_OFFSET,
>   \
> > +   [TRANSCODER_D] = TRANSCODER_D_OFFSET,
>   \
> > +   }
>   \
> >
> >  static const struct intel_device_info adl_p_info = {
> > GEN12_FEATURES,
> > XE_LPD_FEATURES,
> > +   ADLP_TRANSCODERS,
> > PLATFORM(INTEL_ALDERLAKE_P),
> > .require_force_probe = 1,
> > .display.has_cdclk_crawl = 1,
> > @@ -1029,6 +1053,7 @@ static const struct intel_device_info dg2_info = {
> > XE_HP_FEATURES,
> > XE_HPM_FEATURES,
> > XE_LPD_FEATURES,
> > +   DG2_TRANSCODERS,
> > DGFX_FEATURES,
> > .graphics_rel = 55,
> > .media_rel = 55,
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling the phy

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, October 19, 2021 3:48 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Deak, Imre ; Roper, Matthew D
> ; Kulkarni, Vandita
> 
> Subject: Re: [PATCH 4/4] drm/i915/dsi: Ungate clock before enabling the phy
> 
> On Mon, 18 Oct 2021, Vandita Kulkarni  wrote:
> > For the PHY enable/disable signalling to propagate between Dispaly and
> > PHY, DDI clocks need to be running when enabling the PHY.
> >
> 
> A bspec reference would be useful:
> 
> Bspec: NNN
> 
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 8c166f92f8bd..77cd01ecfa80 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1135,8 +1135,6 @@ static void
> >  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> >   const struct intel_crtc_state *crtc_state)
> >  {
> > -   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -
> > /* step 4a: power up all lanes of the DDI used by DSI */
> > gen11_dsi_power_up_lanes(encoder);
> >
> > @@ -1146,6 +1144,8 @@ gen11_dsi_enable_port_and_phy(struct
> intel_encoder *encoder,
> > /* step 4c: configure voltage swing and skew */
> > gen11_dsi_voltage_swing_program_seq(encoder);
> >
> > +   gen11_dsi_ungate_clocks(encoder);
> > +
> > /* enable DDI buffer */
> > gen11_dsi_enable_ddi_buffer(encoder);
> >
> > @@ -1161,9 +1161,7 @@ gen11_dsi_enable_port_and_phy(struct
> intel_encoder *encoder,
> > /* Step (4h, 4i, 4j, 4k): Configure transcoder */
> > gen11_dsi_configure_transcoder(encoder, crtc_state);
> >
> > -   /* Step 4l: Gate DDI clocks */
> > -   if (DISPLAY_VER(dev_priv) == 11)
> > -   gen11_dsi_gate_clocks(encoder);
> > +   gen11_dsi_gate_clocks(encoder);
> 
> So how does this relate to
> 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")

As per the latest bspec, this change doesn't seem to be valid anymore.
It is marked with removed tag.
When TGL got added this change came in.

But now with ADL the whole thing is marked as removed.
So, Do you suggest that I submit a revert for this change ?

Thanks,
Vandita
> 
> >  }
> >
> >  static void gen11_dsi_powerup_panel(struct intel_encoder *encoder)
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsi/xelpd: Fix the bit mask for wakeup GB

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, October 19, 2021 4:21 PM
> To: Nikula, Jani 
> Cc: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org; Deak, Imre ; Roper,
> Matthew D 
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsi/xelpd: Fix the bit mask for
> wakeup GB
> 
> On Tue, Oct 19, 2021 at 01:41:50PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 19, 2021 at 01:28:10PM +0300, Jani Nikula wrote:
> > > On Tue, 19 Oct 2021, Ville Syrjälä  wrote:
> > > > On Tue, Oct 19, 2021 at 01:05:20PM +0300, Jani Nikula wrote:
> > > >> On Mon, 18 Oct 2021, Vandita Kulkarni 
> wrote:
> > > >>
> > > >> Commit message goes here.
> > > >>
> > > >> > Fixes: f87c46c43175 ("drm/i915/dsi/xelpd: Add WA to program LP
> > > >> > to HS wakeup guardband")
> > > >> > Signed-off-by: Vandita Kulkarni 
> > > >> > ---
> > > >> >  drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> > > >> >  drivers/gpu/drm/i915/i915_reg.h| 3 ++-
> > > >> >  2 files changed, 3 insertions(+), 2 deletions(-)
> > > >> >
> > > >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > >> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > >> > index 9ee62707ec72..8c166f92f8bd 100644
> > > >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > >> > @@ -1271,7 +1271,7 @@ static void
> adlp_set_lp_hs_wakeup_gb(struct intel_encoder *encoder)
> > > >> >  if (DISPLAY_VER(i915) == 13) {
> > > >> >  for_each_dsi_port(port, intel_dsi->ports)
> > > >> >  intel_de_rmw(i915,
> TGL_DSI_CHKN_REG(port),
> > > >> > - TGL_DSI_CHKN_LSHS_GB, 0x4);
> > > >> > + TGL_DSI_CHKN_LSHS_GB_MASK,
> > > >> > +TGL_DSI_CHKN_LSHS_GB_MASK);
> > > >>
> > > >> I think you mean the value should be TGL_DSI_CHKN_LSHS_GB.
Yes, my bad.
> > > >
> > > > IMO the value should never be named that. It should be
> > > > TGL_DSI_CHKN_LSHS_GB_.
> > >
> > > Alternatively,
> > >
> > > #define TGL_DSI_CHKN_LSHS_GB(byte_clocks)
>   REG_FIELD_PREP(TGL_DSI_CHKN_LSHS_GB_MASK, (byte_clocks))
> > >
> > > and
> > >
> > > intel_de_rmw(i915, TGL_DSI_CHKN_REG(port),
> > >TGL_DSI_CHKN_LSHS_GB_MASK, TGL_DSI_CHKN_LSHS_GB(4));
> > >
> > > ?
> > >
> > > We're using the value in a specific place that references a w/a, so
> > > the magic 4 isn't too bad.

This seems more appropriate will make this change.
Thanks.
> >
> > Yeah, for parametrized defines I think the "_" is not
> > needed. Probably not even desired. The argument passed in is the
> > "_" essentially.
> 
> Oh and, yes, I think having the magic number in the code is fine for cases 
> like
> this. I'd say I probably even prefer it that way.
> As long as the whole register value isn't a single magic hex constant that I
> have to decode by hand to see what bitfields are getting what values.

Thanks, will use the hardcoding in icl_dsi.
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3)

[Kulkarni, Vandita]

From: Patchwork 
Sent: Tuesday, September 21, 2021 11:05 AM
To: Kulkarni, Vandita 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for drm/i915/display: Fix the dsc check while 
selecting min_cdclk (rev3)

Patch Details
Series:

drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3)

URL:

https://patchwork.freedesktop.org/series/94683/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/index.html

CI Bug Log - changes from CI_DRM_10615_full -> Patchwork_21104_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_21104_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21104_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_21104_full:

IGT changes

Not related to the patch, all these issues seem to be related to sound, @Vudum, 
Lakshminarayana<mailto:lakshminarayana.vu...@intel.com> can you please
Rereport these Fi.CI.IGT: failure for Check SFC fusing on Xe_HP (rev4)
Thanks,
-Vandita

Also these are similar to what was mentioned by Matt earlier, as part of 
results of
Possible regressions

  *   igt@kms_big_fb@x-tiled-16bpp-rotate-180:

 *   shard-apl: NOTRUN -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-apl7/igt@kms_big...@x-tiled-16bpp-rotate-180.html>
 *   shard-kbl: NOTRUN -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl4/igt@kms_big...@x-tiled-16bpp-rotate-180.html>

  *   igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:

 *   shard-tglb: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb5/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html>

  *   igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:

 *   shard-iclb: NOTRUN -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb1/igt@kms_plane_multi...@atomic-pipe-b-tiling-yf.html>

Warnings

  *   igt@i915_module_load@reload:

 *   shard-iclb: 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb8/igt@i915_module_l...@reload.html>
 ([i915#4130]) -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb1/igt@i915_module_l...@reload.html>

Known issues

Here are the changes found in Patchwork_21104_full that come from known issues:

IGT changes
Issues hit

  *   igt@gem_ctx_isolation@preservation-s3@bcs0:

 *   shard-tglb: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@gem_ctx_isolation@preservation...@bcs0.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb7/igt@gem_ctx_isolation@preservation...@bcs0.html>
 ([i915#456])

  *   igt@gem_ctx_isolation@preservation-s3@rcs0:

 *   shard-kbl: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl6/igt@gem_ctx_isolation@preservation...@rcs0.html>
 ([i915#180]) +4 similar issues

  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-iclb: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html>
 -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html>
 ([i915#2842])

  *   igt@gem_exec_fair@basic-none-vip@rcs0:

 *   shard-tglb: NOTRUN -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb3/igt@gem_exec_fair@basic-none-...@rcs0.html>
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace-share@rcs0:

 *   shard-glk: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html>
 -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html>
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace-solo@rcs0:

 *   shard-kbl: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html>
 -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html>
 ([i915#2842])

  *   igt@gem_exec_schedule@semaphore-codependency:

 *   shard-snb: NOTRUN -> 
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-snb2/igt@gem_exec_sched...@semaphore-codepende

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Fix the dsc check while selecting min_cdclk (rev2)

[Kulkarni, Vandita]

From: Patchwork 
Sent: Wednesday, September 15, 2021 5:05 PM
To: Kulkarni, Vandita 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/display: Fix the dsc check while 
selecting min_cdclk (rev2)

Patch Details
Series:

drm/i915/display: Fix the dsc check while selecting min_cdclk (rev2)

URL:

https://patchwork.freedesktop.org/series/94683/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/index.html

CI Bug Log - changes from CI_DRM_10588 -> Patchwork_21054
Summary

FAILURE

Serious unknown changes coming with Patchwork_21054 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21054, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/index.html

Possible new issues

Here are the unknown changes that may have been introduced in Patchwork_21054:

IGT changes
Possible regressions

  *   igt@i915_module_load@reload:

 *   fi-rkl-guc: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-rkl-guc/igt@i915_module_l...@reload.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-rkl-guc/igt@i915_module_l...@reload.html>
 *   fi-icl-y: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-icl-y/igt@i915_module_l...@reload.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-icl-y/igt@i915_module_l...@reload.html>



Not related to the patch. This test seem to fail on the CI randomly with drm-tip

Thanks,

Vandita

Warnings

  *   igt@i915_module_load@reload:

 *   fi-kbl-soraka: 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-kbl-soraka/igt@i915_module_l...@reload.html>
 (i915#4136<https://gitlab.freedesktop.org/drm/intel/issues/4136>) -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-kbl-soraka/igt@i915_module_l...@reload.html>

Known issues

Here are the changes found in Patchwork_21054 that come from known issues:

IGT changes
Issues hit

  *   igt@core_hotunplug@unbind-rebind:

 *   fi-cfl-8700k: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-cfl-8700k/igt@core_hotunp...@unbind-rebind.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-cfl-8700k/igt@core_hotunp...@unbind-rebind.html>
 (i915#4130<https://gitlab.freedesktop.org/drm/intel/issues/4130>)
 *   fi-rkl-11600: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-rkl-11600/igt@core_hotunp...@unbind-rebind.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-rkl-11600/igt@core_hotunp...@unbind-rebind.html>
 (i915#4130<https://gitlab.freedesktop.org/drm/intel/issues/4130>)
 *   fi-kbl-7500u: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html>
 (i915#4130<https://gitlab.freedesktop.org/drm/intel/issues/4130>)

  *   igt@i915_selftest@live@mman:

 *   fi-skl-6700k2: NOTRUN -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-skl-6700k2/igt@i915_selftest@l...@mman.html>
 (i915#3796<https://gitlab.freedesktop.org/drm/intel/issues/3796> / 
i915#4129<https://gitlab.freedesktop.org/drm/intel/issues/4129>)

Possible fixes

  *   igt@i915_module_load@reload:

 *   fi-skl-6700k2: 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-skl-6700k2/igt@i915_module_l...@reload.html>
 (i915#4136<https://gitlab.freedesktop.org/drm/intel/issues/4136>) -> 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-skl-6700k2/igt@i915_module_l...@reload.html>

  *   igt@kms_flip@basic-plain-flip@c-dp1:

 *   fi-cfl-8109u: 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html>
 -> 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html>

  *   igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:

 *   fi-cfl-8109u: 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html>
 (i915#295<https://gitlab.freedesktop.org/drm/intel/issues/295>) -> 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21054/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html>
 +14 similar issues

Warnings

  *   igt@runner@aborted:

 *   fi-rkl-guc: 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10588/fi-rkl-guc/igt@run...

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, September 14, 2021 7:33 PM
> To: Lisovskiy, Stanislav 
> Cc: Ville Syrjälä ; Kulkarni, Vandita
> ; intel-gfx@lists.freedesktop.org; Navare,
> Manasi D 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" 
> wrote:
> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
>  wrote:
> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
> >> > >> > > -----Original Message-
> >> > >> > > From: Ville Syrjälä 
> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> >> > >> > > To: Kulkarni, Vandita 
> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> >> > >> > > ; Navare, Manasi D
> >> > >> > > 
> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> >> > >> > > second VDSC engine for higher moderates
> >> > >> > >
> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni
> wrote:
> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable the
> >> > >> > > > second VDSC engine when moderate is higher that the current
> cdclk.
> >> > >> > > >
> >> > >> > > > Signed-off-by: Vandita Kulkarni
> >> > >> > > > 
> >> > >> > > > ---
> >> > >> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
> >> > >> > > >  1 file changed, 10 insertions(+), 2 deletions(-)
> >> > >> > > >
> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > @@ -70,6 +70,7 @@
> >> > >> > > >  #include "intel_tc.h"
> >> > >> > > >  #include "intel_vdsc.h"
> >> > >> > > >  #include "intel_vrr.h"
> >> > >> > > > +#include "intel_cdclk.h"
> >> > >> > > >
> >> > >> > > >  #define DP_DPRX_ESI_LEN 14
> >> > >> > > >
> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> > >> > > intel_dp *intel_dp,
> >> > >> > > >struct 
> >> > >> > > > drm_connector_state
> *conn_state,
> >> > >> > > >struct 
> >> > >> > > > link_config_limits *limits)  {
> >> > >> > > > +   struct intel_cdclk_state *cdclk_state;
> >> > >> > > > struct intel_digital_port *dig_port =
> dp_to_dig_port(intel_dp);
> >> > >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >> > >> > > >base.base.dev);
> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> >> > >> > > > &pipe_config->hw.adjusted_mode;
> >> > >> > > > +   struct intel_atomic_state *state =
> >> > >> > > > +   
> >> > >> > > > to_intel_atomic_state(pipe_config-
> >> > >> > > >uapi.state);
> >> > >> > > > int pipe_bpp;
> >> > >> > > > int ret;
> >> > >> > > >
> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> >> > >> > > > intel_dp_dsc_compute_config(struct
> 

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, September 14, 2021 12:49 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Navare, Manasi D 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > engine when moderate is higher that the current cdclk.
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 161c33b2c869..55878f65f724 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -70,6 +70,7 @@
> >  #include "intel_tc.h"
> >  #include "intel_vdsc.h"
> >  #include "intel_vrr.h"
> > +#include "intel_cdclk.h"
> >
> >  #define DP_DPRX_ESI_LEN 14
> >
> > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >struct drm_connector_state *conn_state,
> >struct link_config_limits *limits)  {
> > +   struct intel_cdclk_state *cdclk_state;
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &pipe_config->hw.adjusted_mode;
> > +   struct intel_atomic_state *state =
> > +   to_intel_atomic_state(pipe_config-
> >uapi.state);
> > int pipe_bpp;
> > int ret;
> >
> > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > }
> > }
> >
> > +   cdclk_state = intel_atomic_get_cdclk_state(state);
> > +   if (IS_ERR(cdclk_state))
> > +   return PTR_ERR(cdclk_state);
> > +
> > /*
> >  * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > -* is greater than the maximum Cdclock and if slice count is even
> > +* is greater than the current Cdclock and if slice count is even
> >  * then we need to use 2 VDSC instances.
> >  */
> > -   if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > +   if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> 
> So in the end, we didn't have to bump CDCLK up to get rid of that?

The solution that could fix the underruns was either of these:  set max cdclk 
that can drive this or enable the second dsc engine if slice count  > 2  to 
achieve 2ppc.

> 
> Anyways, checked with BSpec 49259, seems to make sense, was no point in
> comparing to max CDCLK, which is not even currently used.
> 
> Reviewed-by: Stanislav Lisovskiy 
> 
> > pipe_config->bigjoiner) {
> > if (pipe_config->dsc.slice_count < 2) {
> > drm_dbg_kms(&dev_priv->drm,
> > --
> > 2.32.0
> >

Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, September 14, 2021 12:59 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Navare, Manasi D 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
> 
> On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > engine when moderate is higher that the current cdclk.
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 161c33b2c869..55878f65f724 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -70,6 +70,7 @@
> >  #include "intel_tc.h"
> >  #include "intel_vdsc.h"
> >  #include "intel_vrr.h"
> > +#include "intel_cdclk.h"
> >
> >  #define DP_DPRX_ESI_LEN 14
> >
> > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >struct drm_connector_state *conn_state,
> >struct link_config_limits *limits)  {
> > +   struct intel_cdclk_state *cdclk_state;
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &pipe_config->hw.adjusted_mode;
> > +   struct intel_atomic_state *state =
> > +   to_intel_atomic_state(pipe_config-
> >uapi.state);
> > int pipe_bpp;
> > int ret;
> >
> > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > }
> > }
> >
> > +   cdclk_state = intel_atomic_get_cdclk_state(state);
> > +   if (IS_ERR(cdclk_state))
> > +   return PTR_ERR(cdclk_state);
> > +
> > /*
> >  * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > -* is greater than the maximum Cdclock and if slice count is even
> > +* is greater than the current Cdclock and if slice count is even
> >  * then we need to use 2 VDSC instances.
> >  */
> > -   if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > +   if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> 
> This is wrong. We compute the cdclk based on the requirements of the
> mode/etc., not the other way around.

Okay , So you suggest that we set the cd clock to max when we have such 
requirement, than enabling the second engine?

> 
> > pipe_config->bigjoiner) {
> > if (pipe_config->dsc.slice_count < 2) {
> > drm_dbg_kms(&dev_priv->drm,
> > --
> > 2.32.0
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [v4 0/5] DSI driver improvement

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Wednesday, September 8, 2021 6:42 PM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Kulkarni, Vandita
> ; Chiou, Cooper ;
> Tseng, William 
> Subject: RE: [v4 0/5] DSI driver improvement
> 
> On Wed, 08 Sep 2021, Jani Nikula  wrote:
> >On Wed, 08 Sep 2021, Lee Shawn C  wrote:
> >> v2: Get data length of brightness value more easily while driver try to
> >> read/write MIPI_DCS_DISPLAY_BRIGHTNESS command.
> >> v3: fix checkpatch warning.
> >
> >The series is v4, what's new here?
> >
> >BR,
> >Jani.
> >
> 
> We don't change anything, just rebase.
> 
> Best regards,
> Shawn

Thanks for the patches and reviews.
Pushed v4 based on results on v3 as there is no change.

Thanks,
Vandita
> 
> >
> >>
> >> Signed-off-by: Lee Shawn C 
> >>
> >> Lee Shawn C (5):
> >>   drm/i915/dsi: wait for header and payload credit available
> >>   drm/i915/dsi: refine send MIPI DCS command sequence
> >>   drm/i915: Get proper min cdclk if vDSC enabled
> >>   drm/i915/dsi: Retrieve max brightness level from VBT
> >>   drm/i915/dsi: Read/write proper brightness value via MIPI DCS command
> >>
> >>  drivers/gpu/drm/i915/display/icl_dsi.c| 50 +--
> >>  drivers/gpu/drm/i915/display/intel_bios.c |  3 ++
> >>  drivers/gpu/drm/i915/display/intel_cdclk.c| 10 
> >>  .../i915/display/intel_dsi_dcs_backlight.c| 33 
> >>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >>  5 files changed, 62 insertions(+), 35 deletions(-)
> >
> >--
> >Jani Nikula, Intel Open Source Graphics Center
> >

Re: [Intel-gfx] [PATCH] drm/i915: Update small joiner ram size

[Kulkarni, Vandita]

Thanks for the review. Changes pushed.

> -Original Message-
> From: Navare, Manasi D 
> Sent: Friday, August 6, 2021 12:13 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Update small joiner ram size
> 
> On Thu, Aug 05, 2021 at 03:49:37PM +0530, Vandita Kulkarni wrote:
> > Xelpd supports larger small joiner ram.
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 75d4ebc66941..d174f0d6e7cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -461,7 +461,9 @@ u32 intel_dp_mode_to_fec_clock(u32 mode_clock)
> > static int  small_joiner_ram_size_bits(struct drm_i915_private *i915)
> > {
> > -   if (DISPLAY_VER(i915) >= 11)
> > +   if (DISPLAY_VER(i915) >= 13)
> > +   return 17280 * 8;
> 
> Verified from the Bspec, looks good to me.
> 
> Reviewed-by: Manasi Navare 
> 
> Manasi
> 
> > +   else if (DISPLAY_VER(i915) >= 11)
> > return 7680 * 8;
> > else
> > return 6144 * 8;
> > --
> > 2.32.0
> >

Re: [Intel-gfx] [v2] drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband

[Kulkarni, Vandita]

Thanks for the review, patches pushed.

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Thursday, August 26, 2021 11:30 AM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [v2] drm/i915/dsi/xelpd: Add WA to program LP to HS
> wakeup guardband
> 
> Thanks for the review. Have fixed in the latest version, will merge once CI is
> green.
> > -Original Message-
> > From: Nikula, Jani 
> > Sent: Wednesday, August 25, 2021 7:38 PM
> > To: Kulkarni, Vandita ; intel-
> > g...@lists.freedesktop.org
> > Cc: Kulkarni, Vandita 
> > Subject: Re: [v2] drm/i915/dsi/xelpd: Add WA to program LP to HS
> > wakeup guardband
> >
> > On Mon, 23 Aug 2021, Vandita Kulkarni 
> wrote:
> > > Wa_16012360555 SW will have to program the "LP to HS Wakeup
> > Guardband"
> > > field to account for the repeaters on the HS Request/Ready PPI
> > > signaling between the Display engine and the DPHY.
> > >
> > > v2: Fix build issue.
> > >
> > > Signed-off-by: Vandita Kulkarni 
> > > ---
> > >  drivers/gpu/drm/i915/display/icl_dsi.c | 25
> > +
> > >  drivers/gpu/drm/i915/i915_reg.h|  8 
> > >  2 files changed, 33 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > index 43ec7fcd3f5d..b075defb88bb 100644
> > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > @@ -1270,6 +1270,28 @@ static void icl_apply_kvmr_pipe_a_wa(struct
> > intel_encoder *encoder,
> > >IGNORE_KVMR_PIPE_A,
> > >enable ? IGNORE_KVMR_PIPE_A : 0);  }
> > > +
> > > +/*
> > > + * Wa_16012360555:ADLP
> >
> > It should be adl-p, i.e. lower case and with a hyphen.
> >
> > > + * SW will have to program the "LP to HS Wakeup Guardband"
> > > + * field (bits 15:12) of register offset 0x6B0C0 (DSI0)
> > > + * and 0x6B8C0 (DSI1) to a value of 4 to account for the repeaters
> > > + * on the HS Request/Ready PPI signaling between
> > > + * the Display engine and the DPHY.
> > > + */
> >
> > I think that's a bit verbose for the comment. In particular the
> > register addresses and bits and values are redundant with the code.
> >
> > > +static void adlp_set_lp_hs_wakeup_gb(struct intel_encoder *encoder)
> {
> > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >
> > i915 variable name is preferred for all new code.
> >
> > > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> > > + enum port port;
> > > +
> > > + if (DISPLAY_VER(dev_priv) == 13) {
> > > + for_each_dsi_port(port, intel_dsi->ports)
> > > + intel_de_rmw(dev_priv, TGL_DSI_CHKN_REG(port),
> > > +  TGL_DSI_CHKN_LSHS_GB, 0x4);
> > > + }
> > > +}
> > > +
> > >  static void gen11_dsi_enable(struct intel_atomic_state *state,
> > >struct intel_encoder *encoder,
> > >const struct intel_crtc_state *crtc_state, @@ -
> > 1283,6 +1305,9
> > > @@ static void gen11_dsi_enable(struct intel_atomic_state *state,
> > >   /* Wa_1409054076:icl,jsl,ehl */
> > >   icl_apply_kvmr_pipe_a_wa(encoder, crtc->pipe, true);
> > >
> > > + /* Wa_16012360555: adlp */
> >
> > No space after : and adl-p.
> >
> > > + adlp_set_lp_hs_wakeup_gb(encoder);
> > > +
> > >   /* step6d: enable dsi transcoder */
> > >   gen11_dsi_enable_transcoder(encoder);
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 72dd3a6d205d..4c90d45343d6
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -11614,6 +11614,14 @@ enum skl_power_gate {
> > >   _ICL_DSI_IO_MODECTL_1)
> > >  #define  COMBO_PHY_MODE_DSI  (1 << 0)
> > >
> > > +/* TGL DSI Chicken register */
> > > +#define _TGL_DSI_CHKN_REG_0  0x6B0C0
> > > +#define _TGL_DSI_CHKN_REG_1  0x6B8C0
> > > +#define TGL_DSI_CHKN_REG(port)   _MMIO_PORT(port,
>   \
> > > + _TGL_DSI_CHKN_REG_0, \
> > > + _TGL_DSI_CHKN_REG_1)
> > > +#define TGL_DSI_CHKN_LSHS_GB (0xF << 12)
> >
> > Please use REG_GENMASK(15, 12)
> >
> > With the issues fixed,
> >
> > Reviewed-by: Jani Nikula 
> >
> >
> > > +
> > >  /* Display Stream Splitter Control */
> > >  #define DSS_CTL1 _MMIO(0x67400)
> > >  #define  SPLITTER_ENABLE (1 << 31)
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [v2] drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband

[Kulkarni, Vandita]

Thanks for the review. Have fixed in the latest version, will merge once CI is 
green.
> -Original Message-
> From: Nikula, Jani 
> Sent: Wednesday, August 25, 2021 7:38 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Kulkarni, Vandita 
> Subject: Re: [v2] drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup
> guardband
> 
> On Mon, 23 Aug 2021, Vandita Kulkarni  wrote:
> > Wa_16012360555 SW will have to program the "LP to HS Wakeup
> Guardband"
> > field to account for the repeaters on the HS Request/Ready PPI
> > signaling between the Display engine and the DPHY.
> >
> > v2: Fix build issue.
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c | 25
> +
> >  drivers/gpu/drm/i915/i915_reg.h|  8 
> >  2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 43ec7fcd3f5d..b075defb88bb 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1270,6 +1270,28 @@ static void icl_apply_kvmr_pipe_a_wa(struct
> intel_encoder *encoder,
> >  IGNORE_KVMR_PIPE_A,
> >  enable ? IGNORE_KVMR_PIPE_A : 0);  }
> > +
> > +/*
> > + * Wa_16012360555:ADLP
> 
> It should be adl-p, i.e. lower case and with a hyphen.
> 
> > + * SW will have to program the "LP to HS Wakeup Guardband"
> > + * field (bits 15:12) of register offset 0x6B0C0 (DSI0)
> > + * and 0x6B8C0 (DSI1) to a value of 4 to account for the repeaters
> > + * on the HS Request/Ready PPI signaling between
> > + * the Display engine and the DPHY.
> > + */
> 
> I think that's a bit verbose for the comment. In particular the register
> addresses and bits and values are redundant with the code.
> 
> > +static void adlp_set_lp_hs_wakeup_gb(struct intel_encoder *encoder) {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> 
> i915 variable name is preferred for all new code.
> 
> > +   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> > +   enum port port;
> > +
> > +   if (DISPLAY_VER(dev_priv) == 13) {
> > +   for_each_dsi_port(port, intel_dsi->ports)
> > +   intel_de_rmw(dev_priv, TGL_DSI_CHKN_REG(port),
> > +TGL_DSI_CHKN_LSHS_GB, 0x4);
> > +   }
> > +}
> > +
> >  static void gen11_dsi_enable(struct intel_atomic_state *state,
> >  struct intel_encoder *encoder,
> >  const struct intel_crtc_state *crtc_state, @@ -
> 1283,6 +1305,9
> > @@ static void gen11_dsi_enable(struct intel_atomic_state *state,
> > /* Wa_1409054076:icl,jsl,ehl */
> > icl_apply_kvmr_pipe_a_wa(encoder, crtc->pipe, true);
> >
> > +   /* Wa_16012360555: adlp */
> 
> No space after : and adl-p.
> 
> > +   adlp_set_lp_hs_wakeup_gb(encoder);
> > +
> > /* step6d: enable dsi transcoder */
> > gen11_dsi_enable_transcoder(encoder);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 72dd3a6d205d..4c90d45343d6
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -11614,6 +11614,14 @@ enum skl_power_gate {
> > _ICL_DSI_IO_MODECTL_1)
> >  #define  COMBO_PHY_MODE_DSI(1 << 0)
> >
> > +/* TGL DSI Chicken register */
> > +#define _TGL_DSI_CHKN_REG_00x6B0C0
> > +#define _TGL_DSI_CHKN_REG_10x6B8C0
> > +#define TGL_DSI_CHKN_REG(port) _MMIO_PORT(port,\
> > +   _TGL_DSI_CHKN_REG_0, \
> > +   _TGL_DSI_CHKN_REG_1)
> > +#define TGL_DSI_CHKN_LSHS_GB   (0xF << 12)
> 
> Please use REG_GENMASK(15, 12)
> 
> With the issues fixed,
> 
> Reviewed-by: Jani Nikula 
> 
> 
> > +
> >  /* Display Stream Splitter Control */
> >  #define DSS_CTL1   _MMIO(0x67400)
> >  #define  SPLITTER_ENABLE   (1 << 31)
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [v4 3/7] drm/i915/dsi: wait for header and payload credit available

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Thursday, August 12, 2021 9:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William ; Lee,
> Shawn C ; Jani Nikula 
> Subject: [v4 3/7] drm/i915/dsi: wait for header and payload credit available
> 
> Driver should wait for free header or payload buffer in FIFO.
> It would be good to wait a while for HW to release credit before give it up to
> write to HW. Without sending initailize command sets completely. It would
> caused MIPI display can't light up properly.
> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 40 --
>  1 file changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 43ec7fcd3f5d..1780830d9909 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -54,20 +54,28 @@ static int payload_credits_available(struct
> drm_i915_private *dev_priv,
>   >> FREE_PLOAD_CREDIT_SHIFT;
>  }
> 
> -static void wait_for_header_credits(struct drm_i915_private *dev_priv,
> - enum transcoder dsi_trans)
> +static bool wait_for_header_credits(struct drm_i915_private *dev_priv,
> + enum transcoder dsi_trans, int hdr_credit)
>  {
>   if (wait_for_us(header_credits_available(dev_priv, dsi_trans) >=
> - MAX_HEADER_CREDIT, 100))
> + hdr_credit, 100)) {
>   drm_err(&dev_priv->drm, "DSI header credits not
> released\n");
> + return false;
> + }
> +
> + return true;
>  }
> 
> -static void wait_for_payload_credits(struct drm_i915_private *dev_priv,
> -  enum transcoder dsi_trans)
> +static bool wait_for_payload_credits(struct drm_i915_private *dev_priv,
> +  enum transcoder dsi_trans, int
> payld_credit)
>  {
>   if (wait_for_us(payload_credits_available(dev_priv, dsi_trans) >=
> - MAX_PLOAD_CREDIT, 100))
> + payld_credit, 100)) {
>   drm_err(&dev_priv->drm, "DSI payload credits not
> released\n");
> + return false;
> + }
> +
> + return true;
>  }
> 
>  static enum transcoder dsi_port_to_transcoder(enum port port) @@ -90,8
> +98,8 @@ static void wait_for_cmds_dispatched_to_panel(struct
> intel_encoder *encoder)
>   /* wait for header/payload credits to be released */
>   for_each_dsi_port(port, intel_dsi->ports) {
>   dsi_trans = dsi_port_to_transcoder(port);
> - wait_for_header_credits(dev_priv, dsi_trans);
> - wait_for_payload_credits(dev_priv, dsi_trans);
> + wait_for_header_credits(dev_priv, dsi_trans,
> MAX_HEADER_CREDIT);
> + wait_for_payload_credits(dev_priv, dsi_trans,
> MAX_PLOAD_CREDIT);
>   }
> 
>   /* send nop DCS command */
> @@ -108,7 +116,7 @@ static void
> wait_for_cmds_dispatched_to_panel(struct intel_encoder *encoder)
>   /* wait for header credits to be released */
>   for_each_dsi_port(port, intel_dsi->ports) {
>   dsi_trans = dsi_port_to_transcoder(port);
> - wait_for_header_credits(dev_priv, dsi_trans);
> + wait_for_header_credits(dev_priv, dsi_trans,
> MAX_HEADER_CREDIT);
>   }
> 
>   /* wait for LP TX in progress bit to be cleared */ @@ -126,18 +134,13
> @@ static bool add_payld_to_queue(struct intel_dsi_host *host, const u8
> *data,
>   struct intel_dsi *intel_dsi = host->intel_dsi;
>   struct drm_i915_private *dev_priv = to_i915(intel_dsi-
> >base.base.dev);
>   enum transcoder dsi_trans = dsi_port_to_transcoder(host->port);
> - int free_credits;
>   int i, j;
> 
>   for (i = 0; i < len; i += 4) {
>   u32 tmp = 0;
> 
> - free_credits = payload_credits_available(dev_priv,
> dsi_trans);
> - if (free_credits < 1) {
> - drm_err(&dev_priv->drm,
> - "Payload credit not available\n");
> + if (!wait_for_payload_credits(dev_priv, dsi_trans, 1))
>   return false;
> - }
> 
>   for (j 

Re: [Intel-gfx] [v4 5/7] drm/i915: Get proper min cdclk if vDSC enabled

[Kulkarni, Vandita]

Have already reviewed v1, v2 and Rb'ed V3 (rev3).

> -Original Message-
> From: Lee, Shawn C 
> Sent: Thursday, August 12, 2021 9:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William ; Lee,
> Shawn C ; Jani Nikula 
> Subject: [v4 5/7] drm/i915: Get proper min cdclk if vDSC enabled
> 
> VDSC engine can process only 1 pixel per Cd clock. In case VDSC is used and
> max slice count == 1, max supported pixel clock should be 100% of CD clock.
> Then do min_cdclk and pixel clock comparison to get proper min cdclk.
> 
> v2:
> - Check for dsc enable and slice count ==1 then allow to
>   double confirm min cdclk value.
> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 

Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 34fa4130d5c4..9aec17b33819 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2139,6 +2139,16 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>   /* Account for additional needs from the planes */
>   min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> 
> + /*
> +  * VDSC engine can process only 1 pixel per Cd clock.
> +  * In case VDSC is used and max slice count == 1,
> +  * max supported pixel clock should be 100% of CD clock.
> +  * Then do min_cdclk and pixel clock comparison to get cdclk.
> +  */
> + if (crtc_state->dsc.compression_enable &&
> + crtc_state->dsc.slice_count == 1)
> + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> +
>   /*
>* HACK. Currently for TGL platforms we calculate
>* min_cdclk initially based on pixel_rate divided
> --
> 2.17.1

Re: [Intel-gfx] [v4 6/7] drm/i915/dsi: Retrieve max brightness level from VBT.

[Kulkarni, Vandita]

> -Original Message-
> From: 
> Sent: Monday, August 23, 2021 2:34 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com; 
> Chiou,
> Cooper ; Tseng, William
> ; Jani Nikula 
> Subject: RE: [v4 6/7] drm/i915/dsi: Retrieve max brightness level from VBT.
> 
> On Mon, 23 Aug 2021, Kulkarni, Vandita  wrote:
> >>
> >> So far, DCS backlight driver hardcode (0xFF) for max brightness level.
> >> MIPI DCS spec allow max 0x for set_display_brightness (51h)
> command.
> >> And VBT brightness precision bits can support 8 ~ 16 bits.
> >>
> >> We should set correct precision bits in VBT that meet panel's request.
> >> Driver can refer to this setting then configure max brightness level
> >> in DCS backlight driver properly.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jani Nikula 
> >> Cc: Vandita Kulkarni 
> >> Cc: Cooper Chiou 
> >> Cc: William Tseng 
> >> Signed-off-by: Lee Shawn C 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_bios.c|  3 +++
> >>  .../gpu/drm/i915/display/intel_dsi_dcs_backlight.c   | 12 +---
> >>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >>  3 files changed, 13 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> >> b/drivers/gpu/drm/i915/display/intel_bios.c
> >> index e86e6ed2d3bf..1affd679d1d1 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> @@ -483,6 +483,9 @@ parse_lfp_backlight(struct drm_i915_private
> >> *i915, level = 255;  }  i915->vbt.backlight.min_brightness =
> >> min_level;
> >> +
> >> +i915->vbt.backlight.max_brightness_level =
> >> +(1 << backlight_data-
> >> >brightness_precision_bits[panel_type]) - 1;
> >>  } else {
> >>  level = backlight_data->level[panel_type];
> >>  i915->vbt.backlight.min_brightness = entry->min_brightness; diff
> >> --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> >> b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> >> index 584c14c4cbd0..cd85520d36e2 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> >> @@ -41,7 +41,7 @@
> >>  #define POWER_SAVE_HIGH(3 << 0)
> >>  #define POWER_SAVE_OUTDOOR_MODE(4 << 0)
> >>
> >> -#define PANEL_PWM_MAX_VALUE0xFF
> >
> >Shouldn't this be panel dependant too?
> 
> If driver did not retrieve proper precision bits, we will use
> PANEL_PWM_MAX_VALUE as default max backlight.
> Do you recommend to keep 0xFF here?
Precision bits are defined from version 236 of VBT , if that is not valid or is 
equal to 8 then max brightness should be 0xFF.
> 
> >> +#define PANEL_PWM_MAX_VALUE0x
> >>
> >>  static u32 dcs_get_backlight(struct intel_connector *connector, enum
> >> pipe
> >> unused)  { @@ -147,10 +147,16 @@ static void
> >> dcs_enable_backlight(const struct intel_crtc_state *crtc_state,
> >> static int dcs_setup_backlight(struct intel_connector *connector,
> >> enum pipe unused)
> >>  {
> >> +struct drm_device *dev = connector->base.dev; struct
> >> +drm_i915_private *dev_priv = to_i915(dev);
> >>  struct intel_panel *panel = &connector->panel;
> >>
> >> -panel->backlight.max = PANEL_PWM_MAX_VALUE; backlight.level =
> >> -panel->PANEL_PWM_MAX_VALUE;
> >> +panel->backlight.max = dev_priv-
> >> >vbt.backlight.max_brightness_level \
> >> +   ? dev_priv->vbt.backlight.max_brightness_level \
> >> +   : PANEL_PWM_MAX_VALUE;
> >> +panel->backlight.level = dev_priv-
> >> >vbt.backlight.max_brightness_level \
> >> + ? dev_priv-
> >> >vbt.backlight.max_brightness_level \
> >> + : PANEL_PWM_MAX_VALUE;
> >>
> >>  return 0;
> >>  }
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h index 005b1cec7007..fbb3f18e7b8e
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -706,6 +706,7 @@ struct intel_vbt_data {
> >>
> >>  struct {
> >>  u16 pwm_freq_hz;
> >
> >VBT doesn't provide max_brightness_level, instead it gives us Brightness
> Precision bits from version 236 onwards.
> 
> I will modify this variable name to "brightness_precision_bits". And move the
> max brightness calculation into dcs_setup_backlight().
> 
> Best regards,
> Shawn
> 
> >> +u16 max_brightness_level;
> >>  bool present;
> >>  bool active_low_pwm;
> >>  u8 min_brightness;/* min_brightness/255 of max */
> >> --
> >> 2.17.1

Re: [Intel-gfx] [v4 4/7] drm/i915/dsi: refine send MIPI DCS command sequence

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Thursday, August 12, 2021 9:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William ; Lee,
> Shawn C ; Jani Nikula 
> Subject: [v4 4/7] drm/i915/dsi: refine send MIPI DCS command sequence
> 
> According to chapter "Sending Commands to the Panel" in bspec #29738 and
> #49188. If driver try to send DCS long pakcet, we have to program TX payload
> register at first. And configure TX header HW register later.
> DSC long packet would not be sent properly if we don't follow this sequence.
> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 

Looks Good to me.
Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 1780830d9909..60413bbf565f 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1807,11 +1807,6 @@ static ssize_t gen11_dsi_host_transfer(struct
> mipi_dsi_host *host,
>   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>   enable_lpdt = true;
> 
> - /* send packet header */
> - ret  = dsi_send_pkt_hdr(intel_dsi_host, dsi_pkt, enable_lpdt);
> - if (ret < 0)
> - return ret;
> -
>   /* only long packet contains payload */
>   if (mipi_dsi_packet_format_is_long(msg->type)) {
>   ret = dsi_send_pkt_payld(intel_dsi_host, dsi_pkt); @@ -
> 1819,6 +1814,11 @@ static ssize_t gen11_dsi_host_transfer(struct
> mipi_dsi_host *host,
>   return ret;
>   }
> 
> + /* send packet header */
> + ret  = dsi_send_pkt_hdr(intel_dsi_host, dsi_pkt, enable_lpdt);
> + if (ret < 0)
> + return ret;
> +
>   //TODO: add payload receive code if needed
> 
>   ret = sizeof(dsi_pkt.header) + dsi_pkt.payload_length;
> --
> 2.17.1

Re: [Intel-gfx] [v4 6/7] drm/i915/dsi: Retrieve max brightness level from VBT.

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Thursday, August 12, 2021 9:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William ; Lee,
> Shawn C ; Jani Nikula 
> Subject: [v4 6/7] drm/i915/dsi: Retrieve max brightness level from VBT.
> 
> So far, DCS backlight driver hardcode (0xFF) for max brightness level.
> MIPI DCS spec allow max 0x for set_display_brightness (51h) command.
> And VBT brightness precision bits can support 8 ~ 16 bits.
> 
> We should set correct precision bits in VBT that meet panel's request.
> Driver can refer to this setting then configure max brightness level in DCS
> backlight driver properly.
> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c|  3 +++
>  .../gpu/drm/i915/display/intel_dsi_dcs_backlight.c   | 12 +---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index e86e6ed2d3bf..1affd679d1d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -483,6 +483,9 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>   level = 255;
>   }
>   i915->vbt.backlight.min_brightness = min_level;
> +
> + i915->vbt.backlight.max_brightness_level =
> + (1 << backlight_data-
> >brightness_precision_bits[panel_type]) - 1;
>   } else {
>   level = backlight_data->level[panel_type];
>   i915->vbt.backlight.min_brightness = entry->min_brightness;
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> index 584c14c4cbd0..cd85520d36e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
> @@ -41,7 +41,7 @@
>  #define POWER_SAVE_HIGH  (3 << 0)
>  #define POWER_SAVE_OUTDOOR_MODE  (4 << 0)
> 
> -#define PANEL_PWM_MAX_VALUE  0xFF

Shouldn't this be panel dependant too?
> +#define PANEL_PWM_MAX_VALUE  0x
> 
>  static u32 dcs_get_backlight(struct intel_connector *connector, enum pipe
> unused)  { @@ -147,10 +147,16 @@ static void dcs_enable_backlight(const
> struct intel_crtc_state *crtc_state,  static int dcs_setup_backlight(struct
> intel_connector *connector,
>  enum pipe unused)
>  {
> + struct drm_device *dev = connector->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_panel *panel = &connector->panel;
> 
> - panel->backlight.max = PANEL_PWM_MAX_VALUE;
> - panel->backlight.level = PANEL_PWM_MAX_VALUE;
> + panel->backlight.max = dev_priv-
> >vbt.backlight.max_brightness_level \
> +? dev_priv->vbt.backlight.max_brightness_level \
> +: PANEL_PWM_MAX_VALUE;
> + panel->backlight.level = dev_priv-
> >vbt.backlight.max_brightness_level \
> +  ? dev_priv-
> >vbt.backlight.max_brightness_level \
> +  : PANEL_PWM_MAX_VALUE;
> 
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 005b1cec7007..fbb3f18e7b8e
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -706,6 +706,7 @@ struct intel_vbt_data {
> 
>   struct {
>   u16 pwm_freq_hz;

VBT doesn't provide max_brightness_level, instead it gives us Brightness 
Precision bits from version 236 onwards.
> + u16 max_brightness_level;
>   bool present;
>   bool active_low_pwm;
>   u8 min_brightness;  /* min_brightness/255 of max */
> --
> 2.17.1

Re: [Intel-gfx] [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

[Kulkarni, Vandita]

Now, this change and changes from patch 51 of this series is taken care as part 
of the below series
https://patchwork.freedesktop.org/series/92750/
and merged.

Thanks,
Vandita
> -Original Message-
> From: Jani Nikula 
> Sent: Friday, July 2, 2021 1:50 PM
> To: Roper, Matthew D ; intel-
> g...@lists.freedesktop.org
> Cc: Patnana, Venkata Sai ; Srivatsa, Anusha
> ; dri-de...@lists.freedesktop.org; Navare,
> Manasi D ; Kulkarni, Vandita
> 
> Subject: Re: [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs
> node for DSC BPP enable
> 
> On Thu, 01 Jul 2021, Matt Roper  wrote:
> > From: Anusha Srivatsa 
> >
> > DSC can be supported per DP connector. This patch creates a per
> > connector debugfs node to expose the Input and Compressed BPP.
> >
> > The same node can be used from userspace to force DSC to a certain
> > BPP.
> >
> > force_dsc_bpp is written through this debugfs node to force DSC BPP to
> > all accepted values
> 
> I think this patch needs rework, and it's independent of the rest of the
> series. Please just drop this one and the next.
> 
> BR,
> Jani.
> 
> >
> > Cc: Vandita Kulkarni 
> > Cc: Manasi Navare 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Patnana Venkata Sai 
> > Signed-off-by: Matt Roper 
> > ---
> >  .../drm/i915/display/intel_display_debugfs.c  | 103 +-
> >  .../drm/i915/display/intel_display_types.h|   1 +
> >  2 files changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index af9e58619667..1805d70ea817 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -2389,6 +2389,100 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> > .write = i915_dsc_fec_support_write
> >  };
> >
> > +static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
> > +{
> > +   struct drm_connector *connector = m->private;
> > +   struct drm_device *dev = connector->dev;
> > +   struct drm_crtc *crtc;
> > +   struct intel_dp *intel_dp;
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct intel_crtc_state *crtc_state = NULL;
> > +   int ret = 0;
> > +   bool try_again = false;
> > +
> > +   drm_modeset_acquire_init(&ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > +
> > +   do {
> > +   try_again = false;
> > +   ret = drm_modeset_lock(&dev-
> >mode_config.connection_mutex,
> > +  &ctx);
> > +   if (ret) {
> > +   ret = -EINTR;
> > +   break;
> > +   }
> > +   crtc = connector->state->crtc;
> > +   if (connector->status != connector_status_connected ||
> !crtc) {
> > +   ret = -ENODEV;
> > +   break;
> > +   }
> > +   ret = drm_modeset_lock(&crtc->mutex, &ctx);
> > +   if (ret == -EDEADLK) {
> > +   ret = drm_modeset_backoff(&ctx);
> > +   if (!ret) {
> > +   try_again = true;
> > +   continue;
> > +   }
> > +   break;
> > +   } else if (ret) {
> > +   break;
> > +   }
> > +   intel_dp =
> intel_attached_dp(to_intel_connector(connector));
> > +   crtc_state = to_intel_crtc_state(crtc->state);
> > +   seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
> > +   seq_printf(m, "Compressed_BPP: %d\n",
> > +   crtc_state->dsc.compressed_bpp);
> > +   } while (try_again);
> > +
> > +   drm_modeset_drop_locks(&ctx);
> > +   drm_modeset_acquire_fini(&ctx);
> > +
> > +   return ret;
> > +}
> > +
> > +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> > +   const char __user *ubuf,
> > +   size_t len, loff_t *offp)
> > +{
> > +   int dsc_bpp = 0;
> > +   int ret;
> > +   struct drm_connector *connector =
> > +   ((struct seq_file *)file->private_data)->private;
> > +   struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connect

Re: [Intel-gfx] [V3 5/7] drm/i915: Get proper min cdclk if vDSC enabled

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Friday, July 23, 2021 12:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William ; Lee,
> Shawn C ; Jani Nikula 
> Subject: [V3 5/7] drm/i915: Get proper min cdclk if vDSC enabled
> 
> VDSC engine can process only 1 pixel per Cd clock. In case VDSC is used and
> max slice count == 1, max supported pixel clock should be 100% of CD clock.
> Then do min_cdclk and pixel clock comparison to get proper min cdclk.
> 
> v2:
> - Check for dsc enable and slice count ==1 then allow to
>   double confirm min cdclk value.

LGTM, 
Reviewed-by: Vandita Kulkarni 

> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 71067a62264d..3e09f6370d27 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2159,6 +2159,16 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>   /* Account for additional needs from the planes */
>   min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> 
> + /*
> +  * VDSC engine can process only 1 pixel per Cd clock.
> +  * In case VDSC is used and max slice count == 1,
> +  * max supported pixel clock should be 100% of CD clock.
> +  * Then do min_cdclk and pixel clock comparison to get cdclk.
> +  */
> + if (crtc_state->dsc.compression_enable &&
> + crtc_state->dsc.slice_count == 1)
> + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> +
>   /*
>* HACK. Currently for TGL platforms we calculate
>* min_cdclk initially based on pixel_rate divided
> --
> 2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Get proper min cdclk if vDSC enabled

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Tuesday, July 20, 2021 8:01 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Ville Syrjala ; Jani Nikula
> ; Chiou, Cooper ;
> Tseng, William 
> Subject: RE: [PATCH 5/5] drm/i915: Get proper min cdclk if vDSC enabled
> 
> 
> On Tue, July 19, 2021, Vandita Kulkarni  wrote:
> >>
> >> VDSC engine can process only 1 pixel per Cd clock. In case VDSC is
> >> used and max slice count == 1, max supported pixel clock should be 100%
> of CD clock.
> >> Then do min_cdclk and pixel clock comparison to get proper min cdclk.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jani Nikula 
> >> Cc: Vandita Kulkarni 
> >> Cc: Cooper Chiou 
> >> Cc: William Tseng 
> >> Signed-off-by: Lee Shawn C 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_cdclk.c | 12 
> >>  1 file changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> index 71067a62264d..c33d574eb991 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> @@ -2159,6 +2159,18 @@ int intel_crtc_compute_min_cdclk(const struct
> >> intel_crtc_state *crtc_state)
> >>  /* Account for additional needs from the planes */  min_cdclk =
> >> max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> >>
> >> +/*
> >> + * VDSC engine can process only 1 pixel per Cd clock.
> >> + * In case VDSC is used and max slice count == 1,
> >> + * max supported pixel clock should be 100% of CD clock.
> >> + * Then do min_cdclk and pixel clock comparison to get cdclk.
> >> + */
> >> +if (DISPLAY_VER(dev_priv) >= 11 &&
> >
> >I think you could just check for dsc enable and slice count ==1.
> >
> 
> DP and eDP would apply the same thing if dsc enabled and sink's dsc slice
> count ==1.
> Is that right?
Yes.
> 
> >Also better to have a check if crtc_clock exceeds dev_priv->max_cdclk_freq
> in dsi_dsc compute_config as well.
> >and return -EINVAL .
> >
> >-Vandita
Since we do not have bigjoiner support on dsi yet and the check wrt 
max_cdclk_freq
is taken care in intel_crtc_compute_config. I think you can leave this for now.
You do not need this clock check again in dsi_compute_config

-Vandita
> >
> 
> We should have this checking in dsi_dsc_compute_config() just like DP driver
> did. What do you think?
> 
>   if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
>   pipe_config->bigjoiner) {
>   if (pipe_config->dsc.slice_count < 2) {
>   drm_dbg_kms(&dev_priv->drm,
>   "Cannot split stream to use 2 VDSC
> instances\n");
>   return -EINVAL;
>   }
> 
>   pipe_config->dsc.dsc_split = true;
>   }
> 
> Best regards,
> Shawn
> 
> >> +intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> >> +crtc_state->dsc.compression_enable &&
> >> +crtc_state->dsc.slice_count == 1)
> >
> >> +min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> >> +
> >>  /*
> >>   * HACK. Currently for TGL platforms we calculate
> >>   * min_cdclk initially based on pixel_rate divided
> >> --
> >> 2.17.1
> >
> >

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Get proper min cdclk if vDSC enabled

[Kulkarni, Vandita]

> -Original Message-
> From: Lee, Shawn C 
> Sent: Monday, July 19, 2021 12:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lee, Shawn C ; Ville Syrjala
> ; Jani Nikula ;
> Kulkarni, Vandita ; Chiou, Cooper
> ; Tseng, William 
> Subject: [PATCH 5/5] drm/i915: Get proper min cdclk if vDSC enabled
> 
> VDSC engine can process only 1 pixel per Cd clock. In case VDSC is used and
> max slice count == 1, max supported pixel clock should be 100% of CD clock.
> Then do min_cdclk and pixel clock comparison to get proper min cdclk.
> 
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Cooper Chiou 
> Cc: William Tseng 
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 71067a62264d..c33d574eb991 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2159,6 +2159,18 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>   /* Account for additional needs from the planes */
>   min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> 
> + /*
> +  * VDSC engine can process only 1 pixel per Cd clock.
> +  * In case VDSC is used and max slice count == 1,
> +  * max supported pixel clock should be 100% of CD clock.
> +  * Then do min_cdclk and pixel clock comparison to get cdclk.
> +  */
> + if (DISPLAY_VER(dev_priv) >= 11 &&

I think you could just check for dsc enable and slice count ==1.

Also better to have a check if crtc_clock exceeds dev_priv->max_cdclk_freq in 
dsi_dsc compute_config as well.
and return -EINVAL .

-Vandita

> + intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> + crtc_state->dsc.compression_enable &&
> + crtc_state->dsc.slice_count == 1)

> + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> +
>   /*
>* HACK. Currently for TGL platforms we calculate
>* min_cdclk initially based on pixel_rate divided
> --
> 2.17.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v7 0/3] Enable setting custom DSC BPP

[Kulkarni, Vandita]

Pushed to drm-intel-next, thanks for the reviews.
-Vandita

> -Original Message-
> From: Kulkarni, Vandita 
> Sent: Tuesday, July 20, 2021 12:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kulkarni, Vandita 
> Subject: [v7 0/3] Enable setting custom DSC BPP
> 
> This series add debugfs entry to force dsc bpp to ceratin valid test value, 
> for
> validation needs.
> This series has been tested locally.
> With the introduction of i915_dsc_bpp debugfs the expectation is that
> whenever there is force_dsc_en set, force_dsc_bpp should have a valid
> value for that format which is between bpp to bpp-1.
> 
> This makes the older test kms_dp_dsc --basic fail as in that case
> force_dsc_bpp would be 0 and is not a valid value.
> 
> Have tested with local changes on the same.
> The series https://patchwork.freedesktop.org/series/91772/
> have the base patches and would need some work on the debugfs name
> change, giving default value for force_dsc_bpp in case of basic-dsc-enable
> test cases, clearing up of the force_dsc_bpp value while exiting the test.
> Which will be floated shortly.
> 
> Have added minor fix on the feci debugfs interface.
> If further changes are needed on the same will float them in a different
> series.
> 
> This series has been reviewed here
> https://patchwork.freedesktop.org/series/92312/#rev5
> 
> Resubmitting it here as the series submitter got overridden due to one of the
> review comment mishaps.
> 
> Patnana Venkata Sai (1):
>   drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
> enable
> 
> Vandita Kulkarni (2):
>   drm/i915/display: Add write permissions for fec support
>   drm/i915/display/dsc: Force dsc BPP
> 
>  .../drm/i915/display/intel_display_debugfs.c  | 78 ++-
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 17 
>  3 files changed, 94 insertions(+), 2 deletions(-)
> 
> --
> 2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v7 3/3] drm/i915/display/dsc: Force dsc BPP

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, July 8, 2021 9:53 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [v7 3/3] drm/i915/display/dsc: Force dsc BPP
> 
> On Thu, 08 Jul 2021, "Kulkarni, Vandita"  wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Thursday, July 8, 2021 6:44 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Kulkarni, Vandita 
> >> Subject: Re: [v7 3/3] drm/i915/display/dsc: Force dsc BPP
> >>
> >> On Thu, 08 Jul 2021, Jani Nikula  wrote:
> >> > On Thu, 08 Jul 2021, Vandita Kulkarni 
> wrote:
> >> >> Set DSC BPP to the value forced through debugfs. It can go from
> >> >> bpc to bpp-1.
> >> >>
> >> >> Signed-off-by: Vandita Kulkarni 
> >> >> ---
> >> >>  drivers/gpu/drm/i915/display/intel_dp.c | 17 +
> >> >>  1 file changed, 17 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> index 5b52beaddada..3e50cdd7e448 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> @@ -1240,6 +1240,23 @@ static int
> >> >> intel_dp_dsc_compute_config(struct
> >> intel_dp *intel_dp,
> >> >> pipe_config->port_clock = intel_dp->common_rates[limits-
> >> >max_clock];
> >> >> pipe_config->lane_count = limits->max_lane_count;
> >> >>
> >> >> +   if (intel_dp->force_dsc_en) {
> >>
> >> Oh, this should check for intel_dp->force_dsc_bpp. We don't want to
> >> always force the bpp when we force dsc enable.
> > Okay will fix this.
> > And I was returning -EINVAL , to fail the test on setting invalid BPP.
> 
> Okay, if it makes the test easier, I guess it's fine. Up to you.

Okay,  for now I have sent a patch like you suggested,  as I see that there are 
no negative test cases .
Have sent the v2 of this patch. So,  it wouldn't make much difference.

Thanks,
Vandita
> 
> BR,
> Jani.
> 
> >
> >>
> >> >> +   /* As of today we support DSC for only RGB */
> >> >> +   if (intel_dp->force_dsc_bpp >= 8 &&
> >> >> +   intel_dp->force_dsc_bpp < pipe_bpp) {
> >> >> +   drm_dbg_kms(&dev_priv->drm,
> >> >> +   "DSC BPP forced to %d",
> >> >> +   intel_dp->force_dsc_bpp);
> >> >> +   pipe_config->dsc.compressed_bpp =
> >> >> +   intel_dp->force_dsc_bpp;
> >> >> +   } else {
> >> >> +   drm_dbg_kms(&dev_priv->drm,
> >> >> +   "Invalid DSC BPP %d",
> >> >> +   intel_dp->force_dsc_bpp);
> >> >> +   return -EINVAL;
> >> >
> >> > I'd just let it use the normal compressed_bpp, with the debug
> >> > message, instead of returning -EINVAL.
> >> >
> >> >> +   }
> >> >> +   }
> >> >> +
> >> >
> >> > This should be *after* the below blocks, because otherwise
> >> > compressed_bpp will be overridden by the normal case, not by the
> >> > force case!
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> >> if (intel_dp_is_edp(intel_dp)) {
> >> >> pipe_config->dsc.compressed_bpp =
> >> >> min_t(u16,
> >> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v7 0/3] Set BPP in the kernel

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Kulkarni, Vandita
> Sent: Thursday, July 8, 2021 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: Re: [Intel-gfx] [v7 0/3] Set BPP in the kernel
> 
> > -Original Message-----
> > From: Kulkarni, Vandita 
> > Sent: Thursday, July 8, 2021 3:56 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani ; Kulkarni, Vandita
> > 
> > Subject: [v7 0/3] Set BPP in the kernel
> >
> > This series adds debugfs entry to force dsc bpp to ceratin valid test
> > value, for validation needs.
> > This series has been tested locally.
> > With the introduction of i915_dsc_bpp debugfs the expectation is that
> > whenever there is force_dsc_en set, force_dsc_bpp should have a valid
> > value for that format which is between bpp to bpp-1.
> Correction : *bpc to bpp-1
> >
> > This makes the older test kms_dp_dsc --basic fail as in that case
> > force_dsc_bpp would be 0 and is not a valid value.

The latest v2 patch fixes this, and if only force_dsc_en is set then default 
calculated
dsc_bpp would be assigned. (Jani)
Also, if the test sends invalid value, the driver will set the default value.( 
Jani)

The test app for testing force_dsc_en - basic dsc enable tests would
remain as is.

Thanks,
Vandita

> >
> > Have tested with local changes on the same.
> > The series https://patchwork.freedesktop.org/series/91772/
> > have the base patches and would need some work on the debugfs name
> > change, giving default value for force_dsc_bpp in case of
> > basic-dsc-enable test cases, clearing up of the force_dsc_bpp value while
> exiting the test.
> > Which will be floated shortly.
> >
> > Have added minor fix on the feci debugfs interface.
> > If further changes are needed on the same will float them in a
> > different series.
> >
> > Patnana Venkata Sai (1):
> >   drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
> > enable
> >
> > Vandita Kulkarni (2):
> >   drm/i915/display: Add write permissions for fec support
> >   drm/i915/display/dsc: Force dsc BPP
> >
> >  .../drm/i915/display/intel_display_debugfs.c  | 78 ++-
> >  .../drm/i915/display/intel_display_types.h|  1 +
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 17 
> >  3 files changed, 94 insertions(+), 2 deletions(-)
> >
> > --
> > 2.32.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v7 3/3] drm/i915/display/dsc: Force dsc BPP

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, July 8, 2021 6:44 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Kulkarni, Vandita 
> Subject: Re: [v7 3/3] drm/i915/display/dsc: Force dsc BPP
> 
> On Thu, 08 Jul 2021, Jani Nikula  wrote:
> > On Thu, 08 Jul 2021, Vandita Kulkarni  wrote:
> >> Set DSC BPP to the value forced through debugfs. It can go from bpc
> >> to bpp-1.
> >>
> >> Signed-off-by: Vandita Kulkarni 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_dp.c | 17 +
> >>  1 file changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 5b52beaddada..3e50cdd7e448 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -1240,6 +1240,23 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >>pipe_config->port_clock = intel_dp->common_rates[limits-
> >max_clock];
> >>pipe_config->lane_count = limits->max_lane_count;
> >>
> >> +  if (intel_dp->force_dsc_en) {
> 
> Oh, this should check for intel_dp->force_dsc_bpp. We don't want to always
> force the bpp when we force dsc enable.
Okay will fix this.
And I was returning -EINVAL , to fail the test on setting invalid BPP.

> 
> >> +  /* As of today we support DSC for only RGB */
> >> +  if (intel_dp->force_dsc_bpp >= 8 &&
> >> +  intel_dp->force_dsc_bpp < pipe_bpp) {
> >> +  drm_dbg_kms(&dev_priv->drm,
> >> +  "DSC BPP forced to %d",
> >> +  intel_dp->force_dsc_bpp);
> >> +  pipe_config->dsc.compressed_bpp =
> >> +  intel_dp->force_dsc_bpp;
> >> +  } else {
> >> +  drm_dbg_kms(&dev_priv->drm,
> >> +  "Invalid DSC BPP %d",
> >> +  intel_dp->force_dsc_bpp);
> >> +  return -EINVAL;
> >
> > I'd just let it use the normal compressed_bpp, with the debug message,
> > instead of returning -EINVAL.
> >
> >> +  }
> >> +  }
> >> +
> >
> > This should be *after* the below blocks, because otherwise
> > compressed_bpp will be overridden by the normal case, not by the force
> > case!
> >
> > BR,
> > Jani.
> >
> >>if (intel_dp_is_edp(intel_dp)) {
> >>pipe_config->dsc.compressed_bpp =
> >>min_t(u16,
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v7 0/3] Set BPP in the kernel

[Kulkarni, Vandita]

> -Original Message-
> From: Kulkarni, Vandita 
> Sent: Thursday, July 8, 2021 3:56 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Kulkarni, Vandita
> 
> Subject: [v7 0/3] Set BPP in the kernel
> 
> This series adds debugfs entry to force dsc bpp to ceratin valid test value, 
> for
> validation needs.
> This series has been tested locally.
> With the introduction of i915_dsc_bpp debugfs the expectation is that
> whenever there is force_dsc_en set, force_dsc_bpp should have a valid
> value for that format which is between bpp to bpp-1.
Correction : *bpc to bpp-1
> 
> This makes the older test kms_dp_dsc --basic fail as in that case
> force_dsc_bpp would be 0 and is not a valid value.
> 
> Have tested with local changes on the same.
> The series https://patchwork.freedesktop.org/series/91772/
> have the base patches and would need some work on the debugfs name
> change, giving default value for force_dsc_bpp in case of basic-dsc-enable
> test cases, clearing up of the force_dsc_bpp value while exiting the test.
> Which will be floated shortly.
> 
> Have added minor fix on the feci debugfs interface.
> If further changes are needed on the same will float them in a different
> series.
> 
> Patnana Venkata Sai (1):
>   drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
> enable
> 
> Vandita Kulkarni (2):
>   drm/i915/display: Add write permissions for fec support
>   drm/i915/display/dsc: Force dsc BPP
> 
>  .../drm/i915/display/intel_display_debugfs.c  | 78 ++-
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 17 
>  3 files changed, 94 insertions(+), 2 deletions(-)
> 
> --
> 2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display/dsc: Set BPP in the kernel

[Kulkarni, Vandita]

> -Original Message-
> From: Patnana, Venkata Sai 
> Sent: Friday, June 25, 2021 3:39 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Patnana, Venkata Sai ; Srivatsa, Anusha
> ; Kulkarni, Vandita
> ; Navare, Manasi D
> 
> Subject: [PATCH 2/2] drm/i915/display/dsc: Set BPP in the kernel
> 
> From: Anusha Srivatsa 
> 
> Set compress BPP in kernel while connector DP or eDP
> 
> Cc: Vandita Kulkarni 
> Cc: Navare Manasi D 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Patnana Venkata Sai 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f74f70691247b..a454ee4210866 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
>   pipe_config->lane_count = limits->max_lane_count;
> 
>   if (intel_dp_is_edp(intel_dp)) {
> - pipe_config->dsc.compressed_bpp =
> - min_t(u16,
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
> -   pipe_config->pipe_bpp);
> + if (intel_dp->force_dsc_bpp) {
> + drm_dbg_kms(&dev_priv->drm,
> + "DSC BPC forced to %d", intel_dp-
> >force_dsc_bpp);
Should be DSC BPP.
> + pipe_config->dsc.compressed_bpp = intel_dp-
> >force_dsc_bpp;
> + } else {
> + pipe_config->dsc.compressed_bpp =
> + min_t(u16,
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
> + pipe_config->pipe_bpp);
> + }
>   pipe_config->dsc.slice_count =
>   drm_dp_dsc_sink_max_slice_count(intel_dp-
> >dsc_dpcd,
>   true);
> @@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
>   "Compressed BPP/Slice Count not
> supported\n");
>   return -EINVAL;
>   }
> - pipe_config->dsc.compressed_bpp = min_t(u16,
> + if (intel_dp->force_dsc_bpp) {
> + drm_dbg_kms(&dev_priv->drm,
> + "DSC BPC forced to %d\n", intel_dp-
> >force_dsc_bpp);
Same as above.
> + pipe_config->dsc.compressed_bpp = intel_dp-
> >force_dsc_bpp;
> + } else {
> + pipe_config->dsc.compressed_bpp = min_t(u16,
> 
> dsc_max_output_bpp >> 4,
>  pipe_config-
> >pipe_bpp);
> + }
>   pipe_config->dsc.slice_count = dsc_dp_slice_count;
>   }
>   /*
> @@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct
> intel_encoder *encoder,
>* Pipe joiner needs compression upto display12 due to BW
> limitation. DG2
>* onwards pipe joiner can be enabled without compression.
>*/
> - drm_dbg_kms(&i915->drm, "Force DSC en = %d\n", intel_dp-
> >force_dsc_en);
> + drm_dbg_kms(&i915->drm, "Force DSC en = %d\n Force DSC BPP =
> %d\n",
> + intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
>   if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
> pipe_config->bigjoiner)) {
>   ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
> --
> 2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)

[Kulkarni, Vandita]

The RB mail on rev 3 from Manasi Navare came in as a new patch rev4.
And all the testing happened on rev4.
Hence these warnings, which are not applicable to the actual patch V3 (rev3)

Thanks,
Vandita
> -Original Message-
> From: Intel-gfx  On Behalf Of
> Patchwork
> Sent: Tuesday, June 8, 2021 10:24 AM
> To: Navare, Manasi D 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsc: Fix
> bigjoiner check in dsc_disable (rev4)
> 
> == Series Details ==
> 
> Series: drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)
> URL   : https://patchwork.freedesktop.org/series/91006/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> bfd70a7d1a4e drm/i915/dsc: Fix bigjoiner check in dsc_disable
> -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit
> description (prefer a maximum 75 chars per line)
> #6:
> This change takes care of resetting the dss_ctl registers in case of
> dsc_disable, bigjoiner disable and also uncompressed joiner disable.
> 
> -:44: ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
> patch author '"Navare, Manasi D" '
> 
> total: 1 errors, 1 warnings, 0 checks, 18 lines checked
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)

[Kulkarni, Vandita]

This issue doesn’t seem to be related to the patch.
@Vudum, Lakshminarayana can you report 
the results.

From: Intel-gfx  On Behalf Of Patchwork
Sent: Tuesday, June 8, 2021 4:08 PM
To: Navare, Manasi D 
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Fix bigjoiner check 
in dsc_disable (rev4)

Patch Details
Series:

drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)

URL:

https://patchwork.freedesktop.org/series/91006/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20303/index.html

CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20303_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_20303_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20303_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_20303_full:

IGT changes
Possible regressions

  *   igt@kms_plane@plane-position-hole@pipe-b-planes:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE

Known issues

Here are the changes found in Patchwork_20303_full that come from known issues:

IGT changes
Issues hit

  *   igt@feature_discovery@display-2x:

 *   shard-iclb: NOTRUN -> 
SKIP
 ([i915#1839])

  *   igt@feature_discovery@psr2:

 *   shard-iclb: 
PASS
 -> 
SKIP
 ([i915#658])

  *   igt@gem_create@create-massive:

 *   shard-snb: NOTRUN -> 
DMESG-WARN
 ([i915#3002])
 *   shard-apl: NOTRUN -> 
DMESG-WARN
 ([i915#3002])

  *   igt@gem_ctx_persistence@clone:

 *   shard-snb: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +4 similar issues

  *   igt@gem_exec_fair@basic-deadline:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2846])

  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-apl: 
PASS
 -> 
SKIP
 ([fdo#109271])

  *   igt@gem_exec_fair@basic-none@vcs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-tglb: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@vecs0:

 *   shard-glk: NOTRUN -> 
FAIL
 ([i915#2842]) +2 similar issues

  *   igt@gem_exec_reloc@basic-wide-active@rcs0:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2389]) +4 similar issues

  *   igt@gem_huc_copy@huc-copy:

 *   shard-apl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#2190])

  *   igt@gem_mmap_gtt@big-copy:

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#307])

  *   igt@gem_pread@exhaustion:

 *   shard-apl: NOTRUN -> 
WARN
 ([i915#2658])

  *   igt@gem_pwrite@basi

Re: [Intel-gfx] [v2] drm/i915/dsc: Fix bigjoiner check in dsc_disable

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Tuesday, June 8, 2021 2:01 AM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Manna, Animesh 
> Subject: Re: [v2] drm/i915/dsc: Fix bigjoiner check in dsc_disable
> 
> On Mon, Jun 07, 2021 at 04:23:42PM +0530, Vandita Kulkarni wrote:
> > This change takes care of resetting the dss_ctl registers in case of
> > dsc_disable, bigjoiner disable and also uncompressed joiner disable.
> >
> > v2: Fix formatting
> >
> > Suggested-by: Jani Nikula 
> > Fixes: d961eb20adb6 (drm/i915/bigjoiner: atomic commit changes for
> > uncompressed joiner)
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3537
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index 19cd9531c115..b9828852a68f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -1161,12 +1161,12 @@ void intel_dsc_disable(const struct
> intel_crtc_state *old_crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
> > -   if (!(old_crtc_state->dsc.compression_enable &&
> > - old_crtc_state->bigjoiner))
> > -   return;
> > -
> > -   intel_de_write(dev_priv, dss_ctl1_reg(old_crtc_state), 0);
> > -   intel_de_write(dev_priv, dss_ctl2_reg(old_crtc_state), 0);
> > +   /* Disable only if either of them is enabled */
> > +   if (old_crtc_state->dsc.compression_enable ||
> > +   old_crtc_state->dsc.compression_enable) {
> 
> Vandita I think you have a copy paste error  the second condition should be
> old_crtc_state->bigjoiner ?
Sorry.
Will fix it.

Thanks,
Vandita
> 
> Manasi
> 
> > +   intel_de_write(dev_priv, dss_ctl1_reg(old_crtc_state), 0);
> > +   intel_de_write(dev_priv, dss_ctl2_reg(old_crtc_state), 0);
> > +   }
> >  }
> >
> >  void intel_uncompressed_joiner_get_config(struct intel_crtc_state
> > *crtc_state)
> > --
> > 2.21.0.5.gaeb582a
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC disable

[Kulkarni, Vandita]

> -Original Message-
> From: Navare, Manasi D 
> Sent: Friday, June 4, 2021 12:16 AM
> To: Kulkarni, Vandita 
> Cc: Manna, Animesh ; Nikula, Jani
> ; Saarinen, Jani ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in
> DSC disable
> 
> On Thu, Jun 03, 2021 at 08:37:22AM -0700, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Manna, Animesh 
> > > Sent: Thursday, June 3, 2021 7:24 PM
> > > To: Kulkarni, Vandita ; Nikula, Jani
> > > ; Saarinen, Jani ;
> > > intel- g...@lists.freedesktop.org
> > > Cc: Navare, Manasi D 
> > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > checks in DSC disable
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Kulkarni, Vandita 
> > > > Sent: Thursday, June 3, 2021 4:55 PM
> > > > To: Nikula, Jani ; Saarinen, Jani
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Cc: Manna, Animesh ; Navare, Manasi D
> > > > 
> > > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > > checks in DSC disable
> > > >
> > > > > -Original Message-
> > > > > From: Nikula, Jani 
> > > > > Sent: Thursday, June 3, 2021 3:11 PM
> > > > > To: Kulkarni, Vandita ; Saarinen,
> > > > > Jani ; intel-gfx@lists.freedesktop.org
> > > > > Cc: Manna, Animesh ; Navare, Manasi D
> > > > > 
> > > > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > > > checks in DSC disable
> > > > >
> > > > > On Thu, 03 Jun 2021, "Kulkarni, Vandita"
> > > > > 
> > > > > wrote:
> > > > > >> -Original Message-
> > > > > >> From: Saarinen, Jani 
> > > > > >> Sent: Thursday, June 3, 2021 1:07 PM
> > > > > >> To: Kulkarni, Vandita ; intel-
> > > > > >> g...@lists.freedesktop.org
> > > > > >> Cc: Nikula, Jani 
> > > > > >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove
> > > > > >> redundant checks in DSC disable
> > > > > >>
> > > > > >> Hi,
> > > > > >> > -Original Message-
> > > > > >> > From: Intel-gfx 
> > > > > >> > On Behalf Of Vandita Kulkarni
> > > > > >> > Sent: torstai 3. kesäkuuta 2021 9.54
> > > > > >> > To: intel-gfx@lists.freedesktop.org
> > > > > >> > Cc: Nikula, Jani 
> > > > > >> > Subject: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > > > >> > checks in DSC disable
> > > > > >> >
> > > > > >> > There can be a chance that pre os has enabled DSC and
> > > > > >> > driver's compute config would not need dsc to be enabled,
> > > > > >> > in such case if we check on compute config's compression
> > > > > >> > state to disable, we might end up in state
> > > > > >> mismatch.
> > > > > >>
> > > > > >> I assume this fixes real gitlab issue too?
> > > > > > Okay, will add the tag
> > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3537
> > > > >
> > > > > See https://lore.kernel.org/r/87fsxzp9qx@intel.com
> > > > >
> > > > > The problem is with ->bigjoiner, not the entire statement.
> > > > Thanks for pointing this out, true that bigjoiner not being
> > > > enabled will stop dsc disabling.
> > > > The bigjoiner check was making the entire condition check
> unnecessary.
> > > >
> > > > Will update and refloat.
> > >
> > > Hi Jani/Vandita,
> > >
> > > For uncompressed bigjoiner case if we want to use the same function
> > > to clear the dsc_ctrl1 register we may need to remove both the
> > > condition check.
> > > As for uncompressed bigjoiner case, compression_enable Will be 0 and
> > > will block in clearing the dss_ctl1_reg.
> >
> > Yes, I was going through and found that bit 20 and 21 of dss_ctl1 are
> > being used for uncompressed joiner.
> > So when dsc is not enabled to avoid writing the regist

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC disable

[Kulkarni, Vandita]

> -Original Message-
> From: Manna, Animesh 
> Sent: Thursday, June 3, 2021 7:24 PM
> To: Kulkarni, Vandita ; Nikula, Jani
> ; Saarinen, Jani ; intel-
> g...@lists.freedesktop.org
> Cc: Navare, Manasi D 
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in
> DSC disable
> 
> 
> 
> > -----Original Message-
> > From: Kulkarni, Vandita 
> > Sent: Thursday, June 3, 2021 4:55 PM
> > To: Nikula, Jani ; Saarinen, Jani
> > ; intel-gfx@lists.freedesktop.org
> > Cc: Manna, Animesh ; Navare, Manasi D
> > 
> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks
> > in DSC disable
> >
> > > -Original Message-
> > > From: Nikula, Jani 
> > > Sent: Thursday, June 3, 2021 3:11 PM
> > > To: Kulkarni, Vandita ; Saarinen, Jani
> > > ; intel-gfx@lists.freedesktop.org
> > > Cc: Manna, Animesh ; Navare, Manasi D
> > > 
> > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > checks in DSC disable
> > >
> > > On Thu, 03 Jun 2021, "Kulkarni, Vandita"
> > > 
> > > wrote:
> > > >> -Original Message-
> > > >> From: Saarinen, Jani 
> > > >> Sent: Thursday, June 3, 2021 1:07 PM
> > > >> To: Kulkarni, Vandita ; intel-
> > > >> g...@lists.freedesktop.org
> > > >> Cc: Nikula, Jani 
> > > >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > >> checks in DSC disable
> > > >>
> > > >> Hi,
> > > >> > -Original Message-
> > > >> > From: Intel-gfx  On
> > > >> > Behalf Of Vandita Kulkarni
> > > >> > Sent: torstai 3. kesäkuuta 2021 9.54
> > > >> > To: intel-gfx@lists.freedesktop.org
> > > >> > Cc: Nikula, Jani 
> > > >> > Subject: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> > > >> > checks in DSC disable
> > > >> >
> > > >> > There can be a chance that pre os has enabled DSC and driver's
> > > >> > compute config would not need dsc to be enabled, in such case
> > > >> > if we check on compute config's compression state to disable,
> > > >> > we might end up in state
> > > >> mismatch.
> > > >>
> > > >> I assume this fixes real gitlab issue too?
> > > > Okay, will add the tag
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3537
> > >
> > > See https://lore.kernel.org/r/87fsxzp9qx@intel.com
> > >
> > > The problem is with ->bigjoiner, not the entire statement.
> > Thanks for pointing this out, true that bigjoiner not being enabled
> > will stop dsc disabling.
> > The bigjoiner check was making the entire condition check unnecessary.
> >
> > Will update and refloat.
> 
> Hi Jani/Vandita,
> 
> For uncompressed bigjoiner case if we want to use the same function to
> clear the dsc_ctrl1 register we may need to remove both the condition
> check.
> As for uncompressed bigjoiner case, compression_enable Will be 0 and will
> block in clearing the dss_ctl1_reg.

Yes, I was going through and found that bit 20 and 21 of dss_ctl1 are being used
for uncompressed joiner.
So when dsc is not enabled to avoid writing the register we could add
below code .

if (dsc)
clear dss_ctl2
if ( bigjoiner | dsc)
clear dss_ctl1;
return;

bigjoiner = 1 and dsc = 0  - uncompressed , I think there is no harm in 
clearing dsc bits again
bigjoiner = 1 and dsc = 1 - compressed - uncompressed bits are already 0
bigjoiner = 0 and dsc= 1 - just dsc  - clear dsc rest are 0s already
bigjoiner = 0 and dsc = 0  do nothing, return

If I have missed any corner case, please let me know.

Thanks,
Vandita
> 
> Regards,
> Animesh
> >
> > Thanks,
> > Vandita
> > >
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Thanks,
> > > > Vandita
> > > >>
> > > >> >
> > > >> > Signed-off-by: Vandita Kulkarni 
> > > >> > ---
> > > >> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 4 
> > > >> >  1 file changed, 4 deletions(-)
> > > >> >
> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > >> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > >> > index 19cd9531c115..b05a9601

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC disable

[Kulkarni, Vandita]

> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, June 3, 2021 3:11 PM
> To: Kulkarni, Vandita ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Navare, Manasi D
> 
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in
> DSC disable
> 
> On Thu, 03 Jun 2021, "Kulkarni, Vandita" 
> wrote:
> >> -Original Message-
> >> From: Saarinen, Jani 
> >> Sent: Thursday, June 3, 2021 1:07 PM
> >> To: Kulkarni, Vandita ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Nikula, Jani 
> >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant
> >> checks in DSC disable
> >>
> >> Hi,
> >> > -Original Message-
> >> > From: Intel-gfx  On Behalf
> >> > Of Vandita Kulkarni
> >> > Sent: torstai 3. kesäkuuta 2021 9.54
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Cc: Nikula, Jani 
> >> > Subject: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks
> >> > in DSC disable
> >> >
> >> > There can be a chance that pre os has enabled DSC and driver's
> >> > compute config would not need dsc to be enabled, in such case if we
> >> > check on compute config's compression state to disable, we might
> >> > end up in state
> >> mismatch.
> >>
> >> I assume this fixes real gitlab issue too?
> > Okay, will add the tag
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3537
> 
> See https://lore.kernel.org/r/87fsxzp9qx@intel.com
> 
> The problem is with ->bigjoiner, not the entire statement.
Thanks for pointing this out, true that bigjoiner not being enabled will stop 
dsc disabling.
The bigjoiner check was making the entire condition check unnecessary.

Will update and refloat.

Thanks,
Vandita
> 
> 
> BR,
> Jani.
> 
> >
> > Thanks,
> > Vandita
> >>
> >> >
> >> > Signed-off-by: Vandita Kulkarni 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 4 
> >> >  1 file changed, 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > index 19cd9531c115..b05a96011d93 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > @@ -1161,10 +1161,6 @@ void intel_dsc_disable(const struct
> >> > intel_crtc_state
> >> > *old_crtc_state)
> >> >  struct intel_crtc *crtc = 
> >> > to_intel_crtc(old_crtc_state->uapi.crtc);
> >> >  struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> >
> >> > -if (!(old_crtc_state->dsc.compression_enable &&
> >> > -  old_crtc_state->bigjoiner))
> >> > -return;
> >> > -
> >> >  intel_de_write(dev_priv, dss_ctl1_reg(old_crtc_state), 0);
> >> >  intel_de_write(dev_priv, dss_ctl2_reg(old_crtc_state), 0);  }
> >> > --
> >> > 2.21.0.5.gaeb582a
> >> >
> >> > ___
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC disable

[Kulkarni, Vandita]

> -Original Message-
> From: Saarinen, Jani 
> Sent: Thursday, June 3, 2021 1:07 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in
> DSC disable
> 
> Hi,
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Vandita Kulkarni
> > Sent: torstai 3. kesäkuuta 2021 9.54
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani 
> > Subject: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in
> > DSC disable
> >
> > There can be a chance that pre os has enabled DSC and driver's compute
> > config would not need dsc to be enabled, in such case if we check on
> > compute config's compression state to disable, we might end up in state
> mismatch.
> 
> I assume this fixes real gitlab issue too?
Okay, will add the tag 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3537

Thanks,
Vandita
> 
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index 19cd9531c115..b05a96011d93 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -1161,10 +1161,6 @@ void intel_dsc_disable(const struct
> > intel_crtc_state
> > *old_crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
> > -   if (!(old_crtc_state->dsc.compression_enable &&
> > - old_crtc_state->bigjoiner))
> > -   return;
> > -
> > intel_de_write(dev_priv, dss_ctl1_reg(old_crtc_state), 0);
> > intel_de_write(dev_priv, dss_ctl2_reg(old_crtc_state), 0);  }
> > --
> > 2.21.0.5.gaeb582a
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 02/23] drm/i915/xelpd: Support DP1.4 compression BPPs

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Monday, May 17, 2021 8:49 PM
> To: Roper, Matthew D ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 02/23] drm/i915/xelpd: Support DP1.4
> compression BPPs
> 
> On Fri, 14 May 2021, Matt Roper  wrote:
> > From: Vandita Kulkarni 
> >
> > Support compression BPPs from bpc to uncompressed BPP -1.
> > So far we have 8,10,12 as valid compressed BPPS now the support is
> > extended.
> >
> > Cc: Manasi Navare 
> > Signed-off-by: Vandita Kulkarni 
> > Signed-off-by: Matt Roper 
> > Reviewed-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 5c983044..16cdec9a4aa3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -521,6 +521,7 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> > drm_dbg_kms(&i915->drm, "Max small joiner bpp: %u\n",
> > max_bpp_small_joiner_ram);
> >
> > +
> > /*
> >  * Greatest allowed DSC BPP = MIN (output BPP from available Link
> BW
> >  * check, output bpp from small joiner RAM check)
> 
> What happened here? This is the full patch?
I see that the rest of the patch is merged.

Thanks
Vandita
> 
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 14/23] drm/i915/adl_p: Tx escape clock with DSI

[Kulkarni, Vandita]

> -Original Message-
> From: Roper, Matthew D 
> Sent: Saturday, May 15, 2021 8:40 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Kulkarni, Vandita
> ; Taylor, Clinton A
> ; Roper, Matthew D
> 
> Subject: [PATCH v4 14/23] drm/i915/adl_p: Tx escape clock with DSI
> 
> From: Mika Kahola 
> 
> Today when the DSI controller is paired with the Combo-PHY it uses the high-
> speed (HS) Word clock for its low power (LP) transmit PPI communication to
> the DPHY. The interface signaling only changes state at an Escape clock
> frequency (i.e. its effectively running on a virtual Tx Escape clock that is
> controlled by counters w/in the controller), but all the interface flops are
> running off the HS clock.
> 
> This has the following drawbacks:
> 
>  * It is a deviation from the PPI spec which assumes signaling is
>running on a physical Escape clock
>  * The PV timings are over constrained (HS timed to 312.5MHz vs.
>an Escape clock of 20MHz max)
> 
> This feature is proposing to change the LP Tx communication between the
> controller and the DPHY from a virtual Tx Escape clock to a physical clock.
> 
> To do this we need to program two "M" divisors. One for the usual
> DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV register and one for
> MIPIO_DWORD8.
> 
> For DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV registers the "M" is calculated
> as following
> 
> Nt = ceil(f_link/160) (theoretical word clock) Nact = max[3, Nt + (Nt + 1)%2]
> (actual word clock) M = Nact * 8
> 
> For MIPIO_DWORD8 register, the divisor "M" is calculated as following
> 
> M = (Nact - 1)/2
> 
> BSpec: 55171
> 
> Cc: Vandita Kulkarni 
> Signed-off-by: Mika Kahola 
> Signed-off-by: Clinton Taylor 
> Signed-off-by: Matt Roper 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 21 +++--
>  drivers/gpu/drm/i915/i915_reg.h|  6 ++
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ce544e20f35c..27251b97f0c3 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -363,10 +363,19 @@ static void gen11_dsi_program_esc_clk_div(struct
> intel_encoder *encoder,
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>   enum port port;
>   int afe_clk_khz;
> - u32 esc_clk_div_m;
> + int theo_word_clk, act_word_clk;
> + u32 esc_clk_div_m, esc_clk_div_m_phy;
> 
>   afe_clk_khz = afe_clk(encoder, crtc_state);
> - esc_clk_div_m = DIV_ROUND_UP(afe_clk_khz, DSI_MAX_ESC_CLK);
> +
> + if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv)) {
> + theo_word_clk = DIV_ROUND_UP(afe_clk_khz, 8 *
> DSI_MAX_ESC_CLK);
> + act_word_clk = max(3, theo_word_clk + (theo_word_clk + 1)
> % 2);
> + esc_clk_div_m = act_word_clk * 8;
> + esc_clk_div_m_phy = (act_word_clk - 1)/2;
> + } else {
> + esc_clk_div_m = DIV_ROUND_UP(afe_clk_khz,
> DSI_MAX_ESC_CLK);
> + }
> 
>   for_each_dsi_port(port, intel_dsi->ports) {
>   intel_de_write(dev_priv, ICL_DSI_ESC_CLK_DIV(port), @@ -
> 379,6 +388,14 @@ static void gen11_dsi_program_esc_clk_div(struct
> intel_encoder *encoder,
>  esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
>   intel_de_posting_read(dev_priv,
> ICL_DPHY_ESC_CLK_DIV(port));
>   }
> +
> + if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv)) {
> + for_each_dsi_port(port, intel_dsi->ports) {
> + intel_de_write(dev_priv, ADL_MIPIO_DW(port, 8),
> +esc_clk_div_m_phy &
> TX_ESC_CLK_DIV_PHY);
> + intel_de_posting_read(dev_priv,
> ADL_MIPIO_DW(port, 8));
> + }
> + }
>  }
> 
>  static void get_dsi_io_power_domains(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 0e7a2616b3cd..2906dff26868
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -11336,6 +11336,12 @@ enum skl_power_gate {
>  #define  ICL_ESC_CLK_DIV_SHIFT   0
>  #define DSI_MAX_ESC_CLK  2   /* in KHz */
> 
> +#define _ADL_MIPIO_REG   0x180
> +#define ADL_MIPIO_DW(port, dw)
>   _MMIO(_ICL_COMBOPHY(port) + _ADL_MIPIO_REG + 4 * (dw))
> +#define   TX_ESC_CLK_DIV_PHY_SEL REGBIT(16)
> +#define   TX_ESC_CLK_DIV_PHY_MASK 

Re: [Intel-gfx] [PATCH] drm/i915: Fix TGL DKL PHY DP vswing handling

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjala 
> Sent: Thursday, October 1, 2020 4:07 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Kulkarni, Vandita ;
> Shankar, Uma 
> Subject: [PATCH] drm/i915: Fix TGL DKL PHY DP vswing handling
> 
> From: Ville Syrjälä 
> 
> The HDMI vs. not-HDMI check got inverted whem the bogus encoder->type
> checks were eliminated. So now we're using 0 as the link rate on DP and
> potentially non-zero on HDMI, which is exactly the opposite of what we
> want. The original bogus check actually worked more correctly by accident
> since if would always evaluate to true. Due to this we now always use the
> RBR/HBR1 vswing table and never ever the HBR2+ vswing table. That is
> probably not a good way to get a high quality signal at HBR2+ rates. Fix the
> check so we pick the right table.
> 
> Cc: sta...@vger.kernel.org
> Cc: Vandita Kulkarni 
> Cc: Uma Shankar 
> Fixes: 94641eb6c696 ("drm/i915/display: Fix the encoder type check")
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Vandita Kulkarni 
I think I missed the inverted change while rebasing.
Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..cdcb7b1034ae 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2742,7 +2742,7 @@ tgl_dkl_phy_ddi_vswing_sequence(struct
> intel_encoder *encoder, int link_clock,
>   u32 n_entries, val, ln, dpcnt_mask, dpcnt_val;
>   int rate = 0;
> 
> - if (type == INTEL_OUTPUT_HDMI) {
> + if (type != INTEL_OUTPUT_HDMI) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> 
>   rate = intel_dp->link_rate;
> --
> 2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for mipi dsi cmd mode (rev15)

[Kulkarni, Vandita]

Hi Lakshmi,
This issue doesn’t seem to be related to this series, can you please check and 
report it if this is not reported.

Thanks,
Vandita

From: Patchwork 
Sent: Monday, September 28, 2020 8:57 PM
To: Kulkarni, Vandita 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for Add support for mipi dsi cmd mode (rev15)

Patch Details
Series:

Add support for mipi dsi cmd mode (rev15)

URL:

https://patchwork.freedesktop.org/series/69290/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/index.html

CI Bug Log - changes from CI_DRM_9062_full -> Patchwork_18581_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_18581_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18581_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_18581_full:

IGT changes
Possible regressions

  *   igt@gem_userptr_blits@process-exit-busy:

 *   shard-skl: NOTRUN -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-skl9/igt@gem_userptr_bl...@process-exit-busy.html>

Known issues

Here are the changes found in Patchwork_18581_full that come from known issues:

IGT changes
Issues hit

  *   igt@kms_big_fb@y-tiled-64bpp-rotate-0:

 *   shard-iclb: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-iclb4/igt@kms_big...@y-tiled-64bpp-rotate-0.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-iclb3/igt@kms_big...@y-tiled-64bpp-rotate-0.html>
 (i915#1982<https://gitlab.freedesktop.org/drm/intel/issues/1982>)

  *   igt@kms_cursor_crc@pipe-a-cursor-suspend:

 *   shard-kbl: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html>
 (i915#180<https://gitlab.freedesktop.org/drm/intel/issues/180>) +2 similar 
issues

  *   igt@kms_cursor_legacy@cursora-vs-flipa-varying-size:

 *   shard-skl: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-skl7/igt@kms_cursor_leg...@cursora-vs-flipa-varying-size.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-skl9/igt@kms_cursor_leg...@cursora-vs-flipa-varying-size.html>
 (i915#1982<https://gitlab.freedesktop.org/drm/intel/issues/1982>) +5 similar 
issues

  *   igt@kms_cursor_legacy@short-flip-before-cursor-toggle:

 *   shard-tglb: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-tglb3/igt@kms_cursor_leg...@short-flip-before-cursor-toggle.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-tglb5/igt@kms_cursor_leg...@short-flip-before-cursor-toggle.html>
 (i915#1982<https://gitlab.freedesktop.org/drm/intel/issues/1982>)

  *   igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:

 *   shard-glk: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html>
 -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html>
 (i915#79<https://gitlab.freedesktop.org/drm/intel/issues/79>)

  *   igt@kms_flip@2x-flip-vs-rmfb@ab-vga1-hdmi-a1:

 *   shard-hsw: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-hsw6/igt@kms_flip@2x-flip-vs-r...@ab-vga1-hdmi-a1.html>
 -> 
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-hsw6/igt@kms_flip@2x-flip-vs-r...@ab-vga1-hdmi-a1.html>
 (i915#1982<https://gitlab.freedesktop.org/drm/intel/issues/1982>)

  *   igt@kms_flip@flip-vs-suspend@c-hdmi-a1:

 *   shard-hsw: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-hsw7/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html>
 -> 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-hsw1/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html>
 (i915#2055<https://gitlab.freedesktop.org/drm/intel/issues/2055>)

  *   igt@perf@polling-parameterized:

 *   shard-skl: 
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-skl1/igt@p...@polling-parameterized.html>
 -> 
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18581/shard-skl8/igt@p...@polling-parameterized.html>
 (i915#1542<https://gitlab.freedesktop.org/drm/intel/issues/1542>)

Possible fixes

  *   igt@gem_fenced_exec_thrash@too-many-fences:

 *   shard-snb: 
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9062/shard-snb5/igt@gem_f

Re: [Intel-gfx] [V14 4/5] drm/i915/dsi: Initiate frame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, September 28, 2020 3:48 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [V14 4/5] drm/i915/dsi: Initiate frame request in cmd mode
> 
> On Thu, Sep 24, 2020 at 06:12:08PM +0530, Vandita Kulkarni wrote:
> > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > frame update request bit.
> > After this  bit is set transcoder hardware will automatically send the
> > frame data to the panel in case of TE NO_GATE mode, where it sends
> > after it receives the TE event in case of TE_GATE mode.
> > Once the frame data is sent to the panel, we see the frame counter
> > updating.
> >
> > v2: Use intel_de_read/write
> >
> > v3: remove the usage of private_flags
> >
> > v4: Use icl_dsi in func names if non static,
> > fix code formatting issues. (Jani)
> >
> > v5: Send frame update request at the beginning of
> > pipe_update_end, use crtc_state mode_flags (Ville)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c  | 26 +
> >  drivers/gpu/drm/i915/display/intel_dsi.h|  1 +
> >  drivers/gpu/drm/i915/display/intel_sprite.c |  7 ++
> >  3 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 2789020e20db..fe946a2e2082 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> *host,
> > return 0;
> >  }
> >
> > +void icl_dsi_frame_update(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);
> > +   u32 tmp, mode_flags;
> > +   enum port port;
> > +
> > +   mode_flags = crtc_state->mode_flags;
> > +
> > +   /*
> > +* case 1 also covers dual link
> > +* In case of dual link, frame update should be set on
> > +* DSI_0
> > +*/
> > +   if (mode_flags & I915_MODE_FLAG_DSI_USE_TE0)
> > +   port = PORT_A;
> > +   else if (mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
> > +   port = PORT_B;
> > +   else
> > +   return;
> > +
> > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > +
> >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > *encoder)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff
> > --git a/drivers/gpu/drm/i915/display/intel_dsi.h
> > b/drivers/gpu/drm/i915/display/intel_dsi.h
> > index 19f78a4022d3..625f2f1ae061 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> > @@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct
> > intel_encoder *encoder)
> >
> >  /* icl_dsi.c */
> >  void icl_dsi_init(struct drm_i915_private *dev_priv);
> > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
> >
> >  /* intel_dsi.c */
> >  int intel_dsi_bitrate(const struct intel_dsi *intel_dsi); diff --git
> > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index 63040cb0d4e1..eaee29e0f535 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -47,6 +47,7 @@
> >  #include "intel_frontbuffer.h"
> >  #include "intel_pm.h"
> >  #include "intel_psr.h"
> > +#include "intel_dsi.h"
> >  #include "intel_sprite.h"
> >
> >  int intel_usecs_to_scanlines(const struct drm_display_mode
> > *adjusted_mode, @@ -202,6 +203,12 @@ void
> intel_pipe_update_end(struct
> > intel_crtc_state *new_crtc_state)
> >
> > trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
> >
> > +   /*
> > +* Incase of mipi dsi command mode, we need to set frame update
> > +* request for every commit.
> > +*/
> > +   icl_dsi_frame_update(new_crtc_state);
> 
> Calling something called icl_dsi_foo() unconditionally from platform agnostic
> code looks confusing. I'd add platform+intel_crtc_has_type() check here.

Ok, sure will add the check.

Thanks
Vandita
> 
> > +
> > /* We're still in the vblank-evade critical section, this can't race.
> >  * Would be slightly nice to just grab the vblank count and arm the
> >  * event outside of the critical section - the spinlock might spin
> > for a
> > --
> > 2.21.0.5.gaeb582a
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, September 23, 2020 4:03 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Wed, Sep 23, 2020 at 10:02:49AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Wednesday, September 23, 2020 3:30 PM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > 
> > > Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd
> > > mode
> > >
> > > On Tue, Sep 22, 2020 at 07:14:25PM +0530, Vandita Kulkarni wrote:
> > > > In TE Gate mode or TE NO_GATE mode on every flip we need to set
> > > > the frame update request bit.
> > > > After this  bit is set transcoder hardware will automatically send
> > > > the frame data to the panel in case of TE NO_GATE mode, where it
> > > > sends after it receives the TE event in case of TE_GATE mode.
> > > > Once the frame data is sent to the panel, we see the frame counter
> > > > updating.
> > > >
> > > > v2: Use intel_de_read/write
> > > >
> > > > v3: remove the usage of private_flags
> > > >
> > > > v4: Use icl_dsi in func names if non static,
> > > > fix code formatting issues. (Jani)
> > > >
> > > > Signed-off-by: Vandita Kulkarni 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26
> 
> > > >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> > > >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> > > >  3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > index 2789020e20db..7d2abc7f6ba3 100644
> > > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct
> > > > intel_dsi_host
> > > *host,
> > > > return 0;
> > > >  }
> > > >
> > > > +void icl_dsi_frame_update(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);
> > > > +   u32 tmp, flags;
> > > > +   enum port port;
> > > > +
> > > > +   flags = crtc->mode_flags;
> > > > +
> > > > +   /*
> > > > +* case 1 also covers dual link
> > > > +* In case of dual link, frame update should be set on
> > > > +* DSI_0
> > > > +*/
> > > > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > > +   port = PORT_A;
> > > > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > > +   port = PORT_B;
> > > > +   else
> > > > +   return;
> > > > +
> > > > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > > +
> > > >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > > *encoder)  {
> > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > diff
> > > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 5a9d933e425a..c4f331f2af45 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -15616,6 +15616,16 @@ static void
> > > > intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > > > intel_set_cdclk_post_plane_update(state);
> > > > }
> > > >
> > > > +   /*
> > > > +* Incase of mipi dsi command mode, we need to set frame update
> > > > +* for every commit
> > > > +*/
> > > > +   for_each_new_intel_crtc_in_state

Re: [Intel-gfx] [V13 5/5] drm/i915/dsi: Enable software vblank counter

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, September 23, 2020 4:05 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
> 
> On Wed, Sep 23, 2020 at 10:16:05AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Wednesday, September 23, 2020 3:30 PM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > 
> > > Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
> > >
> > > On Tue, Sep 22, 2020 at 07:14:26PM +0530, Vandita Kulkarni wrote:
> > > > In case of DSI cmd mode, we get hw vblank counter updated after
> > > > the TE comes in, if we try to read the hw vblank counter in te
> > > > handler we wouldnt have the udpated vblank counter yet.
> > > > This will lead to a state where we would send the vblank event to
> > > > the user space in the next te, though the frame update would have
> > > > completed in the first TE duration itself.
> > > > Hence switch to using software timestamp based vblank counter.
> > > >
> > > > Signed-off-by: Vandita Kulkarni 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> > > >  drivers/gpu/drm/i915/i915_irq.c  |  4 
> > > >  2 files changed, 15 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index c4f331f2af45..8b9e59e52708 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -1808,6 +1808,17 @@ enum pipe intel_crtc_pch_transcoder(struct
> > > > intel_crtc *crtc)  static u32 intel_crtc_max_vblank_count(const
> > > > struct intel_crtc_state *crtc_state)  {
> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(crtc_state->uapi.crtc->dev);
> > > > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > +   u32 flags = crtc->mode_flags;
> > >
> > > That's wrong. You need to look at the crtc_state instead.
> >
> > Thanks,
> > I will use crtc_state.
> 
> I'd also frop the 'flags' variable. Single use so not much point.
> Or at the very least call it 'mode_flags' so we know what it actually is.
Ok, will use mode_flags.

Thanks,
Vandita
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [V13 5/5] drm/i915/dsi: Enable software vblank counter

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, September 23, 2020 3:30 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
> 
> On Tue, Sep 22, 2020 at 07:14:26PM +0530, Vandita Kulkarni wrote:
> > In case of DSI cmd mode, we get hw vblank counter updated after the TE
> > comes in, if we try to read the hw vblank counter in te handler we
> > wouldnt have the udpated vblank counter yet.
> > This will lead to a state where we would send the vblank event to the
> > user space in the next te, though the frame update would have
> > completed in the first TE duration itself.
> > Hence switch to using software timestamp based vblank counter.
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> >  drivers/gpu/drm/i915/i915_irq.c  |  4 
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index c4f331f2af45..8b9e59e52708 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1808,6 +1808,17 @@ enum pipe intel_crtc_pch_transcoder(struct
> > intel_crtc *crtc)  static u32 intel_crtc_max_vblank_count(const struct
> > intel_crtc_state *crtc_state)  {
> > struct drm_i915_private *dev_priv =
> > to_i915(crtc_state->uapi.crtc->dev);
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   u32 flags = crtc->mode_flags;
> 
> That's wrong. You need to look at the crtc_state instead.

Thanks,
I will use crtc_state.

I saw this happening 
crtc->mode_flags = crtc_state->mode_flags;
at intel_crtc_update_active_timings.

Thanks,
-Vandita
> 
> > +
> > +   /*
> > +* From Gen 11, In case of dsi cmd mode, frame counter wouldnt
> > +* have updated at the beginning of TE, if we want to use
> > +* the hw counter, then we would find it updated in only
> > +* the next TE, hence switching to sw counter.
> > +*/
> > +   if (flags & (I915_MODE_FLAG_DSI_USE_TE0 |
> I915_MODE_FLAG_DSI_USE_TE1))
> > +   return 0;
> >
> > /*
> >  * On i965gm the hardware frame counter reads diff --git
> > a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index c2e4b227bdf3..634c60befe7e 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -682,8 +682,12 @@ u32 i915_get_vblank_counter(struct drm_crtc
> > *crtc)
> >  u32 g4x_get_vblank_counter(struct drm_crtc *crtc)  {
> > struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > +   struct drm_vblank_crtc *vblank =
> > +&dev_priv->drm.vblank[drm_crtc_index(crtc)];
> > enum pipe pipe = to_intel_crtc(crtc)->pipe;
> >
> > +   if (!vblank->max_vblank_count)
> > +   return 0;
> > +
> > return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
> >  }
> >
> > --
> > 2.21.0.5.gaeb582a
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, September 23, 2020 3:30 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Tue, Sep 22, 2020 at 07:14:25PM +0530, Vandita Kulkarni wrote:
> > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > frame update request bit.
> > After this  bit is set transcoder hardware will automatically send the
> > frame data to the panel in case of TE NO_GATE mode, where it sends
> > after it receives the TE event in case of TE_GATE mode.
> > Once the frame data is sent to the panel, we see the frame counter
> > updating.
> >
> > v2: Use intel_de_read/write
> >
> > v3: remove the usage of private_flags
> >
> > v4: Use icl_dsi in func names if non static,
> > fix code formatting issues. (Jani)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
> >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> >  3 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 2789020e20db..7d2abc7f6ba3 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> *host,
> > return 0;
> >  }
> >
> > +void icl_dsi_frame_update(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);
> > +   u32 tmp, flags;
> > +   enum port port;
> > +
> > +   flags = crtc->mode_flags;
> > +
> > +   /*
> > +* case 1 also covers dual link
> > +* In case of dual link, frame update should be set on
> > +* DSI_0
> > +*/
> > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > +   port = PORT_A;
> > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > +   port = PORT_B;
> > +   else
> > +   return;
> > +
> > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > +
> >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > *encoder)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5a9d933e425a..c4f331f2af45 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15616,6 +15616,16 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> > intel_set_cdclk_post_plane_update(state);
> > }
> >
> > +   /*
> > +* Incase of mipi dsi command mode, we need to set frame update
> > +* for every commit
> > +*/
> > +   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > +   if (INTEL_GEN(dev_priv) >= 11 &&
> > +   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> > +   if (new_crtc_state->hw.active)
> > +   icl_dsi_frame_update(new_crtc_state);
> > +
> 
> Still the wrong place.
Should I be adding it at the end of pipe update? As we need TE to be enabled 
when we send frame update.

-Thanks
Vandita
> 
> > /* FIXME: We should call drm_atomic_helper_commit_hw_done()
> here
> >  * already, but still need the state for the delayed optimization. To
> >  * fix this:
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
> > b/drivers/gpu/drm/i915/display/intel_dsi.h
> > index 19f78a4022d3..625f2f1ae061 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> > @@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct
> > intel_encoder *encoder)
> >
> >  /* icl_dsi.c */
> >  void icl_dsi_init(struct drm_i915_private *dev_priv);
> > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
> >
> >  /* intel_dsi.c */
> >  int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
> > --
> > 2.21.0.5.gaeb582a
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when validating "4:2:0 only" modes

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915: Use the correct bpp when
> validating "4:2:0 only" modes
> 
> From: Ville Syrjälä 
> 
> When validating a "YCbCr 4:2:0 only" mode we must take into account the
> fact that we're going to be outputting YCbCr
> 4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing the 4:2:0
> downsampling). For YCbCr 4:4:4 the minimum output bpc is 8, for YCbCr 4:2:0
> it'll be half that. The currently hardcoded 6bpc is only correct for RGB 
> 4:4:4,
> which we will never use with these kinds of modes. Figure out what we're
> going to output and use the correct min bpp value to validate whether the
> link has sufficient bandwidth.
> 
> Signed-off-by: Ville Syrjälä 
Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 55 +++--
>  1 file changed, 33 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index aa4801a8123d..54a4b81ea3ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -608,6 +608,37 @@ intel_dp_output_format(struct drm_connector
> *connector,
>   return INTEL_OUTPUT_FORMAT_YCBCR420;
>  }
> 
> +int intel_dp_min_bpp(enum intel_output_format output_format) {
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> + return 6 * 3;
> + else
> + return 8 * 3;
> +}
> +
> +static int intel_dp_output_bpp(enum intel_output_format output_format,
> +int bpp) {
> + /*
> +  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> +  * format of the number of bytes per pixel will be half the number
> +  * of bytes of RGB pixel.
> +  */
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bpp /= 2;
> +
> + return bpp;
> +}
> +
> +static int
> +intel_dp_mode_min_output_bpp(struct drm_connector *connector,
> +  const struct drm_display_mode *mode) {
> + enum intel_output_format output_format =
> + intel_dp_output_format(connector, mode);
> +
> + return intel_dp_output_bpp(output_format,
> +intel_dp_min_bpp(output_format)); }
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -687,7 +718,8 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
>   max_lanes = intel_dp_max_lane_count(intel_dp);
> 
>   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> - mode_rate = intel_dp_link_required(target_clock, 18);
> + mode_rate = intel_dp_link_required(target_clock,
> +
> intel_dp_mode_min_output_bpp(connector, mode));
> 
>   if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
>   return MODE_H_ILLEGAL;
> @@ -2111,19 +2143,6 @@ intel_dp_adjust_compliance_config(struct
> intel_dp *intel_dp,
>   }
>  }
> 
> -static int intel_dp_output_bpp(enum intel_output_format output_format,
> int bpp) -{
> - /*
> -  * bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> -  * format of the number of bytes per pixel will be half the number
> -  * of bytes of RGB pixel.
> -  */
> - if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> - bpp /= 2;
> -
> - return bpp;
> -}
> -
>  /* Optimize link config in order: max bpp, min clock, min lanes */  static 
> int
> intel_dp_compute_link_config_wide(struct intel_dp *intel_dp, @@ -2346,14
> +2365,6 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
>   return 0;
>  }
> 
> -int intel_dp_min_bpp(enum intel_output_format output_format) -{
> - if (output_format == INTEL_OUTPUT_FORMAT_RGB)
> - return 6 * 3;
> - else
> - return 8 * 3;
> -}
> -
>  static int
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min, output}_bpp() from crtc_state

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple intel_dp_{min,
> output}_bpp() from crtc_state
> 
> From: Ville Syrjälä 
> 
> Pass the output_format directly to intel_dp_{min,output}_bpp() rather than
> passing in the crtc_state and digging out the output_format inside the
> functions. This will allow us to reuse the functions for mode validation
> purposes.
> 
> Signed-off-by: Ville Syrjälä 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 15 ---
>  drivers/gpu/drm/i915/display/intel_dp.h |  3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ad9b8b16fadb..aa4801a8123d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2111,14 +2111,14 @@ intel_dp_adjust_compliance_config(struct
> intel_dp *intel_dp,
>   }
>  }
> 
> -static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int
> bpp)
> +static int intel_dp_output_bpp(enum intel_output_format output_format,
> +int bpp)
>  {
>   /*
>* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
>* format of the number of bytes per pixel will be half the number
>* of bytes of RGB pixel.
>*/
> - if (crtc_state->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
>   bpp /= 2;
> 
>   return bpp;
> @@ -2135,7 +2135,7 @@ intel_dp_compute_link_config_wide(struct
> intel_dp *intel_dp,
>   int mode_rate, link_clock, link_avail;
> 
>   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> - int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> + int output_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
> +bpp);
> 
>   mode_rate = intel_dp_link_required(adjusted_mode-
> >crtc_clock,
>  output_bpp);
> @@ -2346,9 +2346,9 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
>   return 0;
>  }
> 
> -int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> +int intel_dp_min_bpp(enum intel_output_format output_format)
>  {
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + if (output_format == INTEL_OUTPUT_FORMAT_RGB)
>   return 6 * 3;
>   else
>   return 8 * 3;
> @@ -2379,7 +2379,7 @@ intel_dp_compute_link_config(struct
> intel_encoder *encoder,
>   limits.min_lane_count = 1;
>   limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> 
> - limits.min_bpp = intel_dp_min_bpp(pipe_config);
> + limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
>   limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
> 
>   if (intel_dp_is_edp(intel_dp)) {
> @@ -2765,7 +2765,8 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   if (pipe_config->dsc.compression_enable)
>   output_bpp = pipe_config->dsc.compressed_bpp;
>   else
> - output_bpp = intel_dp_output_bpp(pipe_config,
> pipe_config->pipe_bpp);
> + output_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
> +  pipe_config->pipe_bpp);
> 
>   intel_link_compute_m_n(output_bpp,
>  pipe_config->lane_count,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 08a1c0aa8b94..a9580d1df35b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -10,6 +10,7 @@
> 
>  #include "i915_reg.h"
> 
> +enum intel_output_format;
>  enum pipe;
>  enum port;
>  struct drm_connector_state;
> @@ -35,7 +36,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
>  struct link_config_limits *limits);  bool
> intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state
> *conn_state); -int intel_dp_min_bpp(const struct intel_crtc_state
> *crtc_state);
> +int intel_dp_min_bpp(enum intel_output_format output_format);
>  bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
>  i915_reg_t dp_reg, enum port port,
>  enum pipe *pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 64d885539e94..6a874b779b1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -130,7 +13

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()

[Kulkarni, Vandita]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, September 18, 2020 3:14 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Extract intel_dp_output_format()
> 
> From: Ville Syrjälä 
> 
> Refactor the output_format calculation into a helper so that we can reuse it
> for mode validation as well.
> 
> Signed-off-by: Ville Syrjälä 

Looks good to me.
Reviewed-by: Vandita Kulkarni 

Thanks,
Vandita
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index bf1e9cf1c0f3..ad9b8b16fadb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -592,6 +592,22 @@ static u8 intel_dp_dsc_get_slice_count(struct
> intel_dp *intel_dp,
>   return 0;
>  }
> 
> +static enum intel_output_format
> +intel_dp_output_format(struct drm_connector *connector,
> +const struct drm_display_mode *mode) {
> + struct intel_dp *intel_dp =
> intel_attached_dp(to_intel_connector(connector));
> + const struct drm_display_info *info = &connector->display_info;
> +
> + if (!drm_mode_is_420_only(info, mode))
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> + if (intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_YCBCR444;
> + else
> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> +}
> +
>  static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
> int hdisplay)
>  {
> @@ -2430,27 +2446,20 @@ intel_dp_compute_link_config(struct
> intel_encoder *encoder,  }
> 
>  static int
> -intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
> -  struct intel_crtc_state *crtc_state,
> +intel_dp_ycbcr420_config(struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)  {
>   struct drm_connector *connector = conn_state->connector;
> - const struct drm_display_info *info = &connector->display_info;
>   const struct drm_display_mode *adjusted_mode =
>   &crtc_state->hw.adjusted_mode;
> 
>   if (!connector->ycbcr_420_allowed)
>   return 0;
> 
> - if (!drm_mode_is_420_only(info, adjusted_mode))
> - return 0;
> + crtc_state->output_format = intel_dp_output_format(connector,
> +adjusted_mode);
> 
> - if (intel_dp->dfp.ycbcr_444_to_420) {
> - crtc_state->output_format =
> INTEL_OUTPUT_FORMAT_YCBCR444;
> + if (crtc_state->output_format !=
> INTEL_OUTPUT_FORMAT_YCBCR420)
>   return 0;
> - }
> -
> - crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> 
>   return intel_pch_panel_fitting(crtc_state, conn_state);  } @@ -
> 2710,8 +2719,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   if (lspcon->active)
>   lspcon_ycbcr420_config(&intel_connector->base,
> pipe_config);
>   else
> - ret = intel_dp_ycbcr420_config(intel_dp, pipe_config,
> -conn_state);
> + ret = intel_dp_ycbcr420_config(pipe_config, conn_state);
>   if (ret)
>   return ret;
> 
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, September 17, 2020 6:08 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B 
> S,
> Karthik 
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Thu, Sep 17, 2020 at 11:56:44AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Thursday, September 17, 2020 5:01 PM
> > > To: Kulkarni, Vandita 
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > ; B S, Karthik 
> > > Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd
> > > mode
> > >
> > > On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> > > > In TE Gate mode or TE NO_GATE mode on every flip we need to set
> > > > the frame update request bit.
> > > > After this  bit is set transcoder hardware will automatically send
> > > > the frame data to the panel in case of TE NO_GATE mode, where it
> > > > sends after it receives the TE event in case of TE_GATE mode.
> > > > Once the frame data is sent to the panel, we see the frame counter
> > > > updating.
> > > >
> > > > v2: Use intel_de_read/write
> > > >
> > > > v3: remove the usage of private_flags
> > > >
> > > > v4: Use icl_dsi in func names if non static,
> > > > fix code formatting issues. (Jani)
> > > >
> > > > Signed-off-by: Vandita Kulkarni 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26
> 
> > > >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> > > >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> > > >  3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > index 2789020e20db..7d2abc7f6ba3 100644
> > > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct
> > > > intel_dsi_host
> > > *host,
> > > > return 0;
> > > >  }
> > > >
> > > > +void icl_dsi_frame_update(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);
> > > > +   u32 tmp, flags;
> > > > +   enum port port;
> > > > +
> > > > +   flags = crtc->mode_flags;
> > > > +
> > > > +   /*
> > > > +* case 1 also covers dual link
> > > > +* In case of dual link, frame update should be set on
> > > > +* DSI_0
> > > > +*/
> > > > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > > +   port = PORT_A;
> > > > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > > +   port = PORT_B;
> > > > +   else
> > > > +   return;
> > > > +
> > > > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > > +
> > > >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > > *encoder)  {
> > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > diff
> > > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index f862403388f6..11a20bf2255f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -15621,6 +15621,16 @@ static void
> > > > intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > > > intel_set_cdclk_post_plane_update(state);
> > > > }
> > > >
> > > > +   /*
> > > > +* Incase of mipi dsi command mode, we need to set frame update
> > > > +* for every commit
> > > > +*/
> > > > +   for_each_new_int

Re: [Intel-gfx] [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, September 17, 2020 5:01 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; B 
> S,
> Karthik 
> Subject: Re: [V12 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Wed, Sep 16, 2020 at 09:45:28PM +0530, Vandita Kulkarni wrote:
> > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > frame update request bit.
> > After this  bit is set transcoder hardware will automatically send the
> > frame data to the panel in case of TE NO_GATE mode, where it sends
> > after it receives the TE event in case of TE_GATE mode.
> > Once the frame data is sent to the panel, we see the frame counter
> > updating.
> >
> > v2: Use intel_de_read/write
> >
> > v3: remove the usage of private_flags
> >
> > v4: Use icl_dsi in func names if non static,
> > fix code formatting issues. (Jani)
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
> >  drivers/gpu/drm/i915/display/intel_display.c | 10 
> >  drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
> >  3 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 2789020e20db..7d2abc7f6ba3 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> *host,
> > return 0;
> >  }
> >
> > +void icl_dsi_frame_update(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);
> > +   u32 tmp, flags;
> > +   enum port port;
> > +
> > +   flags = crtc->mode_flags;
> > +
> > +   /*
> > +* case 1 also covers dual link
> > +* In case of dual link, frame update should be set on
> > +* DSI_0
> > +*/
> > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > +   port = PORT_A;
> > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > +   port = PORT_B;
> > +   else
> > +   return;
> > +
> > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > +
> >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > *encoder)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f862403388f6..11a20bf2255f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> > intel_set_cdclk_post_plane_update(state);
> > }
> >
> > +   /*
> > +* Incase of mipi dsi command mode, we need to set frame update
> > +* for every commit
> > +*/
> > +   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > +   if (INTEL_GEN(dev_priv) >= 11 &&
> > +   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> > +   if (new_crtc_state->hw.active)
> > +   icl_dsi_frame_update(new_crtc_state);
> 
> If this is the thing that triggers the update then it should probably be 
> called at
> the start of intel_pipe_update_end().

I could move it to the end of intel_pipe_update_end, as we need TE to be 
enabled.
Because if the frame updates are gated then, the dsi controller will not drive 
the vblank/ frame start to the display engine
until it receives a TE in the presence of the frame update request.
And if we are in non gated mode then the dsi controller will immediately drive 
the vblank/frame strart as soon as it receives the
frame update request.

So is it ok if I move it to the end of pipe_update_end..

Thanks,
Vandita
> 
> > +
> > /* FIXME: We should call drm_atomic_helper_commit_hw_done()
> here
> >  * already, but still need the state for the delayed optimization. To
> >  * fix this:
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
> > b/drivers/gpu/drm/i915/display/intel_dsi.h
> > index 19f78a4022d3..625f2f1ae061 10064

Re: [Intel-gfx] [V9 4/4] drm/i915/dsi: Initiate fame request in cmd mode

[Kulkarni, Vandita]

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, September 15, 2020 5:36 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; B S, Karthik ;
> Kulkarni, Vandita 
> Subject: Re: [V9 4/4] drm/i915/dsi: Initiate fame request in cmd mode
> 
> On Wed, 09 Sep 2020, Vandita Kulkarni  wrote:
> > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > frame update request bit.
> > After this  bit is set transcoder hardware will automatically send the
> > frame data to the panel in case of TE NO_GATE mode, where it sends
> > after it receives the TE event in case of TE_GATE mode.
> > Once the frame data is sent to the panel, we see the frame counter
> > updating.
> >
> > v2: Use intel_de_read/write
> >
> > v3: remove the usage of private_flags
> >
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
> >  drivers/gpu/drm/i915/display/intel_display.c | 13 ++
> >  drivers/gpu/drm/i915/display/intel_dsi.h |  3 +++
> >  3 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index ee3c5c085cd3..cdc9d8874945 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> *host,
> > return 0;
> >  }
> >
> > +void gen11_dsi_frame_update(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);
> > +   u32 tmp, flags;
> > +   enum port port;
> > +
> > +   flags = crtc->mode_flags;
> > +
> > +   /*
> > +* case 1 also covers dual link
> > +* In case of dual link, frame update should be set on
> > +* DSI_0
> > +*/
> > +   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > +   port = PORT_A;
> > +   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > +   port = PORT_B;
> > +   else
> > +   return;
> > +
> > +   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > +   tmp |= DSI_FRAME_UPDATE_REQUEST;
> > +   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > +
> >  static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > *encoder)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index ec148a8da2c2..cd852c24d3bc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15615,6 +15615,18 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> > intel_set_cdclk_post_plane_update(state);
> > }
> >
> > +   /*
> > +* Incase of mipi dsi command mode, we need to set frame update
> > +* for every commit
> > +*/
> > +   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > +   if ((INTEL_GEN(dev_priv) >= 11) &&
> > +   (intel_crtc_has_type(new_crtc_state,
> INTEL_OUTPUT_DSI))) {
> 
> Excessive parens.
> 
> > +   if (new_crtc_state->hw.active)
> > +   gen11_dsi_frame_update(new_crtc_state);
> > +   }
> > +   }
> > +
> > /* FIXME: We should call drm_atomic_helper_commit_hw_done()
> here
> >  * already, but still need the state for the delayed optimization. To
> >  * fix this:
> > @@ -15626,6 +15638,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> >  */
> > drm_atomic_helper_wait_for_flip_done(dev, &state->base);
> >
> > +
> 
> Superfluous blank line.
> 
> > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > if (new_crtc_state->hw.active &&
> > !needs_modeset(new_crtc_state) && diff --git
> > a/drivers/gpu/drm/i915/display/intel_dsi.h
> > b/drivers/gpu/drm/i915/display/intel_dsi.h
> > index 19f78a4022d3..08f1f586eefb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> > @@ -205,6 +205,9 @@ u32 bxt_dsi_get_pclk(struct intel_encod

Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

[Kulkarni, Vandita]

> -Original Message-
> From: Michel Dänzer 
> Sent: Wednesday, July 29, 2020 1:04 PM
> To: Kulkarni, Vandita ; Zanoni, Paulo R
> ; Vetter, Daniel ; B S,
> Karthik ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma
> ; nicholas.kazlaus...@amd.com
> Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
> 
> On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
> >
> > On async flips, there needs to be some clarity/guideline on the
> > behaviour and event expectation from the driver by user space.
> > Here are few assumptions that we have, 1. Our understanding is that
> > the user space doesn’t expect the timestamp for async flips (but still
> > expects vblank timestamp) , or doesn’t do anything with that, same is the
> assumption wrt the flip sequence, please correct us if we are wrong.
> > 2. In the sequence the user space still expects the counter that marks
> vblanks.
> > 3. The user space can use different event types like DRM_EVENT_VBLANK
> > or DRM_EVENT_FLIP_COMPLETE for getting the corresponding event. And
> their designs are still aligned to this even in case of async.
> >
> > If there are any more expectations from the user space wrt to the
> > event that is being sent from the driver in case of async flip, please let 
> > us
> know.
> >
> > If the user space doesn’t care much about the flip sequence then, we
> > can just not do anything like returning the flip counter like this version 
> > is
> doing and just stick to returning of the frame counter value(which marks
> vblanks).
> 
> There's no such thing as a "flip sequence" in the KMS API. There's only the
> per-CRTC vblank counter. Each flip completion event needs to contain the
> value of that counter when the hardware completed the flip, regardless of
> whether it was an async flip or not.
> 
> As for the timestamp in the event, I'm not sure what the expectations are for
> async flips, but I suspect it may not really matter. E.g. the timestamp
> calculated to correspond to the end of the previous vertical blank period
> might be fine.

Thanks Michel, Paulo, Daniel, Nicholas, Ville for your inputs.
After all the discussions, looks like the async flip time stamp is not of much
use to the userspace and the async flip sequence; hence we will stick to the 
approach of sending vblank time stamp
itself and have a test case in the igt to cover the async flips cases in a 
slightly different way.
And update the documentation.

Thanks,
Vandita
> 
> 
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

[Kulkarni, Vandita]

> -Original Message-
> From: Zanoni, Paulo R 
> Sent: Saturday, July 25, 2020 4:56 AM
> To: B S, Karthik ; intel-gfx@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Vetter, Daniel ;
> Kulkarni, Vandita ;
> nicholas.kazlaus...@amd.com; harry.wentl...@amd.com; Shankar, Uma
> ; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
> 
> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> > Without async flip support in the kernel, fullscreen apps where game
> > resolution is equal to the screen resolution, must perform an extra
> > blit per frame prior to flipping.
> >
> > Asynchronous page flips will also boost the FPS of Mesa benchmarks.
> 
> We had a discussion in patch 1 of v3 regarding the semantics of asynchronous
> flips from the point of view of the user space: how we handle our vblank
> counters, how/when we increment the sequence events and how we
> handle timestamps, how/when we deliver vblank events. Since apparently
> AMD has already enabled this feature, our job would be to implement their
> current behavior so KMS clients can continue to work regardless of the
> driver.
Thanks for your comments Paulo.

On V3 patch1, yes there were comments with this regard.
But seems like we did not coclude on few of the things. There were comments 
from Ville on how we could implement
the timestamping for async flips and that is part of this version.
Also we heard from Nicholas in their driver the time stamp is not mapping to 
the scan out as it happens immediately.

On async flips, there needs to be some clarity/guideline on the behaviour and 
event expectation from the
driver by user space.
Here are few assumptions that we have,
1. Our understanding is that the user space doesn’t expect the timestamp for 
async flips (but still expects vblank timestamp) , or
doesn’t do anything with that, same is the assumption wrt the flip sequence, 
please correct us if we are wrong.
2. In the sequence the user space still expects the counter that marks vblanks.
3. The user space can use different event types like DRM_EVENT_VBLANK or 
DRM_EVENT_FLIP_COMPLETE
for getting the corresponding event. And their designs are still aligned to 
this even in case of async.

If there are any more expectations from the user space wrt to the event that is 
being sent from the
driver in case of async flip, please let us know.

If the user space doesn’t care much about the flip sequence then, we can just 
not do anything like returning
the flip counter like this version is doing and just stick to returning of the 
frame counter value(which marks vblanks).

Based on these, we can tune the current implementation
which right now sends the flip time stamp in case of async flips.

Thanks,
Vandita
> 
> From reading this series it's not super clear to me what exactly is the
> behavior that we're trying to follow. Can you please document somewhere
> what are these rules and expectations? This way, people writing user space
> code (or people improving the other drivers) will have an easier time. In
> addition to text documentation, I believe all our assumptions and rules
> should be coded in IGT: we want to be confident a driver implements async
> page flips correctly when we can verify it passes the IGT.
> 
> Also, in the other patches I raise some additional questions regarding mixing
> async with non-async vblanks: IMHO this should also be documented as text
> and as IGT.
> 
> >
> > v2: -Few patches have been squashed and patches have been shuffled as
> >  per the reviews on the previous version.
> >
> > v3: -Few patches have been squashed and patches have been shuffled as
> >  per the reviews on the previous version.
> >
> > v4: -Made changes to fix the sequence and time stamp issue as per the
> >  comments received on the previous version.
> > -Timestamps are calculated using the flip done time stamp and current
> >  timestamp. Here
> I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used
> >  for timestamp calculations.
> > -Event is sent from the interrupt handler immediately using this
> >  updated timestamps and sequence.
> > -Added more state checks as async flip should only allow change in plane
> >  surface address and nothing else should be allowed to change.
> > -Added a separate plane hook for async flip.
> > -Need to find a way to reject fbc enabling if it comes as part of this
> >  flip as bspec states that changes to FBC are not allowed.
> >
> > v5: -Fixed the Checkpatch and sparse warnings.
> >
> > Karthik B S (5):
> >   drm/i915: Add enable/disable flip done and flip done handler
> >   drm/i915: Add support for async f

Re: [Intel-gfx] [PATCH RESEND 6/7] drm/i915/bios: fill in DSC rc_model_size from VBT

[Kulkarni, Vandita]

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Nikula, Jani ; Navare, Manasi D
> ; Kulkarni, Vandita 
> Subject: [PATCH RESEND 6/7] drm/i915/bios: fill in DSC rc_model_size from
> VBT
> 
> The VBT fields match the DPCD data, so use the same helper.
> 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 839124647202..a4ea0e6c3286 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2494,16 +2494,11 @@ static void fill_dsc(struct intel_crtc_state
> *crtc_state,
> crtc_state->dsc.slice_count);
> 
>   /*
> -  * FIXME: Use VBT rc_buffer_block_size and rc_buffer_size for the
> -  * implementation specific physical rate buffer size. Currently we use
> -  * the required rate buffer model size calculated in
> -  * drm_dsc_compute_rc_parameters() according to VESA DSC Annex E.
> -  *
>* The VBT rc_buffer_block_size and rc_buffer_size definitions
> -  * correspond to DP 1.4 DPCD offsets 0x62 and 0x63. The DP DSC
> -  * implementation should also use the DPCD (or perhaps VBT for eDP)
> -  * provided value for the buffer size.
> +  * correspond to DP 1.4 DPCD offsets 0x62 and 0x63.
>*/
> + vdsc_cfg->rc_model_size = drm_dsc_dp_rc_buffer_size(dsc-
> >rc_buffer_block_size,
> + dsc-
> >rc_buffer_size);
Do we need to handle the invalid case here?

Regards
Vandita

> 
>   /* FIXME: DSI spec says bpc + 1 for this one */
>   vdsc_cfg->line_buf_depth = VBT_DSC_LINE_BUFFER_DEPTH(dsc-
> >line_buffer_depth);
> --
> 2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 4/7] drm/i915/dsc: configure hardware using specified rc_model_size

[Kulkarni, Vandita]

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Nikula, Jani ; Navare, Manasi D
> ; Kulkarni, Vandita 
> Subject: [PATCH RESEND 4/7] drm/i915/dsc: configure hardware using
> specified rc_model_size
> 
> The rc_model_size is specified in the DSC config, and the hardware
> programming should respect that instead of hard coding a value of 8192.
> 
> Regardless, the rc_model_size in DSC config is currently hard coded to the
> same value, so this should have no impact, other than allowing the use of 
> other
> sizes as needed.
> 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 

Looks good to me.
Reviewed-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 95ad87d4ccb3..1f74b0174b1a 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -740,7 +740,7 @@ static void intel_dsc_pps_configure(struct
> intel_encoder *encoder,
> 
>   /* Populate PICTURE_PARAMETER_SET_9 registers */
>   pps_val = 0;
> - pps_val |= DSC_RC_MODEL_SIZE(DSC_RC_MODEL_SIZE_CONST) |
> + pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
>   DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
>   drm_info(&dev_priv->drm, "PPS9 = 0x%08x\n", pps_val);
>   if (!is_pipe_dsc(crtc_state)) {
> --
> 2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 2/7] drm/dsc: add helper for calculating rc buffer size from DPCD

[Kulkarni, Vandita]

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Nikula, Jani ; Alex Deucher
> ; Harry Wentland ; Navare,
> Manasi D ; Kulkarni, Vandita
> 
> Subject: [PATCH RESEND 2/7] drm/dsc: add helper for calculating rc buffer size
> from DPCD
> 
> Add a helper for calculating the rc buffer size from the DCPD offsets
> DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
> 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 

Looks good to me.
Reviewed-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/drm_dsc.c | 27 +++
>  include/drm/drm_dsc.h |  1 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c index
> 09afbc01ea94..ff602f7ec65b 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -49,6 +49,33 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header)  }  EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
> 
> +/**
> + * drm_dsc_dp_rc_buffer_size - get rc buffer size in bytes
> + * @rc_buffer_block_size: block size code, according to DPCD offset 62h
> + * @rc_buffer_size: number of blocks - 1, according to DPCD offset 63h
> + *
> + * return:
> + * buffer size in bytes, or 0 on invalid input  */ int
> +drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size) {
> + int size = 1024 * (rc_buffer_size + 1);
> +
> + switch (rc_buffer_block_size) {
> + case DP_DSC_RC_BUF_BLK_SIZE_1:
> + return 1 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_4:
> + return 4 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_16:
> + return 16 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_64:
> + return 64 * size;
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dsc_dp_rc_buffer_size);
> +
>  /**
>   * drm_dsc_pps_payload_pack() - Populates the DSC PPS
>   *
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h index
> 887954cbfc60..537a68330840 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -602,6 +602,7 @@ struct drm_dsc_pps_infoframe {  } __packed;
> 
>  void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> +int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8
> +rc_buffer_size);
>  void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
> *pps_sdp,
>   const struct drm_dsc_config *dsc_cfg);  int
> drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
> --
> 2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 1/7] drm/dsc: use rc_model_size from DSC config for PPS

[Kulkarni, Vandita]

> -Original Message-
> From: Jani Nikula 
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Nikula, Jani ; Alex Deucher
> ; Harry Wentland ; Navare,
> Manasi D ; Kulkarni, Vandita
> 
> Subject: [PATCH RESEND 1/7] drm/dsc: use rc_model_size from DSC config for
> PPS
> 
> The PPS is supposed to reflect the DSC config instead of hard coding the
> rc_model_size. Make it so.
> 
> Currently all users of drm_dsc_pps_payload_pack() hard code the size to
> 8192 also in the DSC config, so this change should have no impact, other than
> allowing the drivers to use other sizes as needed.
> 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 

Looks good to me.
Reviewed-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/drm_dsc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c index
> 4a475d9696ff..09afbc01ea94 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -186,8 +186,7 @@ void drm_dsc_pps_payload_pack(struct
> drm_dsc_picture_parameter_set *pps_payload,
>   pps_payload->flatness_max_qp = dsc_cfg->flatness_max_qp;
> 
>   /* PPS 38, 39 */
> - pps_payload->rc_model_size =
> - cpu_to_be16(DSC_RC_MODEL_SIZE_CONST);
> + pps_payload->rc_model_size = cpu_to_be16(dsc_cfg->rc_model_size);
> 
>   /* PPS 40 */
>   pps_payload->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
> --
> 2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx