RE: [PATCH 22/22] drm/i915: Use debugfs_create_bool() for "i915_bigjoiner_force_enable"

2024-04-02 Thread Srinivas, Vidya
Hello Ville, Thank you very much for the series. 6K detects fine and works.
Tested-by: Vidya Srinivas 

> -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 22/22] drm/i915: Use debugfs_create_bool() for
> "i915_bigjoiner_force_enable"
> 
> From: Ville Syrjälä 
> 
> There is no reason to make this debugfs file for a simple boolean so
> complicated. Just use debugfs_create_bool().
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 44 +--
>  1 file changed, 2 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index b99c024b0934..3e364891dcd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1402,20 +1402,6 @@ out:   drm_modeset_unlock(
> >drm.mode_config.connection_mutex);
>   return ret;
>  }
> 
> -static int i915_bigjoiner_enable_show(struct seq_file *m, void *data) -{
> - struct intel_connector *connector = m->private;
> - struct drm_crtc *crtc;
> -
> - crtc = connector->base.state->crtc;
> - if (connector->base.status != connector_status_connected || !crtc)
> - return -ENODEV;
> -
> - seq_printf(m, "Bigjoiner enable: %d\n", connector-
> >force_bigjoiner_enable);
> -
> - return 0;
> -}
> -
>  static ssize_t i915_dsc_output_format_write(struct file *file,
>   const char __user *ubuf,
>   size_t len, loff_t *offp)
> @@ -1437,30 +1423,6 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
>   return len;
>  }
> 
> -static ssize_t i915_bigjoiner_enable_write(struct file *file,
> -const char __user *ubuf,
> -size_t len, loff_t *offp)
> -{
> - struct seq_file *m = file->private_data;
> - struct intel_connector *connector = m->private;
> - struct drm_crtc *crtc;
> - bool bigjoiner_en = 0;
> - int ret;
> -
> - crtc = connector->base.state->crtc;
> - if (connector->base.status != connector_status_connected || !crtc)
> - return -ENODEV;
> -
> - ret = kstrtobool_from_user(ubuf, len, _en);
> - if (ret < 0)
> - return ret;
> -
> - connector->force_bigjoiner_enable = bigjoiner_en;
> - *offp += len;
> -
> - return len;
> -}
> -
>  static int i915_dsc_output_format_open(struct inode *inode,
>  struct file *file)
>  {
> @@ -1554,8 +1516,6 @@ static const struct file_operations
> i915_dsc_fractional_bpp_fops = {
>   .write = i915_dsc_fractional_bpp_write  };
> 
> -DEFINE_SHOW_STORE_ATTRIBUTE(i915_bigjoiner_enable);
> -
>  /*
>   * Returns the Current CRTC's bpc.
>   * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> @@ -1640,8 +1600,8 @@ void intel_connector_debugfs_add(struct
> intel_connector *connector)
>   if (DISPLAY_VER(i915) >= 11 &&
>   (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>connector_type == DRM_MODE_CONNECTOR_eDP)) {
> - debugfs_create_file("i915_bigjoiner_force_enable", 0644,
> root,
> - connector, _bigjoiner_enable_fops);
> + debugfs_create_bool("i915_bigjoiner_force_enable", 0644,
> root,
> + >force_bigjoiner_enable);
>   }
> 
>   if (connector_type == DRM_MODE_CONNECTOR_DSI ||
> --
> 2.43.2



RE: [PATCH 5/6] drm/i915: Handle joined pipes inside hsw_crtc_enable()

2024-03-25 Thread Srinivas, Vidya
Thank you Stan. Rev 14 works.
Tested-by: Vidya Srinivas 

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Wednesday, March 20, 2024 8:45 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav ; Saarinen, Jani
> ; ville.syrj...@linux.intel.com; Srinivas, Vidya
> 
> Subject: [PATCH 5/6] drm/i915: Handle joined pipes inside hsw_crtc_enable()
> 
> Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
> slave crtcs should be handled by master hooks. Same for encoders.
> That way we can also remove a bunch of checks like
> intel_crtc_is_bigjoiner_slave.
> 
> v2: - Moved skl_pfit_enable, intel_dsc_enable, intel_crtc_vblank_on to
> intel_enable_ddi,
>   so that it is now finally symmetrical with the disable case, because
> currently
>   for some weird reason we are calling those from
> skl_commit_modeset_enables, while
>   for the disable case those are called from the ddi disable hooks.
> 
> v3: - Create intel_ddi_enable_hdmi_or_sst symmetrical to
>   intel_ddi_post_disable_hdmi_or_sst and move it also under non-mst
> check.
> 
> v4: - Fix intel_enable_ddi sequence
> - Call intel_crtc_update_active_timings for slave pipes as well
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c |  45 -
>  drivers/gpu/drm/i915/display/intel_display.c | 179 ++-
>  drivers/gpu/drm/i915/display/intel_display.h |   7 +
>  3 files changed, 137 insertions(+), 94 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 290ccab7c9ee8..9128b82a49c31 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3366,15 +3366,28 @@ static void intel_enable_ddi_hdmi(struct
> intel_atomic_state *state,
>   intel_wait_ddi_buf_active(dev_priv, port);  }
> 
> -static void intel_enable_ddi(struct intel_atomic_state *state,
> -  struct intel_encoder *encoder,
> -  const struct intel_crtc_state *crtc_state,
> -  const struct drm_connector_state *conn_state)
> +static void intel_ddi_enable_hdmi_or_sst(struct intel_atomic_state *state,
> +  struct intel_encoder *encoder,
> +  const struct intel_crtc_state
> *crtc_state,
> +  const struct drm_connector_state
> *conn_state)
>  {
> - drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + u8 pipe_mask = intel_crtc_joined_pipe_mask(crtc_state);
> + struct intel_crtc *crtc;
> +
> + for_each_intel_crtc_in_pipe_mask_reverse(>drm, crtc,
> pipe_mask) {
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> +
> + intel_dsc_enable(new_crtc_state);
> +
> + if (DISPLAY_VER(i915) >= 9)
> + skl_pfit_enable(new_crtc_state);
> + else
> + ilk_pfit_enable(new_crtc_state);
> + }
> 
> - if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> - intel_ddi_enable_transcoder_func(encoder, crtc_state);
> + intel_ddi_enable_transcoder_func(encoder, crtc_state);
> 
>   /* Enable/Disable DP2.0 SDP split config before transcoder */
>   intel_audio_sdp_split_update(crtc_state);
> @@ -3383,7 +3396,22 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> 
>   intel_ddi_wait_for_fec_status(encoder, crtc_state, true);
> 
> - intel_crtc_vblank_on(crtc_state);
> + for_each_intel_crtc_in_pipe_mask_reverse(>drm, crtc,
> pipe_mask) {
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + intel_crtc_vblank_on(new_crtc_state);
> + }
> +}
> +
> +static void intel_enable_ddi(struct intel_atomic_state *state,
> +  struct intel_encoder *encoder,
> +  const struct intel_crtc_state *crtc_state,
> +  const struct drm_connector_state *conn_state) {
> + drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> +
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> + intel_ddi_enable_hdmi_or_sst(state, encoder, crtc_state,
> conn_state);
> 
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>   intel_enable_ddi_hdmi(state, encoder, crtc_state,
> conn_state); @

RE: [PATCH v2 8/8] drm/i915: Handle joined pipes inside hsw_crtc_disable()

2024-03-03 Thread Srinivas, Vidya
Thank you very much Ville and Stan.
With https://patchwork.freedesktop.org/series/130619/ and 
https://patchwork.freedesktop.org/series/130449/ tested that 6K works
Tested-by: Vidya Srinivas 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 1, 2024 10:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav 
> Subject: [PATCH v2 8/8] drm/i915: Handle joined pipes inside
> hsw_crtc_disable()
> 
> From: Ville Syrjälä 
> 
> Reorganize the crtc disable path to only deal with the master
> pipes/transcoders in intel_old_crtc_state_disables() and offload the handling
> of joined pipes to hsw_crtc_disable().
> This makes the whole thing much more sensible since we can actually control
> the order in which we do the per-pipe vs.
> per-transcoder modeset steps.
> 
> v2: Pass the correct crtc pointer to .crtc_disable()
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 66 
>  1 file changed, 39 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1df3923cc30d..e01536983303 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1793,29 +1793,27 @@ static void hsw_crtc_disable(struct
> intel_atomic_state *state,
>   const struct intel_crtc_state *old_master_crtc_state =
>   intel_atomic_get_old_crtc_state(state, master_crtc);
>   struct drm_i915_private *i915 = to_i915(master_crtc->base.dev);
> + u8 pipe_mask = intel_crtc_joined_pipe_mask(old_master_crtc_state);
> + struct intel_crtc *crtc;
> 
>   /*
>* FIXME collapse everything to one hook.
>* Need care with mst->ddi interactions.
>*/
> - if (!intel_crtc_is_bigjoiner_slave(old_master_crtc_state)) {
> - intel_encoders_disable(state, master_crtc);
> - intel_encoders_post_disable(state, master_crtc);
> - }
> -
> - intel_disable_shared_dpll(old_master_crtc_state);
> + intel_encoders_disable(state, master_crtc);
> + intel_encoders_post_disable(state, master_crtc);
> 
> - if (!intel_crtc_is_bigjoiner_slave(old_master_crtc_state)) {
> - struct intel_crtc *slave_crtc;
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> 
> - intel_encoders_post_pll_disable(state, master_crtc);
> + intel_disable_shared_dpll(old_crtc_state);
> + }
> 
> - intel_dmc_disable_pipe(i915, master_crtc->pipe);
> + intel_encoders_post_pll_disable(state, master_crtc);
> 
> - for_each_intel_crtc_in_pipe_mask(>drm, slave_crtc,
> -
> intel_crtc_bigjoiner_slave_pipes(old_master_crtc_state))
> - intel_dmc_disable_pipe(i915, slave_crtc->pipe);
> - }
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask)
> + intel_dmc_disable_pipe(i915, crtc->pipe);
>  }
> 
>  static void i9xx_pfit_enable(const struct intel_crtc_state *crtc_state) @@ -
> 6753,24 +6751,33 @@ static void intel_update_crtc(struct intel_atomic_state
> *state,  }
> 
>  static void intel_old_crtc_state_disables(struct intel_atomic_state *state,
> -   struct intel_crtc *crtc)
> +   struct intel_crtc *master_crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - const struct intel_crtc_state *new_crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> + const struct intel_crtc_state *old_master_crtc_state =
> + intel_atomic_get_old_crtc_state(state, master_crtc);
> + u8 pipe_mask = intel_crtc_joined_pipe_mask(old_master_crtc_state);
> + struct intel_crtc *crtc;
> 
>   /*
>* We need to disable pipe CRC before disabling the pipe,
>* or we race against vblank off.
>*/
> - intel_crtc_disable_pipe_crc(crtc);
> + for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask)
> + intel_crtc_disable_pipe_crc(crtc);
> 
> - dev_priv->display.funcs.display->crtc_disable(state, crtc);
> - crtc->active = false;
> - intel_fbc_disable(crtc);
> + dev_priv->display.funcs.display->crtc_disable(state, master_crtc);
> 
> - if (!new_crtc_state->hw.active)
> - intel_initial_watermarks(state, crtc);
> + for_each_intel_crtc_in_pipe_mask(_priv->drm, crtc, pipe_mask)
> {
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> +
> + crtc->active = false;
> + intel_fbc_disable(crtc);
> +
> + if (!new_crtc_state->hw.active)
> + intel_initial_watermarks(state, crtc);
> + }

RE: [PATCH 1/2] Revert "drm/i915/mst: Reject modes that require the bigjoiner"

2024-02-28 Thread Srinivas, Vidya



> -Original Message-
> From: Jani Nikula 
> Sent: Wednesday, February 28, 2024 2:39 PM
> To: Srinivas, Vidya ; 
> intel-gfx@lists.freedesktop.org
> Cc: Almahallawy, Khaled ; Srinivas, Vidya
> 
> Subject: Re: [PATCH 1/2] Revert "drm/i915/mst: Reject modes that require the
> bigjoiner"
> 
> On Tue, 27 Feb 2024, Vidya Srinivas  wrote:
> > This reverts commit 9c058492b16f90bb772cb0dad567e8acc68e155d.
> >
> > Reverting for adding MST bigjoiner functionality.
> 
> Please squash this together with the fix. Someone might think a revert is a 
> fix
> that needs to be backported. Besides, for bisection this creates a non-working
> commit.

Hello Jani

Thank you very much. Sure, I will squash it together with the fix and submit.

Regards
Vidya

> 
> BR,
> Jani.
> 
> 
> >
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index db1254b036f1..b062f4ee6c8b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -1349,10 +1349,6 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
> > if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
> > bigjoiner = true;
> > max_dotclk *= 2;
> > -
> > -   /* TODO: add support for bigjoiner */
> > -   *status = MODE_CLOCK_HIGH;
> > -   return 0;
> > }
> >
> > if (DISPLAY_VER(dev_priv) >= 10 &&
> 
> --
> Jani Nikula, Intel


RE: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0

2024-02-27 Thread Srinivas, Vidya



> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, February 27, 2024 2:44 PM
> To: Srinivas, Vidya 
> Cc: Jani Nikula ; 
> intel-gfx@lists.freedesktop.org;
> Saarinen, Jani ; ville.syrj...@linux.intel.com
> Subject: Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
> 
> On Tue, Feb 27, 2024 at 11:06:16AM +0200, Srinivas, Vidya wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav 
> > > Sent: Tuesday, February 27, 2024 2:34 PM
> > > To: Jani Nikula 
> > > Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani
> > > ; ville.syrj...@linux.intel.com; Srinivas,
> > > Vidya 
> > > Subject: Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
> > >
> > > On Mon, Feb 26, 2024 at 09:56:10PM +0200, Jani Nikula wrote:
> > > > On Wed, 21 Feb 2024, Stanislav Lisovskiy
> > > > 
> > > wrote:
> > > > > Patch calculates bigjoiner pipes in mst compute.
> > > > > Patch also passes bigjoiner bool to validate plane max size.
> > > >
> > > > Please use the imperative mood in commit messages, e.g. "calculate"
> > > > intead of "calculates".
> > > >
> > > > Please do not refer to "patch". We know it's a patch, until it
> > > > isn't, and then it's a commit.
> > > >
> > > > Please explain *why* the changes are being done, not just *what*
> > > > is being done.
> > > >
> > > > In the subject, what is "bigjoiner case for DP2.0"? DP 2.0 is a
> > > > spec version, and as such irrelevant for the changes being done.
> > > >
> > > > > Signed-off-by: vsrini4 
> > > >
> > > > ?
> > >
> > > Hi Jani, I just added that patch from Vidya to my series, to be
> > > honest, didn't have time at all to look much into it.
> > > Looks like its me who is going to fix that.
> >
> > Hello Stan
> > My sincere apologies. I dint want to disturb your series, so I did not fix 
> > it.
> > Please let me know if I should fix it. Sorry again.
> > Thank you Jani for the comments.
> >
> > Regards
> > Vidya
> 
> Hi Vidya,
> 
> it is a bit unclear for me as well now, how do we proceed, since your patch is
> part of my series, I was explicitly asked to add it, does it mean you are 
> fixing it
> now or me?
> Well if you address Jani's comments, I definitely dont mind :)

Hello Stan
Thank you so much. Just so that I don't disturb your series,
I have pushed this series https://patchwork.freedesktop.org/series/130449/
After addressing comments from Jani Nikula.

Many thanks Jani for the review
and apologies for the commit message errors. Kindly help check if this series
is okay. Thank you.

Regards
Vidya
 
> 
> > >
> > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 19
> > > > > ---
> > > > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > index 5307ddd4edcf5..fd27d9976c050 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -523,6 +523,7 @@ static int
> > > > > intel_dp_mst_compute_config(struct
> > > intel_encoder *encoder,
> > > > >  struct drm_connector_state 
> > > > > *conn_state)
> > > {
> > > > >   struct drm_i915_private *dev_priv =
> > > > > to_i915(encoder->base.dev);
> > > > > + struct intel_crtc *crtc =
> > > > > +to_intel_crtc(pipe_config->uapi.crtc);
> > > > >   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> > > > >   struct intel_dp *intel_dp = _mst->primary->dp;
> > > > >   const struct intel_connector *connector = @@ -540,6 +541,10 @@
> > > > > static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> > > > >   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > > > >   return -EINVAL;
> > > > >
> > > > > + if (intel_dp_need_bi

RE: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0

2024-02-27 Thread Srinivas, Vidya


> -Original Message-
> From: Manasi Navare 
> Sent: Tuesday, February 27, 2024 11:37 PM
> To: Jani Nikula 
> Cc: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org; Saarinen, Jani ;
> ville.syrj...@linux.intel.com; Srinivas, Vidya 
> Subject: Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
> 
> Thanks Jani for your review.
> Thanks @Lisovskiy, Stanislav  and @vidya.srini...@intel.com for taking this
> patch forward.
> 
> @Jani Nikula , @Ville Syrjälä : MST bigjoiner as a feature needs to be enabled
> upstream and this patch enables that feature.
> If you agree that bigjoiner refactoring patches 1 and 2 have no impact on
> enabling bigjoiner on MST, could we decouple this patch from bigjoiner
> refactoring and land this separately?

Hello Manasi

Thank you.
I have submitted this series as suggested after addressing comments
from Jani Nikula about the commit message errors.
https://patchwork.freedesktop.org/series/130449/

Regards
Vidya

> 
> We need the Bigjoiner to be enabled on MST feature landed asap and
> bigjoiner refactoring can follow.
> 
> Regards
> Manasi
> 
> On Tue, Feb 27, 2024 at 1:15 AM Jani Nikula 
> wrote:
> >
> > On Tue, 27 Feb 2024, "Lisovskiy, Stanislav" 
> wrote:
> > > On Mon, Feb 26, 2024 at 09:56:10PM +0200, Jani Nikula wrote:
> > >> On Wed, 21 Feb 2024, Stanislav Lisovskiy 
> wrote:
> > >> > Patch calculates bigjoiner pipes in mst compute.
> > >> > Patch also passes bigjoiner bool to validate plane max size.
> > >>
> > >> Please use the imperative mood in commit messages, e.g. "calculate"
> > >> intead of "calculates".
> > >>
> > >> Please do not refer to "patch". We know it's a patch, until it
> > >> isn't, and then it's a commit.
> > >>
> > >> Please explain *why* the changes are being done, not just *what* is
> > >> being done.
> > >>
> > >> In the subject, what is "bigjoiner case for DP2.0"? DP 2.0 is a
> > >> spec version, and as such irrelevant for the changes being done.
> > >>
> > >> > Signed-off-by: vsrini4 
> > >>
> > >> ?
> > >
> > > Hi Jani, I just added that patch from Vidya to my series, to be
> > > honest, didn't have time at all to look much into it.
> > > Looks like its me who is going to fix that.
> >
> > Should the original authorship be preserved? If not, please add
> > Co-developed-by. Just having the Signed-off-by is not enough.
> >
> > BR,
> > Jani.
> >
> >
> > >
> > >>
> > >> > Signed-off-by: Stanislav Lisovskiy
> > >> > 
> > >> > ---
> > >> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 19
> > >> > ---
> > >> >  1 file changed, 12 insertions(+), 7 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > >> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > >> > index 5307ddd4edcf5..fd27d9976c050 100644
> > >> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > >> > @@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> > >> >   struct drm_connector_state
> > >> > *conn_state)  {
> > >> >struct drm_i915_private *dev_priv =
> > >> > to_i915(encoder->base.dev);
> > >> > +  struct intel_crtc *crtc =
> > >> > + to_intel_crtc(pipe_config->uapi.crtc);
> > >> >struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> > >> >struct intel_dp *intel_dp = _mst->primary->dp;
> > >> >const struct intel_connector *connector = @@ -540,6 +541,10 @@
> > >> > static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> > >> >if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > >> >return -EINVAL;
> > >> >
> > >> > +  if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> > >> > +  adjusted_mode->crtc_clock))
> > >> > +  pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1,
> > >> > + crtc->pipe);
> > >> > +
> > >> >pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB

RE: [PATCH 2/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset

2024-02-27 Thread Srinivas, Vidya



> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, February 27, 2024 2:41 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani ;
> ville.syrj...@linux.intel.com
> Subject: Re: [PATCH 2/3] Start separating pipe vs transcoder set logic for
> bigjoiner during modeset
> 
> On Tue, Feb 27, 2024 at 06:40:23AM +0200, Srinivas, Vidya wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav 
> > > Sent: Thursday, February 22, 2024 12:50 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Lisovskiy, Stanislav ; Saarinen,
> > > Jani ; ville.syrj...@linux.intel.com;
> > > Srinivas, Vidya 
> > > Subject: [PATCH 2/3] Start separating pipe vs transcoder set logic
> > > for bigjoiner during modeset
> > >
> > > Handle only bigjoiner masters in
> > > skl_commit_modeset_enables/disables,
> > > slave crtcs should be handled by master hooks. Same for encoders.
> > > That way we can also remove a bunch of checks like
> > > intel_crtc_is_bigjoiner_slave.
> > >
> > > v2: Get rid of master vs slave checks and separation in crtc
> > > enable/disable hooks.
> > > Use unified iteration cycle for all of those, while enabling/disabling
> > > transcoder only for those pipes where its needed(Ville Syrjälä)
> > >
> > > v3: Move all the intel_encoder_* calls under transcoder code
> > > path(Ville
> > > Syrjälä)
> > >
> > > v4:  - Call intel_crtc_vblank_on from hsw_crtc_enable only for
> > > non-transcoder path
> > >(for master pipe that will be called from
> > > intel_encoders_enable/intel_enable_ddi)
> > >  - Fix stupid mistake with using crtc->pipe for the mask,
> > > instead of BIT(crtc-
> > > >pipe)
> > >
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_ddi.c |  21 +--
> > >  drivers/gpu/drm/i915/display/intel_display.c | 183 ---
> > >  drivers/gpu/drm/i915/display/intel_display.h |   6 +
> > >  3 files changed, 121 insertions(+), 89 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index bea4415902044..6071e9f500871 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -3100,7 +3100,6 @@ static void intel_ddi_post_disable(struct
> > > intel_atomic_state *state,
> > >  const struct drm_connector_state
> > > *old_conn_state)  {
> > >   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > - struct intel_crtc *slave_crtc;
> > >
> > >   if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> > >   intel_crtc_vblank_off(old_crtc_state);
> > > @@ -3117,17 +3116,6 @@ static void intel_ddi_post_disable(struct
> > > intel_atomic_state *state,
> > >   ilk_pfit_disable(old_crtc_state);
> > >   }
> > >
> > > - for_each_intel_crtc_in_pipe_mask(_priv->drm, slave_crtc,
> > > -
> > > intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
> > > - const struct intel_crtc_state *old_slave_crtc_state =
> > > - intel_atomic_get_old_crtc_state(state, slave_crtc);
> > > -
> > > - intel_crtc_vblank_off(old_slave_crtc_state);
> > > -
> > > - intel_dsc_disable(old_slave_crtc_state);
> > > - skl_scaler_disable(old_slave_crtc_state);
> > > - }
> > > -
> > >   /*
> > >* When called from DP MST code:
> > >* - old_conn_state will be NULL
> > > @@ -3363,8 +3351,7 @@ static void intel_enable_ddi(struct
> > > intel_atomic_state *state,  {
> > >   drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> > >
> > > - if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> > > - intel_ddi_enable_transcoder_func(encoder, crtc_state);
> > > + intel_ddi_enable_transcoder_func(encoder, crtc_state);
> > >
> > >   /* Enable/Disable DP2.0 SDP split config before transcoder */
> > >   intel_audio_sdp_split_update(crtc_state);
> > > @@ -3469,9 +3456,6 @@ void intel_ddi_update_active_dpll(struct
> > > intel_atomic_state *state,
> > > struct intel_crtc *crtc)
> > >

RE: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0

2024-02-27 Thread Srinivas, Vidya



> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, February 27, 2024 2:34 PM
> To: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani ;
> ville.syrj...@linux.intel.com; Srinivas, Vidya 
> Subject: Re: [PATCH 3/3] drm/i915: Fix bigjoiner case for DP2.0
> 
> On Mon, Feb 26, 2024 at 09:56:10PM +0200, Jani Nikula wrote:
> > On Wed, 21 Feb 2024, Stanislav Lisovskiy 
> wrote:
> > > Patch calculates bigjoiner pipes in mst compute.
> > > Patch also passes bigjoiner bool to validate plane max size.
> >
> > Please use the imperative mood in commit messages, e.g. "calculate"
> > intead of "calculates".
> >
> > Please do not refer to "patch". We know it's a patch, until it isn't,
> > and then it's a commit.
> >
> > Please explain *why* the changes are being done, not just *what* is
> > being done.
> >
> > In the subject, what is "bigjoiner case for DP2.0"? DP 2.0 is a spec
> > version, and as such irrelevant for the changes being done.
> >
> > > Signed-off-by: vsrini4 
> >
> > ?
> 
> Hi Jani, I just added that patch from Vidya to my series, to be honest, didn't
> have time at all to look much into it.
> Looks like its me who is going to fix that.

Hello Stan
My sincere apologies. I dint want to disturb your series, so I did not fix it.
Please let me know if I should fix it. Sorry again.
Thank you Jani for the comments.

Regards
Vidya
> 
> >
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 19
> > > ---
> > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index 5307ddd4edcf5..fd27d9976c050 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -523,6 +523,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> > >  struct drm_connector_state *conn_state)
> {
> > >   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> > >   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> > >   struct intel_dp *intel_dp = _mst->primary->dp;
> > >   const struct intel_connector *connector = @@ -540,6 +541,10 @@
> > > static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> > >   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > >   return -EINVAL;
> > >
> > > + if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> > > + adjusted_mode->crtc_clock))
> > > + pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1,
> > > +crtc->pipe);
> > > +
> > >   pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> > >   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > >   pipe_config->has_pch_encoder = false; @@ -1318,12 +1323,6 @@
> > > intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> > >*   corresponding link capabilities of the sink) in case the
> > >*   stream is uncompressed for it by the last branch device.
> > >*/
> > > - if (mode_rate > max_rate || mode->clock > max_dotclk ||
> > > - drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port-
> >full_pbn) {
> > > - *status = MODE_CLOCK_HIGH;
> > > - return 0;
> > > - }
> > > -
> > >   if (mode->clock < 1) {
> > >   *status = MODE_CLOCK_LOW;
> > >   return 0;
> > > @@ -1343,6 +1342,12 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
> > >   return 0;
> > >   }
> > >
> > > + if (mode_rate > max_rate || mode->clock > max_dotclk ||
> > > + drm_dp_calc_pbn_mode(mode->clock, min_bpp << 4) > port-
> >full_pbn) {
> > > + *status = MODE_CLOCK_HIGH;
> > > + return 0;
> > > + }
> > > +
> > >   if (DISPLAY_VER(dev_priv) >= 10 &&
> > >   drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
> > >   /*
> > > @@ -1385,7 +1390,7 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
> > >   return 0;
> > >   }
> > >
> > > - *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
> > > + *status = intel_mode_valid_max_plane_size(dev_priv, mode,
> > > +bigjoiner);
> > >   return 0;
> > >  }
> >
> > --
> > Jani Nikula, Intel


RE: [PATCH 2/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset

2024-02-26 Thread Srinivas, Vidya


> -Original Message-
> From: Intel-gfx  On Behalf Of
> Srinivas, Vidya
> Sent: Tuesday, February 27, 2024 10:10 AM
> To: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org
> Cc: Saarinen, Jani ; ville.syrj...@linux.intel.com
> Subject: RE: [PATCH 2/3] Start separating pipe vs transcoder set logic for
> bigjoiner during modeset
> 
> 
> 
> > -Original Message-
> > From: Lisovskiy, Stanislav 
> > Sent: Thursday, February 22, 2024 12:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Lisovskiy, Stanislav ; Saarinen,
> > Jani ; ville.syrj...@linux.intel.com;
> > Srinivas, Vidya 
> > Subject: [PATCH 2/3] Start separating pipe vs transcoder set logic for
> > bigjoiner during modeset
> >
> > Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
> > slave crtcs should be handled by master hooks. Same for encoders.
> > That way we can also remove a bunch of checks like
> > intel_crtc_is_bigjoiner_slave.
> >
> > v2: Get rid of master vs slave checks and separation in crtc
> > enable/disable hooks.
> > Use unified iteration cycle for all of those, while enabling/disabling
> > transcoder only for those pipes where its needed(Ville Syrjälä)
> >
> > v3: Move all the intel_encoder_* calls under transcoder code
> > path(Ville
> > Syrjälä)
> >
> > v4:  - Call intel_crtc_vblank_on from hsw_crtc_enable only for
> > non-transcoder path
> >(for master pipe that will be called from
> > intel_encoders_enable/intel_enable_ddi)
> >  - Fix stupid mistake with using crtc->pipe for the mask, instead
> > of BIT(crtc-
> > >pipe)
> >
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c |  21 +--
> >  drivers/gpu/drm/i915/display/intel_display.c | 183 ---
> >  drivers/gpu/drm/i915/display/intel_display.h |   6 +
> >  3 files changed, 121 insertions(+), 89 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index bea4415902044..6071e9f500871 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3100,7 +3100,6 @@ static void intel_ddi_post_disable(struct
> > intel_atomic_state *state,
> >const struct drm_connector_state
> > *old_conn_state)  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   struct intel_crtc *slave_crtc;
> >
> > if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> > intel_crtc_vblank_off(old_crtc_state);
> > @@ -3117,17 +3116,6 @@ static void intel_ddi_post_disable(struct
> > intel_atomic_state *state,
> > ilk_pfit_disable(old_crtc_state);
> > }
> >
> > -   for_each_intel_crtc_in_pipe_mask(_priv->drm, slave_crtc,
> > -
> > intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
> > -   const struct intel_crtc_state *old_slave_crtc_state =
> > -   intel_atomic_get_old_crtc_state(state, slave_crtc);
> > -
> > -   intel_crtc_vblank_off(old_slave_crtc_state);
> > -
> > -   intel_dsc_disable(old_slave_crtc_state);
> > -   skl_scaler_disable(old_slave_crtc_state);
> > -   }
> > -
> > /*
> >  * When called from DP MST code:
> >  * - old_conn_state will be NULL
> > @@ -3363,8 +3351,7 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,  {
> > drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> >
> > -   if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> > -   intel_ddi_enable_transcoder_func(encoder, crtc_state);
> > +   intel_ddi_enable_transcoder_func(encoder, crtc_state);
> >
> > /* Enable/Disable DP2.0 SDP split config before transcoder */
> > intel_audio_sdp_split_update(crtc_state);
> > @@ -3469,9 +3456,6 @@ void intel_ddi_update_active_dpll(struct
> > intel_atomic_state *state,
> >   struct intel_crtc *crtc)
> >  {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > -   struct intel_crtc_state *crtc_state =
> > -   intel_atomic_get_new_crtc_state(state, crtc);
> > -   struct intel_crtc *slave_crtc;
> > enum phy phy = intel_port_to_phy(i915, encoder->port);
> >
> > /* FIXME: Add MTL pll_mgr */
> > @@ -3479,9 +3463,6 @@ void intel_ddi_update_active_dpll(struct
> &

RE: [PATCH 2/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset

2024-02-26 Thread Srinivas, Vidya


> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Thursday, February 22, 2024 12:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav ; Saarinen, Jani
> ; ville.syrj...@linux.intel.com; Srinivas, Vidya
> 
> Subject: [PATCH 2/3] Start separating pipe vs transcoder set logic for 
> bigjoiner
> during modeset
> 
> Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
> slave crtcs should be handled by master hooks. Same for encoders.
> That way we can also remove a bunch of checks like
> intel_crtc_is_bigjoiner_slave.
> 
> v2: Get rid of master vs slave checks and separation in crtc enable/disable
> hooks.
> Use unified iteration cycle for all of those, while enabling/disabling
> transcoder only for those pipes where its needed(Ville Syrjälä)
> 
> v3: Move all the intel_encoder_* calls under transcoder code path(Ville
> Syrjälä)
> 
> v4:  - Call intel_crtc_vblank_on from hsw_crtc_enable only for non-transcoder
> path
>(for master pipe that will be called from
> intel_encoders_enable/intel_enable_ddi)
>  - Fix stupid mistake with using crtc->pipe for the mask, instead of 
> BIT(crtc-
> >pipe)
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c |  21 +--
>  drivers/gpu/drm/i915/display/intel_display.c | 183 ---
>  drivers/gpu/drm/i915/display/intel_display.h |   6 +
>  3 files changed, 121 insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index bea4415902044..6071e9f500871 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3100,7 +3100,6 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
>  const struct drm_connector_state
> *old_conn_state)  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct intel_crtc *slave_crtc;
> 
>   if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
>   intel_crtc_vblank_off(old_crtc_state);
> @@ -3117,17 +3116,6 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
>   ilk_pfit_disable(old_crtc_state);
>   }
> 
> - for_each_intel_crtc_in_pipe_mask(_priv->drm, slave_crtc,
> -
> intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
> - const struct intel_crtc_state *old_slave_crtc_state =
> - intel_atomic_get_old_crtc_state(state, slave_crtc);
> -
> - intel_crtc_vblank_off(old_slave_crtc_state);
> -
> - intel_dsc_disable(old_slave_crtc_state);
> - skl_scaler_disable(old_slave_crtc_state);
> - }
> -
>   /*
>* When called from DP MST code:
>* - old_conn_state will be NULL
> @@ -3363,8 +3351,7 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,  {
>   drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> 
> - if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> - intel_ddi_enable_transcoder_func(encoder, crtc_state);
> + intel_ddi_enable_transcoder_func(encoder, crtc_state);
> 
>   /* Enable/Disable DP2.0 SDP split config before transcoder */
>   intel_audio_sdp_split_update(crtc_state);
> @@ -3469,9 +3456,6 @@ void intel_ddi_update_active_dpll(struct
> intel_atomic_state *state,
> struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> - struct intel_crtc_state *crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> - struct intel_crtc *slave_crtc;
>   enum phy phy = intel_port_to_phy(i915, encoder->port);
> 
>   /* FIXME: Add MTL pll_mgr */
> @@ -3479,9 +3463,6 @@ void intel_ddi_update_active_dpll(struct
> intel_atomic_state *state,
>   return;
> 
>   intel_update_active_dpll(state, crtc, encoder);
> - for_each_intel_crtc_in_pipe_mask(>drm, slave_crtc,
> -
> intel_crtc_bigjoiner_slave_pipes(crtc_state))
> - intel_update_active_dpll(state, slave_crtc, encoder);
>  }
> 
>  static void
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 916c13a149fd5..e1ea53fd6a288 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1631,31 +1631,12 @@ static void hsw_configure_cpu_transcoder(const
> struct intel_crtc_state *crtc_sta
>   hsw_set_transconf(crtc_state);
>  }
> 
> 

Re: [Intel-gfx] [PATCH] drm/i915: Fix bigjoiner case for DP2.0

2023-10-13 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, October 13, 2023 4:14 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix bigjoiner case for DP2.0
> 
> On Fri, Oct 13, 2023 at 01:00:00AM +0530, vsrini4 wrote:
> > Patch calculates bigjoiner pipes in mst compute.
> > Patch also passes bigjoiner bool to validate plane max size.
> 
> I doubt this is sufficient. The modeset sequence is still all wrong for
> bigjoiner+mst.

Hello Ville, Many thanks for your reply.
Could you kindly help on this issue. Just floated this patch for reference only.
As you said, Monitor lights up but inconsistent also. I am not well-versed to
make a proper fix. Request your help please. Thanks a lot.

Regards
Vidya

> 
> >
> > Signed-off-by: vsrini4 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index e3f176a093d2..f499ce39b2a8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -308,6 +308,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> >struct drm_connector_state *conn_state)
> {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> > struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> > struct intel_dp *intel_dp = _mst->primary->dp;
> > const struct drm_display_mode *adjusted_mode = @@ -318,6
> +319,10 @@
> > static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > return -EINVAL;
> >
> > +   if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
> > +   adjusted_mode->crtc_clock))
> > +   pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc-
> >pipe);
> > +
> > pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > pipe_config->has_pch_encoder = false; @@ -936,12 +941,6 @@
> > intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> > if (ret)
> > return ret;
> >
> > -   if (mode_rate > max_rate || mode->clock > max_dotclk ||
> > -   drm_dp_calc_pbn_mode(mode->clock, min_bpp, false) > port-
> >full_pbn) {
> > -   *status = MODE_CLOCK_HIGH;
> > -   return 0;
> > -   }
> > -
> > if (mode->clock < 1) {
> > *status = MODE_CLOCK_LOW;
> > return 0;
> > @@ -957,6 +956,12 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
> > max_dotclk *= 2;
> > }
> >
> > +   if (mode_rate > max_rate || mode->clock > max_dotclk ||
> > +   drm_dp_calc_pbn_mode(mode->clock, min_bpp, false) > port-
> >full_pbn) {
> > +   *status = MODE_CLOCK_HIGH;
> > +   return 0;
> > +   }
> > +
> > if (DISPLAY_VER(dev_priv) >= 10 &&
> > drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> > /*
> > @@ -994,7 +999,7 @@ intel_dp_mst_mode_valid_ctx(struct
> drm_connector *connector,
> > if (mode_rate > max_rate && !dsc)
> > return MODE_CLOCK_HIGH;
> >
> > -   *status = intel_mode_valid_max_plane_size(dev_priv, mode, false);
> > +   *status = intel_mode_valid_max_plane_size(dev_priv, mode,
> > +bigjoiner);
> > return 0;
> >  }
> >
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915/display: Dual refresh rate fastset fixes with VRR fastset

2023-08-10 Thread Srinivas, Vidya
Hello Mansi,

I tried your patch for the VRR panel we have (bug 
https://gitlab.freedesktop.org/drm/intel/-/issues/8851).
Have uploaded logs with your patch to the bug as well.
But display is blanking out and also I get underrun. Could you kindly have a 
check please? Many thanks.

Regards
Vidya

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Manasi Navare
> Sent: Thursday, August 10, 2023 4:57 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Drew Davenport ; Sean Paul
> 
> Subject: [Intel-gfx] [PATCH] drm/i915/display: Dual refresh rate fastset fixes
> with VRR fastset
> 
> Dual refresh rate (DRR) fastset seamlessly lets refresh rate throttle without
> needing a full modeset.
> However with the recent VRR fastset patches that got merged this logic was
> broken. This is broken because now with VRR fastset VRR parameters are
> calculated by default at the nominal refresh rate say 120Hz.
> Now when DRR throttle happens to switch refresh rate to 60Hz, crtc clock
> changes and this throws a mismatch in VRR parameters and fastset logic for
> DRR gets thrown off and full modeset is indicated.
> 
> This patch fixes this by ignoring the pipe mismatch for VRR parameters in the
> case of DRR and when VRR is not enabled. With this fix, DRR will still 
> throttle
> seamlessly as long as VRR is not enabled.
> 
> This will still need a full modeset for both DRR and VRR operating together
> during the refresh rate throttle and then enabling VRR since now VRR
> parameters need to be recomputed with new crtc clock and written to HW.
> 
> This DRR + VRR fastset in conjunction needs more work in the driver and will
> be fixed in later patches.
> 
> Cc: Drew Davenport 
> Cc: Ville Syrjälä 
> Cc: Sean Paul 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 763ab569d8f3..441d5f3e06c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5352,7 +5352,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
>   if (IS_G4X(dev_priv) || DISPLAY_VER(dev_priv) >= 5)
>   PIPE_CONF_CHECK_I(pipe_bpp);
> 
> - if (!fastset || !pipe_config->seamless_m_n) {
> + if ((!fastset || !pipe_config->seamless_m_n) &&
> +!pipe_config->vrr.enable) {
>   PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
>   PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
>   }
> @@ -5387,11 +5387,13 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> 
>   if (!fastset)
>   PIPE_CONF_CHECK_BOOL(vrr.enable);
> - PIPE_CONF_CHECK_I(vrr.vmin);
> - PIPE_CONF_CHECK_I(vrr.vmax);
> - PIPE_CONF_CHECK_I(vrr.flipline);
> - PIPE_CONF_CHECK_I(vrr.pipeline_full);
> - PIPE_CONF_CHECK_I(vrr.guardband);
> + if ((!fastset && !pipe_config->seamless_m_n) || pipe_config-
> >vrr.enable) {
> + PIPE_CONF_CHECK_I(vrr.vmin);
> + PIPE_CONF_CHECK_I(vrr.vmax);
> + PIPE_CONF_CHECK_I(vrr.flipline);
> + PIPE_CONF_CHECK_I(vrr.pipeline_full);
> + PIPE_CONF_CHECK_I(vrr.guardband);
> + }
> 
>  #undef PIPE_CONF_CHECK_X
>  #undef PIPE_CONF_CHECK_I
> --
> 2.41.0.640.ga95def55d0-goog



Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities

2023-07-13 Thread Srinivas, Vidya



> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, July 13, 2023 6:39 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
> differing sync polarities
> 
> On Wed, 12 Jul 2023, "Srinivas, Vidya"  wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Wednesday, July 12, 2023 1:44 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to
> >> have differing sync polarities
> >>
> >> On Tue, 11 Jul 2023, Jani Nikula  wrote:
> >> > On Tue, 11 Jul 2023, Vidya Srinivas  wrote:
> >> >> v2: Add Jani Nikula's change for quirk for sync polarity
> >> >
> >> > This was a quick hack suggestion to try. If it works, I think it
> >> > works by concidence, because a fastset won't update the sync flags
> >> > in TRANS_DDI_FUNC_CTL register. Did not check whether they can even
> >> > be updated while the transcoder is enabled.
> >>
> >> Bspec 49198 seems to indicate TRANS_DDI_FUNC_CTL can be changed
> >> without a full mode set.
> >>
> >> The sync polarity still needs to be modified in the ->update_pipe() hooks.
> >
> > Hello Jani,
> >
> > Thank you very much. Apart from sync polarity, VRR panel is doing full
> > modeset between refresh rates 165 to 60Hz due to vrr.vmin, vrr.vmax,
> vrr.flipline and vrr.guardband mismatch.
> > Can VRR panel do seamless fastset between 165Hz and 60Hz? Kindly let me
> know.
> > Thank you.
> 
> I think it should be possible, even if the driver does not handle it properly
> atm.
> 
> Not sure if it can be combined with VRR itself. I guess typically you'd change
> the refresh rate instead of fastset when you're using VRR, but if you're not
> using VRR, would be great to be able to have DRRS and fastsets between the
> modes.

Hello Jani,

Thank you very much for the inputs.

Regards
Vidya

> 
> BR,
> Jani.
> 
> >
> > Regards
> > Vidya
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> >> CC: Jani Nikula 
> >> >> Credits-to: Jani Nikula 
> >> >> Signed-off-by: Vidya Srinivas 
> >> >
> >> > It would be useful to have a bug report at fdo gitlab with the EDID
> >> > attached.
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> >
> >> >> ---
> >> >>  drivers/gpu/drm/i915/display/intel_display.c |  2 +-
> >> >>  drivers/gpu/drm/i915/display/intel_panel.c   | 10 ++
> >> >>  2 files changed, 7 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> index 43cba98f7753..088b45e032aa 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> @@ -5234,7 +5234,7 @@ intel_pipe_config_compare(const struct
> >> intel_crtc_state *current_config,
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >>  DRM_MODE_FLAG_INTERLACE);
> >> >>
> >> >> -  if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)) {
> >> >> +  if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)
> >> &&
> >> >> +!fastset) {
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >>  DRM_MODE_FLAG_PHSYNC);
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> b/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> index 9232a305b1e6..b9eeaedabd22 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> @@ -112,10 +112,12 @@ intel_panel_fixed_mode(struct
> >> >> intel_connector *connector,  static bool is_alt_drrs_mode(const
> >> >> struct drm_display_mode
> >> *mode,
> >> >> const struct drm_display_mode
> >> >> *preferred_mode)
> >> {
> >> >> -  return drm_mode_match(mode, preferred_mode,
> >> >> -DRM_MODE_MATCH_TIMINGS |
> >> >> -DRM_MODE_MATCH_FLAGS |
> >> >> -DRM_MODE_MATCH_3D_FLAGS) &&
> >> >> +  u32 sync_flags = DRM_MODE_FLAG_PHSYNC |
> >> DRM_MODE_FLAG_NHSYNC |
> >> >> +  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC;
> >> >> +
> >> >> +  return (mode->flags & ~sync_flags) == (preferred_mode->flags &
> >> ~sync_flags) &&
> >> >> +  mode->hdisplay == preferred_mode->hdisplay &&
> >> >> +  mode->vdisplay == preferred_mode->vdisplay &&
> >> >>mode->clock != preferred_mode->clock;  }
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities

2023-07-12 Thread Srinivas, Vidya



> -Original Message-
> From: Nikula, Jani 
> Sent: Wednesday, July 12, 2023 1:44 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
> differing sync polarities
> 
> On Tue, 11 Jul 2023, Jani Nikula  wrote:
> > On Tue, 11 Jul 2023, Vidya Srinivas  wrote:
> >> v2: Add Jani Nikula's change for quirk for sync polarity
> >
> > This was a quick hack suggestion to try. If it works, I think it works
> > by concidence, because a fastset won't update the sync flags in
> > TRANS_DDI_FUNC_CTL register. Did not check whether they can even be
> > updated while the transcoder is enabled.
> 
> Bspec 49198 seems to indicate TRANS_DDI_FUNC_CTL can be changed
> without a full mode set.
> 
> The sync polarity still needs to be modified in the ->update_pipe() hooks.

Hello Jani,

Thank you very much. Apart from sync polarity, VRR panel is doing full modeset 
between
refresh rates 165 to 60Hz due to vrr.vmin, vrr.vmax, vrr.flipline and 
vrr.guardband mismatch.
Can VRR panel do seamless fastset between 165Hz and 60Hz? Kindly let me know. 
Thank you.

Regards
Vidya
> 
> 
> BR,
> Jani.
> 
> 
> >
> >> CC: Jani Nikula 
> >> Credits-to: Jani Nikula 
> >> Signed-off-by: Vidya Srinivas 
> >
> > It would be useful to have a bug report at fdo gitlab with the EDID
> > attached.
> >
> > BR,
> > Jani.
> >
> >
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_display.c |  2 +-
> >>  drivers/gpu/drm/i915/display/intel_panel.c   | 10 ++
> >>  2 files changed, 7 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index 43cba98f7753..088b45e032aa 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -5234,7 +5234,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >>  DRM_MODE_FLAG_INTERLACE);
> >>
> >> -  if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)) {
> >> +  if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)
> &&
> >> +!fastset) {
> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >>  DRM_MODE_FLAG_PHSYNC);
> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> >> b/drivers/gpu/drm/i915/display/intel_panel.c
> >> index 9232a305b1e6..b9eeaedabd22 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> >> @@ -112,10 +112,12 @@ intel_panel_fixed_mode(struct intel_connector
> >> *connector,  static bool is_alt_drrs_mode(const struct drm_display_mode
> *mode,
> >> const struct drm_display_mode *preferred_mode)
> {
> >> -  return drm_mode_match(mode, preferred_mode,
> >> -DRM_MODE_MATCH_TIMINGS |
> >> -DRM_MODE_MATCH_FLAGS |
> >> -DRM_MODE_MATCH_3D_FLAGS) &&
> >> +  u32 sync_flags = DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_NHSYNC |
> >> +  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC;
> >> +
> >> +  return (mode->flags & ~sync_flags) == (preferred_mode->flags &
> ~sync_flags) &&
> >> +  mode->hdisplay == preferred_mode->hdisplay &&
> >> +  mode->vdisplay == preferred_mode->vdisplay &&
> >>mode->clock != preferred_mode->clock;  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities

2023-07-11 Thread Srinivas, Vidya



> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, July 11, 2023 9:34 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Srinivas, Vidya 
> Subject: Re: [PATCH] drm/i915: Allow panel drrs modes to have differing sync
> polarities
> 
> On Tue, 11 Jul 2023, Vidya Srinivas  wrote:
> > v2: Add Jani Nikula's change for quirk for sync polarity
> 
> This was a quick hack suggestion to try. If it works, I think it works by
> concidence, because a fastset won't update the sync flags in
> TRANS_DDI_FUNC_CTL register. Did not check whether they can even be
> updated while the transcoder is enabled.
> 
> > CC: Jani Nikula 
> > Credits-to: Jani Nikula 
> > Signed-off-by: Vidya Srinivas 
> 
> It would be useful to have a bug report at fdo gitlab with the EDID attached.

Hello Jani,
I have requested gitlab with EDID attached 
https://gitlab.freedesktop.org/drm/intel/-/issues/8851
Kindly have a check please. Thank you very much.

Regards
Vidya
> 
> BR,
> Jani.
> 
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c |  2 +-
> >  drivers/gpu/drm/i915/display/intel_panel.c   | 10 ++
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 43cba98f7753..088b45e032aa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5234,7 +5234,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> > PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >   DRM_MODE_FLAG_INTERLACE);
> >
> > -   if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)) {
> > +   if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)
> && !fastset)
> > +{
> > PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >   DRM_MODE_FLAG_PHSYNC);
> > PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> > diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> > b/drivers/gpu/drm/i915/display/intel_panel.c
> > index 9232a305b1e6..b9eeaedabd22 100644
> > --- a/drivers/gpu/drm/i915/display/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> > @@ -112,10 +112,12 @@ intel_panel_fixed_mode(struct intel_connector
> > *connector,  static bool is_alt_drrs_mode(const struct drm_display_mode
> *mode,
> >  const struct drm_display_mode *preferred_mode)
> {
> > -   return drm_mode_match(mode, preferred_mode,
> > - DRM_MODE_MATCH_TIMINGS |
> > - DRM_MODE_MATCH_FLAGS |
> > - DRM_MODE_MATCH_3D_FLAGS) &&
> > +   u32 sync_flags = DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_NHSYNC |
> > +   DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC;
> > +
> > +   return (mode->flags & ~sync_flags) == (preferred_mode->flags &
> ~sync_flags) &&
> > +   mode->hdisplay == preferred_mode->hdisplay &&
> > +   mode->vdisplay == preferred_mode->vdisplay &&
> > mode->clock != preferred_mode->clock;  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch

2022-05-25 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Wednesday, May 25, 2022 2:50 PM
> To: Jani Nikula ; Souza, Jose
> ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Syrjala, Ville
> 
> Subject: RE: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless
> mode switch
> 
> 
> 
> > -Original Message-
> > From: Jani Nikula 
> > Sent: Wednesday, May 25, 2022 2:26 PM
> > To: Srinivas, Vidya ; Souza, Jose
> > ; intel-gfx@lists.freedesktop.org
> > Cc: Sean Paul ; Syrjala, Ville
> > 
> > Subject: Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement
> > seamless mode switch
> >
> > On Wed, 25 May 2022, "Srinivas, Vidya"  wrote:
> > > Hello,
> > >
> > > Apologies for bothering. May we kindly know if this solution is approved?
> > > I have provided the Tested-by. Thanks much.
> >
> > IIUC the more complete solution is [1].
> >
> > BR,
> > Jani.
> >
> >
> > [1] https://patchwork.freedesktop.org/series/103491/
> >
> Hello Jani,
> 
> Thank you very much. I will have a check of this.
> For user space triggered seamless modeset WITHOUT setting
> "DRM_MODE_ATOMIC_ALLOW_MODESET", for switch between 2 refresh
> rates, Jose patches is working.
> Jose please correct me if I am wrong. Thank you.
> 
> Regards
> Vidya

Hello Jani,

I checked the new series https://patchwork.freedesktop.org/series/103491/ and 
this is working as well.
I tested it on ADL-P RVP with 144/60Hz panel.
Both solutions from Jose and Ville are working. Many thanks to both.

Regards
Vidya

> >
> >
> > >
> > > Regards
> > > Vidya
> > >
> > >> -Original Message-
> > >> From: Srinivas, Vidya
> > >> Sent: Monday, May 9, 2022 8:44 PM
> > >> To: Souza, Jose ;
> > >> intel-gfx@lists.freedesktop.org
> > >> Cc: Sean Paul ; Ville Syrjälä
> > >> 
> > >> Subject: RE: [PATCH v2 3/3] drm/i915/display: Implement seamless
> > >> mode switch
> > >>
> > >> Hello Jose,
> > >>
> > >> Thanks much for the patch. I tested it on chrome system and the
> > >> patch works.
> > >> Adding my Tested-by.
> > >> Tested-by: Vidya Srinivas 
> > >>
> > >> Regards
> > >> Vidya
> > >>
> > >> > -Original Message-
> > >> > From: Souza, Jose 
> > >> > Sent: Tuesday, May 3, 2022 2:11 AM
> > >> > To: intel-gfx@lists.freedesktop.org
> > >> > Cc: Srinivas, Vidya ; Sean Paul
> > >> > ; Ville Syrjälä
> > >> > ; Souza, Jose
> > >> > 
> > >> > Subject: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> > >> > switch
> > >> >
> > >> > So far the i915's DRRS feature was automatically changing between
> > >> > preferred panel mode and downclock mode based on idleness but
> > >> ChromeOS
> > >> > compositor team is asking to be in control of the mode switch.
> > >> > So for certain types of content it can switch to a mode with a
> > >> > lower refresh rate without the user noticing a thing and saving
> > >> > more
> > power.
> > >> >
> > >> > This seamless mode switch will be triggered when user-space
> > >> > dispatches an atomic commit with the new mode and clears the
> > >> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> > >> >
> > >> > The main steps to acomplish that are:
> > >> >
> > >> > - as mode changed in atomic state
> > drm_atomic_helper_check_modeset()
> > >> > will set mode_changed and it will trigger the crtc state
> > >> > computation so
> > >> > intel_dp_compute_config() will be called and dp_m_n will be
> > >> > computed for the new mode
> > >> >
> > >> > - then intel_dp_drrs_compute_config() will check for the
> > >> > necessary conditions to do a seamless mode switch, if possible
> > >> > crtc_state-
> > >> > >seamless_mode_switch will be set and has_drrs will not be set,
> > >> > >so
> > >> > >i915 will
> > >> > not automatically switch between modes
> > >> >
> > >> > - then intel_crtc_compute_config() will call
> > >> > intel_crtc_compute_pixel_rate() that will take the hint that i

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch

2022-05-25 Thread Srinivas, Vidya


> -Original Message-
> From: Jani Nikula 
> Sent: Wednesday, May 25, 2022 2:26 PM
> To: Srinivas, Vidya ; Souza, Jose
> ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Syrjala, Ville
> 
> Subject: Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless
> mode switch
> 
> On Wed, 25 May 2022, "Srinivas, Vidya"  wrote:
> > Hello,
> >
> > Apologies for bothering. May we kindly know if this solution is approved?
> > I have provided the Tested-by. Thanks much.
> 
> IIUC the more complete solution is [1].
> 
> BR,
> Jani.
> 
> 
> [1] https://patchwork.freedesktop.org/series/103491/
> 
Hello Jani,

Thank you very much. I will have a check of this.
For user space triggered seamless modeset WITHOUT setting 
"DRM_MODE_ATOMIC_ALLOW_MODESET", for switch between 2 refresh rates, Jose 
patches is working.
Jose please correct me if I am wrong. Thank you.

Regards
Vidya
> 
> 
> >
> > Regards
> > Vidya
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Monday, May 9, 2022 8:44 PM
> >> To: Souza, Jose ;
> >> intel-gfx@lists.freedesktop.org
> >> Cc: Sean Paul ; Ville Syrjälä
> >> 
> >> Subject: RE: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> >> switch
> >>
> >> Hello Jose,
> >>
> >> Thanks much for the patch. I tested it on chrome system and the patch
> >> works.
> >> Adding my Tested-by.
> >> Tested-by: Vidya Srinivas 
> >>
> >> Regards
> >> Vidya
> >>
> >> > -Original Message-
> >> > From: Souza, Jose 
> >> > Sent: Tuesday, May 3, 2022 2:11 AM
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Cc: Srinivas, Vidya ; Sean Paul
> >> > ; Ville Syrjälä
> >> > ; Souza, Jose 
> >> > Subject: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> >> > switch
> >> >
> >> > So far the i915's DRRS feature was automatically changing between
> >> > preferred panel mode and downclock mode based on idleness but
> >> ChromeOS
> >> > compositor team is asking to be in control of the mode switch.
> >> > So for certain types of content it can switch to a mode with a
> >> > lower refresh rate without the user noticing a thing and saving more
> power.
> >> >
> >> > This seamless mode switch will be triggered when user-space
> >> > dispatches an atomic commit with the new mode and clears the
> >> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> >> >
> >> > The main steps to acomplish that are:
> >> >
> >> > - as mode changed in atomic state
> drm_atomic_helper_check_modeset()
> >> > will set mode_changed and it will trigger the crtc state
> >> > computation so
> >> > intel_dp_compute_config() will be called and dp_m_n will be
> >> > computed for the new mode
> >> >
> >> > - then intel_dp_drrs_compute_config() will check for the necessary
> >> > conditions to do a seamless mode switch, if possible crtc_state-
> >> > >seamless_mode_switch will be set and has_drrs will not be set, so
> >> > >i915 will
> >> > not automatically switch between modes
> >> >
> >> > - then intel_crtc_compute_config() will call
> >> > intel_crtc_compute_pixel_rate() that will take the hint that it is
> >> > trying to do a seamless mode switch and set pixel_rate to the
> >> > pixel_rate of the old state
> >> >
> >> > - then if nothing else changed in the state
> >> > intel_crtc_check_fastset() will be able to set mode_changed to
> >> > false and i915 can do fastset otherwise the commit will fail during
> >> > the check phase
> >> >
> >> > - now on the atomic commit phase, intel_ddi_update_pipe_dp() will
> >> > be called and will program the new dp_m_n
> >> >
> >> > - nothing else is different in the commit phase until the step to
> >> > verify programmed state, the most important change here is that
> >> > need to save the pixel_rate in DRRS global state as there is no
> >> > other way to get that from hardware or atomic state
> >> >
> >> > v2:
> >> > - not overwritten dp_m_n values in intel_crtc_copy_fastset() when
> >> > doing a seamless_mode_switch
> >> >
> >> > Cc: Vidya Srinivas 
> >> &g

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch

2022-05-24 Thread Srinivas, Vidya
Hello,

Apologies for bothering. May we kindly know if this solution is approved?
I have provided the Tested-by. Thanks much.

Regards
Vidya

> -Original Message-
> From: Srinivas, Vidya
> Sent: Monday, May 9, 2022 8:44 PM
> To: Souza, Jose ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Ville Syrjälä
> 
> Subject: RE: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> switch
> 
> Hello Jose,
> 
> Thanks much for the patch. I tested it on chrome system and the patch
> works.
> Adding my Tested-by.
> Tested-by: Vidya Srinivas 
> 
> Regards
> Vidya
> 
> > -Original Message-
> > From: Souza, Jose 
> > Sent: Tuesday, May 3, 2022 2:11 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Srinivas, Vidya ; Sean Paul
> > ; Ville Syrjälä
> > ; Souza, Jose 
> > Subject: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> > switch
> >
> > So far the i915's DRRS feature was automatically changing between
> > preferred panel mode and downclock mode based on idleness but
> ChromeOS
> > compositor team is asking to be in control of the mode switch.
> > So for certain types of content it can switch to a mode with a lower
> > refresh rate without the user noticing a thing and saving more power.
> >
> > This seamless mode switch will be triggered when user-space dispatches
> > an atomic commit with the new mode and clears the
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> >
> > The main steps to acomplish that are:
> >
> > - as mode changed in atomic state drm_atomic_helper_check_modeset()
> > will set mode_changed and it will trigger the crtc state computation
> > so
> > intel_dp_compute_config() will be called and dp_m_n will be computed
> > for the new mode
> >
> > - then intel_dp_drrs_compute_config() will check for the necessary
> > conditions to do a seamless mode switch, if possible crtc_state-
> > >seamless_mode_switch will be set and has_drrs will not be set, so
> > >i915 will
> > not automatically switch between modes
> >
> > - then intel_crtc_compute_config() will call
> > intel_crtc_compute_pixel_rate() that will take the hint that it is
> > trying to do a seamless mode switch and set pixel_rate to the
> > pixel_rate of the old state
> >
> > - then if nothing else changed in the state intel_crtc_check_fastset()
> > will be able to set mode_changed to false and i915 can do fastset
> > otherwise the commit will fail during the check phase
> >
> > - now on the atomic commit phase, intel_ddi_update_pipe_dp() will be
> > called and will program the new dp_m_n
> >
> > - nothing else is different in the commit phase until the step to
> > verify programmed state, the most important change here is that need
> > to save the pixel_rate in DRRS global state as there is no other way
> > to get that from hardware or atomic state
> >
> > v2:
> > - not overwritten dp_m_n values in intel_crtc_copy_fastset() when
> > doing a seamless_mode_switch
> >
> > Cc: Vidya Srinivas 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c  | 10 +++
> >  drivers/gpu/drm/i915/display/intel_display.c  | 61
> > --- .../drm/i915/display/intel_display_debugfs.c  |  3 +
> >  .../drm/i915/display/intel_display_types.h|  3 +
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 56 ++---
> >  drivers/gpu/drm/i915/display/intel_drrs.c | 38 +---
> >  drivers/gpu/drm/i915/display/intel_drrs.h |  3 +
> >  7 files changed, 151 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9e6fa59eabba7..732e5d425412e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -46,6 +46,7 @@
> >  #include "intel_dp_link_training.h"
> >  #include "intel_dp_mst.h"
> >  #include "intel_dpio_phy.h"
> > +#include "intel_drrs.h"
> >  #include "intel_dsi.h"
> >  #include "intel_fdi.h"
> >  #include "intel_fifo_underrun.h"
> > @@ -3010,6 +3011,14 @@ static void intel_ddi_update_pipe_dp(struct
> > intel_atomic_state *state,
> >
> > intel_backlight_update(state, encoder, crtc_state, conn_state);
> > drm_connector_update_privacy_screen(conn_state);
> > +
> > +   if (crtc_state->seamless_mode_switch) 

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch

2022-05-09 Thread Srinivas, Vidya
Hello Jose,

Thanks much for the patch. I tested it on chrome system and the patch works.
Adding my Tested-by.
Tested-by: Vidya Srinivas 

Regards
Vidya

> -Original Message-
> From: Souza, Jose 
> Sent: Tuesday, May 3, 2022 2:11 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Sean Paul
> ; Ville Syrjälä ;
> Souza, Jose 
> Subject: [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch
> 
> So far the i915's DRRS feature was automatically changing between preferred
> panel mode and downclock mode based on idleness but ChromeOS
> compositor team is asking to be in control of the mode switch.
> So for certain types of content it can switch to a mode with a lower refresh
> rate without the user noticing a thing and saving more power.
> 
> This seamless mode switch will be triggered when user-space dispatches an
> atomic commit with the new mode and clears the
> DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> 
> The main steps to acomplish that are:
> 
> - as mode changed in atomic state drm_atomic_helper_check_modeset() will
> set mode_changed and it will trigger the crtc state computation so
> intel_dp_compute_config() will be called and dp_m_n will be computed for
> the new mode
> 
> - then intel_dp_drrs_compute_config() will check for the necessary
> conditions to do a seamless mode switch, if possible crtc_state-
> >seamless_mode_switch will be set and has_drrs will not be set, so i915 will
> not automatically switch between modes
> 
> - then intel_crtc_compute_config() will call
> intel_crtc_compute_pixel_rate() that will take the hint that it is trying to 
> do a
> seamless mode switch and set pixel_rate to the pixel_rate of the old state
> 
> - then if nothing else changed in the state intel_crtc_check_fastset() will be
> able to set mode_changed to false and i915 can do fastset otherwise the
> commit will fail during the check phase
> 
> - now on the atomic commit phase, intel_ddi_update_pipe_dp() will be
> called and will program the new dp_m_n
> 
> - nothing else is different in the commit phase until the step to verify
> programmed state, the most important change here is that need to save the
> pixel_rate in DRRS global state as there is no other way to get that from
> hardware or atomic state
> 
> v2:
> - not overwritten dp_m_n values in intel_crtc_copy_fastset() when doing a
> seamless_mode_switch
> 
> Cc: Vidya Srinivas 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 10 +++
>  drivers/gpu/drm/i915/display/intel_display.c  | 61 ---
> .../drm/i915/display/intel_display_debugfs.c  |  3 +
>  .../drm/i915/display/intel_display_types.h|  3 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 56 ++---
>  drivers/gpu/drm/i915/display/intel_drrs.c | 38 +---
>  drivers/gpu/drm/i915/display/intel_drrs.h |  3 +
>  7 files changed, 151 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9e6fa59eabba7..732e5d425412e 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -46,6 +46,7 @@
>  #include "intel_dp_link_training.h"
>  #include "intel_dp_mst.h"
>  #include "intel_dpio_phy.h"
> +#include "intel_drrs.h"
>  #include "intel_dsi.h"
>  #include "intel_fdi.h"
>  #include "intel_fifo_underrun.h"
> @@ -3010,6 +3011,14 @@ static void intel_ddi_update_pipe_dp(struct
> intel_atomic_state *state,
> 
>   intel_backlight_update(state, encoder, crtc_state, conn_state);
>   drm_connector_update_privacy_screen(conn_state);
> +
> + if (crtc_state->seamless_mode_switch) {
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> >uapi.crtc);
> +
> + intel_cpu_transcoder_set_m1_n1(intel_crtc,
> +crtc_state->cpu_transcoder,
> +_state->dp_m_n);
> + }
>  }
> 
>  void intel_ddi_update_pipe(struct intel_atomic_state *state, @@ -3484,6
> +3493,7 @@ static void intel_ddi_get_config(struct intel_encoder *encoder,
>   intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
> 
>   intel_psr_get_config(encoder, pipe_config);
> + intel_drrs_get_config(encoder, pipe_config);
>  }
> 
>  void intel_ddi_get_clock(struct intel_encoder *encoder, diff --git
> a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 17d0cad9e1686..e54fbe3b1d394 100644

Re: [Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

2022-04-26 Thread Srinivas, Vidya
Hello Jose,

Thanks much for the patch. I tested it on chrome system and the patch works.
Adding my Tested-by.
Tested-by: Vidya Srinivas 

Regards
Vidya

> -Original Message-
> From: Souza, Jose 
> Sent: Friday, April 22, 2022 12:52 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Sean Paul
> ; Ville Syrjälä ;
> Souza, Jose 
> Subject: [PATCH 1/3] drm: Add infrastructure to allow seamless mode
> switches
> 
> Intel hardware supports change between modes with different refresh rates
> without any glitches or visual artifacts, that feature is called seamless 
> DRRS.
> 
> So far i915 driver was automatically changing between preferred panel mode
> and lower refresh rate mode based on idleness but ChromeOS compositor
> team is requesting to be in control of the mode switch.
> So for a certain types of content it can switch to mode with a lower refresh
> rate without user noticing a thing and saving power.
> 
> This seamless mode switch will be triggered when user-space dispatch a
> atomic commit with the new mode and clears the
> DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> 
> A driver that don't implement atomic_seamless_mode_switch_check
> function will continue to fail in the atomic check phase with "[CRTC:%d:%s]
> requires full modeset" debug message.
> While a driver that implements it and support the seamless change between
> old and new mode will return 0 otherwise it should return the appropried
> errno.
> 
> So here adding basic drm infrastructure to that be supported by i915 and
> other drivers.
> 
> Cc: Vidya Srinivas 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_atomic.c  |  1 +
>  drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  include/drm/drm_crtc.h| 25 +++
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58c0283fb6b0c..21525f9f4b4c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
>   drm_printf(p, "\tself_refresh_active=%d\n", state-
> >self_refresh_active);
>   drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
>   drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> + drm_printf(p, "\tseamless_mode_changed=%d\n",
> +state->seamless_mode_changed);
>   drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
>   drm_printf(p, "\tconnectors_changed=%d\n", state-
> >connectors_changed);
>   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state-
> >color_mgmt_changed); diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9603193d2fa13..e6f3a966f7b86 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct
> drm_device *dev,
>   drm_dbg_atomic(dev, "[CRTC:%d:%s] mode
> changed\n",
>  crtc->base.id, crtc->name);
>   new_crtc_state->mode_changed = true;
> +
> + if (!state->allow_modeset &&
> + crtc->funcs-
> >atomic_seamless_mode_switch_check) {
> + ret = crtc->funcs-
> >atomic_seamless_mode_switch_check(state, crtc);
> + if (ret == -EOPNOTSUPP) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> Seamless mode switch not supported\n",
> +crtc->base.id, crtc-
> >name);
> + return ret;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + new_crtc_state->seamless_mode_changed =
> true;
> + new_crtc_state->mode_changed = false;
> + }
>   }
> 
>   if (old_crtc_state->enable != new_crtc_state->enable) { diff --
> git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3b6d3bdbd0996..c093073ea6e11 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @

Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-12-02 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, December 2, 2021 6:37 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Thu, Dec 02, 2021 at 04:38:36PM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > v2: Addressed review comments from Ville. Added separate functions for
> > max_width - for HDR and SDR
> >
> > v3: Addressed review comments from Ville. Changed names of HDR and
> SDR
> > max_width functions to icl_hdr_plane_max_width and
> > icl_sdr_plane_max_width
> >
> > v4: Fixed paranthesis alignment. No code change
> >
> > Reviewed-by: Ville Syrjälä 
> > Signed-off-by: Vidya Srinivas 
> 
> Pushed to drm-intel-next. Thanks.

Hello Ville, thank you very much for all the help.

Regards
Vidya
> 
> > ---
> >  .../drm/i915/display/skl_universal_plane.c| 21 +++
> >  1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..e717eb58b105 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -420,9 +420,19 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > -  int color_plane,
> > -  unsigned int rotation)
> > +static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
> > +   int color_plane,
> > +   unsigned int rotation)
> > +{
> > +   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +   else
> > +   return 5120;
> > +}
> > +
> > +static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
> > +   int color_plane,
> > +   unsigned int rotation)
> >  {
> > return 5120;
> >  }
> > @@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct
> > drm_i915_private *dev_priv,
> >
> > if (DISPLAY_VER(dev_priv) >= 11) {
> > plane->min_width = icl_plane_min_width;
> > -   plane->max_width = icl_plane_max_width;
> > +   if (icl_is_hdr_plane(dev_priv, plane_id))
> > +   plane->max_width = icl_hdr_plane_max_width;
> > +   else
> > +   plane->max_width = icl_sdr_plane_max_width;
> > plane->max_height = icl_plane_max_height;
> > plane->min_cdclk = icl_plane_min_cdclk;
> > } else if (DISPLAY_VER(dev_priv) >= 10) {
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-12-02 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, December 2, 2021 4:43 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Thu, Dec 02, 2021 at 11:10:37AM +, Srinivas, Vidya wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Thursday, December 2, 2021 4:26 PM
> > > To: Srinivas, Vidya 
> > > Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> > > 
> > > Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in
> > > max_width
> > >
> > > On Thu, Dec 02, 2021 at 03:25:34AM +, Srinivas, Vidya wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ville Syrjälä 
> > > > > Sent: Wednesday, December 1, 2021 8:33 PM
> > > > > To: Srinivas, Vidya 
> > > > > Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> > > > > 
> > > > > Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in
> > > > > max_width
> > > > >
> > > > > On Wed, Dec 01, 2021 at 09:17:27AM +0530, Vidya Srinivas wrote:
> > > > > > PLANE_CUS_CTL has a restriction of 4096 width even though
> > > > > > PLANE_SIZE and scaler size registers supports max 5120.
> > > > > > Take care of this restriction in max_width.
> > > > > >
> > > > > > Without this patch, when 5k content is sent on HDR plane with
> > > > > > NV12 content, FIFO underrun is seen and screen blanks out.
> > > > > >
> > > > > > v2: Addressed review comments from Ville. Added separate
> > > > > > functions for max_width - for HDR and SDR
> > > > > >
> > > > > > v3: Addressed review comments from Ville. Changed names of HDR
> > > > > > and
> > > > > SDR
> > > > > > max_width functions to icl_hdr_plane_max_width and
> > > > > > icl_sdr_plane_max_width
> > > > > >
> > > > > > v4: Fixed paranthesis alignment. No code change
> > > > > >
> > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > Signed-off-by: Vidya Srinivas 
> > > > > > Signed-off-by: Yashashvi Shantam 
> > > > >
> > > > > Hmm. What's this extra sob doing here?
> > > >
> > > > Hello Ville, sincere apologies. When I run checkpatch.pl I see no
> > > > warnings
> > > on my host.
> > > > However patchwork keeps reporting paranthesis alignment warning.
> > > > I tried to push it multiple times after running checkpatch.pl on my 
> > > > host.
> > > Really sorry about that.
> > >
> > > I was asking about the extra "signed-off-by" (sob).
> >
> > Hello Ville, I am really sorry about that. Should I keep single
> > signed-off-by and push the patch again? Kindly let me know. Thank you.
> 
> Yeah, please resend with proper signed-off-by.

Hello Ville, I have kept a single signed-off-by and pushed
https://patchwork.freedesktop.org/patch/465010/?series=97053=9
Apologies for bothering you. Thank you very much. Kindly have a check.

Regards
Vidya


> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-12-02 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, December 2, 2021 4:26 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Thu, Dec 02, 2021 at 03:25:34AM +, Srinivas, Vidya wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä 
> > > Sent: Wednesday, December 1, 2021 8:33 PM
> > > To: Srinivas, Vidya 
> > > Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> > > 
> > > Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in
> > > max_width
> > >
> > > On Wed, Dec 01, 2021 at 09:17:27AM +0530, Vidya Srinivas wrote:
> > > > PLANE_CUS_CTL has a restriction of 4096 width even though
> > > > PLANE_SIZE and scaler size registers supports max 5120.
> > > > Take care of this restriction in max_width.
> > > >
> > > > Without this patch, when 5k content is sent on HDR plane with NV12
> > > > content, FIFO underrun is seen and screen blanks out.
> > > >
> > > > v2: Addressed review comments from Ville. Added separate functions
> > > > for max_width - for HDR and SDR
> > > >
> > > > v3: Addressed review comments from Ville. Changed names of HDR and
> > > SDR
> > > > max_width functions to icl_hdr_plane_max_width and
> > > > icl_sdr_plane_max_width
> > > >
> > > > v4: Fixed paranthesis alignment. No code change
> > > >
> > > > Reviewed-by: Ville Syrjälä 
> > > > Signed-off-by: Vidya Srinivas 
> > > > Signed-off-by: Yashashvi Shantam 
> > >
> > > Hmm. What's this extra sob doing here?
> >
> > Hello Ville, sincere apologies. When I run checkpatch.pl I see no warnings
> on my host.
> > However patchwork keeps reporting paranthesis alignment warning.
> > I tried to push it multiple times after running checkpatch.pl on my host.
> Really sorry about that.
> 
> I was asking about the extra "signed-off-by" (sob).

Hello Ville, I am really sorry about that. Should I keep single signed-off-by 
and push the patch
again? Kindly let me know. Thank you.

Regards
Vidya

> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-12-01 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, December 1, 2021 8:33 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Wed, Dec 01, 2021 at 09:17:27AM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > v2: Addressed review comments from Ville. Added separate functions for
> > max_width - for HDR and SDR
> >
> > v3: Addressed review comments from Ville. Changed names of HDR and
> SDR
> > max_width functions to icl_hdr_plane_max_width and
> > icl_sdr_plane_max_width
> >
> > v4: Fixed paranthesis alignment. No code change
> >
> > Reviewed-by: Ville Syrjälä 
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> 
> Hmm. What's this extra sob doing here?

Hello Ville, sincere apologies. When I run checkpatch.pl I see no warnings on 
my host.
However patchwork keeps reporting paranthesis alignment warning.
I tried to push it multiple times after running checkpatch.pl on my host. 
Really sorry about that.

Regards
Vidya


> 
> > ---
> >  .../drm/i915/display/skl_universal_plane.c| 21 +++
> >  1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..e717eb58b105 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -420,9 +420,19 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > -  int color_plane,
> > -  unsigned int rotation)
> > +static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
> > +   int color_plane,
> > +   unsigned int rotation)
> > +{
> > +   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +   else
> > +   return 5120;
> > +}
> > +
> > +static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
> > +   int color_plane,
> > +   unsigned int rotation)
> >  {
> > return 5120;
> >  }
> > @@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct
> > drm_i915_private *dev_priv,
> >
> > if (DISPLAY_VER(dev_priv) >= 11) {
> > plane->min_width = icl_plane_min_width;
> > -   plane->max_width = icl_plane_max_width;
> > +   if (icl_is_hdr_plane(dev_priv, plane_id))
> > +   plane->max_width = icl_hdr_plane_max_width;
> > +   else
> > +   plane->max_width = icl_sdr_plane_max_width;
> > plane->max_height = icl_plane_max_height;
> > plane->min_cdclk = icl_plane_min_cdclk;
> > } else if (DISPLAY_VER(dev_priv) >= 10) {
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-11-30 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 11:40 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Tue, Nov 30, 2021 at 10:42:20PM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > v2: Addressed review comments from Ville. Added separate functions for
> > max_width - for HDR and SDR
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > ---
> >  .../gpu/drm/i915/display/skl_universal_plane.c  | 17
> > +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..d320a3ba1ade 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
> 
> Naming wise I would probably go with icl_hdr_plane_max_width() and
> icl_sdr_plane_max_width().
> 
> Reviewed-by: Ville Syrjälä 

Thank you very much Ville, for the patch review and RB. Have fixed the naming.

Regards
Vidya

> 
> > +  int color_plane,
> > +  unsigned int rotation)
> > +{
> > +   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +   else
> > +   return 5120;
> > +}
> > +
> > +static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct
> > drm_i915_private *dev_priv,
> >
> > if (DISPLAY_VER(dev_priv) >= 11) {
> > plane->min_width = icl_plane_min_width;
> > -   plane->max_width = icl_plane_max_width;
> > +   if (icl_is_hdr_plane(dev_priv, plane_id))
> > +   plane->max_width = icl_plane_max_width_hdr;
> > +   else
> > +   plane->max_width = icl_plane_max_width_sdr;
> > plane->max_height = icl_plane_max_height;
> > plane->min_cdclk = icl_plane_min_cdclk;
> > } else if (DISPLAY_VER(dev_priv) >= 10) {
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

2021-11-30 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 10:00 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Tue, Nov 30, 2021 at 09:35:34PM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > Change-Id: If629c478ba044c8bde633de9f0fc638aa6c44233
> > ---
> >  .../gpu/drm/i915/display/intel_display_types.h  |  3 ++-
> > .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +
> >  2 files changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ea1e8a6e10b0..0455ea340329 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1358,7 +1358,8 @@ struct intel_plane {
> > int (*min_width)(const struct drm_framebuffer *fb,
> >  int color_plane,
> >  unsigned int rotation);
> > -   int (*max_width)(const struct drm_framebuffer *fb,
> > +   int (*max_width)(struct intel_plane *plane,
> > +const struct drm_framebuffer *fb,
> >  int color_plane,
> >  unsigned int rotation);
> > int (*max_height)(const struct drm_framebuffer *fb, diff --git
> > a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..a49829c5a863 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -313,7 +313,8 @@ static int skl_plane_min_cdclk(const struct
> intel_crtc_state *crtc_state,
> > return DIV_ROUND_UP(pixel_rate * num, den);  }
> >
> > -static int skl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int skl_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -352,7 +353,8 @@ static int skl_plane_max_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int glk_plane_max_width(const struct drm_framebuffer *fb,
> > +static int glk_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -420,10 +422,17 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int icl_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > +   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > +
> > +   if (icl_is_hdr_plane(dev_priv, plane->id) &&
> 
> We could just have separate functions for hdr and sdr planes instead.

Thank you very much Ville, for the patch review. Have added two different 
functions as suggested.
Can you kindly have a check.
Sorry - Not sure why, I don't see the change reflect in patchwork website 
although I am seeing the mail. 

Regards
Vidya

> 
> > +   intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +
> > return 5120;
> >  }
> >
> > @@ -1377,7 +1386,7 @@ static int intel_plane_max_width(struct
> intel_plane *plane,
> >  unsigned int rotation)
> >  {
> > if (plane->max_width)
> > -   return plane->max_width(fb, color_plane, rotation);
> > +   return plane->max_width(plane, fb, color_plane, rotation);
> > else
> > return INT_MAX;
> >  }
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Reject 5k on HDR planes for planar fb formats

2021-11-30 Thread Srinivas, Vidya



> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 3:01 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Reject 5k on HDR planes for planar
> fb formats
> 
> On Thu, Nov 18, 2021 at 11:55:16AM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Reject 5k on HDR plane for planar formats like NV12 to let the user
> > space know about it.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out. Issue is seen on
> > both TGL and ADL platforms.
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > ---
> >  drivers/gpu/drm/i915/display/skl_scaler.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
> > b/drivers/gpu/drm/i915/display/skl_scaler.c
> > index 37eabeff8197..e2e52f5dca3b 100644
> > --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> > +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> > @@ -86,6 +86,7 @@ static u16 skl_scaler_calc_phase(int sub, int scale,
> > bool chroma_cosited)  #define ICL_MAX_DST_H 4096  #define
> > SKL_MIN_YUV_420_SRC_W 16  #define SKL_MIN_YUV_420_SRC_H 16
> > +#define MAX_CUSCTL_W 4096
> >
> >  static int
> >  skl_update_scaler(struct intel_crtc_state *crtc_state, bool
> > force_detach, @@ -221,6 +222,14 @@ int skl_update_scaler_plane(struct
> intel_crtc_state *crtc_state,
> > bool force_detach = !fb || !plane_state->uapi.visible;
> > bool need_scaler = false;
> >
> > +   /* PLANE_CUS_CTL size max 4096 */
> > +   if (icl_is_hdr_plane(dev_priv, intel_plane->id) &&
> > +   fb && intel_format_info_is_yuv_semiplanar(fb->format, fb-
> >modifier) &&
> > +   (drm_rect_width(_state->uapi.src) >> 16) >
> MAX_CUSCTL_W) {
> > +   DRM_ERROR("HDR chroma upsampler size exceeds
> limits\n");
> > +   return -EINVAL;
> > +   }
> 
> Wrong place. Should go into the plane->max_width() hook. There also seems
> to be a minimum height requirement for the CUS which we're not checking
> either.
> 
Thank you very much Ville for the patch review. Have moved the check to 
max_width.
Minimum horizontal should be 8 and vertical should be 4 - Haven't added in this 
yet.
Can you kindly have a check please 
https://patchwork.freedesktop.org/patch/464727/

Regards
Vidya

> > +
> > /* Pre-gen11 and SDR planes always need a scaler for planar
> formats. */
> > if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
> > fb && intel_format_info_is_yuv_semiplanar(fb->format,
> > fb->modifier))
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms

2021-07-13 Thread Srinivas, Vidya
Hello All,

Very sorry to bother you all again. Kindly can you help so that we can close on 
this please?
We have submitted both IGT and kernel patches. If none are okay, should we skip 
the subtest for panels which have width not 64 byte aligned for Intel platforms?

https://patchwork.freedesktop.org/patch/435794/  - IGT patch (we are aligning 
width itself as workaround due to missing alignment in VGEM before reaching 
i915)
https://patchwork.freedesktop.org/patch/436199/  - Kernel patch

Tejas has submitted another solution 
https://patchwork.freedesktop.org/patch/441967/ (256B alignment) - this too 
works.

Regards
Vidya

-Original Message-
From: Surendrakumar Upadhyay, TejaskumarX 
 
Sent: Monday, June 28, 2021 4:39 PM
To: Srinivas, Vidya ; Ville Syrjälä 

Cc: igt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Lin, 
Charlton 
Subject: RE: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms



> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Srinivas, Vidya
> Sent: 31 May 2021 20:18
> To: Ville Syrjälä 
> Cc: igt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; 
> Lin, Charlton 
> Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] 
> tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
> 
> Hello Ville,
> 
> Thank you very much.
> Before reaching our i915's i915_gem_dumb_create, it goes to 
> vgem_gem_dumb_create for kms_prime.
> 
> The pitch gets calculated there and it is not 64 byte aligned. Due to 
> this, intel_framebuffer_init reports "pitch must be 64 byte aligned"
> and framebuffer creation fails. I tried submitting vgem patch where 64 
> byte alignment can be done in vgem_gem_dumb_create and that also 
> passes. But we did not get approval yet as few of them felt, vgem is 
> generic and other platforms might fail if we do 64 byte alignment there.
> 
> Kindly suggest. Thanks a lot.
> 
> Regards
> Vidya
> 
> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, May 31, 2021 7:48 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
> Lin, Charlton 
> Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned 
> pitch to 64 byte for Intel platforms
> 
> On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> > For Intel platforms, pitch needs to be 64 byte aligned.
> > Kernel code vgem_gem_dumb_create which is platform generic code
> doesnt
> > do the alignment. This causes frame buffer creation to fail on Intel 
> > platforms where the pitch is not 64 byte aligned.
> >
> > tests: test run on Intel platforms with panel resolution 1366x768
> >
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  tests/kms_prime.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> > 8cb2ca2a9dc3..fdc941fe8100 100644
> > --- a/tests/kms_prime.c
> > +++ b/tests/kms_prime.c
> > @@ -51,6 +51,8 @@ static struct {
> > { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },  };
> >
> > +bool check_platform;
> > +
> >  IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
> >
> >  static bool has_prime_import(int fd) @@ -101,7 +103,7 @@ static 
> > void prepare_scratch(int exporter_fd, struct
> dumb_bo *scratch,
> > scratch->bpp = 32;
> >
> > scratch->handle = kmstest_dumb_create(exporter_fd,
> > -   scratch->width,
> > +   check_platform? ALIGN(scratch->width, 64): scratch-
> >width,
> 
> The dumb_create ioctl already does this for us.

I915_dumb_create does it for us but "vgem_gem_dumb_create" does not do 64 
ALIGN. And kms_prime is using "vgem_gem_dumb_create" never call i915 
dumb_create() as the IGT creates buffer through VGEM driver, see below IGT 
snippet :

/* ANY = anything that is not VGEM */
first_fd = __drm_open_driver_another(0, DRIVER_ANY | 
DRIVER_VGEM);
igt_require(first_fd >= 0);

second_fd = __drm_open_driver_another(1, DRIVER_ANY | 
DRIVER_VGEM);

Thanks,
Tejas
> 
> > scratch->height,
> > scratch->bpp,
> > >pitch,
> > @@ -262,6 +264,7 @@ igt_main
> >
> > /* ANY = anything that is not VGEM */
> > first_fd = __drm_open_driver_another(0, DRIVER_ANY |
> DRIVER_VGEM);
> > +   check_platform = is_i915_device(first_fd);
> > igt_require(first_fd >= 0);
> >
> > second_fd

Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer

2021-06-21 Thread Srinivas, Vidya
Thank you so much Petri.

Regards
Vidya

-Original Message-
From: Latvala, Petri  
Sent: Monday, June 21, 2021 3:59 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
markyac...@chromium.org; Lin, Charlton 
Subject: Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest 
invalid-buffer

On Fri, May 28, 2021 at 10:02:47AM +0530, Vidya Srinivas wrote:
> Using (void *)-1 directly in read is aborting on chrome systems.
> Following message is seen.
> 
> Starting subtest: invalid-buffer
> *** buffer overflow detected ***: terminated Received signal SIGABRT.
> Stack trace:
> Aborted (core dumped)
> 
> Patch just adds a pointer variable and uses it in read.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/drm_read.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/drm_read.c b/tests/drm_read.c index 
> ccf9d822fd8d..2fdec5be4078 100644
> --- a/tests/drm_read.c
> +++ b/tests/drm_read.c
> @@ -103,10 +103,11 @@ static void teardown(int fd)  static void 
> test_invalid_buffer(int in)  {
>   int fd = setup(in, 0);
> + void *add = (void *)-1;
>  
>   alarm(1);
>  
> - igt_assert_eq(read(fd, (void *)-1, 4096), -1);
> + igt_assert_eq(read(fd, add, 4096), -1);
>   igt_assert_eq(errno, EFAULT);
>  
>   teardown(fd);

This looked weird but then I checked what glibc is actually doing. This is 
FORTIFY_SOURCE in action, and read() checks the buffer with 
__builtin_object_size() that it has room for the read. Which it can only do 
here if the address is a literal.

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


Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

2021-06-18 Thread Srinivas, Vidya
Hello,

Humble request for review of this please 
https://patchwork.freedesktop.org/series/90828/
Can anyone kindly help review this so we can request for merge?

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Tuesday, June 15, 2021 1:55 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: Shankar, Uma 
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Hello Bhanu,

Sorry for the trouble. Kindly can you check if rev 3 is okay? Thanks a lot.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 6:28 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Hello Bhanu,

I have uploaded version 3 where I have not removed primary plane.
Instead I have added a commit of the primary plane and I have changed alpha.
This passes on Gen11 systems.

Kindly check https://patchwork.freedesktop.org/patch/438831/?series=90828=3 
and suggest.

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 1:00 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash 
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = >display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, >argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> 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 i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

2021-06-15 Thread Srinivas, Vidya
Hello Bhanu,

Sorry for the trouble. Kindly can you check if rev 3 is okay? Thanks a lot.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Friday, June 11, 2021 6:28 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Hello Bhanu,

I have uploaded version 3 where I have not removed primary plane.
Instead I have added a commit of the primary plane and I have changed alpha.
This passes on Gen11 systems.

Kindly check https://patchwork.freedesktop.org/patch/438831/?series=90828=3 
and suggest.

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 1:00 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash 
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = >display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, >argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> 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 i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

2021-06-11 Thread Srinivas, Vidya
Hello Bhanu,

I have uploaded version 3 where I have not removed primary plane.
Instead I have added a commit of the primary plane and I have changed alpha.
This passes on Gen11 systems.

Kindly check https://patchwork.freedesktop.org/patch/438831/?series=90828=3 
and suggest.

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Friday, June 11, 2021 1:00 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash 
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = >display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, >argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> 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] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms

2021-06-11 Thread Srinivas, Vidya
Hello Ville,

Apologies for bothering you.
Kms_prime goes through vgem_gem_dumb_create where the pitch gets calculated 
which is not 64 byte aligned.

kms_prime->vgem_gem_dumb_create->intel_framebuffer_init which reports plane 0 
pitch (5464) must be at least 64 byte aligned.

We have submitted this patch for kernel 
https://patchwork.freedesktop.org/patch/436199/ also for the same.
If we try to align stride in IGT after it gets back from vgem_gem_dumb_ioctl, 
Kernel gives error - [drm:intel_fill_fb_info] fb too big for bo (need 4227072 
bytes, have 4198400 bytes).

As a workaround (if the above kernel patch does not go through) we submitted 
this https://patchwork.freedesktop.org/patch/435794/.

Can you kindly help suggest which is the better way? If not both - kindly guide 
us how we can address this issue. Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Monday, May 31, 2021 8:18 PM
To: 'Ville Syrjälä' 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin, 
Charlton 
Subject: RE: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

Hello Ville,

Thank you very much.
Before reaching our i915's i915_gem_dumb_create, it goes to 
vgem_gem_dumb_create for kms_prime.

The pitch gets calculated there and it is not 64 byte aligned. Due to this, 
intel_framebuffer_init reports "pitch must be 64 byte aligned"
and framebuffer creation fails. I tried submitting vgem patch where 64 byte 
alignment can be done in vgem_gem_dumb_create and that also passes. But we did 
not get approval yet as few of them felt, vgem is generic and other platforms 
might fail if we do 64 byte alignment there.

Kindly suggest. Thanks a lot.

Regards
Vidya

-Original Message-
From: Ville Syrjälä 
Sent: Monday, May 31, 2021 7:48 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin, 
Charlton 
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code doesnt 
> do the alignment. This causes frame buffer creation to fail on Intel 
> platforms where the pitch is not 64 byte aligned.
> 
> tests: test run on Intel platforms with panel resolution 1366x768
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_prime.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> 8cb2ca2a9dc3..fdc941fe8100 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -51,6 +51,8 @@ static struct {
>   { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },  };
>  
> +bool check_platform;
> +
>  IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
>  
>  static bool has_prime_import(int fd)
> @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct 
> dumb_bo *scratch,
>   scratch->bpp = 32;
>  
>   scratch->handle = kmstest_dumb_create(exporter_fd,
> - scratch->width,
> + check_platform? ALIGN(scratch->width, 64): 
> scratch->width,

The dumb_create ioctl already does this for us.

>   scratch->height,
>   scratch->bpp,
>   >pitch,
> @@ -262,6 +264,7 @@ igt_main
>  
>   /* ANY = anything that is not VGEM */
>   first_fd = __drm_open_driver_another(0, DRIVER_ANY | 
> DRIVER_VGEM);
> + check_platform = is_i915_device(first_fd);
>   igt_require(first_fd >= 0);
>  
>   second_fd = __drm_open_driver_another(1, DRIVER_ANY | 
> DRIVER_VGEM);
> --
> 2.7.4
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

--
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 i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

2021-06-11 Thread Srinivas, Vidya
Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash  
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749 
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = >display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, >argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> 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] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-10 Thread Srinivas, Vidya
Thank you so much Petri. I see it’s a PASS for almost everything except on one 
GLK.

Regards
Vidya

-Original Message-
From: Latvala, Petri  
Sent: Thursday, June 10, 2021 2:21 PM
To: Srinivas, Vidya 
Cc: juhapekka.heikk...@gmail.com; Modem, Bhanuprakash 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org; Lin, Charlton 
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

On Thu, Jun 10, 2021 at 08:38:42AM +, Srinivas, Vidya wrote:
> Hello Juha-Pekka,
> 
> https://patchwork.freedesktop.org/series/90389/#rev7 shows PASS for all CI.
> However I don’t see kms_big_fb all the subtests running in CI. In the 
> logs I see pass for linear-32bpp-rotate-0

The default view in the CI results only shows tests that have issues. "view -> 
shards all" from the top shows all tests.

https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5907/shards-all.html?testfilter=kms_big_fb


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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-10 Thread Srinivas, Vidya
Hello Juha-Pekka,

https://patchwork.freedesktop.org/series/90389/#rev7 shows PASS for all CI.
However I don’t see kms_big_fb all the subtests running in CI. In the logs I 
see pass for linear-32bpp-rotate-0

May I include your Reviewed by to take it further? Please suggest. Thank you so 
much.

Regards
Vidya

-Original Message-
From: Juha-Pekka Heikkila  
Sent: Tuesday, June 8, 2021 5:21 PM
To: Srinivas, Vidya ; Modem, Bhanuprakash 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

On 8.6.2021 12.19, Srinivas, Vidya wrote:
> Hello Juha-Pekka
> 
> Instead of wait for vblank, this also works igt_pipe_crc_start-> 
> igt_pipe_crc_get_current for small fb after commit -> then 
> igt_pipe_crc_get_current For big fb -> compare -> igt_pipe_crc_stop
> 
> Would this change be okay? Kindly suggest. igt_pipe_crc_collect_crc is 
> not working. It gives CRC mismatch for few subtests like subtest 
> y-tiled-32bpp-rotate-0

This change is ok. It kind of implies there maybe is some problem on your 
platform with starting of crc calculation but if this is only place where it 
will show I'm ok with that since crc will not affect normal users in any way.

I noticed your new patch, lets see how all ci machines behave on that before 
doing anything else.

/Juha-Pekka

> 
> Have submitted the change here 
> https://patchwork.freedesktop.org/patch/437657/?series=90389=6
> 
> Thank you so much.
> 
> Regards
> Vidya
> 
> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, June 8, 2021 1:19 PM
> To: juhapekka.heikk...@gmail.com; Modem, Bhanuprakash 
> ; intel-gfx@lists.freedesktop.org; 
> igt-...@lists.freedesktop.org
> Cc: Lin, Charlton 
> Subject: RE: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] 
> tests/kms_big_fb: Wait for vblank before collecting CRC
> 
> Hello Juha-Pekka and Bhanu
> 
> Thank you for the review comments. Apologies Juha-Pekka, I will incorporate 
> your review comments and try out.
> 
> Regards
> Vidya
> 
> 
> -Original Message-
> From: Juha-Pekka Heikkila 
> Sent: Tuesday, June 8, 2021 1:04 PM
> To: Modem, Bhanuprakash ; Srinivas, 
> Vidya ; intel-gfx@lists.freedesktop.org; 
> igt-...@lists.freedesktop.org
> Cc: Lin, Charlton 
> Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] 
> tests/kms_big_fb: Wait for vblank before collecting CRC
> 
> On 8.6.2021 10.01, Modem, Bhanuprakash wrote:
>>> From: Intel-gfx  On Behalf 
>>> Of Vidya Srinivas
>>> Sent: Friday, May 28, 2021 9:57 AM
>>> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
>>> Cc: markyac...@chromium.org; Lin, Charlton 
>>> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for 
>>> vblank before collecting CRC
>>>
>>> Without wait for vblank, CRC mismatch is seen between big and small 
>>> CRC on few Gen11 systems.
>>>
>>> Signed-off-by: Vidya Srinivas 
>>> ---
>>>tests/kms_big_fb.c | 6 --
>>>1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
>>> b35727a09bd0..f90363c3beb2 100644
>>> --- a/tests/kms_big_fb.c
>>> +++ b/tests/kms_big_fb.c
>>> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>>>static bool test_plane(data_t *data)
>>>{
>>> igt_plane_t *plane = data->plane;
>>> +   igt_display_t *display = >display;
>>
>> For code readability purpose, I think we need to update to use this 
>> variable wherever we are using ">display" in this function.
>> s/">display"/"display"/
>>
>> With above change, this patch LGTM
>> Reviewed-by: Bhanuprakash Modem 
>>
> 
> I still don't see benefit in this patch. For now all this look like is doing 
> is slow down the test and if this actually helps there's a real bug somewhere 
> which is not here. My earlier review comments were not addressed hence repeat 
> here, see below.
> 
> 
>>> struct igt_fb *small_fb = >small_fb;
>>> struct igt_fb *big_fb = >big_fb;
>>> int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 
>>> @@ static bool test_plane(data_t *data)
>>> igt_display_commit2(>display, data->display.is_atomic ?
>>> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>>>
>>> -
>>> +   igt_wait_for_vblank(data->drm_fd,
>>> +displa

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-08 Thread Srinivas, Vidya
Thank you so much Juha-Pekka.

Regards
Vidya

-Original Message-
From: Juha-Pekka Heikkila  
Sent: Tuesday, June 8, 2021 5:21 PM
To: Srinivas, Vidya ; Modem, Bhanuprakash 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

On 8.6.2021 12.19, Srinivas, Vidya wrote:
> Hello Juha-Pekka
> 
> Instead of wait for vblank, this also works igt_pipe_crc_start-> 
> igt_pipe_crc_get_current for small fb after commit -> then 
> igt_pipe_crc_get_current For big fb -> compare -> igt_pipe_crc_stop
> 
> Would this change be okay? Kindly suggest. igt_pipe_crc_collect_crc is 
> not working. It gives CRC mismatch for few subtests like subtest 
> y-tiled-32bpp-rotate-0

This change is ok. It kind of implies there maybe is some problem on your 
platform with starting of crc calculation but if this is only place where it 
will show I'm ok with that since crc will not affect normal users in any way.

I noticed your new patch, lets see how all ci machines behave on that before 
doing anything else.

/Juha-Pekka

> 
> Have submitted the change here 
> https://patchwork.freedesktop.org/patch/437657/?series=90389=6
> 
> Thank you so much.
> 
> Regards
> Vidya
> 
> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, June 8, 2021 1:19 PM
> To: juhapekka.heikk...@gmail.com; Modem, Bhanuprakash 
> ; intel-gfx@lists.freedesktop.org; 
> igt-...@lists.freedesktop.org
> Cc: Lin, Charlton 
> Subject: RE: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] 
> tests/kms_big_fb: Wait for vblank before collecting CRC
> 
> Hello Juha-Pekka and Bhanu
> 
> Thank you for the review comments. Apologies Juha-Pekka, I will incorporate 
> your review comments and try out.
> 
> Regards
> Vidya
> 
> 
> -Original Message-
> From: Juha-Pekka Heikkila 
> Sent: Tuesday, June 8, 2021 1:04 PM
> To: Modem, Bhanuprakash ; Srinivas, 
> Vidya ; intel-gfx@lists.freedesktop.org; 
> igt-...@lists.freedesktop.org
> Cc: Lin, Charlton 
> Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] 
> tests/kms_big_fb: Wait for vblank before collecting CRC
> 
> On 8.6.2021 10.01, Modem, Bhanuprakash wrote:
>>> From: Intel-gfx  On Behalf 
>>> Of Vidya Srinivas
>>> Sent: Friday, May 28, 2021 9:57 AM
>>> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
>>> Cc: markyac...@chromium.org; Lin, Charlton 
>>> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for 
>>> vblank before collecting CRC
>>>
>>> Without wait for vblank, CRC mismatch is seen between big and small 
>>> CRC on few Gen11 systems.
>>>
>>> Signed-off-by: Vidya Srinivas 
>>> ---
>>>tests/kms_big_fb.c | 6 --
>>>1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
>>> b35727a09bd0..f90363c3beb2 100644
>>> --- a/tests/kms_big_fb.c
>>> +++ b/tests/kms_big_fb.c
>>> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>>>static bool test_plane(data_t *data)
>>>{
>>> igt_plane_t *plane = data->plane;
>>> +   igt_display_t *display = >display;
>>
>> For code readability purpose, I think we need to update to use this 
>> variable wherever we are using ">display" in this function.
>> s/">display"/"display"/
>>
>> With above change, this patch LGTM
>> Reviewed-by: Bhanuprakash Modem 
>>
> 
> I still don't see benefit in this patch. For now all this look like is doing 
> is slow down the test and if this actually helps there's a real bug somewhere 
> which is not here. My earlier review comments were not addressed hence repeat 
> here, see below.
> 
> 
>>> struct igt_fb *small_fb = >small_fb;
>>> struct igt_fb *big_fb = >big_fb;
>>> int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 
>>> @@ static bool test_plane(data_t *data)
>>> igt_display_commit2(>display, data->display.is_atomic ?
>>> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>>>
>>> -
>>> +   igt_wait_for_vblank(data->drm_fd,
>>> +display->pipes[data->pipe].crtc_offset);
> 
> Above this line there's flip to different fb. Below this line crc calculation 
> is restarted, get one crc and stop crc. There's several vblanks already spent 
> here, if now adding one more somehow helps it sound like there's

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-08 Thread Srinivas, Vidya
Hello Juha-Pekka

Instead of wait for vblank, this also works
igt_pipe_crc_start-> igt_pipe_crc_get_current for small fb after commit -> then 
igt_pipe_crc_get_current For big fb -> compare -> igt_pipe_crc_stop

Would this change be okay? Kindly suggest. igt_pipe_crc_collect_crc is not 
working. It gives CRC mismatch for few subtests like subtest 
y-tiled-32bpp-rotate-0

Have submitted the change here 
https://patchwork.freedesktop.org/patch/437657/?series=90389=6

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Tuesday, June 8, 2021 1:19 PM
To: juhapekka.heikk...@gmail.com; Modem, Bhanuprakash 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: RE: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

Hello Juha-Pekka and Bhanu

Thank you for the review comments. Apologies Juha-Pekka, I will incorporate 
your review comments and try out.

Regards
Vidya


-Original Message-
From: Juha-Pekka Heikkila 
Sent: Tuesday, June 8, 2021 1:04 PM
To: Modem, Bhanuprakash ; Srinivas, Vidya 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

On 8.6.2021 10.01, Modem, Bhanuprakash wrote:
>> From: Intel-gfx  On Behalf 
>> Of Vidya Srinivas
>> Sent: Friday, May 28, 2021 9:57 AM
>> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
>> Cc: markyac...@chromium.org; Lin, Charlton 
>> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for 
>> vblank before collecting CRC
>>
>> Without wait for vblank, CRC mismatch is seen between big and small 
>> CRC on few Gen11 systems.
>>
>> Signed-off-by: Vidya Srinivas 
>> ---
>>   tests/kms_big_fb.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
>> b35727a09bd0..f90363c3beb2 100644
>> --- a/tests/kms_big_fb.c
>> +++ b/tests/kms_big_fb.c
>> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>>   static bool test_plane(data_t *data)
>>   {
>>  igt_plane_t *plane = data->plane;
>> +igt_display_t *display = >display;
> 
> For code readability purpose, I think we need to update to use this 
> variable wherever we are using ">display" in this function.
> s/">display"/"display"/
> 
> With above change, this patch LGTM
> Reviewed-by: Bhanuprakash Modem 
> 

I still don't see benefit in this patch. For now all this look like is doing is 
slow down the test and if this actually helps there's a real bug somewhere 
which is not here. My earlier review comments were not addressed hence repeat 
here, see below.


>>  struct igt_fb *small_fb = >small_fb;
>>  struct igt_fb *big_fb = >big_fb;
>>  int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 
>> @@ static bool test_plane(data_t *data)
>>  igt_display_commit2(>display, data->display.is_atomic ?
>>  COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>>
>> -
>> +igt_wait_for_vblank(data->drm_fd,
>> +display->pipes[data->pipe].crtc_offset);

Above this line there's flip to different fb. Below this line crc calculation 
is restarted, get one crc and stop crc. There's several vblanks already spent 
here, if now adding one more somehow helps it sound like there's problems in 
crc calculation on some platform or kernel is saying too early framebuffer is 
ready to be shown. Am I missing something here?

/Juha-Pekka

>>  igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>>
>>  igt_plane_set_fb(plane, big_fb);
>>  igt_fb_set_position(big_fb, plane, x, y);
>>  igt_fb_set_size(big_fb, plane, small_fb->width, 
>> small_fb->height);
>> +

spurious empty line need to be removed.

>>  igt_plane_set_size(plane, data->width, data->height);
>>  igt_display_commit2(>display, data->display.is_atomic ?
>>  COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>> -
>> +igt_wait_for_vblank(data->drm_fd, 
>> +display->pipes[data->pipe].crtc_offset);
>>  igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>>
>>  igt_plane_set_fb(plane, NULL);
>> --
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-08 Thread Srinivas, Vidya
Hello Juha-Pekka and Bhanu

Thank you for the review comments. Apologies Juha-Pekka, I will incorporate 
your review comments and try out.

Regards
Vidya


-Original Message-
From: Juha-Pekka Heikkila  
Sent: Tuesday, June 8, 2021 1:04 PM
To: Modem, Bhanuprakash ; Srinivas, Vidya 
; intel-gfx@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait 
for vblank before collecting CRC

On 8.6.2021 10.01, Modem, Bhanuprakash wrote:
>> From: Intel-gfx  On Behalf 
>> Of Vidya Srinivas
>> Sent: Friday, May 28, 2021 9:57 AM
>> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
>> Cc: markyac...@chromium.org; Lin, Charlton 
>> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for 
>> vblank before collecting CRC
>>
>> Without wait for vblank, CRC mismatch is seen between big and small 
>> CRC on few Gen11 systems.
>>
>> Signed-off-by: Vidya Srinivas 
>> ---
>>   tests/kms_big_fb.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index 
>> b35727a09bd0..f90363c3beb2 100644
>> --- a/tests/kms_big_fb.c
>> +++ b/tests/kms_big_fb.c
>> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>>   static bool test_plane(data_t *data)
>>   {
>>  igt_plane_t *plane = data->plane;
>> +igt_display_t *display = >display;
> 
> For code readability purpose, I think we need to update to use this 
> variable wherever we are using ">display" in this function.
> s/">display"/"display"/
> 
> With above change, this patch LGTM
> Reviewed-by: Bhanuprakash Modem 
> 

I still don't see benefit in this patch. For now all this look like is doing is 
slow down the test and if this actually helps there's a real bug somewhere 
which is not here. My earlier review comments were not addressed hence repeat 
here, see below.


>>  struct igt_fb *small_fb = >small_fb;
>>  struct igt_fb *big_fb = >big_fb;
>>  int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 
>> @@ static bool test_plane(data_t *data)
>>  igt_display_commit2(>display, data->display.is_atomic ?
>>  COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>>
>> -
>> +igt_wait_for_vblank(data->drm_fd, 
>> +display->pipes[data->pipe].crtc_offset);

Above this line there's flip to different fb. Below this line crc calculation 
is restarted, get one crc and stop crc. There's several vblanks already spent 
here, if now adding one more somehow helps it sound like there's problems in 
crc calculation on some platform or kernel is saying too early framebuffer is 
ready to be shown. Am I missing something here?

/Juha-Pekka

>>  igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>>
>>  igt_plane_set_fb(plane, big_fb);
>>  igt_fb_set_position(big_fb, plane, x, y);
>>  igt_fb_set_size(big_fb, plane, small_fb->width, 
>> small_fb->height);
>> +

spurious empty line need to be removed.

>>  igt_plane_set_size(plane, data->width, data->height);
>>  igt_display_commit2(>display, data->display.is_atomic ?
>>  COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>> -
>> +igt_wait_for_vblank(data->drm_fd, 
>> +display->pipes[data->pipe].crtc_offset);
>>  igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>>
>>  igt_plane_set_fb(plane, NULL);
>> --
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 

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


Re: [Intel-gfx] [PATCH i-g-t] tests/kms_color: Disable gamma in degamma tests

2021-06-08 Thread Srinivas, Vidya
Thank you very much Bhanu for the review.
I have fixed all the comments, added your RB and submitted series 
https://patchwork.freedesktop.org/series/91145/

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash  
Sent: Tuesday, June 8, 2021 12:17 PM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: markyac...@chromium.org; Almahallawy, Khaled 
; Lin, Charlton ; 
Latvala, Petri ; Shankar, Uma 
Subject: RE: [PATCH i-g-t] tests/kms_color: Disable gamma in degamma tests

> From: Srinivas, Vidya 
> Sent: Monday, June 7, 2021 9:18 AM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Cc: markyac...@chromium.org; Almahallawy, Khaled 
> ; Lin, Charlton 
> ; Latvala, Petri ; 
> Modem, Bhanuprakash ; Shankar, Uma 
> ; Srinivas, Vidya 
> Subject: [PATCH i-g-t] tests/kms_color: Disable gamma in degamma tests
> 
> This patch disables gamma in degamma subtest which is missing.
> It compares CRC between (linear degamma + solid colors) and (max 
> degamma + gradient colors). Patch also cleans up degamma before 
> exiting degamma test and cleans up gamma before exiting gamma test.
> 
> v2 - Addressed review comments from Bhanuprakash Modem Changed full 
> degamma for reference CRC to linear degamma Added clean up of degamma 
> end of degamma test.
> 
> v3 - Addressed review comments from Bhanuprakash Modem Ported changes 
> to kms_color_chamelium
> 
> Change-Id: Ibdb91b603e2e4024d170727d24c6a5425441e2e1
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_color.c   | 14 +++---
>  tests/kms_color_chamelium.c | 12 ++--
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/tests/kms_color.c b/tests/kms_color.c index 
> 3a42532a5c27..1b021ac3ce0c 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -32,7 +32,6 @@ static void test_pipe_degamma(data_t *data,
>   igt_output_t *output;
>   igt_display_t *display = >display;
>   gamma_lut_t *degamma_linear, *degamma_full;
> - gamma_lut_t *gamma_linear;
>   color_t red_green_blue[] = {
>   { 1.0, 0.0, 0.0 },
>   { 0.0, 1.0, 0.0 },
> @@ -45,8 +44,6 @@ static void test_pipe_degamma(data_t *data,
>   degamma_linear = generate_table(data->degamma_lut_size, 1.0);
>   degamma_full = generate_table_max(data->degamma_lut_size);
> 
> - gamma_linear = generate_table(data->gamma_lut_size, 1.0);
> -
>   for_each_valid_output_on_pipe(>display, primary->pipe->pipe,
> output) {
>   drmModeModeInfo *mode;
>   struct igt_fb fb_modeset, fb;
> @@ -75,11 +72,11 @@ static void test_pipe_degamma(data_t *data,
> 
>   igt_plane_set_fb(primary, _modeset);
>   disable_ctm(primary->pipe);
> - disable_degamma(primary->pipe);
> - set_gamma(data, primary->pipe, gamma_linear);
> + disable_gamma(primary->pipe);
> + set_degamma(data, primary->pipe, degamma_linear);
>   igt_display_commit(>display);
> 
> - /* Draw solid colors with no degamma transformation. */
> + /* Draw solid colors with linear degamma transformation. */
>   paint_rectangles(data, mode, red_green_blue, );
>   igt_plane_set_fb(primary, );
>   igt_display_commit(>display);
> @@ -103,15 +100,16 @@ static void test_pipe_degamma(data_t *data,
>*/
>   igt_assert_crc_equal(_fullgamma, _fullcolors);
> 
> + disable_degamma(primary->pipe);
>   igt_plane_set_fb(primary, NULL);
>   igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit(>display);
>   igt_remove_fb(data->drm_fd, );
>   igt_remove_fb(data->drm_fd, _modeset);
>   }
> 
>   free_lut(degamma_linear);
>   free_lut(degamma_full);
> - free_lut(gamma_linear);
>  }
> 
>  /*
> @@ -189,8 +187,10 @@ static void test_pipe_gamma(data_t *data,
>*/
>   igt_assert_crc_equal(_fullgamma, _fullcolors);
> 
> + disable_gamma(primary->pipe);
>   igt_plane_set_fb(primary, NULL);
>   igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit(>display);
>   igt_remove_fb(data->drm_fd, );
>   igt_remove_fb(data->drm_fd, _modeset);
>   }
> diff --git a/tests/kms_color_chamelium.c b/tests/kms_color_chamelium.c 
> index 30b38b82e306..c21d64e9cc9a 100644
> --- a/tests/kms_color_chamelium.c
> +++ b/tests/kms_color_chamelium.c
> @@ -36,7 +36,6 @@ static void test_pipe_degamma(data_t

Re: [Intel-gfx] [PATCH] tests/kms_color: Disable gamma in degamma tests

2021-06-06 Thread Srinivas, Vidya
Thank you very much Bhanu for the review comments. I have addressed the review 
comments and resubmitted the patch.
Have also ported the changed to chamelium. Kindly have a check.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash  
Sent: Sunday, June 6, 2021 2:39 PM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: markyac...@chromium.org; Almahallawy, Khaled 
; Lin, Charlton ; 
Latvala, Petri ; Shankar, Uma 
Subject: RE: [PATCH] tests/kms_color: Disable gamma in degamma tests

> From: Srinivas, Vidya 
> Sent: Friday, June 4, 2021 6:41 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Cc: markyac...@chromium.org; Almahallawy, Khaled 
> ; Lin, Charlton 
> ; Latvala, Petri ; 
> Modem, Bhanuprakash ; Shankar, Uma 
> ; Srinivas, Vidya 
> Subject: [PATCH] tests/kms_color: Disable gamma in degamma tests
> 
> This patch disables gamma in degamma subtest which is missing.
> It compares CRC between (linear degamma + solid colors) and (max 
> degamma + gradient colors).
> 
> v2 - Addressed review comments from Bhanuprakash Modem
> 
> Signed-off-by: Vidya Srinivas 
> Change-Id: Ibdb91b603e2e4024d170727d24c6a5425441e2e1
> ---
>  tests/kms_color.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/kms_color.c b/tests/kms_color.c index 
> 3a42532a5c27..41720dcdd90f 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -32,7 +32,6 @@ static void test_pipe_degamma(data_t *data,
>   igt_output_t *output;
>   igt_display_t *display = >display;
>   gamma_lut_t *degamma_linear, *degamma_full;
> - gamma_lut_t *gamma_linear;
>   color_t red_green_blue[] = {
>   { 1.0, 0.0, 0.0 },
>   { 0.0, 1.0, 0.0 },
> @@ -45,8 +44,6 @@ static void test_pipe_degamma(data_t *data,
>   degamma_linear = generate_table(data->degamma_lut_size, 1.0);
>   degamma_full = generate_table_max(data->degamma_lut_size);
> 
> - gamma_linear = generate_table(data->gamma_lut_size, 1.0);
> -
>   for_each_valid_output_on_pipe(>display, primary->pipe->pipe,
> output) {
>   drmModeModeInfo *mode;
>   struct igt_fb fb_modeset, fb;
> @@ -75,8 +72,8 @@ static void test_pipe_degamma(data_t *data,
> 
>   igt_plane_set_fb(primary, _modeset);
>   disable_ctm(primary->pipe);
> - disable_degamma(primary->pipe);
> - set_gamma(data, primary->pipe, gamma_linear);
> + disable_gamma(primary->pipe);
> + set_degamma(data, primary->pipe, degamma_linear);
>   igt_display_commit(>display);
> 
>   /* Draw solid colors with no degamma transformation. */

Please fix the comment s/"no degamma"/"linear degamma"/.
Also, we need to port this patch on "kms_color_chamelium".

> @@ -103,15 +100,17 @@ static void test_pipe_degamma(data_t *data,
>*/
>   igt_assert_crc_equal(_fullgamma, _fullcolors);
> 
> + disable_degamma(primary->pipe);
>   igt_plane_set_fb(primary, NULL);
>   igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC : 
> COMMIT_LEGACY);
>   igt_remove_fb(data->drm_fd, );
>   igt_remove_fb(data->drm_fd, _modeset);
>   }
> 
>   free_lut(degamma_linear);
>   free_lut(degamma_full);
> - free_lut(gamma_linear);
>  }
> 
>  /*
> @@ -189,8 +188,11 @@ static void test_pipe_gamma(data_t *data,
>*/
>   igt_assert_crc_equal(_fullgamma, _fullcolors);
> 
> + disable_gamma(primary->pipe);
>   igt_plane_set_fb(primary, NULL);
>   igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC : 
> COMMIT_LEGACY);
 
These changes are not relevant to the degamma, but still we need these changes.
It would be good if we mention this in commit message.

With above changes, this patch is
Reviewed-by: Bhanuprakash Modem 

- Bhanu
>   igt_remove_fb(data->drm_fd, );
>   igt_remove_fb(data->drm_fd, _modeset);
>   }
> --
> 2.26.2

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix coverage-vs-premult-vs-constant tests

2021-06-04 Thread Srinivas, Vidya
Thank you very much Mark, for testing the patch and providing the "Tested-by" 
tag.

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Saturday, June 5, 2021 12:12 AM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix 
coverage-vs-premult-vs-constant tests

On Tue, Jun 1, 2021 at 7:54 AM Vidya Srinivas  wrote:
>
> Few Gen11 systems show CRC mismatch. Make 
> coverage-vs-premult-vs-constant code similar to constant_alpha_min or 
> basic_alpha
>
Tested on ChromeOS on JSL (Drawlat)
Tested-by: Mark Yacoub 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749 
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t *data, enum 
> pipe pipe, igt_plane_t
> igt_display_t *display = >display;
> igt_crc_t ref_crc = {}, crc = {};
>
> -   /* Set a background color on the primary fb for testing */
> -   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> -   
> igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe], 
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
> igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, 
> "Coverage");
> igt_plane_set_fb(plane, >argb_fb_cov_7e);
> igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer

2021-06-04 Thread Srinivas, Vidya
Thank you very much Mark, for testing the patch and providing the "Tested-by" 
tag.

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Saturday, June 5, 2021 12:13 AM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
Almahallawy, Khaled ; Lin, Charlton 

Subject: Re: [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer

On Fri, May 28, 2021 at 12:41 AM Vidya Srinivas  
wrote:
>
> Using (void *)-1 directly in read is aborting on chrome systems.
> Following message is seen.
>
> Starting subtest: invalid-buffer
> *** buffer overflow detected ***: terminated Received signal SIGABRT.
> Stack trace:
> Aborted (core dumped)
>
> Patch just adds a pointer variable and uses it in read.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/drm_read.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/drm_read.c b/tests/drm_read.c index 
> ccf9d822fd8d..2fdec5be4078 100644
> --- a/tests/drm_read.c
> +++ b/tests/drm_read.c
> @@ -103,10 +103,11 @@ static void teardown(int fd)  static void 
> test_invalid_buffer(int in)  {
> int fd = setup(in, 0);
> +   void *add = (void *)-1;
>
> alarm(1);
>
> -   igt_assert_eq(read(fd, (void *)-1, 4096), -1);
> +   igt_assert_eq(read(fd, add, 4096), -1);
> igt_assert_eq(errno, EFAULT);
>
> teardown(fd);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-06-04 Thread Srinivas, Vidya
Thank you very much Mark, for testing the patch and providing the "Tested-by" 
tag.

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Saturday, June 5, 2021 12:20 AM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
Almahallawy, Khaled ; Lin, Charlton 

Subject: Re: [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before 
collecting CRC

On Fri, May 28, 2021 at 12:36 AM Vidya Srinivas  
wrote:
>
> Without wait for vblank, CRC mismatch is seen between big and small 
> CRC on few Gen11 systems.
>
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_big_fb.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index 
> b35727a09bd0..f90363c3beb2 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)  static bool 
> test_plane(data_t *data)  {
> igt_plane_t *plane = data->plane;
> +   igt_display_t *display = >display;
> struct igt_fb *small_fb = >small_fb;
> struct igt_fb *big_fb = >big_fb;
> int w = data->big_fb_width - small_fb->width; @@ -337,16 
> +338,17 @@ static bool test_plane(data_t *data)
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>
> -
> +   igt_wait_for_vblank(data->drm_fd, 
> + display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, big_fb);
> igt_fb_set_position(big_fb, plane, x, y);
> igt_fb_set_size(big_fb, plane, small_fb->width, 
> small_fb->height);
> +
> igt_plane_set_size(plane, data->width, data->height);
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> +   igt_wait_for_vblank(data->drm_fd, 
> + display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, NULL);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms

2021-06-04 Thread Srinivas, Vidya
Thank you very much Mark, for testing the patch and providing the "Tested-by" 
tag.
I shall incorporate you review comments and submit the patch.

Additionally, we have submitted the kernel alternative 
https://patchwork.freedesktop.org/patch/436199/

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Saturday, June 5, 2021 12:24 AM
To: Srinivas, Vidya 
Cc: Ville Syrjälä ; 
igt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Lin, Charlton 

Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

On Mon, May 31, 2021 at 10:47 AM Srinivas, Vidya  
wrote:
>
> Hello Ville,
>
> Thank you very much.
> Before reaching our i915's i915_gem_dumb_create, it goes to 
> vgem_gem_dumb_create for kms_prime.
>
> The pitch gets calculated there and it is not 64 byte aligned. Due to this, 
> intel_framebuffer_init reports "pitch must be 64 byte aligned"
> and framebuffer creation fails. I tried submitting vgem patch where 64 
> byte alignment can be done in vgem_gem_dumb_create and that also passes. But 
> we did not get approval yet as few of them felt, vgem is generic and other 
> platforms might fail if we do 64 byte alignment there.
>
> Kindly suggest. Thanks a lot.
>
> Regards
> Vidya
>
> -Original Message-----
> From: Ville Syrjälä 
> Sent: Monday, May 31, 2021 7:48 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
> Lin, Charlton 
> Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned 
> pitch to 64 byte for Intel platforms
>
> On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> > For Intel platforms, pitch needs to be 64 byte aligned.
> > Kernel code vgem_gem_dumb_create which is platform generic code 
> > doesnt do the alignment. This causes frame buffer creation to fail 
> > on Intel platforms where the pitch is not 64 byte aligned.
> >
> > tests: test run on Intel platforms with panel resolution 1366x768
> >
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  tests/kms_prime.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> > 8cb2ca2a9dc3..fdc941fe8100 100644
> > --- a/tests/kms_prime.c
> > +++ b/tests/kms_prime.c
> > @@ -51,6 +51,8 @@ static struct {
> >   { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },  };
> >
> > +bool check_platform;
I think we can do a more precise name to indicate which platform.
Something like is_intel_device or is_i915 would be more appropriate.
alternatively, we can drop the boolean and just do the check when needed.
So it would look something like
+ is_i915_device(fd) ? ALIGN(scratch->width, 64) : scratch->width,

> > +
> >  IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
> >
> >  static bool has_prime_import(int fd) @@ -101,7 +103,7 @@ static 
> > void prepare_scratch(int exporter_fd, struct dumb_bo *scratch,
> >   scratch->bpp = 32;
> >
> >   scratch->handle = kmstest_dumb_create(exporter_fd,
> > - scratch->width,
> > + check_platform? ALIGN(scratch->width, 64): 
> > + scratch->width,
>
> The dumb_create ioctl already does this for us.
>
> >   scratch->height,
> >   scratch->bpp,
> >   >pitch, @@ -262,6 +264,7 @@ igt_main
> >
> >   /* ANY = anything that is not VGEM */
> >   first_fd = __drm_open_driver_another(0, DRIVER_ANY | 
> > DRIVER_VGEM);
> > + check_platform = is_i915_device(first_fd);
> >   igt_require(first_fd >= 0);
> >
> >   second_fd = __drm_open_driver_another(1, DRIVER_ANY | 
> > DRIVER_VGEM);
> > --
> > 2.7.4
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
> --
> Ville Syrjälä
> Intel
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] tests/kms_color: Remove gamma code from degamma tests

2021-06-04 Thread Srinivas, Vidya
Thank you very much Mark, for testing the patch and providing the "Tested-by" 
tag.

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Friday, June 4, 2021 11:58 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
Almahallawy, Khaled ; Lin, Charlton 
; Latvala, Petri 
Subject: Re: [PATCH i-g-t] tests/kms_color: Remove gamma code from degamma tests

On Thu, Jun 3, 2021 at 1:04 PM Vidya Srinivas  wrote:
>
> CRC should be collected without degamma transformation and after 
> drawing gradient with degamma LUT.
> This patch removes things which are not related to degamma and makes 
> it similar to pipe gamma test.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_color.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/tests/kms_color.c b/tests/kms_color.c index 
> 3a42532a5c27..2c9821cdecce 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -31,8 +31,7 @@ static void test_pipe_degamma(data_t *data,  {
> igt_output_t *output;
> igt_display_t *display = >display;
> -   gamma_lut_t *degamma_linear, *degamma_full;
> -   gamma_lut_t *gamma_linear;
> +   gamma_lut_t *degamma_full;
> color_t red_green_blue[] = {
> { 1.0, 0.0, 0.0 },
> { 0.0, 1.0, 0.0 },
> @@ -42,11 +41,8 @@ static void test_pipe_degamma(data_t *data,
> igt_require(igt_pipe_obj_has_prop(primary->pipe, 
> IGT_CRTC_DEGAMMA_LUT));
> igt_require(igt_pipe_obj_has_prop(primary->pipe, 
> IGT_CRTC_GAMMA_LUT));
>
> -   degamma_linear = generate_table(data->degamma_lut_size, 1.0);
> degamma_full = generate_table_max(data->degamma_lut_size);
>
> -   gamma_linear = generate_table(data->gamma_lut_size, 1.0);
> -
> for_each_valid_output_on_pipe(>display, primary->pipe->pipe, 
> output) {
> drmModeModeInfo *mode;
> struct igt_fb fb_modeset, fb; @@ -75,8 +71,7 @@ static 
> void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, _modeset);
> disable_ctm(primary->pipe);
> -   disable_degamma(primary->pipe);
> -   set_gamma(data, primary->pipe, gamma_linear);
> +   set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
>
> /* Draw solid colors with no degamma transformation. 
> */ @@ -92,7 +87,6 @@ static void test_pipe_degamma(data_t *data,
>  */
> paint_gradient_rectangles(data, mode, red_green_blue, );
> igt_plane_set_fb(primary, );
> -   set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
> igt_wait_for_vblank(data->drm_fd,
> 
> display->pipes[primary->pipe->pipe].crtc_offset);
> @@ -105,13 +99,13 @@ static void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> +   igt_display_commit2(>display, data->display.is_atomic ?
> +   COMMIT_ATOMIC 
> + : COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
>
> -   free_lut(degamma_linear);
> free_lut(degamma_full);
> -   free_lut(gamma_linear);
>  }
>
>  /*
> @@ -191,6 +185,8 @@ static void test_pipe_gamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> +   igt_display_commit2(>display, data->display.is_atomic ?
> +   COMMIT_ATOMIC 
> + : COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend

2021-06-04 Thread Srinivas, Vidya
Thank you so much Mark. This patch is not required. I have abandoned it.
We needed to stop tlsdate daemon which was holding the RTC lock (initctl stop 
tlsdated).

Apologies for the same.

Regards
Vidya

-Original Message-
From: Mark Yacoub  
Sent: Saturday, June 5, 2021 12:17 AM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; 
Almahallawy, Khaled ; Lin, Charlton 

Subject: Re: [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend

Tested it on ChromeOS and it runs well. But I think we should fix the root 
cause instead.

On Fri, May 28, 2021 at 12:33 AM Vidya Srinivas  
wrote:
>
> Some Intel Gen11 systems are not able to do a RTC wake.
> Instead change the default SUSPEND_TEST_NONE to SUSPEND_TEST_PLATFORM.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_flip.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 
> 8f736652be90..8afac88c9b15 100755
> --- a/tests/kms_flip.c
> +++ b/tests/kms_flip.c
> @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, 
> unsigned int *events)
>
> if (o->flags & TEST_SUSPEND)
> igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> - SUSPEND_TEST_NONE);
> + is_i915_device(drm_fd)?
> + 
> + SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE);
>
> if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > 
> 0)
> igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, 
> _reply)
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix coverage-vs-premult-vs-constant tests

2021-06-01 Thread Srinivas, Vidya
Thank you so much Petri. Apologies for the incorrect commit message.
I will submit the patch with the clear commit message.

Regards
Vidya

-Original Message-
From: Latvala, Petri  
Sent: Tuesday, June 1, 2021 7:11 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix 
coverage-vs-premult-vs-constant tests

On Tue, Jun 01, 2021 at 05:15:39PM +0530, Vidya Srinivas wrote:
> tests/kms_plane_alpha_blend: Fix coverage-vs-premult-vs-constant tests
>
> Few Gen11 systems show CRC mismatch. Make 
> coverage-vs-premult-vs-constant code similar to constant_alpha_min or 
> basic_alpha
> 
> Signed-off-by: Vidya Srinivas 


Please make the first line of the commit message a statement that tells what 
change you're making, and in the full text block state why that's done. "Fix 
a-b-c tests" is useless later when browsing oneliner git logs. It doesn't even 
tell which problem is fixed.

Meaning, something like:


==
tests/kms_plane_alpha_blend: Don't set primary fb color in 
coverage-vs-premult-vs-constant

Similar change has already been done in tests xxx and yyy.
This fixes CRC mismatches seen with some Gen11 systems.

Signed-off-by etc
==


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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms

2021-05-31 Thread Srinivas, Vidya
Hello Ville,

Thank you very much.
Before reaching our i915's i915_gem_dumb_create, it goes to 
vgem_gem_dumb_create for kms_prime.

The pitch gets calculated there and it is not 64 byte aligned. Due to this, 
intel_framebuffer_init reports "pitch must be 64 byte aligned"
and framebuffer creation fails. I tried submitting vgem patch where 64 byte 
alignment can be done in vgem_gem_dumb_create and that also
passes. But we did not get approval yet as few of them felt, vgem is generic 
and other platforms might fail if we do 64 byte alignment there.

Kindly suggest. Thanks a lot.

Regards
Vidya

-Original Message-
From: Ville Syrjälä  
Sent: Monday, May 31, 2021 7:48 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin, 
Charlton 
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code doesnt 
> do the alignment. This causes frame buffer creation to fail on Intel 
> platforms where the pitch is not 64 byte aligned.
> 
> tests: test run on Intel platforms with panel resolution 1366x768
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_prime.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c index 
> 8cb2ca2a9dc3..fdc941fe8100 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -51,6 +51,8 @@ static struct {
>   { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },  };
>  
> +bool check_platform;
> +
>  IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
>  
>  static bool has_prime_import(int fd)
> @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct 
> dumb_bo *scratch,
>   scratch->bpp = 32;
>  
>   scratch->handle = kmstest_dumb_create(exporter_fd,
> - scratch->width,
> + check_platform? ALIGN(scratch->width, 64): 
> scratch->width,

The dumb_create ioctl already does this for us.

>   scratch->height,
>   scratch->bpp,
>   >pitch,
> @@ -262,6 +264,7 @@ igt_main
>  
>   /* ANY = anything that is not VGEM */
>   first_fd = __drm_open_driver_another(0, DRIVER_ANY | 
> DRIVER_VGEM);
> + check_platform = is_i915_device(first_fd);
>   igt_require(first_fd >= 0);
>  
>   second_fd = __drm_open_driver_another(1, DRIVER_ANY | 
> DRIVER_VGEM);
> --
> 2.7.4
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

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


Re: [Intel-gfx] [igt-dev] [PATCH 4/4] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-05-27 Thread Srinivas, Vidya
Hello Juha-Pekka,

I am sorry, this is not needed.
Thank you so much.

Regards
Vidya

-Original Message-
From: Juha-Pekka Heikkila  
Sent: Thursday, May 27, 2021 8:40 PM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [PATCH 4/4] [RFC] tests/kms_big_fb: Wait for vblank 
before collecting CRC

On 27.5.2021 17.31, Vidya Srinivas wrote:
> Without wait for vblank, CRC mismatch is seen between big and small 
> CRC on some intel Gen11 platforms.
> 
> Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
> Signed-off-by: Vidya Srinivas 
> ---
>   tests/kms_big_fb.c | 10 +++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index 
> b2027b6b9d1b..da682593429b 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>   static bool test_plane(data_t *data)
>   {
>   igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
>   struct igt_fb *small_fb = >small_fb;
>   struct igt_fb *big_fb = >big_fb;
>   int w = data->big_fb_width - small_fb->width; @@ -269,6 +270,7 @@ 
> static bool test_plane(data_t *data)
>   { w / 3, h * 3 / 4, },
>   { w, h, },
>   };
> + bool check_platform_intel = is_i915_device(data->drm_fd);

You will not need to do this. This test start with

drm_open_driver_master(DRIVER_INTEL)

hence will always be only on intel device.

>   
>   if (!igt_plane_has_format_mod(plane, data->format, data->modifier))
>   return false;
> @@ -336,17 +338,19 @@ static bool test_plane(data_t *data)
>   
>   igt_display_commit2(>display, data->display.is_atomic ?
>   COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> -
> + if (check_platform_intel)
> + igt_wait_for_vblank(data->drm_fd, 
> +display->pipes[data->pipe].crtc_offset);

Above this line there's flip to different framebuffer and below this line 
there's restart of crc collection before get any crc. If there's need to wait a 
vblank at this place to get matching crcs the actual bug is somewhere else.

>   igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>   
>   igt_plane_set_fb(plane, big_fb);
>   igt_fb_set_position(big_fb, plane, x, y);
>   igt_fb_set_size(big_fb, plane, small_fb->width, 
> small_fb->height);
> +
>   igt_plane_set_size(plane, data->width, data->height);
>   igt_display_commit2(>display, data->display.is_atomic ?
>   COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + if (check_platform_intel)
> + igt_wait_for_vblank(data->drm_fd, 
> +display->pipes[data->pipe].crtc_offset);

Here it's the same story as above.

>   igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>   
>   igt_plane_set_fb(plane, NULL);
> 

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC

2021-05-21 Thread Srinivas, Vidya
Hello Juha-Pekka

We are seeing the CRC failures on Jasperlake systems. Sometimes the test passes 
and sometimes it fails throwing CRC error.

Regards
Vidya

-Original Message-
From: Juha-Pekka Heikkila  
Sent: Friday, May 21, 2021 5:00 PM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
igt-...@lists.freedesktop.org
Cc: Lin, Charlton 
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before 
collecting CRC

Hi Vidya,

on which machines this would help? I see there's many vblanks already being 
waited. There's igt_display_commit2 which probably will block and even if it 
didn't there's igt_pipe_crc_collect_crc(..) where crc calculation is started 
after flip and then get one crc before disabling crc counting again.

/Juha-Pekka

On 21.5.2021 7.08, Vidya Srinivas wrote:
> Without wait for vblank, CRC mismatch is seen between big and small 
> CRC on few systems
> 
> Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
> Signed-off-by: Vidya Srinivas 
> ---
>   tests/kms_big_fb.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index 
> b2027b6b9d1b..7d78ff829d41 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
>   static bool test_plane(data_t *data)
>   {
>   igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
>   struct igt_fb *small_fb = >small_fb;
>   struct igt_fb *big_fb = >big_fb;
>   int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 @@ 
> static bool test_plane(data_t *data)
>   igt_display_commit2(>display, data->display.is_atomic ?
>   COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>   
> -
> + igt_wait_for_vblank(data->drm_fd, 
> +display->pipes[data->pipe].crtc_offset);
>   igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>   
>   igt_plane_set_fb(plane, big_fb);
>   igt_fb_set_position(big_fb, plane, x, y);
>   igt_fb_set_size(big_fb, plane, small_fb->width, 
> small_fb->height);
> +
>   igt_plane_set_size(plane, data->width, data->height);
>   igt_display_commit2(>display, data->display.is_atomic ?
>   COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + igt_wait_for_vblank(data->drm_fd, 
> +display->pipes[data->pipe].crtc_offset);
>   igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>   
>   igt_plane_set_fb(plane, NULL);
> 

___
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: Configure SKL+ scaler initial phase correctly

2018-05-30 Thread Srinivas, Vidya
Thank you.
Reviewed-By: Vidya Srinivas 

> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
> 
> Subject: [PATCH 2/2] drm/i915: Configure SKL+ scaler initial phase correctly
> 
> From: Ville Syrjälä 
> 
> Set up the SKL+ scaler initial phase registers correctly. Otherwise we start
> fetching the data from the center of the first pixel instead of the top-left
> corner, which obviously then leads to right/bottom edges replicating data
> excessively as the data runs out half a pixel too soon.
> 
> Cc: Vidya Srinivas 
> Cc: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  4 
>  drivers/gpu/drm/i915/intel_display.c | 41
> 
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_sprite.c  | 26 +--
>  4 files changed, 70 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 196a0eb79272..094527403ede
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6774,6 +6774,10 @@ enum {
>  #define _PS_VPHASE_1B   0x68988
>  #define _PS_VPHASE_2B   0x68A88
>  #define _PS_VPHASE_1C   0x69188
> +#define  PS_Y_PHASE(x)   ((x) << 16)
> +#define  PS_UV_RGB_PHASE(x)  ((x) << 0)
> +#define   PS_PHASE_MASK  (0x7fff << 1) /* u2.13 */
> +#define   PS_PHASE_TRIP  (1 << 0)
> 
>  #define _PS_HPHASE_1A   0x68194
>  #define _PS_HPHASE_2A   0x68294
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 42c1f4a56556..07185644a88a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4729,6 +4729,39 @@ static void cpt_verify_modeset(struct
> drm_device *dev, int pipe)
>   }
>  }
> 
> +/*
> + * The hardware phase 0.0 refers to the center of the pixel.
> + * We want to start from the top/left edge which is phase
> + * -0.5. That matches how the hardware calculates the scaling
> + * factors (from top-left of the first pixel to bottom-right
> + * of the last pixel, as opposed to the pixel centers).
> + *
> + * For 4:2:0 subsampled chroma planes we obviously have to
> + * adjust that so that the chroma sample position lands in
> + * the right spot.
> + *
> + * Note that for packed YCbCr 4:2:2 formats there is no way to
> + * control chroma siting. The hardware simply replicates the
> + * chroma samples for both of the luma samples, and thus we don't
> + * actually get the expected MPEG2 chroma siting convention :(
> + * The same behaviour is observed on pre-SKL platforms as well.
> + */
> +u16 skl_scaler_calc_phase(int sub, bool chroma_cosited) {
> + int phase = -0x8000;
> + u16 trip = 0;
> +
> + if (chroma_cosited)
> + phase += (sub - 1) * 0x8000 / sub;
> +
> + if (phase < 0)
> + phase = 0x1 + phase;
> + else
> + trip = PS_PHASE_TRIP;
> +
> + return ((phase >> 2) & PS_PHASE_MASK) | trip; }
> +
>  static int
>  skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> unsigned int scaler_user, int *scaler_id, @@ -4928,14
> +4961,22 @@ static void skylake_pfit_enable(struct intel_crtc *crtc)
>   >config->scaler_state;
> 
>   if (crtc->config->pch_pfit.enabled) {
> + u16 uv_rgb_hphase, uv_rgb_vphase;
>   int id;
> 
>   if (WARN_ON(crtc->config->scaler_state.scaler_id < 0))
>   return;
> 
> + uv_rgb_hphase = skl_scaler_calc_phase(1, false);
> + uv_rgb_vphase = skl_scaler_calc_phase(1, false);
> +
>   id = scaler_state->scaler_id;
>   I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
>   PS_FILTER_MEDIUM | scaler_state-
> >scalers[id].mode);
> + I915_WRITE_FW(SKL_PS_VPHASE(pipe, id),
> +   PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_vphase));
> + I915_WRITE_FW(SKL_PS_HPHASE(pipe, id),
> +   PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_hphase));
>   I915_WRITE(SKL_PS_WIN_POS(pipe, id), crtc->config-
> >pch_pfit.pos);
>   I915_WRITE(SKL_PS_WIN_SZ(pipe, id), crtc->config-
> >pch_pfit.size);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/inte

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup

2018-05-30 Thread Srinivas, Vidya
Thank you.
Reviewed-By: Vidya Srinivas 

> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
> 
> Subject: [PATCH 1/2] drm/i915: Remove bogus NV12 PLANE_COLOR_CTL
> setup
> 
> From: Ville Syrjälä 
> 
> We already handle the color encoding mode properly. Remove the broken
> NV12 special case.
> 
> Cc: Vidya Srinivas 
> Cc: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f5c078c9d0d2..42c1f4a56556 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3643,11 +3643,6 @@ u32 glk_plane_color_ctl(const struct
> intel_crtc_state *crtc_state,
>   plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
> 
>   if (intel_format_is_yuv(fb->format->format)) {
> - if (fb->format->format == DRM_FORMAT_NV12) {
> - plane_color_ctl |=
> -
>   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - goto out;
> - }
>   if (plane_state->base.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
>   plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
>   else
> @@ -3656,7 +3651,7 @@ u32 glk_plane_color_ctl(const struct
> intel_crtc_state *crtc_state,
>   if (plane_state->base.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
>   plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
>   }
> -out:
> +
>   return plane_color_ctl;
>  }
> 
> --
> 2.16.1

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


Re: [Intel-gfx] [PULL] drm-intel-next

2018-05-15 Thread Srinivas, Vidya


> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, May 15, 2018 3:26 PM
> To: Dave Airlie <airl...@gmail.com>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>; Jani Nikula
> <jani.nik...@linux.intel.com>; Joonas Lahtinen
> <joonas.lahti...@linux.intel.com>; Vivi, Rodrigo <rodrigo.v...@intel.com>;
> Sean Paul <seanp...@chromium.org>; Gustavo Padovan
> <gust...@padovan.org>; Maarten Lankhorst
> <maarten.lankho...@linux.intel.com>; dri-de...@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; dim-to...@lists.freedesktop.org; Wang, Zhi
> A <zhi.a.w...@intel.com>; Zhenyu Wang <zhen...@linux.intel.com>;
> Srinivas, Vidya <vidya.srini...@intel.com>
> Subject: [PULL] drm-intel-next
> 
> 
> Hi Dave -
> 
> So this one contains the problematic pull from gvt. It's got both a backmerge
> and a rebase. I spotted the rebase, but intentionally let it slide due to the
> deadline closing, and then completely missed the backmerge. I don't know
> what I was thinking. My bad, sorry.
> 
> We'll need to improve our workflows with the gvt team.
> 
> Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know if
> you can tolerate it, or if we need to rewrite history.
> 
> BR,
> Jani.
> 
> 
> PS. Regarding the changelog, Vidya Srinivas <vidya.srini...@intel.com> had a
> huge role in the NV12 work, but alas I failed to give proper credit because 
> the
> patches were based on earlier work by Chandra.

No problem at all :) Sincerely, Thank you so much. It was based on Chandra's 
original work and without Maarten
It would never reach the merge stage :)

> 
> 
> drm-intel-next-2018-05-14:
> Last drm/i915 changes for v4.18:
> 
> - NV12 enabling (Chandra, Maarten)
> - ICL workarounds (Oscar)
> - ICL basic DPLL enabling (Paulo)
> - GVT updates
> - DP link config refactoring (Jani)
> - Module parameter to override DMC firmware (Jani)
> - PSR updates (José, DK, Daniel, Ville)
> - ICL DP vswing programming (Manasi)
> - ICL DBuf slice updates (Mahesh)
> - Selftest fixes and updates (Chris, Matthew, Oscar)
> - Execlist fixes and updates (Chris)
> - Stolen memory first 4k fix (Hans de Goede)
> - wait_for fixes (Mika)
> - Tons of GEM improvements (Chris)
> - Plenty of other fixes and improvements (Everyone)
> - Crappy changelog (Me)
> 
> BR,
> Jani.
> 
> The following changes since commit
> 0ab390262c4920f26f8202063a268d5fc829728e:
> 
>   Merge tag 'drm-misc-next-2018-04-26' of
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30
> 09:32:43 +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-
> 14
> 
> for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea:
> 
>   drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300)
> 
> 
> Last drm/i915 changes for v4.18:
> 
> - NV12 enabling (Chandra, Maarten)
> - ICL workarounds (Oscar)
> - ICL basic DPLL enabling (Paulo)
> - GVT updates
> - DP link config refactoring (Jani)
> - Module parameter to override DMC firmware (Jani)
> - PSR updates (José, DK, Daniel, Ville)
> - ICL DP vswing programming (Manasi)
> - ICL DBuf slice updates (Mahesh)
> - Selftest fixes and updates (Chris, Matthew, Oscar)
> - Execlist fixes and updates (Chris)
> - Stolen memory first 4k fix (Hans de Goede)
> - wait_for fixes (Mika)
> - Tons of GEM improvements (Chris)
> - Plenty of other fixes and improvements (Everyone)
> - Crappy changelog (Me)
> 
> 
> Abhay Kumar (1):
>   drm/i915/audio: set minimum CD clock to twice the BCLK
> 
> Andy Shevchenko (1):
>   i915: Convert to use match_string() helper
> 
> Anusha Srivatsa (1):
>   drm/i915/firmware: Correct URL for firmware
> 
> Chandra Konduru (3):
>   drm/i915: Add NV12 support to intel_framebuffer_init
>   drm/i915: Add NV12 as supported format for primary plane
>   drm/i915: Add NV12 as supported format for sprite plane
> 
> Changbin Du (1):
>   drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio
> with debug level
> 
> Chris Wilson (53):
>   drm/i915: Check whitelist registers across resets
>   drm/i915: Call i915_perf_fini() on init_hw error unwind
>   drm/i915: Move the priotree struct to its own headers
>   drm/i915: Rename priotree to sched
>   drm/i915: Pack params to engine->schedule() into a struct
>   drm/i915: Build request info on stack before printk
>   drm/i915: Don't 

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-11 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Friday, May 11, 2018 1:50 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v8 3/6] drm/i915: Add skl_check_nv12_surface for NV12
> 
> Op 11-05-18 om 23:33 schreef Vidya Srinivas:
> > From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> >
> > v4: Added RB from Mika
> >
> > v5: Rebased the series. Removed checks of mult of 4 in
> > skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
> > where src x/w is being checked for mult of 2 for yuv planes.
> >
> > v6: Made changes to skl_check_nv12_surface as per WA#1106
> >
> > Reviewed-by: Mika Kahola <mika.kah...@intel.com>
> > Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> Thanks, pushed the series to DINQ. :)

Thank you so much :)

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


Re: [Intel-gfx] [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-10 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, May 8, 2018 5:08 PM
> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>; 'intel-
> g...@lists.freedesktop.org' <intel-gfx@lists.freedesktop.org>
> Subject: RE: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12
> 
> 
> 
> > -----Original Message-
> > From: Srinivas, Vidya
> > Sent: Tuesday, May 8, 2018 8:36 AM
> > To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; intel-
> > g...@lists.freedesktop.org
> > Subject: RE: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for
> > NV12
> >
> >
> >
> > > -Original Message-
> > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > > Sent: Monday, May 7, 2018 2:56 PM
> > > To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> > > g...@lists.freedesktop.org
> > > Subject: Re: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for
> > > NV12
> > >
> > > Op 10-05-18 om 10:31 schreef Vidya Srinivas:
> > > > From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > > >
> > > > We skip src trunction/adjustments for
> > > > NV12 case and handle the sizes directly.
> > > > Without this, pipe fifo underruns are seen on APL/KBL.
> > > >
> > > > v2: For NV12, making the src coordinates multiplier of 4
> > > >
> > > > v3: Moving all the src coords handling code for NV12 to
> > > > skl_check_nv12_surface
> > > >
> > > > v4: Added RB from Mika
> > > >
> > > > v5: Rebased the series. Removed checks of mult of 4 in
> > > > skl_update_scaler, Added NV12 condition in
> > > > intel_check_sprite_plane where src x/w is being checked for mult of 2
> for yuv planes.
> > > >
> > > > Reviewed-by: Mika Kahola <mika.kah...@intel.com>
> > > > Signed-off-by: Maarten Lankhorst
> > > > <maarten.lankho...@linux.intel.com>
> > > > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 42
> > > > ++--
> > > >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> > > >  2 files changed, 41 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index dfca71e..cca46f9 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -3102,6 +3102,42 @@ static int skl_check_main_surface(const
> > > > struct
> > > intel_crtc_state *crtc_state,
> > > > return 0;
> > > >  }
> > > >
> > > > +static int
> > > > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > > > +  struct intel_plane_state *plane_state) {
> > > > +   int crtc_x2 = plane_state->base.crtc_x + 
> > > > plane_state->base.crtc_w;
> > > > +   int crtc_y2 = plane_state->base.crtc_y +
> > > > +plane_state->base.crtc_h;
> > > > +
> > > > +   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > > > +   ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > > > +   ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > > > +   ((plane_state->base.src_h >> 16) % 4) != 0) {
> > > > +   DRM_DEBUG_KMS("src coords must be multiple of 4 for
> > > NV12\n");
> > > > +   return -EINVAL;
> > > > +   }
> > > > +
> > > > +   /* Clipping would cause a 1-3 pixel gap at the edge of the 
> > > > screen? */
> > > > +   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w
> > > > +%
> > > 4) ||
> > > > +   (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h
> > > > +%
> > > > +4))
> > > {
> > > > +   DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> > > %u,%u\n",
> > > > + crtc_x2, crtc_y2,
> > > > + crtc_state->pipe_src_w, 
> > > > crtc_state->pipe_src_h);
> > 

Re: [Intel-gfx] [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-08 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, May 8, 2018 8:36 AM
> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12
> 
> 
> 
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Monday, May 7, 2018 2:56 PM
> > To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for
> > NV12
> >
> > Op 10-05-18 om 10:31 schreef Vidya Srinivas:
> > > From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > >
> > > We skip src trunction/adjustments for
> > > NV12 case and handle the sizes directly.
> > > Without this, pipe fifo underruns are seen on APL/KBL.
> > >
> > > v2: For NV12, making the src coordinates multiplier of 4
> > >
> > > v3: Moving all the src coords handling code for NV12 to
> > > skl_check_nv12_surface
> > >
> > > v4: Added RB from Mika
> > >
> > > v5: Rebased the series. Removed checks of mult of 4 in
> > > skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
> > > where src x/w is being checked for mult of 2 for yuv planes.
> > >
> > > Reviewed-by: Mika Kahola <mika.kah...@intel.com>
> > > Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 42
> > > ++--
> > >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> > >  2 files changed, 41 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index dfca71e..cca46f9 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3102,6 +3102,42 @@ static int skl_check_main_surface(const
> > > struct
> > intel_crtc_state *crtc_state,
> > >   return 0;
> > >  }
> > >
> > > +static int
> > > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > > +struct intel_plane_state *plane_state) {
> > > + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> > > + int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> > > +
> > > + if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > > + ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > > + ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > > + ((plane_state->base.src_h >> 16) % 4) != 0) {
> > > + DRM_DEBUG_KMS("src coords must be multiple of 4 for
> > NV12\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> > > + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> > 4) ||
> > > + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h %
> > > +4))
> > {
> > > + DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> > %u,%u\n",
> > > +   crtc_x2, crtc_y2,
> > > +   crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> > > + return -EINVAL;
> > > + }
> > Oops, wrong checks here..
> >
> > skl_check_nv12_surface is only needed for Display WA #1106, so check
> > might need to be something like:
> >
> > static int
> > skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >struct intel_plane_state *plane_state) {
> > /* Display WA #1106 */
> > if (plane_state->base.rotation != (DRM_MODE_REFLECT_X |
> > DRM_MODE_ROTATE_90) &&
> > plane_state->base.rotation != DRM_MODE_ROTATE_270)
> > return 0;
> >
> > /* src coordinates are rotated here. We check height but report it as
> > width. */
> > if (((drm_rect_height(_state->base.src) >> 16) % 4) != 0) {
> > DRM_DEBUG_KMS("src width must be multiple of 4 for
> rotated NV12\n");
> > return -EINVAL;
> > }
> >
> > return 0;
> > }
> >
> > Would this hit FIFO underruns?
> 
> Thank you. I have made the change and floated the series. Please have a
> check.
> When I tested It on my end on GLK, I did not observe any fifo underruns. Will
> wait for IGT test results from BAT.
> 

IGT BAT shows PASS on rev 6 of https://patchwork.freedesktop.org/series/41674/
This has the change for skl_check_nv12_surface. Can you please have a check?
Thank you.

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


Re: [Intel-gfx] [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 2:56 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v7 3/6] drm/i915: Add skl_check_nv12_surface for NV12
> 
> Op 10-05-18 om 10:31 schreef Vidya Srinivas:
> > From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> >
> > v4: Added RB from Mika
> >
> > v5: Rebased the series. Removed checks of mult of 4 in
> > skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
> > where src x/w is being checked for mult of 2 for yuv planes.
> >
> > Reviewed-by: Mika Kahola <mika.kah...@intel.com>
> > Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 42
> > ++--
> >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> >  2 files changed, 41 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dfca71e..cca46f9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3102,6 +3102,42 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> > return 0;
> >  }
> >
> > +static int
> > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > +  struct intel_plane_state *plane_state) {
> > +   int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> > +   int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> > +
> > +   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_h >> 16) % 4) != 0) {
> > +   DRM_DEBUG_KMS("src coords must be multiple of 4 for
> NV12\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> > +   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> 4) ||
> > +   (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
> {
> > +   DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> %u,%u\n",
> > + crtc_x2, crtc_y2,
> > + crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> > +   return -EINVAL;
> > +   }
> Oops, wrong checks here..
> 
> skl_check_nv12_surface is only needed for Display WA #1106, so check
> might need to be something like:
> 
> static int
> skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>  struct intel_plane_state *plane_state) {
>   /* Display WA #1106 */
>   if (plane_state->base.rotation != (DRM_MODE_REFLECT_X |
> DRM_MODE_ROTATE_90) &&
>   plane_state->base.rotation != DRM_MODE_ROTATE_270)
>   return 0;
> 
>   /* src coordinates are rotated here. We check height but report it as
> width. */
>   if (((drm_rect_height(_state->base.src) >> 16) % 4) != 0) {
>   DRM_DEBUG_KMS("src width must be multiple of 4 for
> rotated NV12\n");
>   return -EINVAL;
>   }
> 
>   return 0;
> }
> 
> Would this hit FIFO underruns?

Thank you. I have made the change and floated the series. Please have a check.
When I tested It on my end on GLK, I did not observe any fifo underruns. Will 
wait for IGT
test results from BAT.

Regards
Vidya


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


Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 2:08 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:34 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, May 7, 2018 1:59 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 07-05-18 om 10:29 schreef Srinivas, Vidya:
> >>>> -Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Monday, May 7, 2018 1:55 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>> supported format for sprite plane
> >>>>
> >>>> Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
> >>>>>> -Original Message-
> >>>>>> From: Srinivas, Vidya
> >>>>>> Sent: Monday, May 7, 2018 1:46 PM
> >>>>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> >>>>>> intel- g...@lists.freedesktop.org
> >>>>>> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>>> supported format for sprite plane
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>> Sent: Monday, May 7, 2018 1:44 PM
> >>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>>>> g...@lists.freedesktop.org
> >>>>>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>>>> supported format for sprite plane
> >>>>>>>
> >>>>>>> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> >>>>>>>>> -Original Message-
> >>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>>>> Sent: Monday, May 7, 2018 1:38 PM
> >>>>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>>>>>> g...@lists.freedesktop.org
> >>>>>>>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>>>>>> supported format for sprite plane
> >>>>>>>>>
> >>>>>>>>> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> >>>>>>>>>> From: Chandra Konduru <chandra.kond...@intel.com>
> >>>>>>>>>>
> >>>>>>>>>> This patch adds NV12 to list of supported formats for sprite
> plane.
> >>>>>>>>>>
> >>>>>>>>>> v2: Rebased (me)
> >>>>>>>>>>
> >>>>>>>>>> v3: Review comments by Ville addressed
> >>>>>>>>>> - Removed skl_plane_formats_with_nv12 and added
> >>>>>>>>>> NV12 case in existing skl_plane_formats
> >>>>>>>>>> - Added the 10bpc RGB formats
> >>>>>>>>>>
> >>>>>>>>>> v4: Addressed review comments from Clinton A Taylor "Why
> are
> >> we
> >>>>>>>>> adding
> >>>>>>>>>> 10 bit RGB formats with the NV12 series patches?
> >>>>>>>>>> Trying to set XR30 or AB30 results in error returned even
> >>>>>>>>>> though the modes are advertised for the planes"
> >>>>>>>>>> - Removed 10bit RGB formats added previously with NV12
> series
> >>>>>>>>>>
> >>>>>

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:59 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:29 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, May 7, 2018 1:55 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
> >>>> -Original Message-
> >>>> From: Srinivas, Vidya
> >>>> Sent: Monday, May 7, 2018 1:46 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>> supported format for sprite plane
> >>>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Monday, May 7, 2018 1:44 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>> g...@lists.freedesktop.org
> >>>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>> supported format for sprite plane
> >>>>>
> >>>>> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> >>>>>>> -Original Message-
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>> Sent: Monday, May 7, 2018 1:38 PM
> >>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>>>> g...@lists.freedesktop.org
> >>>>>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>>>> supported format for sprite plane
> >>>>>>>
> >>>>>>> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> >>>>>>>> From: Chandra Konduru <chandra.kond...@intel.com>
> >>>>>>>>
> >>>>>>>> This patch adds NV12 to list of supported formats for sprite plane.
> >>>>>>>>
> >>>>>>>> v2: Rebased (me)
> >>>>>>>>
> >>>>>>>> v3: Review comments by Ville addressed
> >>>>>>>> - Removed skl_plane_formats_with_nv12 and added
> >>>>>>>> NV12 case in existing skl_plane_formats
> >>>>>>>> - Added the 10bpc RGB formats
> >>>>>>>>
> >>>>>>>> v4: Addressed review comments from Clinton A Taylor "Why are
> we
> >>>>>>> adding
> >>>>>>>> 10 bit RGB formats with the NV12 series patches?
> >>>>>>>> Trying to set XR30 or AB30 results in error returned even
> >>>>>>>> though the modes are advertised for the planes"
> >>>>>>>> - Removed 10bit RGB formats added previously with NV12 series
> >>>>>>>>
> >>>>>>>> v5: Missed the Tested-by/Reviewed-by in the previous series
> >>>>>>>> Adding the same to commit message in this version.
> >>>>>>>> Addressed review comments from Clinton A Taylor "Why are we
> >>>> adding
> >>>>>>>> 10 bit RGB formats with the NV12 series patches?
> >>>>>>>> Trying to set XR30 or AB30 results in error returned even
> >>>>>>>> though the modes are advertised for the planes"
> >>>>>>>> - Previous version has 10bit RGB format removed from VLV
> >>>>>>>> formats by mistake. Fixing that in this version.
> >>>>>>>> Removed 10bit RGB formats added previously with NV12 series
> for
> >>>> SKL.
> >>>>>>>> v6: Addressed review comments by Ville Restricting the NV12 to
> >>>

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:55 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:20 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Monday, May 7, 2018 1:46 PM
> >> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >>
> >>
> >>> -----Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Monday, May 7, 2018 1:44 PM
> >>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>> g...@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>> supported format for sprite plane
> >>>
> >>> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Monday, May 7, 2018 1:38 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>> g...@lists.freedesktop.org
> >>>>> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >>>>> supported format for sprite plane
> >>>>>
> >>>>> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> >>>>>> From: Chandra Konduru <chandra.kond...@intel.com>
> >>>>>>
> >>>>>> This patch adds NV12 to list of supported formats for sprite plane.
> >>>>>>
> >>>>>> v2: Rebased (me)
> >>>>>>
> >>>>>> v3: Review comments by Ville addressed
> >>>>>> - Removed skl_plane_formats_with_nv12 and added
> >>>>>> NV12 case in existing skl_plane_formats
> >>>>>> - Added the 10bpc RGB formats
> >>>>>>
> >>>>>> v4: Addressed review comments from Clinton A Taylor "Why are we
> >>>>> adding
> >>>>>> 10 bit RGB formats with the NV12 series patches?
> >>>>>> Trying to set XR30 or AB30 results in error returned even though
> >>>>>> the modes are advertised for the planes"
> >>>>>> - Removed 10bit RGB formats added previously with NV12 series
> >>>>>>
> >>>>>> v5: Missed the Tested-by/Reviewed-by in the previous series
> >>>>>> Adding the same to commit message in this version.
> >>>>>> Addressed review comments from Clinton A Taylor "Why are we
> >> adding
> >>>>>> 10 bit RGB formats with the NV12 series patches?
> >>>>>> Trying to set XR30 or AB30 results in error returned even though
> >>>>>> the modes are advertised for the planes"
> >>>>>> - Previous version has 10bit RGB format removed from VLV formats
> >>>>>> by mistake. Fixing that in this version.
> >>>>>> Removed 10bit RGB formats added previously with NV12 series for
> >> SKL.
> >>>>>> v6: Addressed review comments by Ville Restricting the NV12 to
> >>>>>> BXT and PIPE A and B
> >>>>>>
> >>>>>> v7: Rebased (me)
> >>>>>>
> >>>>>> v8: Rebased (me)
> >>>>>> Restricting NV12 changes to BXT and KBL Restricting NV12 changes
> >>>>>> for plane 0 (overlay)
> >>>>>>
> >>>>>> v9: Rebased (me)
> >>>>>>
> >>>>>> v10: Addressed review comments from Maarten.
> >>>>>> Adding NV12 to skl_plane_formats itself.
> >>>>>>
> >>>>>> v11: Addressed review comments from Shashank Sharma
> >>>>>>
> >>>>>> v12: Addressed review comments from Shashank Sharma Made the
> >>>>> condition
> >>>>>> in intel_sprite_plane_create simple and easy to read as suggested.
> >>>>>>
&g

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Monday, May 7, 2018 1:46 PM
> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> 
> 
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Monday, May 7, 2018 1:44 PM
> > To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> > supported format for sprite plane
> >
> > Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Monday, May 7, 2018 1:38 PM
> > >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> > >> supported format for sprite plane
> > >>
> > >> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> > >>> From: Chandra Konduru <chandra.kond...@intel.com>
> > >>>
> > >>> This patch adds NV12 to list of supported formats for sprite plane.
> > >>>
> > >>> v2: Rebased (me)
> > >>>
> > >>> v3: Review comments by Ville addressed
> > >>> - Removed skl_plane_formats_with_nv12 and added
> > >>> NV12 case in existing skl_plane_formats
> > >>> - Added the 10bpc RGB formats
> > >>>
> > >>> v4: Addressed review comments from Clinton A Taylor "Why are we
> > >> adding
> > >>> 10 bit RGB formats with the NV12 series patches?
> > >>> Trying to set XR30 or AB30 results in error returned even though
> > >>> the modes are advertised for the planes"
> > >>> - Removed 10bit RGB formats added previously with NV12 series
> > >>>
> > >>> v5: Missed the Tested-by/Reviewed-by in the previous series Adding
> > >>> the same to commit message in this version.
> > >>> Addressed review comments from Clinton A Taylor "Why are we
> adding
> > >>> 10 bit RGB formats with the NV12 series patches?
> > >>> Trying to set XR30 or AB30 results in error returned even though
> > >>> the modes are advertised for the planes"
> > >>> - Previous version has 10bit RGB format removed from VLV formats
> > >>> by mistake. Fixing that in this version.
> > >>> Removed 10bit RGB formats added previously with NV12 series for
> SKL.
> > >>>
> > >>> v6: Addressed review comments by Ville Restricting the NV12 to BXT
> > >>> and PIPE A and B
> > >>>
> > >>> v7: Rebased (me)
> > >>>
> > >>> v8: Rebased (me)
> > >>> Restricting NV12 changes to BXT and KBL Restricting NV12 changes
> > >>> for plane 0 (overlay)
> > >>>
> > >>> v9: Rebased (me)
> > >>>
> > >>> v10: Addressed review comments from Maarten.
> > >>> Adding NV12 to skl_plane_formats itself.
> > >>>
> > >>> v11: Addressed review comments from Shashank Sharma
> > >>>
> > >>> v12: Addressed review comments from Shashank Sharma Made the
> > >> condition
> > >>> in intel_sprite_plane_create simple and easy to read as suggested.
> > >>>
> > >>> v13: Adding reviewed by tag from Shashank Sharma Addressed review
> > >>> comments from Juha-Pekka Heikkila
> > >>> "NV12 not to be supported by SKL"
> > >>>
> > >>> v14: Addressed review comments from Ville Added
> skl_planar_formats
> > >>> to include NV12 and a check skl_plane_has_planar in sprite create
> > >>> Added
> > >>> NV12 format to skl_mod_supported. These were review comments
> > from
> > >>> Kristian Høgsberg <hoegsb...@gmail.com>
> > >>>
> > >>> v15: Added reviewed by from Juha-Pekka Heikkila
> > >>>
> > >>> v16: Rebased the series
> > >>>
> > >>> v17: Added all tiling under mod supported for NV12 Credits to
> > >>> Megha Aggarwal
> > &g

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:44 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 07-05-18 om 10:11 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, May 7, 2018 1:38 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> >>> From: Chandra Konduru <chandra.kond...@intel.com>
> >>>
> >>> This patch adds NV12 to list of supported formats for sprite plane.
> >>>
> >>> v2: Rebased (me)
> >>>
> >>> v3: Review comments by Ville addressed
> >>> - Removed skl_plane_formats_with_nv12 and added
> >>> NV12 case in existing skl_plane_formats
> >>> - Added the 10bpc RGB formats
> >>>
> >>> v4: Addressed review comments from Clinton A Taylor "Why are we
> >> adding
> >>> 10 bit RGB formats with the NV12 series patches?
> >>> Trying to set XR30 or AB30 results in error returned even though the
> >>> modes are advertised for the planes"
> >>> - Removed 10bit RGB formats added previously with NV12 series
> >>>
> >>> v5: Missed the Tested-by/Reviewed-by in the previous series Adding
> >>> the same to commit message in this version.
> >>> Addressed review comments from Clinton A Taylor "Why are we adding
> >>> 10 bit RGB formats with the NV12 series patches?
> >>> Trying to set XR30 or AB30 results in error returned even though the
> >>> modes are advertised for the planes"
> >>> - Previous version has 10bit RGB format removed from VLV formats by
> >>> mistake. Fixing that in this version.
> >>> Removed 10bit RGB formats added previously with NV12 series for SKL.
> >>>
> >>> v6: Addressed review comments by Ville Restricting the NV12 to BXT
> >>> and PIPE A and B
> >>>
> >>> v7: Rebased (me)
> >>>
> >>> v8: Rebased (me)
> >>> Restricting NV12 changes to BXT and KBL Restricting NV12 changes for
> >>> plane 0 (overlay)
> >>>
> >>> v9: Rebased (me)
> >>>
> >>> v10: Addressed review comments from Maarten.
> >>> Adding NV12 to skl_plane_formats itself.
> >>>
> >>> v11: Addressed review comments from Shashank Sharma
> >>>
> >>> v12: Addressed review comments from Shashank Sharma Made the
> >> condition
> >>> in intel_sprite_plane_create simple and easy to read as suggested.
> >>>
> >>> v13: Adding reviewed by tag from Shashank Sharma Addressed review
> >>> comments from Juha-Pekka Heikkila
> >>> "NV12 not to be supported by SKL"
> >>>
> >>> v14: Addressed review comments from Ville Added skl_planar_formats
> >>> to include NV12 and a check skl_plane_has_planar in sprite create
> >>> Added
> >>> NV12 format to skl_mod_supported. These were review comments
> from
> >>> Kristian Høgsberg <hoegsb...@gmail.com>
> >>>
> >>> v15: Added reviewed by from Juha-Pekka Heikkila
> >>>
> >>> v16: Rebased the series
> >>>
> >>> v17: Added all tiling under mod supported for NV12 Credits to Megha
> >>> Aggarwal
> >>>
> >>> v18: Added RB by Maarten and Kristian
> >>>
> >>> Credits-to: Megha Aggarwal <megha.aggar...@intel.com>
> >>> Credits-to: Kristian Høgsberg <hoegsb...@gmail.com>
> >>> Reviewed-by: Kristian Høgsberg <hoegsb...@gmail.com>
> >>> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>
> >>> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikk...@gmail.com>
> >>> Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
> >>> Reviewed-by: Clinton Taylor <clinton.a.tay...@intel.com>
> >>> Signed-off-by: Chandra Kondur

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported format for sprite plane

2018-05-07 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, May 7, 2018 1:38 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 6/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 06-05-18 om 19:44 schreef Vidya Srinivas:
> > From: Chandra Konduru <chandra.kond...@intel.com>
> >
> > This patch adds NV12 to list of supported formats for sprite plane.
> >
> > v2: Rebased (me)
> >
> > v3: Review comments by Ville addressed
> > - Removed skl_plane_formats_with_nv12 and added
> > NV12 case in existing skl_plane_formats
> > - Added the 10bpc RGB formats
> >
> > v4: Addressed review comments from Clinton A Taylor "Why are we
> adding
> > 10 bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Removed 10bit RGB formats added previously with NV12 series
> >
> > v5: Missed the Tested-by/Reviewed-by in the previous series Adding the
> > same to commit message in this version.
> > Addressed review comments from Clinton A Taylor "Why are we adding 10
> > bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Previous version has 10bit RGB format removed from VLV formats by
> > mistake. Fixing that in this version.
> > Removed 10bit RGB formats added previously with NV12 series for SKL.
> >
> > v6: Addressed review comments by Ville Restricting the NV12 to BXT and
> > PIPE A and B
> >
> > v7: Rebased (me)
> >
> > v8: Rebased (me)
> > Restricting NV12 changes to BXT and KBL Restricting NV12 changes for
> > plane 0 (overlay)
> >
> > v9: Rebased (me)
> >
> > v10: Addressed review comments from Maarten.
> > Adding NV12 to skl_plane_formats itself.
> >
> > v11: Addressed review comments from Shashank Sharma
> >
> > v12: Addressed review comments from Shashank Sharma Made the
> condition
> > in intel_sprite_plane_create simple and easy to read as suggested.
> >
> > v13: Adding reviewed by tag from Shashank Sharma Addressed review
> > comments from Juha-Pekka Heikkila
> > "NV12 not to be supported by SKL"
> >
> > v14: Addressed review comments from Ville Added skl_planar_formats to
> > include NV12 and a check skl_plane_has_planar in sprite create Added
> > NV12 format to skl_mod_supported. These were review comments from
> > Kristian Høgsberg <hoegsb...@gmail.com>
> >
> > v15: Added reviewed by from Juha-Pekka Heikkila
> >
> > v16: Rebased the series
> >
> > v17: Added all tiling under mod supported for NV12 Credits to Megha
> > Aggarwal
> >
> > v18: Added RB by Maarten and Kristian
> >
> > Credits-to: Megha Aggarwal <megha.aggar...@intel.com>
> > Credits-to: Kristian Høgsberg <hoegsb...@gmail.com>
> > Reviewed-by: Kristian Høgsberg <hoegsb...@gmail.com>
> > Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>
> > Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikk...@gmail.com>
> > Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
> > Reviewed-by: Clinton Taylor <clinton.a.tay...@intel.com>
> > Signed-off-by: Chandra Konduru <chandra.kond...@intel.com>
> > Signed-off-by: Nabendu Maiti <nabendu.bikash.ma...@intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_sprite.c | 29
> > +++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index c73553a..cdcae9e 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1180,6 +1180,19 @@ static uint32_t skl_plane_formats[] = {
> > DRM_FORMAT_VYUY,
> >  };
> >
> > +static uint32_t skl_planar_formats[] = {
> > +   DRM_FORMAT_RGB565,
> > +   DRM_FORMAT_ABGR,
> > +   DRM_FORMAT_ARGB,
> > +   DRM_FORMAT_XBGR,
> > +   DRM_FORMAT_XRGB,
> > +   DRM_FORMAT_YUYV,
> > +   DRM_FORMAT_YVYU,
> > +   DRM_FORMAT_UYVY,
> > +   DRM_FORMAT_VYUY,
> > +   DRM

Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-05-05 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Friday, May 4, 2018 6:46 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; 'Kristian Høgsberg'
> <hoegsb...@gmail.com>
> Cc: 'intel-gfx@lists.freedesktop.org' <intel-gfx@lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> 
> Op 03-05-18 om 10:58 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Wednesday, May 2, 2018 3:47 PM
> >> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; Kristian
> >> Høgsberg <hoegsb...@gmail.com>
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> >>
> >>
> >>
> >>> -----Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Wednesday, May 2, 2018 2:29 PM
> >>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Kristian Høgsberg
> >>> <hoegsb...@gmail.com>
> >>> Cc: intel-gfx@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> >>>
> >>> Hey,
> >>>
> >>> Op 02-05-18 om 04:43 schreef Srinivas, Vidya:
> >>>>> -Original Message-
> >>>>> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> >>>>> Sent: Monday, April 30, 2018 11:58 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>
> >>>>> Cc: intel-gfx@lists.freedesktop.org
> >>>>> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> >>>>>
> >>>>> On Thu, Apr 19, 2018 at 3:34 AM Vidya Srinivas
> >>>>> <vidya.srini...@intel.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Enabling NV12 support:
> >>>>>> - Framebuffer creation
> >>>>>> - Primary and Sprite plane support Patch series depend on Enable
> >>>>>> display workaround 827 patch mentioned below submitted by
> Maarten
> >>>>> How are we looking on being able to land these last NV12 patches?
> >>>> I think Maarten is working on this series related
> >>>> https://patchwork.freedesktop.org/series/42476/
> >>>> I guess all would go in together?
> >>> I did some testing and with just the nv12 series and my series I
> >>> don't hit underruns.
> >> Thank you so much. I applied your series
> >> https://patchwork.freedesktop.org/series/42476/
> >> And then applied the NV12 series
> >> https://patchwork.freedesktop.org/series/41674/
> >> Somehow, I see that patch 6 doesn’t show the updated contents you
> >> have submitted under https://patchwork.freedesktop.org/patch/219915/
> >> Not sure if only I don’t see the change (series show updated may 2nd
> >> but rev
> >> 3 contents are not reflecting in patch 6)
> > What I meant to ask was - should I make the changes and update again?
> > Or could you please help push it from your side? Please let me know.
> > Thank you. Also, can all these go in now? I mean for merge :)
> We want to test again on top of drm-tip, so best just make the changes, and
> reorder in the order I specified earlier. :)
> 
Thank you so much. I have changed the patch and ordering as per your suggestion
vnd floated them. Kindly have a check.

Regards
Vidya

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


Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-05-03 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Wednesday, May 2, 2018 3:47 PM
> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; Kristian
> Høgsberg <hoegsb...@gmail.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> 
> 
> 
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Wednesday, May 2, 2018 2:29 PM
> > To: Srinivas, Vidya <vidya.srini...@intel.com>; Kristian Høgsberg
> > <hoegsb...@gmail.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> >
> > Hey,
> >
> > Op 02-05-18 om 04:43 schreef Srinivas, Vidya:
> > >
> > >> -----Original Message-
> > >> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> > >> Sent: Monday, April 30, 2018 11:58 PM
> > >> To: Srinivas, Vidya <vidya.srini...@intel.com>
> > >> Cc: intel-gfx@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> > >>
> > >> On Thu, Apr 19, 2018 at 3:34 AM Vidya Srinivas
> > >> <vidya.srini...@intel.com>
> > >> wrote:
> > >>
> > >>> Enabling NV12 support:
> > >>> - Framebuffer creation
> > >>> - Primary and Sprite plane support Patch series depend on Enable
> > >>> display workaround 827 patch mentioned below submitted by Maarten
> > >> How are we looking on being able to land these last NV12 patches?
> > > I think Maarten is working on this series related
> > > https://patchwork.freedesktop.org/series/42476/
> > > I guess all would go in together?
> >
> > I did some testing and with just the nv12 series and my series I don't
> > hit underruns.
> 
> Thank you so much. I applied your series
> https://patchwork.freedesktop.org/series/42476/
> And then applied the NV12 series
> https://patchwork.freedesktop.org/series/41674/
> Somehow, I see that patch 6 doesn’t show the updated contents you have
> submitted under https://patchwork.freedesktop.org/patch/219915/
> Not sure if only I don’t see the change (series show updated may 2nd but rev
> 3 contents are not reflecting in patch 6)

What I meant to ask was - should I make the changes and update again?
Or could you please help push it from your side? Please let me know.
Thank you. Also, can all these go in now? I mean for merge :)

Regards
Vidya

> 
> But, I manually made the changes you mentioned and I too did not see any
> underruns on GLK.
> Couldn’t run the set on APL as we now have BXT removed.
> 
> Regards
> Vidya
> 
> > I made the following changes to your series on top of mine:
> >
> > skl_update_scaler check removed, was done in patch 6 instead.
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ad13c797e946..0a651f26f827 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4861,8 +4861,7 @@ skl_update_scaler(struct intel_crtc_state
> > *crtc_state, bool force_detach,
> > }
> >
> > if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
> > -   (src_h < SKL_MIN_YUV_420_SRC_H || (src_w % 4) != 0 ||
> > -(src_h % 4) != 0)) {
> > +   (src_h < SKL_MIN_YUV_420_SRC_H || src_w <
> > SKL_MIN_YUV_420_SRC_W))
> > +{
> > DRM_DEBUG_KMS("NV12: src dimensions not met\n");
> > return -EINVAL;
> > }
> >
> > And fixup sprite format.
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index dcba946af2ff..573ef6932633 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1011,6 +1011,7 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> > src->y2 = (src_y + src_h) << 16;
> >
> > if (intel_format_is_yuv(fb->format->format) &&
> > +   fb->format->format != DRM_FORMAT_NV12 &&
> > (src_x % 2 || src_w % 2)) {
> > DRM_DEBUG_KMS("src x/w (%u, %u) must be a
> multiple of 2 for YUV
> > planes\n",
> >   src_x, src_w);

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


Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-05-02 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, May 2, 2018 2:29 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Kristian Høgsberg
> <hoegsb...@gmail.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> 
> Hey,
> 
> Op 02-05-18 om 04:43 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> >> Sent: Monday, April 30, 2018 11:58 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> >>
> >> On Thu, Apr 19, 2018 at 3:34 AM Vidya Srinivas
> >> <vidya.srini...@intel.com>
> >> wrote:
> >>
> >>> Enabling NV12 support:
> >>> - Framebuffer creation
> >>> - Primary and Sprite plane support
> >>> Patch series depend on Enable display workaround 827 patch mentioned
> >>> below submitted by Maarten
> >> How are we looking on being able to land these last NV12 patches?
> > I think Maarten is working on this series related
> > https://patchwork.freedesktop.org/series/42476/
> > I guess all would go in together?
> 
> I did some testing and with just the nv12 series and my series I don't hit
> underruns.

Thank you so much. I applied your series 
https://patchwork.freedesktop.org/series/42476/
And then applied the NV12 series https://patchwork.freedesktop.org/series/41674/
Somehow, I see that patch 6 doesn’t show the updated contents you have 
submitted under https://patchwork.freedesktop.org/patch/219915/
Not sure if only I don’t see the change (series show updated may 2nd but rev 3 
contents are not reflecting in patch 6)

But, I manually made the changes you mentioned and I too did not see any 
underruns on GLK.
Couldn’t run the set on APL as we now have BXT removed.

Regards
Vidya

> I made the following changes to your series on top of mine:
> 
> skl_update_scaler check removed, was done in patch 6 instead.
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ad13c797e946..0a651f26f827 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4861,8 +4861,7 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
>   }
> 
>   if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
> - (src_h < SKL_MIN_YUV_420_SRC_H || (src_w % 4) != 0 ||
> -  (src_h % 4) != 0)) {
> + (src_h < SKL_MIN_YUV_420_SRC_H || src_w <
> SKL_MIN_YUV_420_SRC_W))
> +{
>   DRM_DEBUG_KMS("NV12: src dimensions not met\n");
>   return -EINVAL;
>   }
> 
> And fixup sprite format.
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index dcba946af2ff..573ef6932633 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1011,6 +1011,7 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
>   src->y2 = (src_y + src_h) << 16;
> 
>   if (intel_format_is_yuv(fb->format->format) &&
> + fb->format->format != DRM_FORMAT_NV12 &&
>   (src_x % 2 || src_w % 2)) {
>   DRM_DEBUG_KMS("src x/w (%u, %u) must be a
> multiple of 2 for YUV planes\n",
> src_x, src_w);

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


Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-05-01 Thread Srinivas, Vidya


> -Original Message-
> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> Sent: Monday, April 30, 2018 11:58 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support
> 
> On Thu, Apr 19, 2018 at 3:34 AM Vidya Srinivas <vidya.srini...@intel.com>
> wrote:
> 
> > Enabling NV12 support:
> > - Framebuffer creation
> > - Primary and Sprite plane support
> > Patch series depend on Enable display workaround 827 patch mentioned
> > below submitted by Maarten
> 
> How are we looking on being able to land these last NV12 patches?

I think Maarten is working on this series related 
https://patchwork.freedesktop.org/series/42476/
I guess all would go in together?

Regards
Vidya

> 
> Kristian
> 
> > Changes from prev version:
> > Removed BXT support for NV12 due to WA826
> 
> > Chandra Konduru (3):
> >drm/i915: Add NV12 as supported format for primary plane
> >drm/i915: Add NV12 as supported format for sprite plane
> >drm/i915: Add NV12 support to intel_framebuffer_init
> 
> > Maarten Lankhorst (2):
> >drm/i915: Enable display workaround 827 for all planes, v2.
> >drm/i915: Add skl_check_nv12_surface for NV12
> 
> > Vidya Srinivas (1):
> >drm/i915: Enable Display WA 0528
> 
> >   drivers/gpu/drm/i915/intel_atomic_plane.c |   7 +-
> >   drivers/gpu/drm/i915/intel_display.c  | 175
> ++
> >   drivers/gpu/drm/i915/intel_drv.h  |   3 +
> >   drivers/gpu/drm/i915/intel_sprite.c   |  44 +++-
> >   4 files changed, 203 insertions(+), 26 deletions(-)
> 
> > --
> > 2.7.4
> 
> > ___
> > 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 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-18 Thread Srinivas, Vidya


> -Original Message-
> From: Kahola, Mika
> Sent: Wednesday, April 18, 2018 5:39 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> skl_check_nv12_surface for NV12
> 
> On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote:
> > From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> The patch looks good to me.
> 
> Reviewed-by: Mika Kahola <mika.kah...@intel.com>

Thank you. Will add the RB in next push.

Regards
Vidya
> 
> >
> > Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 39
> > 
> >  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
> >  2 files changed, 50 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 925402e..b8dbaca 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct
> > intel_crtc_state *crtc_state,
> >     return 0;
> >  }
> >
> > +static int
> > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > +      struct intel_plane_state *plane_state) {
> > +   int crtc_x2 = plane_state->base.crtc_x + plane_state-
> > >base.crtc_w;
> > +   int crtc_y2 = plane_state->base.crtc_y + plane_state-
> > >base.crtc_h;
> > +
> > +   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > +   ((plane_state->base.src_h >> 16) % 4) != 0) {
> > +   DRM_DEBUG_KMS("src coords must be multiple of 4 for
> > NV12\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Clipping would cause a 1-3 pixel gap at the edge of the
> > screen? */
> > +   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state-
> > >pipe_src_w % 4) ||
> > +   (crtc_y2 > crtc_state->pipe_src_h && crtc_state-
> > >pipe_src_h % 4)) {
> > +   DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> > %u,%u\n",
> > +     crtc_x2, crtc_y2,
> > +     crtc_state->pipe_src_w, crtc_state-
> > >pipe_src_h);
> > +   return -EINVAL;
> > +   }
> > +
> > +   plane_state->base.src.x1 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18)
> > << 18;
> > +   plane_state->base.src.x2 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18)
> > << 18;
> > +   plane_state->base.src.y1 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18)
> > << 18;
> > +   plane_state->base.src.y2 =
> > +   DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18)
> > << 18;
> > +
> > +   return 0;
> > +}
> > +
> >  static int skl_check_nv12_aux_surface(struct intel_plane_state
> > *plane_state)
> >  {
> >     const struct drm_framebuffer *fb = plane_state->base.fb; @@ -
> 3201,6
> > +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state
> > *crtc_state,
> >      * the main surface setup depends on it.
> >      */
> >     if (fb->format->format == DRM_FORMAT_NV12) {
> > +   ret = skl_check_nv12_surface(crtc_state,
> > plane_state);
> > +   if (ret)
> > +   return ret;
> >     ret = skl_check_nv12_aux_surface(plane_state);
> >     if (ret)
> >     return ret;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..f9985fb 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-18 Thread Srinivas, Vidya




> -Original Message-

> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]

> Sent: Thursday, April 19, 2018 12:06 AM

> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

> Cc: Srinivas, Vidya <vidya.srini...@intel.com>; intel-

> g...@lists.freedesktop.org

> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add

> skl_check_nv12_surface for NV12

>

> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:

> > Op 18-04-18 om 17:32 schreef Ville Syrjälä:

> > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:

> > >> From: Maarten Lankhorst 
> > >> <maarten.lankho...@linux.intel.com<mailto:maarten.lankho...@linux.intel.com>>

> > >>

> > >> We skip src trunction/adjustments for

> > >> NV12 case and handle the sizes directly.

> > >> Without this, pipe fifo underruns are seen on APL/KBL.

> > >>

> > >> v2: For NV12, making the src coordinates multiplier of 4

> > >>

> > >> v3: Moving all the src coords handling code for NV12 to

> > >> skl_check_nv12_surface

> > >>

> > >> Signed-off-by: Maarten Lankhorst

> > >> <maarten.lankho...@linux.intel.com<mailto:maarten.lankho...@linux.intel.com>>

> > >> Signed-off-by: Vidya Srinivas 
> > >> <vidya.srini...@intel.com<mailto:vidya.srini...@intel.com>>

> > >> ---

> > >>  drivers/gpu/drm/i915/intel_display.c | 39

> > >> 

> > >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++

> > >>  2 files changed, 50 insertions(+), 4 deletions(-)

> > >>

> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c

> > >> b/drivers/gpu/drm/i915/intel_display.c

> > >> index 925402e..b8dbaca 100644

> > >> --- a/drivers/gpu/drm/i915/intel_display.c

> > >> +++ b/drivers/gpu/drm/i915/intel_display.c

> > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const

> struct intel_crtc_state *crtc_state,

> > >>  return 0;

> > >>  }

> > >>

> > >> +static int

> > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,

> > >> +   struct intel_plane_state 
> > >> *plane_state) {

> > >> +int crtc_x2 = plane_state->base.crtc_x + 
> > >> plane_state->base.crtc_w;

> > >> +int crtc_y2 = plane_state->base.crtc_y +

> > >> +plane_state->base.crtc_h;

> > >> +

> > >> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_y >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_w >> 16) % 4) != 0 ||

> > >> +((plane_state->base.src_h >> 16) % 4) != 0) {

> > >> +DRM_DEBUG_KMS("src coords must be 
> > >> multiple of 4 for

> NV12\n");

> > >> +return -EINVAL;

> > >> +}

> > > I don't really see why we should check these. The clipped

> > > coordinates are what matters.

> >

> > To propagate our limits to the userspace. I think we should do it for

> > all formats, but NV12 is the first YUV format we have tests for. If we

> > could we should do something similar for the other YUV formats, but they

> have different requirements.

> >

> > In case of NV12 we don't have existing userspace, there will be

> > nothing that breaks if we enforce limits from the start.

>

> But what about sub-pixel coordinates? You're totally ignoring them here.

> We need to come up with some proper rules for this stuff.

>

> >

> > >> +

> > >> +/* Clipping would cause a 1-3 pixel gap at the edge of 
> > >> the screen? */

> > >> +if ((crtc_x2 > crtc_state->pipe_src_w && 
> > >> crtc_state->pipe_src_w %

> 4) ||

> > >> +(crtc_y2 > crtc_state->pipe_src_h && 
> > >> crtc_state->pipe_src_h % 4))

> {

> > >> +DRM_DEBUG_KMS("It's not possible to 
> > >> clip %u,%u to

> %u,%u\n",

> > >> + 

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Saarinen, Jani
> Sent: Wednesday, April 18, 2018 11:07 AM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Maarten Lankhorst
> <maarten.lankho...@linux.intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Hi,
> 
> > -Original Message-
> > From: Srinivas, Vidya
> > Sent: keskiviikko 18. huhtikuuta 2018 6.56
> > To: Saarinen, Jani <jani.saari...@intel.com>; Maarten Lankhorst
> > <maarten.lankho...@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> >
> >
> > > -Original Message-
> > > From: Saarinen, Jani
> > > Sent: Tuesday, April 17, 2018 4:23 PM
> > > To: Srinivas, Vidya <vidya.srini...@intel.com>; Maarten Lankhorst
> > > <maarten.lankho...@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > for
> > > NV12
> > >
> > > HI,
> > > > -Original Message-
> > > > From: Srinivas, Vidya
> > > > Sent: tiistai 17. huhtikuuta 2018 13.49
> > > > To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> > > > Saarinen, Jani <jani.saari...@intel.com>;
> > > > intel-gfx@lists.freedesktop.org
> > > > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > > for
> > > > NV12
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Maarten Lankhorst
> > > > > [mailto:maarten.lankho...@linux.intel.com]
> > > > > Sent: Tuesday, April 17, 2018 3:32 PM
> > > > > To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> > > > > <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > > > > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > adjustments for
> > > > > NV12
> > > > >
> > > > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > > > > >
> > > > > >> -Original Message-
> > > > > >> From: Maarten Lankhorst
> > > > > >> [mailto:maarten.lankho...@linux.intel.com]
> > > > > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > > > > >> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen,
> > > > > >> Jani <jani.saari...@intel.com>;
> > > > > >> intel-gfx@lists.freedesktop.org
> > > > > >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >> adjustments for
> > > > > >> NV12
> > > > > >>
> > > > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > > > > >>>> -Original Message-
> > > > > >>>> From: Srinivas, Vidya
> > > > > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > > > > >>>> To: 'Maarten Lankhorst'
> > > > > >>>> <maarten.lankho...@linux.intel.com>;
> > > > > >>>> Saarinen, Jani <jani.saari...@intel.com>;
> > > > > >>>> intel-gfx@lists.freedesktop.org
> > > > > >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > > > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >>>> adjustments for
> > > > > >>>> NV12
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> -Original Message-
> > > > > >>>>> From: Maarten Lankhorst
> > > > > >>>>> [mailto:maarten.lankho...@linux.intel.com]
> > > > > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > > > > >

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -Original Message-
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saari...@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >>>>> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -Original Message-
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srini...@intel.com>;
> >>>>>>> intel-gfx-try...@lists.freedesktop.org;
> >>>>>>> intel- g...@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -Original Message-
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> >>>>>>>>> intel-gfx- try...@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saari...@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -Original Message-
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>>>>>>>>> try...@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kam...

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Saarinen, Jani
> Sent: Tuesday, April 17, 2018 4:23 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Maarten Lankhorst
> <maarten.lankho...@linux.intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> HI,
> > -Original Message-
> > From: Srinivas, Vidya
> > Sent: tiistai 17. huhtikuuta 2018 13.49
> > To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; Saarinen,
> > Jani <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> >
> >
> > > -Original Message-----
> > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > > Sent: Tuesday, April 17, 2018 3:32 PM
> > > To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> > > <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > for
> > > NV12
> > >
> > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > > >
> > > >> -Original Message-
> > > >> From: Maarten Lankhorst
> > > >> [mailto:maarten.lankho...@linux.intel.com]
> > > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > > >> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> > > >> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > > >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >> adjustments for
> > > >> NV12
> > > >>
> > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > > >>>> -Original Message-
> > > >>>> From: Srinivas, Vidya
> > > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > > >>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> > > >>>> Saarinen, Jani <jani.saari...@intel.com>;
> > > >>>> intel-gfx@lists.freedesktop.org
> > > >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>> adjustments for
> > > >>>> NV12
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> -Original Message-
> > > >>>>> From: Maarten Lankhorst
> > > >>>>> [mailto:maarten.lankho...@linux.intel.com]
> > > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > > >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> > > >>>>> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > > >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>> adjustments for
> > > >>>>> NV12
> > > >>>>>
> > > >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > > >>>>>>> -Original Message-
> > > >>>>>>> From: Maarten Lankhorst
> > > >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> > > >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> > > >>>>>>> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas,
> > > >>>>>>> Vidya <vidya.srini...@intel.com>;
> > > >>>>>>> intel-gfx-try...@lists.freedesktop.org;
> > > >>>>>>> intel- g...@lists.freedesktop.org
> > > >>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > > >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>>>> adjustments for
> > > >>>>>>> NV12
> > > >>>>>>>
> > > >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > > >>>

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -Original Message-
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saari...@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >>>>> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -Original Message-
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srini...@intel.com>;
> >>>>>>> intel-gfx-try...@lists.freedesktop.org;
> >>>>>>> intel- g...@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -Original Message-
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> >>>>>>>>> intel-gfx- try...@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saari...@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -Original Message-
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>>>>>>>>> try...@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kam...

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -Original Message-
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saari...@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >>>>> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -Original Message-
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srini...@intel.com>;
> >>>>>>> intel-gfx-try...@lists.freedesktop.org;
> >>>>>>> intel- g...@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -Original Message-
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> >>>>>>>>> intel-gfx- try...@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saari...@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -Original Message-
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>>>>>>>>> try...@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kam...

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:04 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Tuesday, April 17, 2018 1:32 PM
> >> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>;
> >> Saarinen, Jani <jani.saari...@intel.com>;
> >> intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> >>> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> >>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> >>>>> <vidya.srini...@intel.com>;
> >>>>> intel-gfx-try...@lists.freedesktop.org;
> >>>>> intel- g...@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Srinivas, Vidya
> >>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> >>>>>>> intel-gfx- try...@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>>>> <jani.saari...@intel.com>
> >>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for NV12
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Maarten Lankhorst
> >>>>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>>>>>>> try...@lists.freedesktop.org
> >>>>>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>>>>> <jani.saari...@intel.com>
> >>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>> adjustments for
> >>>>>>>> NV12
> >>>>>>>>
> >>>>>>>> Hmm, more thought about src adjustments...
> >>>>>>>>
> >>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>>>>> We skip src trunction/adjustments for
> >>>>>>>>> NV12 case and handle the sizes directly.
> >>>>>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>>>>>>
> >>>>>>>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>>>>>>
> >>>>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>>>> <ma

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Kahola, Mika
> Sent: Tuesday, April 17, 2018 2:49 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src
> adjustments for NV12
> 
> On Fri, 2018-04-13 at 17:44 +0530, Vidya Srinivas wrote:
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 11 +++
> >  drivers/gpu/drm/i915/intel_sprite.c  | 15 +++
> >  2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bc83f10..f64708f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> intel_plane
> > *plane,
> >     bool can_position = false;
> >     int ret;
> >     uint32_t pixel_format = 0;
> > +   struct drm_plane_state *plane_state = >base;
> > +   struct drm_rect *src = _state->src;
> This seems unnecessary. We could use the line below to get the src's.
Sure thank you, am moving all the handling code to skl_check_nv12_aux_surface 
as suggested
By Maarten. So this wont be necessary.

Regards
Vidya
> 
> > +
> > +   *src = drm_plane_state_src(plane_state);
> >
> >     if (INTEL_GEN(dev_priv) >= 9) {
> >     /* use scaler when colorkey is not required */ @@ -13001,6
> > +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> >     if (!state->base.fb)
> >     return 0;
> >
> > +   if (pixel_format == DRM_FORMAT_NV12) {
> > +   src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > +   src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > +   src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > +   src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > +   }
> > +
> >     if (INTEL_GEN(dev_priv) >= 9) {
> >     ret = skl_check_plane_surface(crtc_state, state);
> >     if (ret)
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..c1dd85e 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >     return vscale;
> >     }
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12) {
> > +   if (src->x2 >> 16 == 16)
> > +   src->x2 = 16 << 16;
> > +   if (src->y2 >> 16 == 16)
> > +   src->y2 = 16 << 16;
> > +   goto nv12_min_no_clip;
> > +   }
> > +
> >     /* Make the source viewport size an exact multiple of the
> scaling
> > factors. */
> >     drm_rect_adjust_size(src,
> >      drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> >      drm_rect_height(dst) * vscale -
> drm_rect_height(src));
> >
> > +nv12_min_no_clip:
> >     drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> >     state->base.rotation);
> >
> > @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >     src->x2 = (src_x + src_w) << 16;
> >     src->y1 = src_y << 16;
> >     src->y2 = (src_y + src_h) << 16;
> > +   if (fb->format->format == DRM_FORMAT_NV12) {
> > +   src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > +   src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > +   src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > +   src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > +   }
> >     }
> >
> >     dst->x1 = crtc_x;
> --
> Mika Kahola - Intel OTC

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


Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, April 17, 2018 1:32 PM
> To: 'Maarten Lankhorst' <maarten.lankho...@linux.intel.com>; Saarinen,
> Jani <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> 
> 
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 1:21 PM
> > To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> > <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Tuesday, April 17, 2018 12:55 PM
> > >> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> > >> <vidya.srini...@intel.com>; intel-gfx-try...@lists.freedesktop.org;
> > >> intel- g...@lists.freedesktop.org
> > >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > >> for
> > >> NV12
> > >>
> > >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > >>> Lets move this to intel-gfx to get more eyes on it.
> > >>>
> > >>>> -Original Message-
> > >>>> From: Srinivas, Vidya
> > >>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > >>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> > >>>> intel-gfx- try...@lists.freedesktop.org
> > >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> > >>>> <jani.saari...@intel.com>
> > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>> adjustments for NV12
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -Original Message-
> > >>>>> From: Maarten Lankhorst
> > >>>>> [mailto:maarten.lankho...@linux.intel.com]
> > >>>>> Sent: Monday, April 16, 2018 8:00 PM
> > >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> > >>>>> try...@lists.freedesktop.org
> > >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> > >>>>> <jani.saari...@intel.com>
> > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>> adjustments for
> > >>>>> NV12
> > >>>>>
> > >>>>> Hmm, more thought about src adjustments...
> > >>>>>
> > >>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > >>>>>> We skip src trunction/adjustments for
> > >>>>>> NV12 case and handle the sizes directly.
> > >>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
> > >>>>>>
> > >>>>>> v2: For NV12, making the src coordinates multiplier of 4
> > >>>>>>
> > >>>>>> Credits-to: Maarten Lankhorst
> > >>>>>> <maarten.lankho...@linux.intel.com>
> > >>>>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > >>>>>> ---
> > >>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++
> > >>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++
> > >>>>>>  2 files changed, 26 insertions(+)
> > >>>>>>
> > >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> index bc83f10..f64708f 100644
> > >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> > >>>>> intel_plane *plane,
> > >>>>>>  bool can_position = false;
> > &

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 1:21 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 12:55 PM
> >> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> >> <vidya.srini...@intel.com>; intel-gfx-try...@lists.freedesktop.org;
> >> intel- g...@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>> Lets move this to intel-gfx to get more eyes on it.
> >>>
> >>>> -Original Message-
> >>>> From: Srinivas, Vidya
> >>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>;
> >>>> intel-gfx- try...@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>> <jani.saari...@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for NV12
> >>>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>>>> try...@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>>>> <jani.saari...@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Hmm, more thought about src adjustments...
> >>>>>
> >>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>> We skip src trunction/adjustments for
> >>>>>> NV12 case and handle the sizes directly.
> >>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>>>
> >>>>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>>>
> >>>>>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>>>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>>>>> ---
> >>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++
> >>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++
> >>>>>>  2 files changed, 26 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> index bc83f10..f64708f 100644
> >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>>>> intel_plane *plane,
> >>>>>>bool can_position = false;
> >>>>>>int ret;
> >>>>>>uint32_t pixel_format = 0;
> >>>>>> +  struct drm_plane_state *plane_state = >base;
> >>>>>> +  struct drm_rect *src = _state->src;
> >>>>>> +
> >>>>>> +  *src = drm_plane_state_src(plane_state);
> >>>>>>
> >>>>>>if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>/* use scaler when colorkey is not required */ @@ -
> 13001,6
> >>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
> >>>>>>if (!state->base.fb)
> >>>>>>return 0;
> >>>>>>
> >>>

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-17 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 12:55 PM
> To: Saarinen, Jani <jani.saari...@intel.com>; Srinivas, Vidya
> <vidya.srini...@intel.com>; intel-gfx-try...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > Lets move this to intel-gfx to get more eyes on it.
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: tiistai 17. huhtikuuta 2018 5.47
> >> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>; intel-gfx-
> >> try...@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >> <jani.saari...@intel.com>
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for NV12
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Monday, April 16, 2018 8:00 PM
> >>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >>> try...@lists.freedesktop.org
> >>> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >>> <jani.saari...@intel.com>
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Hmm, more thought about src adjustments...
> >>>
> >>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>> We skip src trunction/adjustments for
> >>>> NV12 case and handle the sizes directly.
> >>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>
> >>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>
> >>>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>>> ---
> >>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++
> >>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++
> >>>>  2 files changed, 26 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>> index bc83f10..f64708f 100644
> >>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>> intel_plane *plane,
> >>>>  bool can_position = false;
> >>>>  int ret;
> >>>>  uint32_t pixel_format = 0;
> >>>> +struct drm_plane_state *plane_state = >base;
> >>>> +struct drm_rect *src = _state->src;
> >>>> +
> >>>> +*src = drm_plane_state_src(plane_state);
> >>>>
> >>>>  if (INTEL_GEN(dev_priv) >= 9) {
> >>>>  /* use scaler when colorkey is not required */ @@ 
> >>>> -13001,6
> >>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> >>>>  if (!state->base.fb)
> >>>>  return 0;
> >>>>
> >>>> +if (pixel_format == DRM_FORMAT_NV12) {
> >>>> +src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>> +src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>> +src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>> +src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>> +}
> >>> Lets reject non multiple of 4 coordinates for plane_state's src_x
> >>> and src_y, and before adjustment also reject non multiple of 4
> >>> src_w/src_h.fter that we can also reject clipping to the
> >>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> >>> multiple of 4. That way an application trying to go beyond the screen.
> >> kms_plane_scaling and some other tests during execution generate lots
> >> of non mult of 4 buffer width/height. All these tests will show fail
> >> in t

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Add NV12 as supported format for sprite plane

2018-04-15 Thread Srinivas, Vidya
Thank you so much. I had included your name also under credits-to
I will add your RB before merging.

Regards
Vidya

> -Original Message-
> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> Sent: Friday, April 13, 2018 9:44 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> On Fri, Apr 13, 2018 at 5:18 AM Vidya Srinivas <vidya.srini...@intel.com>
> wrote:
> 
> > From: Chandra Konduru <chandra.kond...@intel.com>
> 
> > This patch adds NV12 to list of supported formats for sprite plane.
> 
> > v2: Rebased (me)
> 
> > v3: Review comments by Ville addressed
> > - Removed skl_plane_formats_with_nv12 and added
> > NV12 case in existing skl_plane_formats
> > - Added the 10bpc RGB formats
> 
> > v4: Addressed review comments from Clinton A Taylor "Why are we
> adding
> > 10 bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Removed 10bit RGB formats added previously with NV12 series
> 
> > v5: Missed the Tested-by/Reviewed-by in the previous series Adding the
> > same to commit message in this version.
> > Addressed review comments from Clinton A Taylor "Why are we adding 10
> > bit RGB formats with the NV12 series patches?
> > Trying to set XR30 or AB30 results in error returned even though the
> > modes are advertised for the planes"
> > - Previous version has 10bit RGB format removed from VLV formats by
> > mistake. Fixing that in this version.
> > Removed 10bit RGB formats added previously with NV12 series for SKL.
> 
> > v6: Addressed review comments by Ville Restricting the NV12 to BXT and
> > PIPE A and B
> 
> > v7: Rebased (me)
> 
> > v8: Rebased (me)
> > Restricting NV12 changes to BXT and KBL Restricting NV12 changes for
> > plane 0 (overlay)
> 
> > v9: Rebased (me)
> 
> > v10: Addressed review comments from Maarten.
> > Adding NV12 to skl_plane_formats itself.
> 
> > v11: Addressed review comments from Shashank Sharma
> 
> > v12: Addressed review comments from Shashank Sharma Made the
> condition
> > in intel_sprite_plane_create simple and easy to read as suggested.
> 
> > v13: Adding reviewed by tag from Shashank Sharma Addressed review
> > comments from Juha-Pekka Heikkila
> > "NV12 not to be supported by SKL"
> 
> > v14: Addressed review comments from Ville Added skl_planar_formats to
> > include NV12 and a check skl_plane_has_planar in sprite create Added
> > NV12 format to skl_mod_supported. These were review comments from
> > Kristian Høgsberg <hoegsb...@gmail.com>
> 
> > v15: Added reviewed by from Juha-Pekka Heikkila
> 
> > v16: Rebased the series
> 
> > v17: Added all tiling under mod supported for NV12 Credits to Megha
> > Aggarwal
> 
> > Credits-to: Megha Aggarwal <megha.aggar...@intel.com>
> > Credits-to: Kristian Høgsberg <hoegsb...@gmail.com>
> > Tested-by: Clinton Taylor <clinton.a.tay...@intel.com>
> > Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikk...@gmail.com>
> > Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
> > Reviewed-by: Clinton Taylor <clinton.a.tay...@intel.com>
> > Signed-off-by: Chandra Konduru <chandra.kond...@intel.com>
> > Signed-off-by: Nabendu Maiti <nabendu.bikash.ma...@intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_sprite.c | 29
> +++--
> >   1 file changed, 27 insertions(+), 2 deletions(-)
> 
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> > index aa1dfaa..8b7947d 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1253,6 +1253,19 @@ static uint32_t skl_plane_formats[] = {
> >  DRM_FORMAT_VYUY,
> >   };
> 
> > +static uint32_t skl_planar_formats[] = {
> > +   DRM_FORMAT_RGB565,
> > +   DRM_FORMAT_ABGR,
> > +   DRM_FORMAT_ARGB,
> > +   DRM_FORMAT_XBGR,
> > +   DRM_FORMAT_XRGB,
> > +   DRM_FORMAT_YUYV,
> > +   DRM_FORMAT_YVYU,
> > +   DRM_FORMAT_UYVY,
> > +   DRM_FORMAT_VYUY,
> > +   DRM_FORMAT_NV12,
> > +};
> > +
> >   static const uint64_t skl_plane_format_modifiers_no

Re: [Intel-gfx] [PATCH v1 5/6] drm/i915: Do not do fb src adjustments for NV12

2018-04-13 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, April 12, 2018 4:41 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; Intel Graphics Development
> <intel-gfx@lists.freedesktop.org>; Ville Syrjälä
> <ville.syrj...@linux.intel.com>
> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>
> Subject: Re: [PATCH v1 5/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 12-04-18 om 12:07 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 11, 2018 4:08 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-gfx-
> >> try...@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> >> <jani.saari...@intel.com>
> >> Subject: Re: [PATCH v1 5/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 11-04-18 om 11:09 schreef Vidya Srinivas:
> >>> We skip src trunction/adjustments for
> >>> NV12 case and handle the sizes directly.
> >>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>
> >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_display.c | 88
> >>> ++--
> >>>  drivers/gpu/drm/i915/intel_sprite.c  | 10 +++-
> >>>  2 files changed, 92 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index ebb3f8e..e4cf7a6 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -12951,6 +12951,86 @@ skl_max_scale(struct intel_crtc
> >>> *intel_crtc, }
> >>>
> >>>  static int
> >>> +intel_primary_plane_state(struct drm_plane_state *plane_state,
> >>> +   const struct drm_crtc_state *crtc_state,
> >>> +   int min_scale, int max_scale,
> >>> +   bool can_position, bool can_update_disabled) {
> >>> + struct drm_framebuffer *fb = plane_state->fb;
> >>> + struct drm_rect *src = _state->src;
> >>> + struct drm_rect *dst = _state->dst;
> >>> + unsigned int rotation = plane_state->rotation;
> >>> + struct drm_rect clip = {};
> >>> + int hscale, vscale;
> >>> +
> >>> + WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state-
> >>> crtc);
> >>> +
> >>> + *src = drm_plane_state_src(plane_state);
> >>> + *dst = drm_plane_state_dest(plane_state);
> >>> +
> >>> + if (!fb) {
> >>> + plane_state->visible = false;
> >>> + return 0;
> >>> + }
> >>> +
> >>> + /* crtc should only be NULL when disabling (i.e., !fb) */
> >>> + if (WARN_ON(!plane_state->crtc)) {
> >>> + plane_state->visible = false;
> >>> + return 0;
> >>> + }
> >>> +
> >>> + if (!crtc_state->enable && !can_update_disabled) {
> >>> + DRM_DEBUG_KMS("Cannot update plane of a disabled
> >> CRTC.\n");
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
> >>> +
> >>> + /* Check scaling */
> >>> + hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> >>> + vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> >>> + if (hscale < 0 || vscale < 0) {
> >>> + DRM_DEBUG_KMS("Invalid scaling of plane\n");
> >>> + drm_rect_debug_print("src: ", _state->src, true);
> >>> + drm_rect_debug_print("dst: ", _state->dst, false);
> >>> + return -ERANGE;
> >>> + }
> >>> +
> >>> + if (crtc_state->enable)
> >>> + drm_mode_get_hv_timing(_state->mode, ,
> >> );
> >>> +
> >>> + if (fb->format->format == DRM_FORMAT_NV12) {
&g

Re: [Intel-gfx] [PATCH v1 6/6] drm/i915: Enable Display WA 0528

2018-04-11 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 11, 2018 3:09 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>
> Subject: Re: [PATCH v1 6/6] drm/i915: Enable Display WA 0528
> 
> Op 11-04-18 om 11:09 schreef Vidya Srinivas:
> > Possible hang with NV12 plane surface formats.
> > WA: When the plane source pixel format is NV12, the CHICKEN_PIPESL_*
> > register bit 22 must be set to 1 and the render decompression must not
> > be enabled on any of the planes in that pipe.
> The last part is still missing from this patch, you still need to reject CCS 
> fb's?


Thank you. Yeah, RC should not be enabled on the plane which has NV12 enabled. 
If we want
RC, then I need to set it to 22. Right now on APL I see RC was disabled at that 
time.
So I did not include this portion yet.

> 
> And this should probably be patch 2.
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 24 ++--
> >  1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index e4cf7a6..71eb49e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -511,12 +511,28 @@ skl_wa_clkgate(struct drm_i915_private
> *dev_priv, int pipe, bool enable)
> > return;
> >
> > if (enable)
> > +   I915_WRITE(CHICKEN_PIPESL_1(pipe), HSW_FBCQ_DIS);
> > +   else
> > +   I915_WRITE(CHICKEN_PIPESL_1(pipe), ~HSW_FBCQ_DIS);
> You're writing all bits except HSW_FBCQ_DIS here to the chicken register.. I
> don't think you want that. :)
Oops sorry, the name of the function was supposed to be skl_wa_528.
Thank you.

> > +
> > +   POSTING_READ(CHICKEN_PIPESL_1(pipe));
> > +}
> > +
> > +static void
> > +skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool
> > +enable) {
> > +   if (IS_SKYLAKE(dev_priv))
> > +   return;
> > +
> > +   if (enable)
> > I915_WRITE(CLKGATE_DIS_PSL(pipe),
> >DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> > else
> > I915_WRITE(CLKGATE_DIS_PSL(pipe),
> >I915_READ(CLKGATE_DIS_PSL(pipe)) &
> >~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> > +
> > +   POSTING_READ(CLKGATE_DIS_PSL(pipe));
> >  }
> >
> >  static bool
> > @@ -5202,8 +5218,10 @@ static void intel_post_plane_update(struct
> > intel_crtc_state *old_crtc_state)
> >
> > /* Display WA 827 */
> > if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> > -   !needs_nv12_wa(dev_priv, pipe_config))
> > +   !needs_nv12_wa(dev_priv, pipe_config)) {
> > skl_wa_clkgate(dev_priv, crtc->pipe, false);
> > +   skl_wa_528(dev_priv, crtc->pipe, false);
> > +   }
> >  }
> >
> >  static void intel_pre_plane_update(struct intel_crtc_state
> > *old_crtc_state, @@ -5240,8 +5258,10 @@ static void
> > intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> >
> > /* Display WA 827 */
> > if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> > -   needs_nv12_wa(dev_priv, pipe_config))
> > +   needs_nv12_wa(dev_priv, pipe_config)) {
> > skl_wa_clkgate(dev_priv, crtc->pipe, true);
> > +   skl_wa_528(dev_priv, crtc->pipe, true);
> > +   }
> >
> > /*
> >  * Vblank time updates from the shadow to live plane control
> > register
> 

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


Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enable display workaround 827 for all planes.

2018-04-11 Thread Srinivas, Vidya
Patch looks good to me.
Reviewed-by: Vidya Srinivas 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Maarten Lankhorst
> Sent: Monday, April 9, 2018 6:17 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Enable display workaround 827
> for all planes.
> 
> The workaround was applied only to the primary plane, but is required on all
> planes. Iterate over all planes in the crtc atomic check to see if the
> workaround is enabled, and only perform the actual toggling in the pre/post
> plane update functions.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 40 +-
> --
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  2 files changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 487a6e235222..829b593a3cee 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5162,7 +5162,6 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (old_primary_state) {
>   struct drm_plane_state *new_primary_state =
>   drm_atomic_get_new_plane_state(old_state,
> primary);
> - struct drm_framebuffer *fb = new_primary_state->fb;
> 
>   intel_fbc_post_update(crtc);
> 
> @@ -5170,15 +5169,11 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   (needs_modeset(_config->base) ||
>!old_primary_state->visible))
>   intel_post_enable_primary(>base,
> pipe_config);
> -
> - /* Display WA 827 */
> - if ((INTEL_GEN(dev_priv) == 9 &&
> !IS_GEMINILAKE(dev_priv)) ||
> - IS_CANNONLAKE(dev_priv)) {
> - if (fb && fb->format->format ==
> DRM_FORMAT_NV12)
> - skl_wa_clkgate(dev_priv, crtc->pipe, false);
> - }
> -
>   }
> +
> + /* Display WA 827 */
> + if (old_crtc_state->nv12_wa && !pipe_config->nv12_wa)
> + skl_wa_clkgate(dev_priv, crtc->pipe, false);
>  }
> 
>  static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> @@ -5202,14 +5197,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>   struct intel_plane_state *new_primary_state =
>   intel_atomic_get_new_plane_state(old_intel_state,
> 
> to_intel_plane(primary));
> - struct drm_framebuffer *fb = new_primary_state->base.fb;
> -
> - /* Display WA 827 */
> - if ((INTEL_GEN(dev_priv) == 9 &&
> !IS_GEMINILAKE(dev_priv)) ||
> - IS_CANNONLAKE(dev_priv)) {
> - if (fb && fb->format->format ==
> DRM_FORMAT_NV12)
> - skl_wa_clkgate(dev_priv, crtc->pipe, true);
> - }
> 
>   intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
>   /*
> @@ -5221,6 +5208,10 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>   intel_set_cpu_fifo_underrun_reporting(dev_priv,
> crtc->pipe, false);
>   }
> 
> + /* Display WA 827 */
> + if (!old_crtc_state->nv12_wa && pipe_config->nv12_wa)
> + skl_wa_clkgate(dev_priv, crtc->pipe, true);
> +
>   /*
>* Vblank time updates from the shadow to live plane control
> register
>* are blocked if the memory self-refresh mode is active at that @@
> -10485,6 +10476,21 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
>   return ret;
>   }
> 
> + pipe_config->nv12_wa = false;
> +
> + /* Apply display WA 827 if required. */
> + if (crtc_state->active &&
> + ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
> +  IS_CANNONLAKE(dev_priv))) {
> + struct drm_plane *plane;
> + const struct drm_plane_state *plane_state;
> +
> + drm_atomic_crtc_state_for_each_plane_state(plane,
> plane_state, crtc_state)
> + if (plane_state->fb &&
> + plane_state->fb->format->format ==
> DRM_FORMAT_NV12)
> + pipe_config->nv12_wa = true;
> + }
> +
>   if (crtc_state->color_mgmt_changed) {
>   ret = intel_color_check(crtc, crtc_state);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9969309132d0..9c2b7f78d5dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -723,6 +723,7 @@ struct intel_crtc_state {
>   bool update_wm_pre, update_wm_post; /* watermarks are updated
> */
>   bool fb_changed; /* fb on any of the planes is 

Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12

2018-04-10 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 10, 2018 12:53 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
> 
> Op 10-04-18 om 04:37 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, April 9, 2018 5:15 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >> NV12
> >>
> >> Op 09-04-18 om 11:41 schreef Srinivas, Vidya:
> >>>> -----Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Monday, April 9, 2018 2:38 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >>>> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >>>> NV12
> >>>>
> >>>> Op 09-04-18 om 10:57 schreef Srinivas, Vidya:
> >>>>>> -Original Message-
> >>>>>> From: Maarten Lankhorst
> >>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>> Sent: Monday, April 9, 2018 2:04 PM
> >>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>>> g...@lists.freedesktop.org
> >>>>>> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >>>>>> NV12
> >>>>>>
> >>>>>> Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> >>>>>>> Series contain preparation patches for NV12 support Enabling
> >>>>>>> NV12 KMD support will follow the series
> >>>>>>>
> >>>>>>> Chandra Konduru (3):
> >>>>>>>   drm/i915: Set scaler mode for NV12
> >>>>>>>   drm/i915: Update format_is_yuv() to include NV12
> >>>>>>>   drm/i915: Upscale scaler max scale for NV12
> >>>>>>>
> >>>>>>> Mahesh Kumar (9):
> >>>>>>>   drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> >>>>>>>   drm/i915/skl+: refactor WM calculation for NV12
> >>>>>>>   drm/i915/skl+: add NV12 in skl_format_to_fourcc
> >>>>>>>   drm/i915/skl+: support verification of DDB HW state for NV12
> >>>>>>>   drm/i915/skl+: NV12 related changes for WM
> >>>>>>>   drm/i915/skl+: pass skl_wm_level struct to wm compute func
> >>>>>>>   drm/i915/skl+: make sure higher latency level has higher wm
> value
> >>>>>>>   drm/i915/skl+: nv12 workaround disable WM level 1-7
> >>>>>>>   drm/i915/skl: split skl_compute_ddb function
> >>>>>>>
> >>>>>>> Vidya Srinivas (2):
> >>>>>>>   drm/i915: Display WA 827
> >>>>>>>   drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> >>>>>>>
> >>>>>>>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >>>>>>>  drivers/gpu/drm/i915/i915_reg.h  |   5 +
> >>>>>>>  drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
> >>>>>>> drivers/gpu/drm/i915/intel_display.c |  93 ++--
> >>>>>>>  drivers/gpu/drm/i915/intel_drv.h |  11 +-
> >>>>>>>  drivers/gpu/drm/i915/intel_pm.c  | 438
> >> ++--
> >>>> ---
> >>>>>> 
> >>>>>>>  drivers/gpu/drm/i915/intel_sprite.c  |   7 +-
> >>>>>>>  7 files changed, 393 insertions(+), 185 deletions(-)
> >>>>>> This series looks good, so for any patches I missed:
> >>>>>>
> >>>>>> Reviewed-by: Maarten Lankhorst
> >>>>>> <maarten.lankho...@linux.intel.com>
> >>>>>>
> >>>>>> Do you have commit rights, or should I push them?
> >>>>> Thank you. I don’t have commit rights I think.
> >>>>> Also, Should I add your RB for all the patches and push them again?
> >>>>>
> >>>> I'll push them. :)
> >>> Thank you so much :)
> >>>
> >> Pushed!
> > Thank you so much.
> >
> > Regards
> > Vidya
> Found a bug in the application of the workaround, could you look at
> https://patchwork.freedesktop.org/patch/215928/ ?

Thank you. Patch looks good to me.

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


Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12

2018-04-09 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 5:15 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
> 
> Op 09-04-18 om 11:41 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, April 9, 2018 2:38 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >> NV12
> >>
> >> Op 09-04-18 om 10:57 schreef Srinivas, Vidya:
> >>>> -----Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Monday, April 9, 2018 2:04 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >>>> NV12
> >>>>
> >>>> Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> >>>>> Series contain preparation patches for NV12 support Enabling NV12
> >>>>> KMD support will follow the series
> >>>>>
> >>>>> Chandra Konduru (3):
> >>>>>   drm/i915: Set scaler mode for NV12
> >>>>>   drm/i915: Update format_is_yuv() to include NV12
> >>>>>   drm/i915: Upscale scaler max scale for NV12
> >>>>>
> >>>>> Mahesh Kumar (9):
> >>>>>   drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> >>>>>   drm/i915/skl+: refactor WM calculation for NV12
> >>>>>   drm/i915/skl+: add NV12 in skl_format_to_fourcc
> >>>>>   drm/i915/skl+: support verification of DDB HW state for NV12
> >>>>>   drm/i915/skl+: NV12 related changes for WM
> >>>>>   drm/i915/skl+: pass skl_wm_level struct to wm compute func
> >>>>>   drm/i915/skl+: make sure higher latency level has higher wm value
> >>>>>   drm/i915/skl+: nv12 workaround disable WM level 1-7
> >>>>>   drm/i915/skl: split skl_compute_ddb function
> >>>>>
> >>>>> Vidya Srinivas (2):
> >>>>>   drm/i915: Display WA 827
> >>>>>   drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> >>>>>
> >>>>>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >>>>>  drivers/gpu/drm/i915/i915_reg.h  |   5 +
> >>>>>  drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
> >>>>> drivers/gpu/drm/i915/intel_display.c |  93 ++--
> >>>>>  drivers/gpu/drm/i915/intel_drv.h |  11 +-
> >>>>>  drivers/gpu/drm/i915/intel_pm.c  | 438
> ++--
> >> ---
> >>>> 
> >>>>>  drivers/gpu/drm/i915/intel_sprite.c  |   7 +-
> >>>>>  7 files changed, 393 insertions(+), 185 deletions(-)
> >>>> This series looks good, so for any patches I missed:
> >>>>
> >>>> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>>>
> >>>> Do you have commit rights, or should I push them?
> >>> Thank you. I don’t have commit rights I think.
> >>> Also, Should I add your RB for all the patches and push them again?
> >>>
> >> I'll push them. :)
> > Thank you so much :)
> >
> Pushed!
Thank you so much.

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


Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12

2018-04-09 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:38 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kam...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
> 
> Op 09-04-18 om 10:57 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, April 9, 2018 2:04 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for
> >> NV12
> >>
> >> Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> >>> Series contain preparation patches for NV12 support Enabling NV12
> >>> KMD support will follow the series
> >>>
> >>> Chandra Konduru (3):
> >>>   drm/i915: Set scaler mode for NV12
> >>>   drm/i915: Update format_is_yuv() to include NV12
> >>>   drm/i915: Upscale scaler max scale for NV12
> >>>
> >>> Mahesh Kumar (9):
> >>>   drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> >>>   drm/i915/skl+: refactor WM calculation for NV12
> >>>   drm/i915/skl+: add NV12 in skl_format_to_fourcc
> >>>   drm/i915/skl+: support verification of DDB HW state for NV12
> >>>   drm/i915/skl+: NV12 related changes for WM
> >>>   drm/i915/skl+: pass skl_wm_level struct to wm compute func
> >>>   drm/i915/skl+: make sure higher latency level has higher wm value
> >>>   drm/i915/skl+: nv12 workaround disable WM level 1-7
> >>>   drm/i915/skl: split skl_compute_ddb function
> >>>
> >>> Vidya Srinivas (2):
> >>>   drm/i915: Display WA 827
> >>>   drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> >>>
> >>>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >>>  drivers/gpu/drm/i915/i915_reg.h  |   5 +
> >>>  drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
> >>> drivers/gpu/drm/i915/intel_display.c |  93 ++--
> >>>  drivers/gpu/drm/i915/intel_drv.h |  11 +-
> >>>  drivers/gpu/drm/i915/intel_pm.c  | 438 ++--
> ---
> >> 
> >>>  drivers/gpu/drm/i915/intel_sprite.c  |   7 +-
> >>>  7 files changed, 393 insertions(+), 185 deletions(-)
> >> This series looks good, so for any patches I missed:
> >>
> >> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>
> >> Do you have commit rights, or should I push them?
> > Thank you. I don’t have commit rights I think.
> > Also, Should I add your RB for all the patches and push them again?
> >
> I'll push them. :)

Thank you so much :)

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


Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12

2018-04-09 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:04 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
> 
> Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> > Series contain preparation patches for NV12 support Enabling NV12 KMD
> > support will follow the series
> >
> > Chandra Konduru (3):
> >   drm/i915: Set scaler mode for NV12
> >   drm/i915: Update format_is_yuv() to include NV12
> >   drm/i915: Upscale scaler max scale for NV12
> >
> > Mahesh Kumar (9):
> >   drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> >   drm/i915/skl+: refactor WM calculation for NV12
> >   drm/i915/skl+: add NV12 in skl_format_to_fourcc
> >   drm/i915/skl+: support verification of DDB HW state for NV12
> >   drm/i915/skl+: NV12 related changes for WM
> >   drm/i915/skl+: pass skl_wm_level struct to wm compute func
> >   drm/i915/skl+: make sure higher latency level has higher wm value
> >   drm/i915/skl+: nv12 workaround disable WM level 1-7
> >   drm/i915/skl: split skl_compute_ddb function
> >
> > Vidya Srinivas (2):
> >   drm/i915: Display WA 827
> >   drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> >
> >  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >  drivers/gpu/drm/i915/i915_reg.h  |   5 +
> >  drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
> > drivers/gpu/drm/i915/intel_display.c |  93 ++--
> >  drivers/gpu/drm/i915/intel_drv.h |  11 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 438 ++-
> 
> >  drivers/gpu/drm/i915/intel_sprite.c  |   7 +-
> >  7 files changed, 393 insertions(+), 185 deletions(-)
> 
> This series looks good, so for any patches I missed:
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> 
> Do you have commit rights, or should I push them?

Thank you. I don’t have commit rights I think.
Also, Should I add your RB for all the patches and push them again?

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


Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12

2018-04-09 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:04 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
> 
> Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> > Series contain preparation patches for NV12 support Enabling NV12 KMD
> > support will follow the series
> >
> > Chandra Konduru (3):
> >   drm/i915: Set scaler mode for NV12
> >   drm/i915: Update format_is_yuv() to include NV12
> >   drm/i915: Upscale scaler max scale for NV12
> >
> > Mahesh Kumar (9):
> >   drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> >   drm/i915/skl+: refactor WM calculation for NV12
> >   drm/i915/skl+: add NV12 in skl_format_to_fourcc
> >   drm/i915/skl+: support verification of DDB HW state for NV12
> >   drm/i915/skl+: NV12 related changes for WM
> >   drm/i915/skl+: pass skl_wm_level struct to wm compute func
> >   drm/i915/skl+: make sure higher latency level has higher wm value
> >   drm/i915/skl+: nv12 workaround disable WM level 1-7
> >   drm/i915/skl: split skl_compute_ddb function
> >
> > Vidya Srinivas (2):
> >   drm/i915: Display WA 827
> >   drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> >
> >  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >  drivers/gpu/drm/i915/i915_reg.h  |   5 +
> >  drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
> > drivers/gpu/drm/i915/intel_display.c |  93 ++--
> >  drivers/gpu/drm/i915/intel_drv.h |  11 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 438 ++-
> 
> >  drivers/gpu/drm/i915/intel_sprite.c  |   7 +-
> >  7 files changed, 393 insertions(+), 185 deletions(-)
> 
> This series looks good, so for any patches I missed:
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> 
> Do you have commit rights, or should I push them?
I don’t have commit rights I think. Could you please push it?
Thank you.

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


Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-05 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, April 5, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 05-04-18 om 07:18 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 2:37 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 04-04-18 om 10:51 schreef Srinivas, Vidya:
> >>>> -----Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Wednesday, April 4, 2018 2:18 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >>>> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >>>> restrictions for NV12
> >>>>
> >>>> Op 04-04-18 om 10:04 schreef Srinivas, Vidya:
> >>>>>> -Original Message-
> >>>>>> From: Maarten Lankhorst
> >>>>>> [mailto:maarten.lankho...@linux.intel.com]
> >>>>>> Sent: Wednesday, April 4, 2018 1:28 PM
> >>>>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>>>> g...@lists.freedesktop.org
> >>>>>> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >>>>>> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >>>>>> restrictions for NV12
> >>>>>>
> >>>>>> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>>>>>> As per display WA 1106, to avoid corruption issues
> >>>>>>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>>>>>> dimensions to be multiplier of 4 We fail the case where src
> >>>>>>> width or height is not multiple of 4 for NV12.
> >>>>>>> We also set the scaler destination height and width to be
> >>>>>>> multiple of 4. Without this, pipe fifo underruns were seen on APL
> and KBL.
> >>>>>>> We also skip src trunction/adjustments for NV12 case and handle
> >>>>>>> the sizes directly in skl_update_plane
> >>>>>>>
> >>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>> <maarten.lankho...@linux.intel.com>
> >>>>>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>>>>>> ---
> >>>>>>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>>>>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>>>>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>>>>>> b/drivers/gpu/drm/i915/intel_drv.h
> >>>>>>> index 9c58da0..a1f718d 100644
> >>>>>>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>>>>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>>>>>> @@ -159,6 +159,8 @@
> >>>>>>>  #define INTEL_I2C_BUS_DVO 1
> >>>>>>>  #define INTEL_I2C_BUS_SDVO 2
> >>>>>>>
> >>>>>>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>>>>>> +
> >>>>>>>  /* these are outputs from the chip - integrated only
> >>>>>>> external chips are via DVO or SDVO output */  enum
> >>>>>>> intel_output_type { diff --git
> >>>>>>> a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>>>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>>>>>> index d5dad44..b2292dd 100644
> >>>>>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>>>> +++

Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 2:37 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:51 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 2:18 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 04-04-18 om 10:04 schreef Srinivas, Vidya:
> >>>> -----Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Wednesday, April 4, 2018 1:28 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >>>> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >>>> restrictions for NV12
> >>>>
> >>>> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>>>> As per display WA 1106, to avoid corruption issues
> >>>>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>>>> dimensions to be multiplier of 4 We fail the case where src width
> >>>>> or height is not multiple of 4 for NV12.
> >>>>> We also set the scaler destination height and width to be multiple
> >>>>> of 4. Without this, pipe fifo underruns were seen on APL and KBL.
> >>>>> We also skip src trunction/adjustments for NV12 case and handle
> >>>>> the sizes directly in skl_update_plane
> >>>>>
> >>>>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>>>> ---
> >>>>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>>>> b/drivers/gpu/drm/i915/intel_drv.h
> >>>>> index 9c58da0..a1f718d 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>>>> @@ -159,6 +159,8 @@
> >>>>>  #define INTEL_I2C_BUS_DVO 1
> >>>>>  #define INTEL_I2C_BUS_SDVO 2
> >>>>>
> >>>>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>>>> +
> >>>>>  /* these are outputs from the chip - integrated only
> >>>>> external chips are via DVO or SDVO output */  enum
> >>>>> intel_output_type { diff --git
> >>>>> a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> index d5dad44..b2292dd 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> >>>>> uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> >>>>> unsigned long irqflags;
> >>>>>
> >>>>> +   if (fb->format->format == DRM_FORMAT_NV12 &&
> >>>>> +   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> >>>>> +   DRM_DEBUG_KMS("NV12: src dimensions not
> valid\n");
> >>>>> +   return;
> >>>>> +   }
> >>>>> +
> >>>> You can't do this check in skl_update_plane, it's way too late. It
> >>>> should be rejected in the plane check with -EINVAL, or perhaps in
> >> skl_update_scaler.
> >>> Have done it right from intel_framebuffer_init onwards, have done it
> >>> in skl_update_scaler also In fact i

Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 2:18 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:04 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 1:28 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>> As per display WA 1106, to avoid corruption issues
> >>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>> dimensions to be multiplier of 4 We fail the case where src width or
> >>> height is not multiple of 4 for NV12.
> >>> We also set the scaler destination height and width to be multiple
> >>> of 4. Without this, pipe fifo underruns were seen on APL and KBL. We
> >>> also skip src trunction/adjustments for NV12 case and handle the
> >>> sizes directly in skl_update_plane
> >>>
> >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>> b/drivers/gpu/drm/i915/intel_drv.h
> >>> index 9c58da0..a1f718d 100644
> >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>> @@ -159,6 +159,8 @@
> >>>  #define INTEL_I2C_BUS_DVO 1
> >>>  #define INTEL_I2C_BUS_SDVO 2
> >>>
> >>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>> +
> >>>  /* these are outputs from the chip - integrated only
> >>> external chips are via DVO or SDVO output */  enum
> >>> intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>> index d5dad44..b2292dd 100644
> >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> >>>   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> >>>   unsigned long irqflags;
> >>>
> >>> + if (fb->format->format == DRM_FORMAT_NV12 &&
> >>> + ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> >>> + DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
> >>> + return;
> >>> + }
> >>> +
> >> You can't do this check in skl_update_plane, it's way too late. It
> >> should be rejected in the plane check with -EINVAL, or perhaps in
> skl_update_scaler.
> > Have done it right from intel_framebuffer_init onwards, have done it
> > in skl_update_scaler also In fact it will get rejected in framebuffer init 
> > and
> all these are duplicate checks, can remove them.
> >>>   /* Sizes are 0 based */
> >>>   src_w--;
> >>>   src_h--;
> >>> @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >>> PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> >> scaler->mode);
> >>>   I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> >>>   I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
> >> << 16) | crtc_y);
> >>> - I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> >>> -   ((crtc_w + 1) << 16)|(crtc_h + 1));
> >>> -
> >>> + if (fb->format->format == DRM_FORMAT_NV12)
> >>> + I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> >>> +   (MULT4(crtc_w) << 16) |
> >> MULT4(crtc_h));
> >> See the comment above, sizes are 0 based. This will add 1 to the
> >> size, so the size is always 1 more than requested.
> >> I don't think it would pass plane CRC tests..
> > When I align it to mult of 4, 1919 (which was 1920-1) becomes 1920 back.
> > If we don’t do this, I see fifo underruns. The destination width and
> > height If not mult of 4, I am seeing underruns.
> What you see as 1920 is 1921, which should be underrunning even more and
> is out of FB bounds.
Sorry, I gave a wrong example here. It doesn’t happen when we scale it to full 
resolution.
It happened during other testing when the scaled dest width or height was not
multiple of 4.
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 2:02 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:29 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 1:40 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 04-04-18 om 10:06 schreef Srinivas, Vidya:
> >>>> -----Original Message-
> >>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>>> Sent: Wednesday, April 4, 2018 1:33 PM
> >>>> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >>>> g...@lists.freedesktop.org
> >>>> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >>>> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >>>> restrictions for NV12
> >>>>
> >>>> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>>>> As per display WA 1106, to avoid corruption issues
> >>>>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>>>> dimensions to be multiplier of 4 We fail the case where src width
> >>>>> or height is not multiple of 4 for NV12.
> >>>>> We also set the scaler destination height and width to be multiple
> >>>>> of 4. Without this, pipe fifo underruns were seen on APL and KBL.
> >>>>> We also skip src trunction/adjustments for NV12 case and handle
> >>>>> the sizes directly in skl_update_plane
> >>>>>
> >>>>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>>>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>>>> ---
> >>>>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>>>> b/drivers/gpu/drm/i915/intel_drv.h
> >>>>> index 9c58da0..a1f718d 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>>>> @@ -159,6 +159,8 @@
> >>>>>  #define INTEL_I2C_BUS_DVO 1
> >>>>>  #define INTEL_I2C_BUS_SDVO 2
> >>>>>
> >>>>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>>>> +
> >>>>>  /* these are outputs from the chip - integrated only
> >>>>> external chips are via DVO or SDVO output */  enum
> >>>>> intel_output_type { diff --git
> >>>>> a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> index d5dad44..b2292dd 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>>>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> >>>>> uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> >>>>> unsigned long irqflags;
> >>>>>
> >>>>> +   if (fb->format->format == DRM_FORMAT_NV12 &&
> >>>>> +   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> >>>>> +   DRM_DEBUG_KMS("NV12: src dimensions not
> valid\n");
> >>>>> +   return;
> >>>>> +   }
> >>>> Also on a side note, don't add DRM_DEBUG_KMS in update_plane or
> >>>> disable_plane calls. It can take an arbitrary amount of time,
> >>>> resulting in an atomic update failure.
> >>> Sure, thank you. These are anyway duplicate checks. I will remove them.
> >>> The main one is done in intel_framebuffer_init as suggested by you.
> >> They're not duplicate, they're done for related reasons:
> >> 1. It doesn't make sense to allow creation of a framebuffer with an
> >> invalid width/height if the full width/height cannot be used.
> >> 2. The checks in skl_update_scaler are the ones that will reject even
> >> showing a subset with invalid width, which can cause the fifo underruns.
> > If we don’t keep dest width and height as mult of 4, fifo underruns are
> seen.
> > Shall we reject those also? Then it will be safe. As per my
> > observation, We have only two options. Either change it to mult of 4
> > or reject it :( Please suggest.
> Reject non multiples of 4. Userspace can adapt. :)

:) okay. Thank you. I will update the patch.

Regards
Vidya

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


Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 1:40 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:06 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 1:33 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>> As per display WA 1106, to avoid corruption issues
> >>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>> dimensions to be multiplier of 4 We fail the case where src width or
> >>> height is not multiple of 4 for NV12.
> >>> We also set the scaler destination height and width to be multiple
> >>> of 4. Without this, pipe fifo underruns were seen on APL and KBL. We
> >>> also skip src trunction/adjustments for NV12 case and handle the
> >>> sizes directly in skl_update_plane
> >>>
> >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>> b/drivers/gpu/drm/i915/intel_drv.h
> >>> index 9c58da0..a1f718d 100644
> >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>> @@ -159,6 +159,8 @@
> >>>  #define INTEL_I2C_BUS_DVO 1
> >>>  #define INTEL_I2C_BUS_SDVO 2
> >>>
> >>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>> +
> >>>  /* these are outputs from the chip - integrated only
> >>> external chips are via DVO or SDVO output */  enum
> >>> intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>> index d5dad44..b2292dd 100644
> >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> >>>   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> >>>   unsigned long irqflags;
> >>>
> >>> + if (fb->format->format == DRM_FORMAT_NV12 &&
> >>> + ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> >>> + DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
> >>> + return;
> >>> + }
> >> Also on a side note, don't add DRM_DEBUG_KMS in update_plane or
> >> disable_plane calls. It can take an arbitrary amount of time,
> >> resulting in an atomic update failure.
> > Sure, thank you. These are anyway duplicate checks. I will remove them.
> > The main one is done in intel_framebuffer_init as suggested by you.
> They're not duplicate, they're done for related reasons:
> 1. It doesn't make sense to allow creation of a framebuffer with an invalid
> width/height if the full width/height cannot be used.
> 2. The checks in skl_update_scaler are the ones that will reject even showing
> a subset with invalid width, which can cause the fifo underruns.

If we don’t keep dest width and height as mult of 4, fifo underruns are seen.
Shall we reject those also? Then it will be safe. As per my observation,
We have only two options. Either change it to mult of 4 or reject it :(
Please suggest.

Thanks
Vidya

> >>> +
> >>>   /* Sizes are 0 based */
> >>>   src_w--;
> >>>   src_h--;
> >>> @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >>> PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> >> scaler->mode);
> >>>   I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> >>>   I915_WRITE_FW(SKL_PS_WIN_

Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 1:40 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:06 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 1:33 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> >>> As per display WA 1106, to avoid corruption issues
> >>> NV12 plane height needs to be multiplier of 4 We expect the src
> >>> dimensions to be multiplier of 4 We fail the case where src width or
> >>> height is not multiple of 4 for NV12.
> >>> We also set the scaler destination height and width to be multiple
> >>> of 4. Without this, pipe fifo underruns were seen on APL and KBL. We
> >>> also skip src trunction/adjustments for NV12 case and handle the
> >>> sizes directly in skl_update_plane
> >>>
> >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >>>  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >>>  2 files changed, 18 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>> b/drivers/gpu/drm/i915/intel_drv.h
> >>> index 9c58da0..a1f718d 100644
> >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>> @@ -159,6 +159,8 @@
> >>>  #define INTEL_I2C_BUS_DVO 1
> >>>  #define INTEL_I2C_BUS_SDVO 2
> >>>
> >>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>> +
> >>>  /* these are outputs from the chip - integrated only
> >>> external chips are via DVO or SDVO output */  enum
> >>> intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>> index d5dad44..b2292dd 100644
> >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>> @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> >>>   uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> >>>   unsigned long irqflags;
> >>>
> >>> + if (fb->format->format == DRM_FORMAT_NV12 &&
> >>> + ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> >>> + DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
> >>> + return;
> >>> + }
> >> Also on a side note, don't add DRM_DEBUG_KMS in update_plane or
> >> disable_plane calls. It can take an arbitrary amount of time,
> >> resulting in an atomic update failure.
> > Sure, thank you. These are anyway duplicate checks. I will remove them.
> > The main one is done in intel_framebuffer_init as suggested by you.
> They're not duplicate, they're done for related reasons:
> 1. It doesn't make sense to allow creation of a framebuffer with an invalid
> width/height if the full width/height cannot be used.
> 2. The checks in skl_update_scaler are the ones that will reject even showing
> a subset with invalid width, which can cause the fifo underruns.

Sorry, yeah that’s correct. I will remove it only from skl_update_plane.
Regarding the crtc_w and crtc_h, I see that when its not even,
fifo underruns are seen. Kindly suggest on that. Thank you.

> >>> +
> >>>   /* Sizes are 0 based */
> >>>   src_w--;
> >>>   src_h--;
> >>> @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >>> PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> >> scaler->mode);
> >>>   I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> >>>   I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
> >> << 16) 

Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 1:33 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> > As per display WA 1106, to avoid corruption issues
> > NV12 plane height needs to be multiplier of 4 We expect the src
> > dimensions to be multiplier of 4 We fail the case where src width or
> > height is not multiple of 4 for NV12.
> > We also set the scaler destination height and width to be multiple of
> > 4. Without this, pipe fifo underruns were seen on APL and KBL. We also
> > skip src trunction/adjustments for NV12 case and handle the sizes
> > directly in skl_update_plane
> >
> > Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >  2 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9c58da0..a1f718d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -159,6 +159,8 @@
> >  #define INTEL_I2C_BUS_DVO 1
> >  #define INTEL_I2C_BUS_SDVO 2
> >
> > +#define MULT4(x) ((x + 3) & ~0x03)
> > +
> >  /* these are outputs from the chip - integrated only
> > external chips are via DVO or SDVO output */  enum
> > intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index d5dad44..b2292dd 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> > uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> > unsigned long irqflags;
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12 &&
> > +   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> > +   DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
> > +   return;
> > +   }
> Also on a side note, don't add DRM_DEBUG_KMS in update_plane or
> disable_plane calls. It can take an arbitrary amount of time, resulting in an
> atomic update failure.
Sure, thank you. These are anyway duplicate checks. I will remove them.
The main one is done in intel_framebuffer_init as suggested by you.

> > +
> > /* Sizes are 0 based */
> > src_w--;
> > src_h--;
> > @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >   PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> scaler->mode);
> > I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> > I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
> << 16) | crtc_y);
> > -   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > - ((crtc_w + 1) << 16)|(crtc_h + 1));
> > -
> > +   if (fb->format->format == DRM_FORMAT_NV12)
> > +   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > + (MULT4(crtc_w) << 16) |
> MULT4(crtc_h));
> > +   else
> > +   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > + ((crtc_w + 1) << 16)|(crtc_h + 1));
> > I915_WRITE_FW(PLANE_POS(pipe, plane_id), 0);
> > } else {
> > I915_WRITE_FW(PLANE_POS(pipe, plane_id), (crtc_y << 16)
> | crtc_x);
> > @@ -969,6 +978,9 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> > return -EINVAL;
> > }
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12)
> > +   goto check_plane_surface;
> > +
> > /* setup can_scale, min_scale, max_scale */
> > if (INTEL_GEN(dev_priv) >= 9) {
> > if (state->base.fb)
> > @@ -1112,6 +1124,7 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> > dst->y1 = crtc_y;
> > dst->y2 = crtc_y + crtc_h;
> >
> > +check_plane_surface:
> > if (INTEL_GEN(dev_priv) >= 9) {
> > ret = skl_check_plane_surface(crtc_state, state);
> > if (ret)
> 

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


Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

2018-04-04 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 1:28 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten <maarten.lankho...@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> > As per display WA 1106, to avoid corruption issues
> > NV12 plane height needs to be multiplier of 4 We expect the src
> > dimensions to be multiplier of 4 We fail the case where src width or
> > height is not multiple of 4 for NV12.
> > We also set the scaler destination height and width to be multiple of
> > 4. Without this, pipe fifo underruns were seen on APL and KBL. We also
> > skip src trunction/adjustments for NV12 case and handle the sizes
> > directly in skl_update_plane
> >
> > Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >  2 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9c58da0..a1f718d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -159,6 +159,8 @@
> >  #define INTEL_I2C_BUS_DVO 1
> >  #define INTEL_I2C_BUS_SDVO 2
> >
> > +#define MULT4(x) ((x + 3) & ~0x03)
> > +
> >  /* these are outputs from the chip - integrated only
> > external chips are via DVO or SDVO output */  enum
> > intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index d5dad44..b2292dd 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> > uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> > unsigned long irqflags;
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12 &&
> > +   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> > +   DRM_DEBUG_KMS("NV12: src dimensions not valid\n");
> > +   return;
> > +   }
> > +
> You can't do this check in skl_update_plane, it's way too late. It should be
> rejected in the plane check with -EINVAL, or perhaps in skl_update_scaler.
Have done it right from intel_framebuffer_init onwards, have done it in 
skl_update_scaler also
In fact it will get rejected in framebuffer init and all these are duplicate 
checks, can remove them.
> > /* Sizes are 0 based */
> > src_w--;
> > src_h--;
> > @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >   PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> scaler->mode);
> > I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> > I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
> << 16) | crtc_y);
> > -   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > - ((crtc_w + 1) << 16)|(crtc_h + 1));
> > -
> > +   if (fb->format->format == DRM_FORMAT_NV12)
> > +   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > + (MULT4(crtc_w) << 16) |
> MULT4(crtc_h));
> See the comment above, sizes are 0 based. This will add 1 to the size, so the
> size is always 1 more than requested.
> I don't think it would pass plane CRC tests..

When I align it to mult of 4, 1919 (which was 1920-1) becomes 1920 back.
If we don’t do this, I see fifo underruns. The destination width and height
If not mult of 4, I am seeing underruns.

> > +   else
> > +   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > + ((crtc_w + 1) << 16)|(crtc_h + 1));
> > I915_WRITE_FW(PLANE_POS(pipe, plane_id), 0);
> > } else {
> > I915_WRITE_FW(PLANE_POS(pipe, plane_id), (crtc_y << 16)
> | crtc_x);
> > @@ -969,6 +978,9 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> > return -EINVAL;
> > }
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12)
> > +   goto check_plane_surface;
> > +
> > /* setup can_scale, min_scale, max_scale */
> > if (INTEL_GEN(dev_priv) >= 9) {
> > if (state->base.fb)
> > @@ -1112,6 +1124,7 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> > dst->y1 = crtc_y;
> > dst->y2 = crtc_y + crtc_h;
> >
> > +check_plane_surface:
> > if (INTEL_GEN(dev_priv) >= 9) {
> > ret = skl_check_plane_surface(crtc_state, state);
> > if (ret)
> 

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


Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

2018-04-02 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, March 29, 2018 2:19 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
> 
> Op 29-03-18 om 10:06 schreef Vidya Srinivas:
> > As per display WA 1106, to avoid corruption issues
> > NV12 plane height needs to be multiplier of 4 Hence we modify the fb
> > src and destination height and width to be multiples of 4. Without
> > this, pipe fifo underruns were seen on APL and KBL.
> >
> > Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h| 2 ++
> >  drivers/gpu/drm/i915/intel_sprite.c | 8 
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9c58da0..a1f718d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -159,6 +159,8 @@
> >  #define INTEL_I2C_BUS_DVO 1
> >  #define INTEL_I2C_BUS_SDVO 2
> >
> > +#define MULT4(x) ((x + 3) & ~0x03)
> > +
> >  /* these are outputs from the chip - integrated only
> > external chips are via DVO or SDVO output */  enum
> > intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 538d938..9f466c6 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -261,6 +261,14 @@ skl_update_plane(struct intel_plane *plane,
> > crtc_w--;
> > crtc_h--;
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12) {
> > +   src_w = MULT4(src_w);
> > +   src_h = MULT4(src_h);
> > +   crtc_w = MULT4(crtc_w);
> > +   crtc_h = MULT4(crtc_h);
> > +   DRM_ERROR("%d %d %d %d\n", src_w, src_h, crtc_w,
> crtc_h);
> > +   }
> > +
> > spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> 
> Nearly there!
> 
> Do we have limitations for width too? But I think we shouldn't ever adjust
> src for any format.
> This means that we should probably get rid of the drm_rect_adjust_size call
> in intel_check_sprite_plane.
> 
> If any limitations of NV12 are hit, we should reject with -EINVAL instead so
> userspace can decide what to do.
> The best place to put those checks is probably in skl_update_scaler, where
> they will be checked by the primary plane too.
> 
> This will mean the tests fail, but that can be fixed by selecting 16 as
> width/height for NV12 in IGT. If you change it to 16 you can put my r-b on it.
> 
> Also I think we should put the same limitations for width and height being a
> multiple in intel_framebuffer_init.
> 
> And on a final note for patch ordering, put the workaround and gen10 patch
> before enabling nv12 support.

Thank you. I have added the restriction in intel_framebuffer_init and have
re-ordered the series. Have also floated the i-g-t patch with 16x16 buffer
and I have included your r-b. Kindly have a check. Currently since we have 17x17
the restriction hits and kernel message fb dimensions are not right is seen for
tests. If the 16x16 i-g-t patch gets merged, we can get the results. On my side,
I have tested with many buffers (mult of 4) and no underruns are seen.
https://patchwork.freedesktop.org/series/39670/ (rev 7)
> 
> ~Maarten

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


Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

2018-04-02 Thread Srinivas, Vidya


> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, March 29, 2018 5:03 PM
> To: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
> 
> On Thu, Mar 29, 2018 at 12:28:48PM +0200, Maarten Lankhorst wrote:
> > Op 29-03-18 om 11:19 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Thursday, March 29, 2018 2:19 PM
> > >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane
> > >> size mult of
> > >> 4 for NV12
> > >>
> > >> Op 29-03-18 om 10:06 schreef Vidya Srinivas:
> > >>> As per display WA 1106, to avoid corruption issues
> > >>> NV12 plane height needs to be multiplier of 4 Hence we modify the
> > >>> fb src and destination height and width to be multiples of 4.
> > >>> Without this, pipe fifo underruns were seen on APL and KBL.
> > >>>
> > >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> > >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> > >>> ---
> > >>>  drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > >>>  drivers/gpu/drm/i915/intel_sprite.c | 8 
> > >>>  2 files changed, 10 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > >>> b/drivers/gpu/drm/i915/intel_drv.h
> > >>> index 9c58da0..a1f718d 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> > >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> > >>> @@ -159,6 +159,8 @@
> > >>>  #define INTEL_I2C_BUS_DVO 1
> > >>>  #define INTEL_I2C_BUS_SDVO 2
> > >>>
> > >>> +#define MULT4(x) ((x + 3) & ~0x03)
> > >>> +
> > >>>  /* these are outputs from the chip - integrated only
> > >>> external chips are via DVO or SDVO output */  enum
> > >>> intel_output_type { diff --git
> > >>> a/drivers/gpu/drm/i915/intel_sprite.c
> > >>> b/drivers/gpu/drm/i915/intel_sprite.c
> > >>> index 538d938..9f466c6 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > >>> @@ -261,6 +261,14 @@ skl_update_plane(struct intel_plane *plane,
> > >>> crtc_w--;
> > >>> crtc_h--;
> > >>>
> > >>> +   if (fb->format->format == DRM_FORMAT_NV12) {
> > >>> +   src_w = MULT4(src_w);
> > >>> +   src_h = MULT4(src_h);
> > >>> +   crtc_w = MULT4(crtc_w);
> > >>> +   crtc_h = MULT4(crtc_h);
> > >>> +   DRM_ERROR("%d %d %d %d\n", src_w, src_h, crtc_w,
> > >> crtc_h);
> > >>> +   }
> > >>> +
> > >>> spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > >>>
> > >>> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > >> Nearly there!
> > >>
> > >> Do we have limitations for width too? But I think we shouldn't ever
> > >> adjust src for any format.
> > >> This means that we should probably get rid of the
> > >> drm_rect_adjust_size call in intel_check_sprite_plane.
> > >>
> > >> If any limitations of NV12 are hit, we should reject with -EINVAL
> > >> instead so userspace can decide what to do.
> > >> The best place to put those checks is probably in
> > >> skl_update_scaler, where they will be checked by the primary plane too.
> > >>
> > >> This will mean the tests fail, but that can be fixed by selecting
> > >> 16 as width/height for NV12 in IGT. If you change it to 16 you can put
> my r-b on it.
> > >>
> > >> Also I think we should put the same limitations for width and
> > >> height being a multiple in intel_framebuffer_init.
> > >>
> > >> And on a final note for patch ordering, put the workar

Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

2018-03-29 Thread Srinivas, Vidya


> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, March 29, 2018 3:59 PM
> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of
> 4 for NV12
> 
> Op 29-03-18 om 11:19 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Thursday, March 29, 2018 2:19 PM
> >> To: Srinivas, Vidya <vidya.srini...@intel.com>; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size
> >> mult of
> >> 4 for NV12
> >>
> >> Op 29-03-18 om 10:06 schreef Vidya Srinivas:
> >>> As per display WA 1106, to avoid corruption issues
> >>> NV12 plane height needs to be multiplier of 4 Hence we modify the fb
> >>> src and destination height and width to be multiples of 4. Without
> >>> this, pipe fifo underruns were seen on APL and KBL.
> >>>
> >>> Credits-to: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >>> Signed-off-by: Vidya Srinivas <vidya.srini...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_drv.h| 2 ++
> >>>  drivers/gpu/drm/i915/intel_sprite.c | 8 
> >>>  2 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>> b/drivers/gpu/drm/i915/intel_drv.h
> >>> index 9c58da0..a1f718d 100644
> >>> --- a/drivers/gpu/drm/i915/intel_drv.h
> >>> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >>> @@ -159,6 +159,8 @@
> >>>  #define INTEL_I2C_BUS_DVO 1
> >>>  #define INTEL_I2C_BUS_SDVO 2
> >>>
> >>> +#define MULT4(x) ((x + 3) & ~0x03)
> >>> +
> >>>  /* these are outputs from the chip - integrated only
> >>> external chips are via DVO or SDVO output */  enum
> >>> intel_output_type { diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>> index 538d938..9f466c6 100644
> >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>> @@ -261,6 +261,14 @@ skl_update_plane(struct intel_plane *plane,
> >>>   crtc_w--;
> >>>   crtc_h--;
> >>>
> >>> + if (fb->format->format == DRM_FORMAT_NV12) {
> >>> + src_w = MULT4(src_w);
> >>> + src_h = MULT4(src_h);
> >>> + crtc_w = MULT4(crtc_w);
> >>> + crtc_h = MULT4(crtc_h);
> >>> + DRM_ERROR("%d %d %d %d\n", src_w, src_h, crtc_w,
> >> crtc_h);
> >>> + }
> >>> +
> >>>   spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >>>
> >>>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> >> Nearly there!
> >>
> >> Do we have limitations for width too? But I think we shouldn't ever
> >> adjust src for any format.
> >> This means that we should probably get rid of the
> >> drm_rect_adjust_size call in intel_check_sprite_plane.
> >>
> >> If any limitations of NV12 are hit, we should reject with -EINVAL
> >> instead so userspace can decide what to do.
> >> The best place to put those checks is probably in skl_update_scaler,
> >> where they will be checked by the primary plane too.
> >>
> >> This will mean the tests fail, but that can be fixed by selecting 16
> >> as width/height for NV12 in IGT. If you change it to 16 you can put my r-b
> on it.
> >>
> >> Also I think we should put the same limitations for width and height
> >> being a multiple in intel_framebuffer_init.
> >>
> >> And on a final note for patch ordering, put the workaround and gen10
> >> patch before enabling nv12 support.
> > Thank you. Okay, I will make these changes and check once. The
> > limitation in Framebuffer init is already present where it expects
> > width and height >= 16 As per bspec no minimum for width has been
> > mentioned. And regarding the Add check for primary plane (same like
> > sprite), can we add that as a separate patch Because if we add it with
> > NV12 series, it would be like adding the changes and Returning before
> executing them.
> I don't think we'll lose much if we fail to cr

  1   2   >