Re: [Intel-gfx] [RFC v3 3/9] drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment

[Pandiyan, Dhinakaran]

On Wed, 2019-10-02 at 15:29 -0700, Matt Roper wrote:
> On Mon, Sep 23, 2019 at 03:29:29AM -0700, Dhinakaran Pandiyan wrote:
> > Easier to read if all the alignment changes are in one place and contained
> > within a function.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Matt Roper 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 31 ++--
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a94d145dd048..c437f00c2072 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2551,7 +2551,22 @@ intel_fb_stride_alignment(const struct 
> > drm_framebuffer *fb, int
> > color_plane)
> > else
> > return 64;
> > } else {
> > -   return intel_tile_width_bytes(fb, color_plane);
> > +   u32 tile_width = intel_tile_width_bytes(fb, color_plane);
> > +
> > +   /*
> > +* Display WA #0531: skl,bxt,kbl,glk
> > +*
> > +* Render decompression and plane width > 3840
> > +* combined with horizontal panning requires the
> > +* plane stride to be a multiple of 4. We'll just
> > +* require the entire fb to accommodate that to avoid
> > +* potential runtime errors at plane configuration time.
> > +*/
> > +   if (IS_GEN(dev_priv, 9) && is_ccs_modifier(fb->modifier) &&
> > +   color_plane == 0 && fb->width > 3840)
> > +   tile_width *= 4;
> 
> I realize you're only moving this, but I find this workaround
> description confusing since the wording is somewhat ambiguous as to
> whether it's expecting the plane stride to be a multiple of 4 bytes or 4
> tiles.  On casual read, I think most people would assume that we're
> talking about bytes here.  Only once you realize that the PLANE_STRIDE
> register itself gets programmed in units of tile width does the wording
> here become clear.  Maybe we could clarify the comment while moving it?
I remember wanting to rewrite that comment for the exact reason, but forgot to 
do so. Thanks for the
review, I'll fix it.

> 
> Also it might be slightly more clear to do a "return tile_width * 4"
> here instead of modifying tile_width since that's a bit more intuitive
> description of what we're trying to do.
> 
> Either way,
> 
> Reviewed-by: Matt Roper 
> 
> 
> Matt
> 
> 
> > +
> > +   return tile_width;
> > }
> >  }
> >  
> > @@ -15705,20 +15720,6 @@ static int intel_framebuffer_init(struct 
> > intel_framebuffer *intel_fb,
> > }
> >  
> > stride_alignment = intel_fb_stride_alignment(fb, i);
> > -
> > -   /*
> > -* Display WA #0531: skl,bxt,kbl,glk
> > -*
> > -* Render decompression and plane width > 3840
> > -* combined with horizontal panning requires the
> > -* plane stride to be a multiple of 4. We'll just
> > -* require the entire fb to accommodate that to avoid
> > -* potential runtime errors at plane configuration time.
> > -*/
> > -   if (IS_GEN(dev_priv, 9) && i == 0 && fb->width > 3840 &&
> > -   is_ccs_modifier(fb->modifier))
> > -   stride_alignment *= 4;
> > -
> > if (fb->pitches[i] & (stride_alignment - 1)) {
> > DRM_DEBUG_KMS("plane %d pitch (%d) must be at least %u 
> > byte aligned\n",
> >   i, fb->pitches[i], stride_alignment);
> > -- 
> > 2.17.1
> > 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v3 6/9] drm/framebuffer: Format modifier for Intel Gen-12 media compression

[Pandiyan, Dhinakaran]

On Mon, 2019-09-23 at 03:29 -0700, Dhinakaran Pandiyan wrote:
> Gen-12 display can decompress surfaces compressed by the media engine, add
> a new modifier as the driver needs to know the surface was compressed by
> the media or render engine.
> 
> Cc: Nanley G Chery 
> Cc: Matt Roper 
> Cc: Ville Syrjälä 

Cc: Guangyao

> Signed-off-by: Dhinakaran Pandiyan 
> Signed-off-by: Lucas De Marchi 
> ---
>  include/uapi/drm/drm_fourcc.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 1f0fbf0398f6..c4a4e0fdbee5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -421,6 +421,19 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
>  
> +/*
> + * Intel color control surfaces (CCS) for Gen-12 media compression
> + *
> + * The main surface is Y-tiled and at plane index 0, the CCS is linear and
> + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> + * main surface. In other words, 4 bits in CCS map to a main surface cache
> + * line pair. The main surface pitch is required to be a multiple of four
> + * Y-tile widths. For semi-planar formats like NV12, CCS plane follows the
> + * Y and UV planes i.e., planes 0 and 2 are used for Y and UV surfaces,
> + * planes 1 and 3 for the respective CCS.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Pandiyan, Dhinakaran]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, July 30, 2019 10:09 AM
> To: Vivi, Rodrigo 
> Cc: Nikula, Jani ; Joonas Lahtinen
> ; Souza, Jose ;
> sas...@kernel.org; intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org;
> Pandiyan, Dhinakaran 
> Subject: Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for
> the PSR section
> 
> On Tue, Jul 30, 2019 at 09:56:59AM -0700, Rodrigo Vivi wrote:
> >
> > On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > > > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan
> wrote:
> > > > > > > > > > A single 32-bit PSR2 training pattern field follows the 
> > > > > > > > > > sixteen
> > > > > > > > > > element
> > > > > > > > > > array of PSR table entries in the VBT spec. But, we 
> > > > > > > > > > incorrectly
> > > > > > > > > > define
> > > > > > > > > > this PSR2 field for each of the PSR table entries. As a 
> > > > > > > > > > result,
> the
> > > > > > > > > > PSR1
> > > > > > > > > > training pattern duration for any panel_type != 0 will be
> parsed
> > > > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for 
> > > > > > > > > > VBTs
> > > > > > > > > > with bdb
> > > > > > > > > > version >= 226 will also be wrong.
> > > > > > > > > >
> > > > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > > > Cc: José Roberto de Souza 
> > > > > > > > > > Cc: sta...@vger.kernel.org
> > > > > > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new 
> > > > > > > > > > field
> > > > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > > > Bugzilla: 
> > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > > > Signed-off-by: Dhinakaran Pandiyan
> 
> > > > > > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > > > > > Acked-by: Rodrigo Vivi 
> > > > > > > > > > Tested-by: François Guerraz 
> > > > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > > > Link:
> > > > > > > > > >
> https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-
> dhinakaran.pandi...@intel.com
> > > > > > > > > > (cherry picked from commit
> > > > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > > >
> > > > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > > >
> > > > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > > >
> > > > > > > This line is automatically added by "dim" tool when
> > > > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > > >
> > > > > > What do you need her from us to accept this patch?
> > > > >
> > > > > Um, you have read the stable kernel rules, right?
> > > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-
> rules.html
> > > > >
> >

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Pandiyan, Dhinakaran]

On Wed, 2019-07-17 at 14:35 +0300, Ville Syrjälä wrote:
> On Tue, Jul 16, 2019 at 03:03:21PM -0700, Dhinakaran Pandiyan wrote:
> > A single 32-bit PSR2 training pattern field follows the sixteen element
> > array of PSR table entries in the VBT spec. But, we incorrectly define
> > this PSR2 field for each of the PSR table entries. As a result, the PSR1
> > training pattern duration for any panel_type != 0 will be parsed
> > incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
> > version >= 226 will also be wrong.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: José Roberto de Souza 
> > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 
> > TP2/3 wakeup time")
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> Reviewed-by: Ville Syrjälä 
> 
> Please sync the igt copy after landing this.

Will do, thanks!

-DK
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> >  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++---
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 21501d565327..b416b394b641 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const 
> > struct bdb_header *bdb)
> > }
> >  
> > if (bdb->version >= 226) {
> > -   u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
> > +   u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
> >  
> > wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
> > switch (wakeup_time) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > index 93f5c9d204d6..09cd37fb0b1c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > @@ -481,13 +481,13 @@ struct psr_table {
> > /* TP wake up time in multiple of 100 */
> > u16 tp1_wakeup_time;
> > u16 tp2_tp3_wakeup_time;
> > -
> > -   /* PSR2 TP2/TP3 wakeup time for 16 panels */
> > -   u32 psr2_tp2_tp3_wakeup_time;
> >  } __packed;
> >  
> >  struct bdb_psr {
> > struct psr_table psr_table[16];
> > +
> > +   /* PSR2 TP2/TP3 wakeup time for 16 panels */
> > +   u32 psr2_tp2_tp3_wakeup_time;
> >  } __packed;
> >  
> >  /*
> > -- 
> > 2.17.1
> > 
> > ___
> > 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] drm/i915/vbt: Fix VBT parsing for the PSR section

[Pandiyan, Dhinakaran]

On Tue, 2019-07-16 at 15:03 -0700, Dhinakaran Pandiyan wrote:
> A single 32-bit PSR2 training pattern field follows the sixteen element
> array of PSR table entries in the VBT spec. But, we incorrectly define
> this PSR2 field for each of the PSR table entries. As a result, the PSR1
> training pattern duration for any panel_type != 0 will be parsed
> incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
> version >= 226 will also be wrong.

This was reported and bisected by 
Aliaksei Urbanski here - https://bugzilla.kernel.org/show_bug.cgi?id=204183

I'll add Bugzilla after the fix is confirmed.

Cc: Rodrigo Vivi 
Cc: José Roberto de Souza 
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 
wakeup time")z
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 21501d565327..b416b394b641 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
}
 
if (bdb->version >= 226) {
-   u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
+   u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
 
wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
switch (wakeup_time) {
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 93f5c9d204d6..09cd37fb0b1c 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -481,13 +481,13 @@ struct psr_table {
/* TP wake up time in multiple of 100 */
u16 tp1_wakeup_time;
u16 tp2_tp3_wakeup_time;
-
-   /* PSR2 TP2/TP3 wakeup time for 16 panels */
-   u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 struct bdb_psr {
struct psr_table psr_table[16];
+
+   /* PSR2 TP2/TP3 wakeup time for 16 panels */
+   u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Add _TRANS2()

[Pandiyan, Dhinakaran]

On Wed, 2019-04-17 at 15:37 -0700, José Roberto de Souza wrote:
> A new macro that is going to be added in a further patch will need to
> adjust the offset returned by _MMIO_TRANS2(), so here adding
> _TRANS2() and moving most of the implementation of _MMIO_TRANS2() to
> it and while at it taking the opportunity to rename pipe to trans.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b74824f0b5b1..9ef306b79e0d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -250,9 +250,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MMIO_PIPE2(pipe, reg)   _MMIO(INTEL_INFO(dev_priv)-
> >pipe_offsets[pipe] - \
> INTEL_INFO(dev_priv)-
> >pipe_offsets[PIPE_A] + (reg) + \
> DISPLAY_MMIO_BASE(dev_priv))
> -#define _MMIO_TRANS2(pipe, reg)  _MMIO(INTEL_INFO(dev_priv)-
> >trans_offsets[(pipe)] - \
> -   INTEL_INFO(dev_priv)-
> >trans_offsets[TRANSCODER_A] + (reg) + \
> -   DISPLAY_MMIO_BASE(dev_priv))
> +#define _TRANS2(trans, reg)  (INTEL_INFO(dev_priv)-
_TRANS() and _MMIO_TRANS() name the first argument "tran"

Can you please keep the same name "tran"?

Reviewed-by: Dhinakaran Pandiyan 

> >trans_offsets[(trans)] - \
> +  INTEL_INFO(dev_priv)-
> >trans_offsets[TRANSCODER_A] + (reg) + \
> +  DISPLAY_MMIO_BASE(dev_priv))
> +#define _MMIO_TRANS2(trans, reg) _MMIO(_TRANS2(trans, reg))
>  #define _CURSOR2(pipe, reg)  _MMIO(INTEL_INFO(dev_priv)-
> >cursor_offsets[(pipe)] - \
> INTEL_INFO(dev_priv)-
> >cursor_offsets[PIPE_A] + (reg) + \
> DISPLAY_MMIO_BASE(dev_priv))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/psr: Remove partial PSR support on multiple transcoders

[Pandiyan, Dhinakaran]

On Thu, 2019-04-04 at 14:20 -0700, Rodrigo Vivi wrote:
> On Thu, Apr 04, 2019 at 12:40:34PM -0700, Souza, Jose wrote:
> > On Wed, 2019-04-03 at 17:31 -0700, Rodrigo Vivi wrote:
> > > On Wed, Apr 03, 2019 at 04:35:38PM -0700, José Roberto de Souza
> > > wrote:
> > > > PSR is only supported in eDP transcoder and there is only one
> > > > instance of it, so lets drop all of this code.
> > > 
> > > Is this sentence true? I mean, in the way it is written it
> > > seems like HW doesn't actually support it...
> > > Or should we re-phrase for we are not really enabling support
> > > for other transcoders than eDP and we do not have plans to do
> > > it so soon so let's clean the code...
> > > or something like that?
> > 
> > Okay, what about replace it for:
> > 
> > Since BDW all transcoders have PSR registers but only EDP transcoder
> > can drive a EDP panel and as PSR is only part of the EDP specification,
> > for real usage PSR is only supported in EDP panel, so lets drop all of
> > this useless code.
> 
> well, this still looks like HW limitation. If PSR is supported by HW on
> different transcoders is because there's some possibility of adding
> eDP on other transcoders. They wouldn't waste so many register space
> if that wasn't the case.
> 
> Even though we have a dedicated transcoder for eDP I don't
> believe we can assume that eDP is not supported on the other ones.
> 

Why not write something like (or exactly) this 

"i915 does not support enabling PSR on any transcoder other than eDP. Clean up
the misleading non-eDP code that currently exists to allow for the rework of PSR
register definitions in the next patch"


-DK
> > 
> > 
> > 
> > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  17 +---
> > > >  drivers/gpu/drm/i915/intel_psr.c | 147 ---
> > > > 
> > > >  2 files changed, 42 insertions(+), 122 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index c59cfa83dbaf..18e2991b376d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -4241,13 +4241,9 @@ enum {
> > > >  /* Bspec claims those aren't shifted but stay at 0x64800 */
> > > >  #define EDP_PSR_IMR_MMIO(0x64834)
> > > >  #define EDP_PSR_IIR_MMIO(0x64838)
> > > > -#define   EDP_PSR_ERROR(shift) (1 << ((shift)
> > > > + 2))
> > > > -#define   EDP_PSR_POST_EXIT(shift) (1 << ((shift) + 1))
> > > > -#define   EDP_PSR_PRE_ENTRY(shift) (1 << (shift))
> > > > -#define   EDP_PSR_TRANSCODER_C_SHIFT   24
> > > > -#define   EDP_PSR_TRANSCODER_B_SHIFT   16
> > > > -#define   EDP_PSR_TRANSCODER_A_SHIFT   8
> > > > -#define   EDP_PSR_TRANSCODER_EDP_SHIFT 0
> > > > +#define   EDP_PSR_ERROR(1 << 2)
> > > > +#define   EDP_PSR_POST_EXIT(1 << 1)
> > > > +#define   EDP_PSR_PRE_ENTRY(1 << 0)
> > > >  
> > > >  #define EDP_PSR_AUX_CTL_MMIO(dev_priv-
> > > > > psr_mmio_base + 0x10)
> > > > 
> > > >  #define   EDP_PSR_AUX_CTL_TIME_OUT_MASK(3 << 26)
> > > > @@ -4312,12 +4308,7 @@ enum {
> > > >  #define   EDP_PSR2_IDLE_FRAME_MASK 0xf
> > > >  #define   EDP_PSR2_IDLE_FRAME_SHIFT0
> > > >  
> > > > -#define _PSR_EVENT_TRANS_A 0x60848
> > > > -#define _PSR_EVENT_TRANS_B 0x61848
> > > > -#define _PSR_EVENT_TRANS_C 0x62848
> > > > -#define _PSR_EVENT_TRANS_D 0x63848
> > > > -#define _PSR_EVENT_TRANS_EDP   0x6F848
> > > > -#define PSR_EVENT(trans)   _MMIO_TRANS2(trans,
> > > > _PSR_EVENT_TRANS_A)
> > > > +#define PSR_EVENT  _MMIO(0x6F848)
> > > >  #define  PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
> > > >  #define  PSR_EVENT_PSR2_DISABLED   (1 << 16)
> > > >  #define  PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN  (1 << 15)
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index bb97c1657493..b984e005b72e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -84,46 +84,12 @@ static bool intel_psr2_enabled(struct
> > > > drm_i915_private *dev_priv,
> > > > }
> > > >  }
> > > >  
> > > > -static int edp_psr_shift(enum transcoder cpu_transcoder)
> > > > -{
> > > > -   switch (cpu_transcoder) {
> > > > -   case TRANSCODER_A:
> > > > -   return EDP_PSR_TRANSCODER_A_SHIFT;
> > > > -   case TRANSCODER_B:
> > > > -   return EDP_PSR_TRANSCODER_B_SHIFT;
> > > > -   case TRANSCODER_C:
> > > > -   return EDP_PSR_TRANSCODER_C_SHIFT;
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915: Fix PSR2 selective update corruption after PSR1 setup

[Pandiyan, Dhinakaran]

Thanks for checking, appreciate it.

-DK

> -Original Message-
> From: Runyan, Arthur J
> Sent: Wednesday, March 20, 2019 11:58 AM
> To: Souza, Jose ; Vivi, Rodrigo
> ; Pandiyan, Dhinakaran
> 
> Cc: Aigal, Pavana A ; 'intel-
> g...@lists.freedesktop.org' 
> Subject: RE: [PATCH] drm/i915: Fix PSR2 selective update corruption after
> PSR1 setup
> 
> PSR2 logic is incorrectly looking at this register bit during DC5 exit.
> Not a DMC problem, but DMC enables DC5.
> I'll update Bspec to require the bit to be not set when PSR2 is used.
> 
> > -Original Message-
> > From: Runyan, Arthur J
> > Sent: Tuesday, 12 March, 2019 4:42 PM
> > To: Souza, Jose ; Vivi, Rodrigo
> > ; Pandiyan, Dhinakaran
> > 
> > Cc: Aigal, Pavana A ; intel-
> > g...@lists.freedesktop.org
> > Subject: RE: [PATCH] drm/i915: Fix PSR2 selective update corruption
> > after
> > PSR1 setup
> >
> > Strange.  DMC doesn't look at training patterns.  I've asked the PSR2
> > guys to look for any cross-connection.
> >
> > > -Original Message-
> > > From: Souza, Jose
> > > Sent: Tuesday, 12 March, 2019 2:29 PM
> > > To: Vivi, Rodrigo ; Pandiyan, Dhinakaran
> > > 
> > > Cc: Runyan, Arthur J ; Aigal, Pavana A
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [PATCH] drm/i915: Fix PSR2 selective update corruption
> > > after
> > > PSR1 setup
> > >
> > > On Tue, 2019-03-12 at 14:14 -0700, Dhinakaran Pandiyan wrote:
> > > > On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> > > > > On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> > > > > wrote:
> > > > > > For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is
> > > > > > kept set while PSR2 is enabled, it causes some selective
> > > > > > updates to fail after got back from DC6 for the first time.
> > > >
> > > > That's suspicious, why does a PSR1 control register have any
> > > > effect on PSR2. Was PSR1 enabled before PSR2?
> > >
> > > Yes it only happens when switching from PSR1 -> PSR2, I caught this
> > > issue now because I had a external connector attached so display was
> > > never going to DC6.
> > >
> > > >
> > > >
> > > >
> > > > > > So lets clear this register before enabled PSR2, as it could
> > > > > > be set by a previous i915 module, firmware/BIOS or by a
> > > > > > previous mode that is not compatible with PSR2.
> > > > >
> > > > > Does it happen when you don't have DMC loaded?
> > > > >
> > > > > Because It looks like a DMC bug for me...
> > > > >
> > > > > If by removing DMC we don't see the issue, could we please file
> > > > > this bug to DMC while adding a FIXME with DMC bugged version on it?
> > > > >
> > > > > Aa: Pavana
> > > > >
> > > > > If it doesn't happen with DMC loaded than maybe a HSD would for
> > > > > hw team would be good anyway.
> > > > >
> > > > > Cc: Art.
> > > > >
> > > > > Thanks,
> > > > > Rodrigo.
> > > > >
> > > > > > Cc: Dhinakaran Pandiyan 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
> > > > > >  1 file changed, 10 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > index 7bab6a009e0d..ae62f8124558 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > @@ -494,12 +494,20 @@ static void hsw_activate_psr2(struct
> > > > > > intel_dp
> > > > > > *intel_dp)
> > > > > >  {
> > > > > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > > > u32 val;
> > > > > > +   int idle_frames;
> > > > > > +
> > > > > > +   /*
> > > > > > +* Keeping this PSR1 register set while PSR2 is enabled
> > > > > > +causes
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915: Fix PSR2 selective update corruption after PSR1 setup

[Pandiyan, Dhinakaran]

On Tue, 2019-03-12 at 14:28 -0700, Souza, Jose wrote:
> On Tue, 2019-03-12 at 14:14 -0700, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> > > On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> > > wrote:
> > > > For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is
> > > > kept
> > > > set
> > > > while PSR2 is enabled, it causes some selective updates to fail
> > > > after
> > > > got back from DC6 for the first time.
> > 
> > That's suspicious, why does a PSR1 control register have any effect
> > on
> > PSR2. Was PSR1 enabled before PSR2? 
> 
> Yes it only happens when switching from PSR1 -> PSR2, I caught this
> issue now because I had a external connector attached so display was
> never going to DC6.

I am a bit confused now :) Do you see the issue if PSR1 was never
enabled before enabling PSR2?

> > 
> > 
> > 
> > > > So lets clear this register before enabled PSR2, as it could be
> > > > set
> > > > by a previous i915 module, firmware/BIOS or by a previous mode
> > > > that
> > > > is not compatible with PSR2.
> > > 
> > > Does it happen when you don't have DMC loaded?
> > > 
> > > Because It looks like a DMC bug for me...
> > > 
> > > If by removing DMC we don't see the issue, could we please file
> > > this bug to DMC while adding a FIXME with DMC bugged version on
> > > it?
> > > 
> > > Aa: Pavana
> > > 
> > > If it doesn't happen with DMC loaded than maybe a HSD would for
> > > hw
> > > team would be good anyway.
> > > 
> > > Cc: Art.
> > > 
> > > Thanks,
> > > Rodrigo.
> > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
> > > >  1 file changed, 10 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 7bab6a009e0d..ae62f8124558 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -494,12 +494,20 @@ static void hsw_activate_psr2(struct
> > > > intel_dp
> > > > *intel_dp)
> > > >  {
> > > > struct drm_i915_private *dev_priv =
> > > > dp_to_i915(intel_dp);
> > > > u32 val;
> > > > +   int idle_frames;
> > > > +
> > > > +   /*
> > > > +* Keeping this PSR1 register set while PSR2 is enabled
> > > > causes
> > > > some
> > > > +* PSR2 selective updates to fail, corrupting screen.
> > > > +*/
> > > > +   val = I915_READ(EDP_PSR_CTL);
> > > > +   if (val & EDP_PSR_TP1_TP3_SEL)
> > > > +   I915_WRITE(EDP_PSR_CTL, val &
> > > > ~EDP_PSR_TP1_TP3_SEL);
> > 
> > Since PSR1 should be disabled at this point, a rmw is not
> > necessary.
> > Does this work? 
> > I915_WRITE(EDP_PSR_CTL, 0);
> > 
> > We could do the same thing in psr_exit() as well.
> 
> Write 0 also works and I'm doing RMW because I always try to save any
> writes.
Why so? Do we want to retain the old value in PSR_CTL when PSR2 is
enabled? 

> 
> No need to do it in psr_exit(), the important is do it here because
> other i915 module or BIOS could leave it set.
Right, that was an orthogonal suggestion to avoid the RMW that we do to
disable PSR1 and PSR2.

psr1 and psr2 activate functions recompute the values fully, so there
is no benefit in flipping just the enable bit in psr_exit().
> 
> > 
> > > >  
> > > > /* Let's use 6 as the minimum to cover all known cases
> > > > including the
> > > >  * off-by-one issue that HW has in some cases.
> > > >  */
> > > > -   int idle_frames = max(6, dev_priv-
> > > > >vbt.psr.idle_frames);
> > > > -
> > > > +   idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > > > idle_frames = max(idle_frames, dev_priv-
> > > > >psr.sink_sync_latency
> > > > + 1);
> > > > val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
> > > >  
> > > > -- 
> > > > 2.21.0
> > > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 4/9] drm/i915/psr: Drop test for EDP in CRTC when forcing commit

[Pandiyan, Dhinakaran]

On Thu, 2019-03-07 at 14:53 -0800, Souza, Jose wrote:
> On Thu, 2019-03-07 at 12:26 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > > If has_psr is set it means that CRTC has a EDP panel attached so
> > > it
> > > can be dropped, also has_psr is better than check for EDP output
> > > alone as it will avoid set mode_changed when PSR is not supported
> > > in
> > > panel or with current modeset.
> > 
> > Since we were already checking has_psr, I don't think it is
> > relevant
> > to
> > say checking just that is "better than check for EDP output alone".
> > Can
> > you please reword the commit message?
> 
> What about replace everything to:
> 
> If has_psr is set it means that CRTC has a EDP panel attached so the
> EDP check is redundant and can be dropped.
Yes, reads better.

> 
> > 
> > Reviewed-by: Dhinakaran Pandiyan 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Reviewed-by: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/intel_psr.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 6175b1d2e0c8..2d9f64c362e2 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -981,9 +981,7 @@ static int intel_psr_fastset_force(struct
> > > drm_i915_private *dev_priv)
> > >  
> > >   intel_crtc_state = to_intel_crtc_state(crtc_state);
> > >  
> > > - if (crtc_state->active &&
> > > - intel_crtc_has_type(intel_crtc_state,
> > > INTEL_OUTPUT_EDP) &&
> > > - intel_crtc_state->has_psr) {
> > > + if (crtc_state->active && intel_crtc_state->has_psr) {
> > >   /* Mark mode as changed to trigger a pipe-
> > > > update() */
> > > 
> > >   crtc_state->mode_changed = true;
> > >   break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic

[Pandiyan, Dhinakaran]

On Thu, 2019-02-28 at 17:14 -0800, Souza, Jose wrote:
> On Thu, 2019-02-28 at 17:06 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-02-28 at 15:26 -0800, Souza, Jose wrote:
> > > On Thu, 2019-02-28 at 18:56 +0200, Ville Syrjälä wrote:
> > > > On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza
> > > > wrote:
> > > > > Other features like PSR2 also needs to be disabled while
> > > > > getting
> > > > > CRC
> > > > > so lets rename ips_force_disable to crc_enabled, drop all
> > > > > this
> > > > > checks
> > > > > for pipe A and HSW and BDW and make it generic and
> > > > > hsw_compute_ips_config() will take care of all the checks
> > > > > removed
> > > > > from here.
> > > > > 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_display.c  | 10 +--
> > > > >  drivers/gpu/drm/i915/intel_drv.h  |  3 +-
> > > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +
> > > > > 
> > > > > --
> > > > >  3 files changed, 24 insertions(+), 31 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 816e8f124b3b..328967c642b3 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -6751,7 +6751,13 @@ static bool
> > > > > hsw_compute_ips_config(struct
> > > > > intel_crtc_state *crtc_state)
> > > > >   if (!hsw_crtc_state_ips_capable(crtc_state))
> > > > >   return false;
> > > > >  
> > > > > - if (crtc_state->ips_force_disable)
> > > > > + /*
> > > > > +  * When IPS gets enabled, the pipe CRC changes. Since
> > > > > IPS gets
> > > > > +  * enabled and disabled dynamically based on package C
> > > > > states,
> > > > > +  * user space can't make reliable use of the CRCs, so
> > > > > let's
> > > > > just
> > > > > +  * completely disable it.
> > > > > +  */
> > > > > + if (crtc_state->crc_enabled)
> > > > >   return false;
> > > > 
> > > > Hmm. I was wondering how we even manage to pass the state
> > > > checker
> > > > with
> > > > the current code. But apparently we don't have state checking
> > > > for
> > > > IPS.
> > > > I would suggest moving this into hsw_compute_ips_config() and
> > > > then
> > > > adding the state checker (for HSW only though since BDW can't
> > > > do
> > > > the
> > > > readout).
> > > > 
> > > > >  
> > > > >   /* IPS should be fine as long as at least one plane is
> > > > > enabled.
> > > > > */
> > > > > @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct
> > > > > intel_crtc_state *crtc_state)
> > > > >   saved_state->shared_dpll = crtc_state->shared_dpll;
> > > > >   saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> > > > >   saved_state->pch_pfit.force_thru = crtc_state-
> > > > > > pch_pfit.force_thru;
> > > > > 
> > > > > - saved_state->ips_force_disable = crtc_state-
> > > > > > ips_force_disable;
> > > > > 
> > > > > + saved_state->crc_enabled = crtc_state->crc_enabled;
> > > > >   if (IS_G4X(dev_priv) ||
> > > > >   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > >   saved_state->wm = crtc_state->wm;
> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > index 5412373e2f98..2be64529e4a2 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > @@ -999,7 +999,8 @@ struct intel_crtc_state {
> > > > >   struct intel_link_m_n fdi_m_n;
> > > > >  
> > > > >   bool ips_enabled;
> > > > > - bool ips_force_disable;
> > > > > +
> > > > > + bool crc_enabled;
> > > > >  
> > > > >   bool enable_fbc;
> > > > >  
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > index 53d4ec68d3c4..f6d0b2aaffe2 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > @@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum
> > > > > intel_pipe_crc_source *source,
> > > > >   return 0;
> > > > >  }
> > > > >  
> > > > > -static void hsw_pipe_A_crc_wa(struct drm_i915_private
> > > > > *dev_priv,
> > > > > -   bool enable)
> > > > > +static void
> > > > > +intel_crtc_crc_prepare(struct drm_i915_private *dev_priv,
> > > > > struct
> > > > > drm_crtc *crtc,
> > > > 
> > > > Just pass in the intel_crtc
> > > 
> > > Okay
> > > 
> > > > > +bool enable)
> > > > >  {
> > > > >   struct drm_device *dev = _priv->drm;
> > > > > - struct intel_crtc *crtc =
> > > > > intel_get_crtc_for_pipe(dev_priv,
> > > > > PIPE_A);
> > > > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > > 
> > > > and then we don't have to have an ugly name for this.
> 

Re: [Intel-gfx] [PATCH 1/4] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset

[Pandiyan, Dhinakaran]

On Wed, 2019-02-13 at 18:02 -0800, José Roberto de Souza wrote:
> Forcing a specific CRTC to the eDP connector was causing the
> intel_psr_fastset_force() to mark mode_chaged in the wrong and
> disabled CRTC causing no update in the PSR state.
> 
> Looks like our internal state track do not clear output_types and
> has_psr in the disabled CRTCs, not sure if this is the expected
> behavior or not but in the mean time this fix the issue.

Is there an IGT that's failing because of this? Looks like the state
would have got cleared only if the crtc was enabled to drive another
encoder.

> 
> Cc: Maarten Lankhorst 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 75c1a5deebf5..08967836b48e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -986,7 +986,8 @@ static int intel_psr_fastset_force(struct
> drm_i915_private *dev_priv)
>  
>   intel_crtc_state = to_intel_crtc_state(crtc_state);
>  
> - if (intel_crtc_has_type(intel_crtc_state,
> INTEL_OUTPUT_EDP) &&
> + if (crtc_state->enable &&
> + intel_crtc_has_type(intel_crtc_state,
> INTEL_OUTPUT_EDP) &&
>   intel_crtc_state->has_psr) {
>   /* Mark mode as changed to trigger a pipe-
> >update() */
>   crtc_state->mode_changed = true;
I was wondering if we should remove the 'break;' that follows instead
and let ->update_pipe take care of the rest. However, checking
crtc_state->enable makes sense as there is not much point in triggering
a fastset on a disabled crtc.

Reviewed-by: Dhinakaran Pandiyan  

There might be a better way to do this, so please double check with
someone :)

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x

[Pandiyan, Dhinakaran]

On Fri, 2019-02-15 at 23:34 +0200, Ville Syrjälä wrote:
> On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan
> > > wrote:
> > > > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > DP CRCs don't really work on g4x. If you want any CRCs on DP
> > > > > you
> > > > > must
> > > > > select the CRC source before the port is enabled, otherwise
> > > > > the
> > > > > CRC
> > > > > source select bits simply ignore any writes to them. And once
> > > > > the
> > > > > port
> > > > > is enabled we mustn't change the CRC source select until the
> > > > > port
> > > > > is
> > > > > disabled. That almost works, but not quite :( Eventually the
> > > > > CRC
> > > > > source
> > > > > select bits get permanently stuck one way or the other, and
> > > > > after
> > > > > that
> > > > > a reboot (or possibly a display reset) is needed to get
> > > > > working
> > > > > CRCs
> > > > > on that pipe (not matter which CRC source we try to use).
> > > > > 
> > > > > Additionally the DFT scrambler reset bits we're trying to use
> > > > > don't
> > > > > seem to exist on g4x. There are some potentially relevant
> > > > > looking
> > > > > bits
> > > > > in the pipe registers, but when I tried it I got stable
> > > > > looking
> > > > > CRCs
> > > > > without setting any bits for this.
> > > > > 
> > > > > If there is a way to make DP CRCs work reliably on g4x, I
> > > > > wasn't
> > > > > able to find it. So let's just remove the broken code we
> > > > > have.
> > > > 
> > > > 
> > > > I think we can modify i9xx_pipe_crc_auto_source() to pick
> > > > "pipe"
> > > > CRC
> > > > when userspace selects "auto" and the output is DP/eDP.
> > > 
> > > Nope. Spec says:
> > > "Pipe CRC should not be run when Display Port or TV is enabled on
> > > this
> > >  pipe."
> > > 
> > > and
> > > 
> > > "CRC Source Select: These bits select the source of the data to
> > > put
> > > into
> > >  the CRC logic.
> > >  000: Pipe A (Not available when DisplayPort or TV is enabled on
> > > this
> > >  pipe)"
> > > 
> > 
> > After digging through some old specs, I do see this restriction for
> > gen-4 and VLV, but for some reason not for gen-3 or CHV. 
> 
> gen3 predates DP (g4x being the first platform that has it). I don't
> think SDVO->DP was ever a thing. SDVO->HDMI did happen but even that
> one is quite rare.

TV? I see TV initialization for a couple of gen-3 platforms but the
spec does not say that pipe CRCs are not available.
> 
> The display engine side of CHV is 99.9% VLV, with a few extra
> bits and pieces glued on top.

Thanks for the clarification, the CHV spec for some reason make it a
point to specify VLV in paranthesis

: Pipe C (Not available when DisplayPort or TV is enabled on this
pipe) [VLV]

> 
> > 
> > There is no good choice for "auto" other than DP and since DP does
> > not
> > work, returning -EINVAL makes sense.
> > Reviewed-by: Dhinakaran Pandiyan 
> > 
> > > Though I must admit I've never actually tried it to see what
> > > actually
> > > happens.
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 80 -
> > > > > 
> > > > > 
> > > > > --
> > > > >  1 file changed, 11 insertions(+), 69 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > index fe0ff89b980b..66bb7b031537 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > @@ -191,8 +191,6 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > > drm_i915_private *dev_priv,
> > > > >enum intel_pipe_crc_source
> > > > > *source,
> > > > >u32 *val)
> > > > >  {
> > > > > - bool need_stable_symbols = false;
> > > > > -
> > > > >   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > > > >   int ret = i9xx_pipe_crc_auto_source(dev_priv,
> > > > > pipe,
> > > > > source);
> > > > >   if (ret)
> > > > > @@ -208,56 +206,23 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > > drm_i915_private *dev_priv,
> > > > >   return -EINVAL;
> > > > >   *val = PIPE_CRC_ENABLE |
> > > > > PIPE_CRC_SOURCE_TV_PRE;
> > > > >   break;
> > > > > - case INTEL_PIPE_CRC_SOURCE_DP_B:
> > > > > - if (!IS_G4X(dev_priv))
> > > > > - return -EINVAL;
> > > > > - *val = PIPE_CRC_ENABLE |
> > > > > PIPE_CRC_SOURCE_DP_B_G4X;
> > > > > - need_stable_symbols = true;
> > > > > - break;
> > > > > - case INTEL_PIPE_CRC_SOURCE_DP_C:
> > > > > - if (!IS_G4X(dev_priv))
> > > > > - return -EINVAL;
> > > > > -

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC

[Pandiyan, Dhinakaran]

On Thu, 2019-02-14 at 15:19 -0800, Souza, Jose wrote:
> On Thu, 2019-02-14 at 11:00 -0800, Dhinakaran Pandiyan wrote:
> > On Wed, 2019-02-13 at 18:02 -0800, José Roberto de Souza wrote:
> > > As stated in CRC_CTL spec, after PSR entry state CRC will not be
> > > calculated anymore what is not a problem as IGT tests do some
> > > screen
> > > change and then request the pipe CRC right after the change so
> > > PSR
> > > will go to idle state and only will entry again after at least 6
> > > idles frames.
> > > 
> > > But for PSR2 it is more problematic as any change to the screen
> > > could
> > > trigger a selective/partial update causing the CRC value not to
> > > be
> > > calculated over the full frame.
> > 
> > Okay, that reasoning runs counter to my understanding. My
> > understanding
> > is that the whole frame is fetched and processed at the pipe level
> > but
> > the DDI sends selective blocks of pixels. So, if the CRC's are
> > calculated at the pipe level, the CRC should be for the full frame
> > with
> > PSR2 having no effect? Checking bspec, I see there are DDI CRCs as
> > well, which should reflect the partial frame that PSR2 sends.
> > 
> > To get a better understanding, I'd like to know what the source for
> > mismatching CRCs is?
> 
> Well the naming is misleading for newer gens, before BDW this was a
> pipe register(8067) but now it is a DDI register(7536) but the
> register
> offset was kept the same.
Do we even read this register DDI_CRC_CTL? Don't see it defined in
i915_reg.h or referenced in intel_pipe_crc.c.
> 
> In my testing hardware generate 4 interruptions with wrong CRC values
> then stops forever probably because vblank interruptions are off.
Yeah, my guess is that power management is affecting the CRC generation
rather than pipe CRC's being calculated only on the SU update blocks.


> > 
> > 
> > > So here it disables PSR2 and keep it disabled while user is
> > > requesting pipe CRC.
> > > 
> > > BSpec: 7536
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 10 ++
> > >  drivers/gpu/drm/i915/intel_psr.c  | 23
> > > +++
> > >  4 files changed, 35 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 17fe942eaafa..609e9c5bd453 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -520,6 +520,7 @@ struct i915_psr {
> > >   bool sink_not_reliable;
> > >   bool irq_aux_error;
> > >   u16 su_x_granularity;
> > > + bool pipe_crc_enabled;
> > >  };
> > >  
> > >  enum intel_pch {
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 3398b28c053b..40ce7a600585 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -2103,6 +2103,7 @@ void intel_psr_short_pulse(struct intel_dp
> > > *intel_dp);
> > >  int intel_psr_wait_for_idle(const struct intel_crtc_state
> > > *new_crtc_state,
> > >   u32 *out_value);
> > >  bool intel_psr_enabled(struct intel_dp *intel_dp);
> > > +void intel_psr_crc_prepare_or_finish(struct drm_i915_private
> > > *dev_priv, enum pipe pipe, bool prepare);
> > >  
> > >  /* intel_quirks.c */
> > >  void intel_init_quirks(struct drm_i915_private *dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index a8554dc4f196..5d8772399f60 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -583,6 +583,14 @@ int intel_crtc_verify_crc_source(struct
> > > drm_crtc
> > > *crtc, const char *source_name,
> > >   return -EINVAL;
> > >  }
> > >  
> > > +static inline void intel_crtc_crc_prepare_or_finish(struct
> > > drm_crtc
> > > *crtc, bool prepare)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > +
> > > + intel_psr_crc_prepare_or_finish(dev_priv, intel_crtc->pipe,
> > > prepare);
> > > +}
> > > +
> > >  int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char
> > > *source_name)
> > >  {
> > >   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > @@ -609,6 +617,8 @@ int intel_crtc_set_crc_source(struct drm_crtc
> > > *crtc, const char *source_name)
> > >   if (ret != 0)
> > >   goto out;
> > >  
> > > + intel_crtc_crc_prepare_or_finish(crtc, source !=
> > > INTEL_PIPE_CRC_SOURCE_NONE);
> > > +
> > >   pipe_crc->source = source;
> > >   I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
> > >   POSTING_READ(PIPE_CRC_CTL(crtc->index));
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 08967836b48e..9c93138988aa 

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Execute the default PSR code path when setting i915_edp_psr_debug

[Pandiyan, Dhinakaran]

On Tue, 2019-02-05 at 16:23 -0800, Souza, Jose wrote:
> On Tue, 2019-02-05 at 15:50 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-01-31 at 17:59 -0800, José Roberto de Souza wrote:
> > > Changing the i915_edp_psr_debug was enabling, disabling or
> > > switching
> > > PSR version by directly calling intel_psr_disable_locked() and
> > > intel_psr_enable_locked(), what is not the default PSR path that
> > > will
> > > be executed by real users.
> > > 
> > > So lets force a fastset in the PSR CRTC to trigger a pipe update
> > > and
> > > stress the default code path.
> > > 
> > > Recently a bug was found when switching from PSR2 to PSR1 while
> > > enable_psr kernel parameter was set to the default parameter,
> > > this
> > > changes fix it and also fixes the bug linked bellow were DRRS was
> > > left enabled together with PSR when enabling PSR from debugfs.
> > > 
> > > v2: Handling missing case: disabled to PSR1
> > > 
> > > v3: Not duplicating the whole atomic state(Maarten)
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
> > > Cc: Maarten Lankhorst 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c |  14 +--
> > >  drivers/gpu/drm/i915/i915_drv.h |   2 +-
> > >  drivers/gpu/drm/i915/intel_ddi.c|   2 +-
> > >  drivers/gpu/drm/i915/intel_drv.h|   6 +-
> > >  drivers/gpu/drm/i915/intel_psr.c| 188 +-
> > > --
> > > --
> > > --
> > >  5 files changed, 119 insertions(+), 93 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index fa2c226fc779..766a5b4ad3d6 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2607,7 +2607,6 @@ static int
> > >  i915_edp_psr_debug_set(void *data, u64 val)
> > >  {
> > >   struct drm_i915_private *dev_priv = data;
> > > - struct drm_modeset_acquire_ctx ctx;
> > >   intel_wakeref_t wakeref;
> > >   int ret;
> > >  
> > > @@ -2618,18 +2617,7 @@ i915_edp_psr_debug_set(void *data, u64
> > > val)
> > >  
> > >   wakeref = intel_runtime_pm_get(dev_priv);
> > >  
> > > - drm_modeset_acquire_init(,
> > > DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > > -
> > > -retry:
> > > - ret = intel_psr_set_debugfs_mode(dev_priv, , val);
> > > - if (ret == -EDEADLK) {
> > > - ret = drm_modeset_backoff();
> > > - if (!ret)
> > > - goto retry;
> > > - }
> > > -
> > > - drm_modeset_drop_locks();
> > > - drm_modeset_acquire_fini();
> > > + ret = intel_psr_set_debugfs_mode(dev_priv, val);
> > >  
> > >   intel_runtime_pm_put(dev_priv, wakeref);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index f11c66d172d3..baee581a0d5b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -496,7 +496,7 @@ struct i915_psr {
> > >  
> > >   u32 debug;
> > >   bool sink_support;
> > > - bool prepared, enabled;
> > > + bool enabled;
> > >   struct intel_dp *dp;
> > >   enum pipe pipe;
> > >   bool active;
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index ca705546a0ab..9211e4579489 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3556,7 +3556,7 @@ static void intel_ddi_update_pipe_dp(struct
> > > intel_encoder *encoder,
> > >  {
> > >   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > >  
> > > - intel_psr_enable(intel_dp, crtc_state);
> > > + intel_psr_update(intel_dp, crtc_state);
> > >   intel_edp_drrs_enable(intel_dp, crtc_state);
> > >  
> > >   intel_panel_update_backlight(encoder, crtc_state, conn_state);
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 90ba5436370e..4c01decc30d3 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -2067,9 +2067,9 @@ void intel_psr_enable(struct intel_dp
> > > *intel_dp,
> > > const struct intel_crtc_state *crtc_state);
> > >  void intel_psr_disable(struct intel_dp *intel_dp,
> > > const struct intel_crtc_state *old_crtc_state);
> > > -int intel_psr_set_debugfs_mode(struct drm_i915_private
> > > *dev_priv,
> > > -struct drm_modeset_acquire_ctx *ctx,
> > > -u64 value);
> > > +void intel_psr_update(struct intel_dp *intel_dp,
> > > +   const struct intel_crtc_state *crtc_state);
> > > +int intel_psr_set_debugfs_mode(struct drm_i915_private
> > > *dev_priv,
> > > u64 value);
> > >  void intel_psr_invalidate(struct drm_i915_private *dev_priv,
> > > unsigned frontbuffer_bits,
> > > enum fb_op_origin origin);
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > 

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915/psr: Check if source supports sink specific SU granularity

[Pandiyan, Dhinakaran]

On Mon, 2018-12-03 at 14:45 -0800, Souza, Jose wrote:
> On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > According to eDP spec, sink can required specific selective
> > > update
> > > granularity that source must comply.
> > > Here caching the value if required and checking if source
> > > supports
> > > it.
> > > 
> > > Cc: Rodrigo Vivi 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_psr.c | 21 -
> > >  2 files changed, 21 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 43ac6873a2bb..0727d8051dd3 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -507,6 +507,7 @@ struct i915_psr {
> > >   ktime_t last_exit;
> > >   bool sink_not_reliable;
> > >   bool irq_aux_error;
> > > + u16 su_x_granularity;
> > >  };
> > >  
> > >  enum intel_pch {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 282ff1bc68a7..f9eccaac850a 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -261,6 +261,23 @@ static u8
> > > intel_dp_get_sink_sync_latency(struct
> > > intel_dp *intel_dp)
> > >   return val;
> > >  }
> > >  
> > > +static u16 intel_dp_get_su_x_granulartiy(struct intel_dp
> > > *intel_dp)
> > > +{
> > > + u16 val;
> > > + ssize_t r;
> > > +
> > > + if (!(intel_dp->psr_dpcd[1] & DP_PSR2_SU_GRANULARITY_REQUIRED))
> > > {
> > > + /* Returning the default X granularity */
> > > + return 4;
> > > + }
> > 
> > nit: Braces not needed, you could move the comment a line above.
> > 
> > A value of 0 in this DPCD indicates there is no granularity
> > requirement, why assume 4? 
> 
> Like you said bellow, 4 is the default granularity if this is not
> set.
> 
The spec states 0 means no granularity requirements, return 1 here?

> > 
> > > +
> > > + r = drm_dp_dpcd_read(_dp->aux, DP_PSR2_SU_X_GRANULARITY,
> > > , 2);
> > > + if (r != 2)
> > > + DRM_WARN("Unable to read DP_PSR2_SU_X_GRANULARITY\n");
> > 
> > Please change this to the warning level that we use elsewhere for
> > aux
> > failures.
> 
> So changing to DRM_DEBUG_KMS()
> 
> > 
> > If I'm reading the spec correctly, a value of 0 in this DPCD means
> > the
> > sink expects a granularity of 4, so returning 0 would be incorrect.
> > 
> > > +
> > > + return val;
> > 
> > Assume the default value of 4 if aux read fails (after printing an
> > error)
> > 
> 
> Done
> 
> 
> > > +}
> > > +
> > >  void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > >  {
> > >   struct drm_i915_private *dev_priv =
> > > @@ -315,6 +332,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > > *intel_dp)
> > >   if (dev_priv->psr.sink_psr2_support) {
> > >   dev_priv->psr.colorimetry_support =
> > >   intel_dp_get_colorimetry_status(intel_d
> > > p);
> > > + dev_priv->psr.su_x_granularity =
> > > + intel_dp_get_su_x_granulartiy(intel_dp)
> > > ;
> > >   }
> > >   }
> > >  }
> > > @@ -546,7 +565,7 @@ static bool intel_psr2_config_valid(struct
> > > intel_dp *intel_dp,
> > >* at each 4 lines with height of 4 lines, what eDP states
> > >* that sink should support.
> > >*/
> > > - if (crtc_hdisplay % 4) {
> > > + if (crtc_hdisplay % dev_priv->psr.su_x_granularity) {
> > >   DRM_DEBUG_KMS("PSR2 not enabled, default SU granularity
> > > not match\n");
> > >   return false;
> > >   }
___
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: Reuse plane format modifier checks to verify addfb() arguments

[Pandiyan, Dhinakaran]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Friday, October 26, 2018 7:46 AM
> To: Pandiyan, Dhinakaran 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/i915: Reuse plane format modifier checks to
> verify addfb() arguments
> 
> On Thu, Oct 25, 2018 at 06:32:56PM -0700, Dhinakaran Pandiyan wrote:
> > Currently there is some duplication of pixel format and modifier
> > validation code between the fb creation and plane check paths. We can
> > unify them by checking if any plane supports a pixel format and
> > modifier combination during framebuffer creation.
> >
> > Suggested-by: Ville Syrjälä 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 116
> > ++-
> >  1 file changed, 19 insertions(+), 97 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe045abb6472..1b5d936a93d0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14362,6 +14362,19 @@ u32 intel_fb_pitch_limit(struct
> drm_i915_private *dev_priv,
> >  DRM_MODE_ROTATE_0);
> >  }
> >
> > +static bool any_plane_supports_format(struct drm_i915_private
> *dev_priv,
> > +uint64_t fb_modifier,
> > +uint32_t pixel_format)
> 
> "format first, modifier second" is the typical covention.
Yeah, I did go that way. intel_fb_pitch_limit() that's right above inverts the 
order,
so I switched it keep it locally consistent.


> 
> But I think we could stuff this entire thing into the core, in case someone 
> else
> wants to reuse it. I think I even posted the patches that do it like that.
> Ah yes: https://patchwork.freedesktop.org/series/39700/
Since you posted them first, let's go with it. Patches 1-3 look good to me, can
you rebase and send them to the list? The second patch does not apply.


> 
> > +{
> > +   struct drm_plane *plane;
> > +
> > +   drm_for_each_plane(plane, _priv->drm)
> > +   if (!drm_plane_check_pixel_format(plane, pixel_format,
> > + fb_modifier))
> > +   return true;
> > +   return false;
> > +}
> > +
> >  static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> >   struct drm_i915_gem_object *obj,
> >   struct drm_mode_fb_cmd2 *mode_cmd)
> @@ -14399,40 +14412,12 @@
> > static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
> > }
> > }
> >
> > -   /* Passed in modifier sanity checking. */
> > -   switch (mode_cmd->modifier[0]) {
> > -   case I915_FORMAT_MOD_Y_TILED_CCS:
> > -   case I915_FORMAT_MOD_Yf_TILED_CCS:
> > -   switch (mode_cmd->pixel_format) {
> > -   case DRM_FORMAT_XBGR:
> > -   case DRM_FORMAT_ABGR:
> > -   case DRM_FORMAT_XRGB:
> > -   case DRM_FORMAT_ARGB:
> > -   break;
> > -   default:
> > -   DRM_DEBUG_KMS("RC supported only with
> RGB formats\n");
> > -   goto err;
> > -   }
> > -   /* fall through */
> > -   case I915_FORMAT_MOD_Yf_TILED:
> > -   if (mode_cmd->pixel_format == DRM_FORMAT_C8) {
> > -   DRM_DEBUG_KMS("Indexed format does not
> support Yf tiling\n");
> > -   goto err;
> > -   }
> > -   /* fall through */
> > -   case I915_FORMAT_MOD_Y_TILED:
> > -   if (INTEL_GEN(dev_priv) < 9) {
> > -   DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
> > - mode_cmd->modifier[0]);
> > -   goto err;
> > -   }
> > -   break;
> > -   case DRM_FORMAT_MOD_LINEAR:
> > -   case I915_FORMAT_MOD_X_TILED:
> > -   break;
> > -   default:
> > -   DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
> > - mode_cmd->modifier[0]);
> > +   if (!any_plane_supports_format(dev_priv, mode_cmd->modifier[0],
> > +  mode_cmd->pixel_format)) {
> > +   DRM_DEBUG_KMS("Unsupported pixel format %s or
> modifier 0x%llx\n"

Re: [Intel-gfx] [PATCH 3/8] drm/i915/psr: Enable sink to trigger a interruption on PSR2 CRC mismatch

[Pandiyan, Dhinakaran]

On Thu, 2018-09-20 at 13:43 -0700, José Roberto de Souza wrote:
> eDP spec states 2 different bits to enable sink to trigger a
> interruption when there is a CRC mismatch.
> DP_PSR_CRC_VERIFICATION is for PSR only and
> DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6f3c6f0c539f..b4edbbda8d71 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -340,7 +340,7 @@ static void intel_psr_enable_sink(struct intel_dp
> *intel_dp)
>   if (dev_priv->psr.psr2_enabled) {
>   drm_dp_dpcd_writeb(_dp->aux,
> DP_RECEIVER_ALPM_CONFIG,
>  DP_ALPM_ENABLE);
> - dpcd_val |= DP_PSR_ENABLE_PSR2;
> + dpcd_val |= DP_PSR_ENABLE_PSR2 |
> DP_PSR_IRQ_HPD_WITH_CRC_ERRORS;
>   } 
} else if (INTEL_GEN(dev_priv) >=8) {

dpcd_val |= DP_PSR_CRC_VERIFICATION;
}

How about doing this for clarity? 



>  
>   if (dev_priv->psr.link_standby)


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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/dp: Move hdcp link check function into short pulse handler

[Pandiyan, Dhinakaran]

On Wed, 2018-09-19 at 21:05 +0300, Ville Syrjälä wrote:
> On Wed, Sep 19, 2018 at 05:49:33PM +0000, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-09-19 at 20:30 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:20:09AM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > This way all short pulse handlers except MST are in one place.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan  > > > om>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 123c2eafafab..03d2c6426016 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4501,6 +4501,9 @@ intel_dp_short_pulse(struct intel_dp
> > > > *intel_dp)
> > > > drm_kms_helper_hotplug_event(_priv->drm);
> > > > }
> > > >  
> > > > +   /* Short pulse can signify loss of hdcp authentication
> > > > */
> > > > +   intel_hdcp_check_link(intel_dp->attached_connector);
> > > > +
> > > > return true;
> > > >  }
> > > >  
> > > > @@ -5634,9 +5637,6 @@ intel_dp_hpd_pulse(struct
> > > > intel_digital_port
> > > > *intel_dig_port, bool long_hpd)
> > > >  
> > > > handled = intel_dp_short_pulse(intel_dp);
> > > >  
> > > > -   /* Short pulse can signify loss of hdcp
> > > > authentication */
> > > > -   intel_hdcp_check_link(intel_dp-
> > > > > attached_connector);
> > > > 
> > > > -
> > > 
> > > This changes the behaviour to skip intel_hdcp_check_link() when
> > > intel_dp_short_pulse() decides to fall back to full detect. Not
> > > sure
> > > if
> > > that's OK or not.
> > 
> > I'm thinking we should move the decision to fallback to the very
> > end of
> > intel_dp_short_pulse(). 
> 
> Perhaps. The entire "how do we process hpd_irqs correctly?" thing
> needs some real thought.

One noteworthy information I remember from my last reading of the spec
is that the sink is required to generate a distinct IRQ_HPD to request
retraining. But then, if we get two interrupts in quick succession, a
queued work item will end up handling both. 

> 
> > 
> > The benefit we get is to disable PSR if the sink complained of PSR
> > errors and then check if the hardware retrained the link correctly
> > after we disabled.
> > 
> > 
> > > 
> > > > if (!handled)
> > > > goto put_power;
> > > > }
> > > > -- 
> > > > 2.14.1
> > > > 
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > > 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915/dp: Restrict link retrain workaround to external monitors

[Pandiyan, Dhinakaran]

On Tue, 2018-09-18 at 08:50 -0700, Rodrigo Vivi wrote:
> On Tue, Sep 18, 2018 at 11:33:24AM -0400, Lyude Paul wrote:
> > Did the patch this references get pushed? I saw it fly by and I
> > thought we had
> > decided not to pull it in
> 
> ops, I created the confusion. Sorry.
> 
> What I decided that week was to not pull to drm-intel-fixes until
> Ville
> or Jani acking. But it was already part of dinq, so moving to drm-
> next
> and I didn't removed or reverted it.

I would have preferred to limit this work around to the specific
monitor it was needed for. The next best thing is to at least limit it
to external monitors? The code adds a bunch of extra dpcd reads to
check link status and acquires locks whenever user spaces wants a
->detect() and most sinks do not need this.

Let me know what your thoughts are.

-DK


> 
> So... But ville acked on irc and I pulled to -fixes on the following
> week
> as well.
> 
> So yes, patch is there ;)
> 
> > 
> > On Tue, 2018-09-18 at 00:20 -0700, Dhinakaran Pandiyan wrote:
> > > commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality
> > > check,
> > > unconditionally during long pulse"")' applies a work around for
> > > monitors
> > > that don't signal link loss. Limit this only for external
> > > displays as
> > > eDP features like PSR when active will have the link turned off
> > > and the
> > > driver ends up retraining the link seeeing that link is not
> > > synchronized.
> > > 
> > > Cc: Lyude Paul 
> > > Cc: Jan-Marek Glogowski 
> > > Cc: Ville Syrjälä 
> > > Cc: Rodrigo Vivi 
> > > References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link
> > > quality check,
> > > unconditionally during long pulse"")
> > > Signed-off-by: Dhinakaran Pandiyan  > > >
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index cac1c7c6cbfd..8bf9afa5683c 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5072,7 +5072,9 @@ intel_dp_long_pulse(struct intel_connector
> > > *connector,
> > >*/
> > >   status = connector_status_disconnected;
> > >   goto out;
> > > - } else {
> > > + }
> > > +
> > > + if (!intel_dp_is_edp(intel_dp)) {
> > >   /*
> > >* Some monitors do not signal loss of link
> > > synchronization
> > >* with an IRQ_HPD, so force a link status
> > > check.
> > 
> > ___
> > 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 5/5] drm/i915/dp: Move hdcp link check function into short pulse handler

[Pandiyan, Dhinakaran]

On Wed, 2018-09-19 at 20:30 +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:20:09AM -0700, Dhinakaran Pandiyan wrote:
> > This way all short pulse handlers except MST are in one place.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 123c2eafafab..03d2c6426016 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4501,6 +4501,9 @@ intel_dp_short_pulse(struct intel_dp
> > *intel_dp)
> > drm_kms_helper_hotplug_event(_priv->drm);
> > }
> >  
> > +   /* Short pulse can signify loss of hdcp authentication */
> > +   intel_hdcp_check_link(intel_dp->attached_connector);
> > +
> > return true;
> >  }
> >  
> > @@ -5634,9 +5637,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> >  
> > handled = intel_dp_short_pulse(intel_dp);
> >  
> > -   /* Short pulse can signify loss of hdcp
> > authentication */
> > -   intel_hdcp_check_link(intel_dp-
> > >attached_connector);
> > -
> 
> This changes the behaviour to skip intel_hdcp_check_link() when
> intel_dp_short_pulse() decides to fall back to full detect. Not sure
> if
> that's OK or not.

I'm thinking we should move the decision to fallback to the very end of
intel_dp_short_pulse(). 

The benefit we get is to disable PSR if the sink complained of PSR
errors and then check if the hardware retrained the link correctly
after we disabled.


> 
> > if (!handled)
> > goto put_power;
> > }
> > -- 
> > 2.14.1
> > 
> > ___
> > 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 3/5] drm/i915/dp: Remove intel_dp->detect_done flag

[Pandiyan, Dhinakaran]

On Wed, 2018-09-19 at 20:28 +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:20:07AM -0700, Dhinakaran Pandiyan wrote:
> > The intel_dp->detect_done flag is no more useful. Pull
> > intel_dp_long_pulse() into the lone caller,
> > 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 63 +---
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> >  2 files changed, 20 insertions(+), 44 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 8bf9afa5683c..d06bf4303814 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5012,13 +5012,25 @@ intel_dp_unset_edid(struct intel_dp
> > *intel_dp)
> >  }
> >  
> >  static int
> > -intel_dp_long_pulse(struct intel_connector *connector,
> > -   struct drm_modeset_acquire_ctx *ctx)
> > +intel_dp_detect(struct drm_connector *connector,
> > +   struct drm_modeset_acquire_ctx *ctx,
> > +   bool force)
> >  {
> > -   struct drm_i915_private *dev_priv = to_i915(connector-
> > >base.dev);
> > -   struct intel_dp *intel_dp = intel_attached_dp(
> > >base);
> > -   enum drm_connector_status status;
> > +   struct drm_i915_private *dev_priv = to_i915(connector-
> > >dev);
> > +   struct intel_dp *intel_dp = intel_attached_dp(connector);
> > +   int status;
> > u8 sink_irq_vector = 0;
> > +   struct drm_crtc *crtc;
> > +
> > +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > + connector->base.id, connector->name);
> > +
> > +   crtc = connector->state->crtc;
> > +   if (crtc) {
> > +   status = drm_modeset_lock(>mutex, ctx);
> 
> The 'status' name looks a bit weird here. I'm leaning towards keeping
> the 'int ret' for this case.
It does indeed, just wanted to reuse the local variable. Will change it
in the next version.

> 
> Hmm. Actually, why are we even taking this lock here anyway? I would
> imagine we only need it for the link retraining and 
> intel_dp_retrain_link() already grabs it so we should be able to
> just drop this code. Would allow page flips and detect to execute
> in parallel again.
> 
Looks like the code wasn't updated when intel_dp_retrain_link() started
grabbing the locks.

> > +   if (status)
> > +   return status;
> > +   }
> >  
> > WARN_ON(!drm_modeset_is_locked(_priv-
> > >drm.mode_config.connection_mutex));
> >  
> > @@ -5093,9 +5105,9 @@ intel_dp_long_pulse(struct intel_connector
> > *connector,
> > intel_dp->aux.i2c_defer_count = 0;
> >  
> > intel_dp_set_edid(intel_dp);
> > -   if (intel_dp_is_edp(intel_dp) || connector->detect_edid)
> > +   if (intel_dp_is_edp(intel_dp) ||
> > +   to_intel_connector(connector)->detect_edid)
> > status = connector_status_connected;
> > -   intel_dp->detect_done = true;
> >  
> > /* Try to read the source of the interrupt */
> > if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> > @@ -5120,37 +5132,6 @@ intel_dp_long_pulse(struct intel_connector
> > *connector,
> > return status;
> >  }
> >  
> > -static int
> > -intel_dp_detect(struct drm_connector *connector,
> > -   struct drm_modeset_acquire_ctx *ctx,
> > -   bool force)
> > -{
> > -   struct intel_dp *intel_dp = intel_attached_dp(connector);
> > -   int status = connector->status;
> > -
> > -   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > - connector->base.id, connector->name);
> > -
> > -   /* If full detect is not performed yet, do a full detect
> > */
> > -   if (!intel_dp->detect_done) {
> > -   struct drm_crtc *crtc;
> > -   int ret;
> > -
> > -   crtc = connector->state->crtc;
> > -   if (crtc) {
> > -   ret = drm_modeset_lock(>mutex, ctx);
> > -   if (ret)
> > -   return ret;
> > -   }
> > -
> > -   status = intel_dp_long_pulse(intel_dp-
> > >attached_connector, ctx);
> > -   }
> > -
> > -   intel_dp->detect_done = false;
> > -
> > -   return status;
> > -}
> > -
> >  static void
> >  intel_dp_force(struct drm_connector *connector)
> >  {
> > @@ -5643,7 +5624,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> >  
> > if (long_hpd) {
> > intel_dp->reset_link_params = true;
> > -   intel_dp->detect_done = false;
> > return IRQ_NONE;
> > }
> >  
> > @@ -5660,7 +5640,6 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > intel_dp->is_mst = false;
> > drm_dp_mst_topology_mgr_set_mst(_dp-
> > >mst_mgr,
> > intel_dp-
> > >is_mst);
> > -   intel_dp->detect_done = false;
> > goto put_power;
> > }
> > }
> > @@ -5673,10 +5652,8 @@ intel_dp_hpd_pulse(struct 

Re: [Intel-gfx] [PATCH 1/5] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()

[Pandiyan, Dhinakaran]

On Tue, 2018-09-18 at 08:51 -0700, Rodrigo Vivi wrote:
> On Tue, Sep 18, 2018 at 12:20:05AM -0700, Dhinakaran Pandiyan wrote:
> > Comment claims link needs to be retrained because the connected
> > sink raised
> > a long pulse to indicate link loss. If the sink did so,
> > intel_dp_hotplug() would have handled link retraining. Looking at
> > the
> > logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-
> > apply
> > Perform link quality check, unconditionally during long pulse"")',
> > the
> > issue is that the sink does not trigger an interrupt. We want the
> > ->detect() from user space to check link status and retrain.
> > Ville's
> > review for the original patch also indicates the same root cause.
> > 
> > I have also renamed long_pulse() to full_detect().
> 
> have you?!
> I just see the comment change on this patch ;)
> 
> 
> > v2: Patch split and rewrote comment..
I split the renaming part. I'll rewrite the commit message if you want
me to.



> > 
> > Cc: Lyude Paul 
> > Cc: Ville Syrjälä 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Cc: Jan-Marek Glogowski 
> > References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality
> > check, unconditionally during long pulse"")
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 12 ++--
> >  1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 436c22de33b6..cac1c7c6cbfd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5074,16 +5074,8 @@ intel_dp_long_pulse(struct intel_connector
> > *connector,
> > goto out;
> > } else {
> > /*
> > -* If display is now connected check links status,
> > -* there has been known issues of link loss
> > triggering
> > -* long pulse.
> > -*
> > -* Some sinks (eg. ASUS PB287Q) seem to perform
> > some
> > -* weird HPD ping pong during modesets. So we can
> > apparently
> > -* end up with HPD going low during a modeset, and
> > then
> > -* going back up soon after. And once that happens
> > we must
> > -* retrain the link to get a picture. That's in
> > case no
> > -* userspace component reacted to intermittent HPD
> > dip.
> > +* Some monitors do not signal loss of link
> > synchronization
> > +* with an IRQ_HPD, so force a link status check.
> >  */
> > struct intel_encoder *encoder =
> > _to_dig_port(intel_dp)->base;
> >  
> > -- 
> > 2.14.1
> > 
> > ___
> > 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] drm/i915: Be defensive and don't assume PSR has any commit to sync against

[Pandiyan, Dhinakaran]

On Wed, 2018-09-05 at 12:51 +0200, Maarten Lankhorst wrote:
> Op 05-09-18 om 12:22 schreef Ville Syrjälä:
> > On Tue, Sep 04, 2018 at 08:54:03PM +, Pandiyan, Dhinakaran
> > wrote:
> > > On Tue, 2018-09-04 at 19:12 +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-09-04 19:06:29)
> > > > > On Tue, Sep 04, 2018 at 08:59:32PM +0300, Ville Syrjälä
> > > > > wrote:
> > > > > > On Tue, Sep 04, 2018 at 06:44:14PM +0100, Chris Wilson
> > > > > > wrote:
> > > > > > > Quoting Ville Syrjälä (2018-09-04 18:39:53)
> > > > > > > > On Tue, Sep 04, 2018 at 05:29:02PM +0100, Chris Wilson
> > > > > > > > wrote:
> > > > > > > > > If the previous modeset commit has completed and is
> > > > > > > > > no
> > > > > > > > > longer part of
> > > > > > > > > the crtc state, skip waiting for it.
> > > > > > > > > 
> > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?i
> > > > > > > > > d=1077
> > > > > > > > > 92
> > > > > > > > > Fixes: c44301fce614 ("drm/i915: Allow control of PSR
> > > > > > > > > at
> > > > > > > > > runtime through debugfs, v6")
> > > > > > > > > Signed-off-by: Chris Wilson  > > > > > > > > >
> > > > > > > > > Cc: Maarten Lankhorst  > > > > > > > > com>
> > > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > > Cc: Dhinakaran Pandiyan  > > > > > > > > m>
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/i915/intel_psr.c | 16 ++--
> > > > > > > > > 
> > > > > > > > >  1 file changed, 10 insertions(+), 6 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > > > > index 21984d4c08ed..bddc9c7c681e 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > > > > @@ -834,6 +834,7 @@ int
> > > > > > > > > intel_psr_set_debugfs_mode(struct
> > > > > > > > > drm_i915_private *dev_priv,
> > > > > > > > >   struct drm_device *dev = _priv->drm;
> > > > > > > > >   struct drm_connector_state *conn_state;
> > > > > > > > >   struct intel_crtc_state *crtc_state = NULL;
> > > > > > > > > + struct drm_crtc_commit *commit = NULL;
> > > > > > > > >   struct drm_crtc *crtc;
> > > > > > > > >   struct intel_dp *dp;
> > > > > > > > >   int ret;
> > > > > > > > > @@ -860,12 +861,15 @@ int
> > > > > > > > > intel_psr_set_debugfs_mode(struct
> > > > > > > > > drm_i915_private *dev_priv,
> > > > > > > > >   return ret;
> > > > > > > > >  
> > > > > > > > >   crtc_state = to_intel_crtc_state(crtc-
> > > > > > > > > > state);
> > > > > > > > > 
> > > > > > > > > - ret =
> > > > > > > > > wait_for_completion_interruptible(_state-
> > > > > > > > > >base.commit-
> > > > > > > > > > hw_done);
> > > > > > > > > 
> > > > > > > > > - } else
> > > > > > > > > - ret =
> > > > > > > > > wait_for_completion_interruptible(_state-
> > > > > > > > > >commit-
> > > > > > > > > > hw_done);
> > > > > > > > > 
> > > > > > > > > -
> > > > > > > > > - if (ret)
> > > > > > > > > - return ret;
> > > > > > > > > + 

Re: [Intel-gfx] [PATCH] drm/i915: Be defensive and don't assume PSR has any commit to sync against

[Pandiyan, Dhinakaran]

On Tue, 2018-09-04 at 19:12 +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-09-04 19:06:29)
> > On Tue, Sep 04, 2018 at 08:59:32PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 04, 2018 at 06:44:14PM +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-09-04 18:39:53)
> > > > > On Tue, Sep 04, 2018 at 05:29:02PM +0100, Chris Wilson wrote:
> > > > > > If the previous modeset commit has completed and is no
> > > > > > longer part of
> > > > > > the crtc state, skip waiting for it.
> > > > > > 
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1077
> > > > > > 92
> > > > > > Fixes: c44301fce614 ("drm/i915: Allow control of PSR at
> > > > > > runtime through debugfs, v6")
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > Cc: Maarten Lankhorst 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Cc: Dhinakaran Pandiyan 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_psr.c | 16 ++--
> > > > > >  1 file changed, 10 insertions(+), 6 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > index 21984d4c08ed..bddc9c7c681e 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > > > @@ -834,6 +834,7 @@ int intel_psr_set_debugfs_mode(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > >   struct drm_device *dev = _priv->drm;
> > > > > >   struct drm_connector_state *conn_state;
> > > > > >   struct intel_crtc_state *crtc_state = NULL;
> > > > > > + struct drm_crtc_commit *commit = NULL;
> > > > > >   struct drm_crtc *crtc;
> > > > > >   struct intel_dp *dp;
> > > > > >   int ret;
> > > > > > @@ -860,12 +861,15 @@ int intel_psr_set_debugfs_mode(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > >   return ret;
> > > > > >  
> > > > > >   crtc_state = to_intel_crtc_state(crtc-
> > > > > > >state);
> > > > > > - ret =
> > > > > > wait_for_completion_interruptible(_state->base.commit-
> > > > > > >hw_done);
> > > > > > - } else
> > > > > > - ret =
> > > > > > wait_for_completion_interruptible(_state->commit-
> > > > > > >hw_done);
> > > > > > -
> > > > > > - if (ret)
> > > > > > - return ret;
> > > > > > + commit = crtc_state->base.commit;
> > > > > > + } else {
> > > > > > + commit = conn_state->commit;
> > > > > 
> > > > > I can't even find where we clear state->commit after its
> > > > > done.
> > > > > Do we just leave it pointing at freed memory or something?
> > > > > Also I
> > > > > can't figure out why drm_atomic_helper_commit_hw_done()
> > > > > copies
> > > > > the commit also to the old state.
> > > > 
> > > > Let me be the messenger then ;) commit is NULL at this point, I
> > > > just
> > > > presumed it was intentional.
> > > 
> > > My expectation would be that it gets cleared somewhere, but I
> > > simply
> > > can't find any such code.
> > 
> > Actually it looks like there is no such code. The event based
> > release_crtc_commit() thing gets its own reference so presumably
> > the
> > original reference stays with the state until the state itself gets
> > destroyed.
> 
> Happy with the it never had a commit theory, or is this a deeper
> problem
> that needs root causing?

Just so that I understand this correctly, even if there was a prior
commit, state->commit would have been freed when completion was
signaled. Is that right?


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Clean up skl_plane_has_planar()

[Pandiyan, Dhinakaran]

On Mon, 2018-08-27 at 14:56 +0300, Ville Syrjälä wrote:
> On Fri, Aug 24, 2018 at 01:38:55PM -0700, Dhinakaran Pandiyan wrote:
> > skl_plane_has_planar is hard to read, simplify the logic by
> > checking for
> > support in the order of platform, pipe and plane.
> 
> I had a slightly different version of this somewhere. But this one
> might
> be even better.
> 
> > 
> > No change in functionality intended.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 27 +---
> > ---
> >  1 file changed, 9 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 30fdfd1a3037..7e18bd8b21b8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13622,24 +13622,15 @@ static bool skl_plane_has_fbc(struct
> > drm_i915_private *dev_priv,
> >  bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
> >   enum pipe pipe, enum plane_id plane_id)
> >  {
> > -   if (plane_id == PLANE_PRIMARY) {
> > -   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> > -   return false;
> > -   else if ((INTEL_GEN(dev_priv) == 9 && pipe ==
> > PIPE_C) &&
> > -!IS_GEMINILAKE(dev_priv))
> > -   return false;
> > -   } else if (plane_id >= PLANE_SPRITE0) {
> > -   if (plane_id == PLANE_CURSOR)
> > -   return false;
> > -   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv)
> > == 10) {
> > -   if (plane_id != PLANE_SPRITE0)
> > -   return false;
> > -   } else {
> > -   if (plane_id != PLANE_SPRITE0 || pipe ==
> > PIPE_C ||
> > -   IS_SKYLAKE(dev_priv) ||
> > IS_BROXTON(dev_priv))
> > -   return false;
> > -   }
> > -   }
> > +   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> > +   return false;
> > +
> > +   if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)
> > && pipe == PIPE_C)
> > +   return false;
> > +
> > +   if (plane_id == PLANE_CURSOR || plane_id != PLANE_SPRITE0)
> > +   return false;
> 
> The cursor check is rather redundant here. IIRC I put it at the very
> start of the function to make it obvious that cursor never supports
> this. But we could just as well drop the check entirely.
> 
> This also disables NV12 for the primary plane which isn't correct.
That's a good catch, thanks.
Switch the condition to
if (plane_id != PLANE_PRIMARY && plane_id != PLANE_SPRITE0)

return false;
?

> 
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.17.1
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Clean up skl_plane_has_planar()

[Pandiyan, Dhinakaran]

On Fri, 2018-08-24 at 16:16 -0700, Rodrigo Vivi wrote:
> On Fri, Aug 24, 2018 at 10:27:09PM +0000, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > On Fri, 2018-08-24 at 15:15 -0700, Rodrigo Vivi wrote:
> > > On Fri, Aug 24, 2018 at 01:38:55PM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > skl_plane_has_planar is hard to read, simplify the logic by
> > > > checking for
> > > > support in the order of platform, pipe and plane.
> > > > 
> > > > No change in functionality intended.
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: Dhinakaran Pandiyan  > > > om>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 27 +---
> > > > 
> > > > ---
> > > >  1 file changed, 9 insertions(+), 18 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 30fdfd1a3037..7e18bd8b21b8 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -13622,24 +13622,15 @@ static bool skl_plane_has_fbc(struct
> > > > drm_i915_private *dev_priv,
> > > >  bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
> > > >   enum pipe pipe, enum plane_id
> > > > plane_id)
> > > >  {
> > > > -   if (plane_id == PLANE_PRIMARY) {
> > > > -   if (IS_SKYLAKE(dev_priv) ||
> > > > IS_BROXTON(dev_priv))
> > > > -   return false;
> > > > -   else if ((INTEL_GEN(dev_priv) == 9 && pipe ==
> > > > PIPE_C) &&
> > > > -!IS_GEMINILAKE(dev_priv))
> > > > -   return false;
> > > > -   } else if (plane_id >= PLANE_SPRITE0) {
> > > > -   if (plane_id == PLANE_CURSOR)
> > > > -   return false;
> > > > -   if (IS_GEMINILAKE(dev_priv) ||
> > > > INTEL_GEN(dev_priv)
> > > > == 10) {
> > > > -   if (plane_id != PLANE_SPRITE0)
> > > > -   return false;
> > > > -   } else {
> > > > -   if (plane_id != PLANE_SPRITE0 || pipe
> > > > ==
> > > > PIPE_C ||
> > > > -   IS_SKYLAKE(dev_priv) ||
> > > > IS_BROXTON(dev_priv))
> > > > -   return false;
> > 
> > ^ Here it does, or am I not seeing the paranthesis correctly.
> 
> dam... it is so bad that I got confused when drawing a
> table here...
> 
> nip: The name of the function seems wrong since "skl_" always
> return false
Looks like the first versions of the patch implementing nv12 did
include SKL, not clear what happened later.

> but I don't have a better suggestion ... maybe just "intel_"
> and can be in a follow up patch...
> 
> so,
> 
> Reviewed-by: Rodrigo Vivi 

Thanks!

-DK

> 
> > 
> > > > -   }
> > > > -   }
> > > > +   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> > > > +   return false;
> > > 
> > > The current code is indeed ugly, but I'm afraid it doesn't always
> > > return
> > > false for these platforms.
> > > 
> > > for instance plane_id = PLANE_SPRITE0
> > > 
> > > > +
> > > > +   if (INTEL_GEN(dev_priv) == 9 &&
> > > > !IS_GEMINILAKE(dev_priv)
> > > > && pipe == PIPE_C)
> > > > +   return false;
> > > > +
> > > > +   if (plane_id == PLANE_CURSOR || plane_id !=
> > > > PLANE_SPRITE0)
> > > > +   return false;
> > > > +
> > > > return true;
> > > >  }
> > > >  
> > > > -- 
> > > > 2.17.1
> > > > 
> > > > ___
> > > > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Clean up skl_plane_has_planar()

[Pandiyan, Dhinakaran]

On Fri, 2018-08-24 at 15:15 -0700, Rodrigo Vivi wrote:
> On Fri, Aug 24, 2018 at 01:38:55PM -0700, Dhinakaran Pandiyan wrote:
> > skl_plane_has_planar is hard to read, simplify the logic by
> > checking for
> > support in the order of platform, pipe and plane.
> > 
> > No change in functionality intended.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 27 +---
> > ---
> >  1 file changed, 9 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 30fdfd1a3037..7e18bd8b21b8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13622,24 +13622,15 @@ static bool skl_plane_has_fbc(struct
> > drm_i915_private *dev_priv,
> >  bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
> >   enum pipe pipe, enum plane_id plane_id)
> >  {
> > -   if (plane_id == PLANE_PRIMARY) {
> > -   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> > -   return false;
> > -   else if ((INTEL_GEN(dev_priv) == 9 && pipe ==
> > PIPE_C) &&
> > -!IS_GEMINILAKE(dev_priv))
> > -   return false;
> > -   } else if (plane_id >= PLANE_SPRITE0) {
> > -   if (plane_id == PLANE_CURSOR)
> > -   return false;
> > -   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv)
> > == 10) {
> > -   if (plane_id != PLANE_SPRITE0)
> > -   return false;
> > -   } else {
> > -   if (plane_id != PLANE_SPRITE0 || pipe ==
> > PIPE_C ||
> > -   IS_SKYLAKE(dev_priv) ||
> > IS_BROXTON(dev_priv))
> > -   return false;
^ Here it does, or am I not seeing the paranthesis correctly.

> > -   }
> > -   }
> > +   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> > +   return false;
> 
> The current code is indeed ugly, but I'm afraid it doesn't always
> return
> false for these platforms.
> 
> for instance plane_id = PLANE_SPRITE0
> 
> > +
> > +   if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)
> > && pipe == PIPE_C)
> > +   return false;
> > +
> > +   if (plane_id == PLANE_CURSOR || plane_id != PLANE_SPRITE0)
> > +   return false;
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.17.1
> > 
> > ___
> > 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] drm/i915: Show debugfs dpcd read failure directly

[Pandiyan, Dhinakaran]

On Mon, 2018-08-20 at 10:15 +0300, Jani Nikula wrote:
> On Fri, 20 Jul 2018, Rodrigo Vivi  wrote:
> > Instead of using a backchannel if some dpcd read failed we
> > can show that directly on debugfs output.
> > 
> > We are not returning an error because we might still want
> > to know if sub-sequent reads works, but we shouldn't
> > need to check 2 places to see why reg is not on the list.
> 
> Should we just nuke this debugfs and use the aux chardev interface to
> dpcd instead?

Given that this debugfs does not print decoded information, I think, it
offers very little benefit over direct reads. We also print some DPCD's
in dmesg, so I'm in favour of killing it. Don't see the file being used
in IGTs either.

Your comment also reminds about the IGT tool that Tarun started writing
for reading DPCD.

-DK


> 
> BR,
> Jani.
> 
> > 
> > Cc: Jani Nikula 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 59dc0610ea44..5d8da4e8c444 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4846,8 +4846,8 @@ static int i915_dpcd_show(struct seq_file *m,
> > void *data)
> >  
> > err = drm_dp_dpcd_read(_dp->aux, b->offset,
> > buf, size);
> > if (err <= 0) {
> > -   DRM_ERROR("dpcd read (%zu bytes at %u)
> > failed (%zd)\n",
> > - size, b->offset, err);
> > +   seq_printf(m, "dpcd read (%zu bytes at %u)
> > failed (%zd)\n",
> > +  size, b->offset, err);
> > continue;
> > }
> 
> 
___
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/psr: Remove wait_for_idle() for PSR2

[Pandiyan, Dhinakaran]

On Mon, 2018-08-13 at 11:17 -0700, Tarun Vyas wrote:
> On Mon, Aug 13, 2018 at 11:10:00AM -0700, Pandiyan, Dhinakaran wrote:
> > On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> > > On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > CI runs show PSR2 does not go to IDLE with selective update
> > > > enabled
> > > > on
> > > > all PSR exit triggers. Specifically, logs indicate the hardware
> > > > enters
> > > > "SLEEP Selective Update" and not "IDLE Reset state' like the
> > > > kernel
> > > > expects. This check was added for PSR1 but incorrectly extended
> > > > to
> > > > PSR2,
> > > > remove this check for PSR2 as there is a plan to test only PSR1
> > > > on
> > > > PSR2
> > > > panels.
> > > > 
> > > > Also add bspec reference to the comment about idle timeout.
> > > > 
> > > > Cc: Tarun Vyas 
> > > > Cc: José Roberto de Souza 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: Dhinakaran Pandiyan  > > > om>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_psr.c | 39 --
> > > > 
> > > > --
> > > >  1 file changed, 14 insertions(+), 25 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 5686ddaa6a72..09be9bfee2be 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -722,37 +722,26 @@ int intel_psr_wait_for_idle(const struct
> > > > intel_crtc_state *new_crtc_state,
> > > >  {
> > > > struct intel_crtc *crtc =
> > > > to_intel_crtc(new_crtc_state-
> > > > > base.crtc);
> > > > 
> > > > struct drm_i915_private *dev_priv = to_i915(crtc-
> > > > > base.dev);
> > > > 
> > > > -   i915_reg_t reg;
> > > > -   u32 mask;
> > > > -
> > > > -   if (!new_crtc_state->has_psr)
> > > > -   return 0;
> > > >  
> > > > /*
> > > > -* The sole user right now is
> > > > intel_pipe_update_start(),
> > > > -* which won't race with psr_enable/disable, which is
> > > > -* where psr2_enabled is written to. So, we don't need
> > > > -* to acquire the psr.lock. More importantly, we want
> > > > the
> > > > -* latency inside intel_pipe_update_start() to be as
> > > > low
> > > > -* as possible, so no need to acquire psr.lock when it
> > > > is
> > > > -* not needed and will induce latencies in the atomic
> > > > -* update path.
> > > > +* The sole user right now is
> > > > intel_pipe_update_start(),
> > > > which won't
> > > > +* race with psr_enable/disable where psr2_enabled is
> > > > written to. So, we
> > > > +* don't need to acquire the psr.lock. More
> > > > importantly,
> > > > we want the
> > > > +* latency inside intel_pipe_update_start() to be as
> > > > low
> > > > as possible, so
> > > > +* no need to acquire psr.lock when it is not needed
> > > > and
> > > > will induce
> > > > +* latencies in the atomic update path.
> > > >  */
> > > 
> > > I think we shouldn't change this format here to keep patch
> > > cleaner...
> > > if there is any change here I couldn't see because it is changing
> > > all
> > > lines and if there is no change I think it is better not to touch
> > > because
> > > it removes the focus of the real changes.
> > 
> > Okay.
> > > 
> > > > -   if (dev_priv->psr.psr2_enabled) {
> > > > -   reg = EDP_PSR2_STATUS;
> > > > -   mask = EDP_PSR2_STATUS_STATE_MASK;
> > > > -   } else {
> > > > -   reg = EDP_PSR_STATUS;
> > > > -   mask = EDP_PSR_STATUS_STATE_MASK;
> > > > -   }
> > > > +   if (!new_crtc_state->has_psr || READ_ONCE(dev_priv-
> > > > > psr.psr2_enabled))
> > > 
> > &g

Re: [Intel-gfx] [PATCH] drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit

[Pandiyan, Dhinakaran]

On Mon, 2018-08-13 at 09:47 -0700, Rodrigo Vivi wrote:
> On Mon, Aug 13, 2018 at 03:47:20PM +0200, Maarten Lankhorst wrote:
> > Op 11-08-18 om 02:50 schreef Dhinakaran Pandiyan:
> > > We print the last attempted entry and last exit timestamps only
> > > when
> > > IRQ debug is requested. This check was missed when new debug
> > > flags were
> > > added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
> > > runtime through debugfs, v6")
> > > 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Dhinakaran Pandiyan  > > >
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 26b7e5276b15..374b550d9a4f 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2735,7 +2735,7 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > >   psr_source_status(dev_priv, m);
> > >   mutex_unlock(_priv->psr.lock);
> > >  
> > > - if (READ_ONCE(dev_priv->psr.debug)) {
> > > + if (READ_ONCE(dev_priv->psr.debug) & I915_PSR_DEBUG_IRQ)
> > > {
> > >   seq_printf(m, "Last attempted entry at: %lld\n",
> > >  dev_priv->psr.last_entry_attempt);
> > >   seq_printf(m, "Last exit at: %lld\n",
> > 
> > Oops indeed.
> > 
> > Reviewed-by: Maarten Lankhorst 
> 
> before pushing to dinq please check the compilation there..
> kbuild bot raised an issue...
> 
> so apparently we will need a backmerge before pushing this...

The failures are on 

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.18-rc8 next-20180810]

Is a back-merge expected to fix that? and who does that back-merge?

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove wait_for_idle() for PSR2

[Pandiyan, Dhinakaran]

On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan wrote:
> > CI runs show PSR2 does not go to IDLE with selective update enabled
> > on
> > all PSR exit triggers. Specifically, logs indicate the hardware
> > enters
> > "SLEEP Selective Update" and not "IDLE Reset state' like the kernel
> > expects. This check was added for PSR1 but incorrectly extended to
> > PSR2,
> > remove this check for PSR2 as there is a plan to test only PSR1 on
> > PSR2
> > panels.
> > 
> > Also add bspec reference to the comment about idle timeout.
> > 
> > Cc: Tarun Vyas 
> > Cc: José Roberto de Souza 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 39 --
> > --
> >  1 file changed, 14 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 5686ddaa6a72..09be9bfee2be 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -722,37 +722,26 @@ int intel_psr_wait_for_idle(const struct
> > intel_crtc_state *new_crtc_state,
> >  {
> > struct intel_crtc *crtc = to_intel_crtc(new_crtc_state-
> > >base.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc-
> > >base.dev);
> > -   i915_reg_t reg;
> > -   u32 mask;
> > -
> > -   if (!new_crtc_state->has_psr)
> > -   return 0;
> >  
> > /*
> > -* The sole user right now is intel_pipe_update_start(),
> > -* which won't race with psr_enable/disable, which is
> > -* where psr2_enabled is written to. So, we don't need
> > -* to acquire the psr.lock. More importantly, we want the
> > -* latency inside intel_pipe_update_start() to be as low
> > -* as possible, so no need to acquire psr.lock when it is
> > -* not needed and will induce latencies in the atomic
> > -* update path.
> > +* The sole user right now is intel_pipe_update_start(),
> > which won't
> > +* race with psr_enable/disable where psr2_enabled is
> > written to. So, we
> > +* don't need to acquire the psr.lock. More importantly,
> > we want the
> > +* latency inside intel_pipe_update_start() to be as low
> > as possible, so
> > +* no need to acquire psr.lock when it is not needed and
> > will induce
> > +* latencies in the atomic update path.
> >  */
> 
> I think we shouldn't change this format here to keep patch cleaner...
> if there is any change here I couldn't see because it is changing all
> lines and if there is no change I think it is better not to touch
> because
> it removes the focus of the real changes.

Okay.
> 
> > -   if (dev_priv->psr.psr2_enabled) {
> > -   reg = EDP_PSR2_STATUS;
> > -   mask = EDP_PSR2_STATUS_STATE_MASK;
> > -   } else {
> > -   reg = EDP_PSR_STATUS;
> > -   mask = EDP_PSR_STATUS_STATE_MASK;
> > -   }
> > +   if (!new_crtc_state->has_psr || READ_ONCE(dev_priv-
> > >psr.psr2_enabled))
> 
> I now see that we are removing psr2 of the picture, but I don't see
> how we are
> improving psr2 situation here.
> what am I missing?
> 
When the patch was written, we did not have sufficient tests to tell us
the wait_for_idle condition was wrong for PSR2. It was not known
whether the wait was *necessary* for PSR2, think of this as a partial
revert. Now that CI has pointed out, (and I checked with a PSR2 panel)
that the condition is wrong, we should be removing it for PSR2. If you
think about it, it does improve PSR2 my removing irrelevant code.


> > +   return 0;
> >  
> > /*
> > -* Max time for PSR to idle = Inverse of the refresh rate
> > +
> > -* 6 ms of exit training time + 1.5 ms of aux channel
> > -* handshake. 50 msec is defesive enough to cover
> > everything.
> > +* From Bspec Panel Self Refresh (BDW+):
> 
> This is another case, if we didn't change the format only this line ^
> would be in the patch and it would be cleaner and easier to review
> the
> changes.
> 
> but my biggest concern with this patch is how do we check now
> wait_psr2 idle
> 
> > +* Max. time for PSR to idle = inverse of the refresh rate
> > + 6 ms of
> > +* exit training time + 1.5 ms of aux channel handshake.
> > 50 ms is
> > +* defensive enough to cover everything.
> >  */
> > -
> > -   return __intel_wait_for_register(dev_priv, reg, mask,
> > +   return __intel_wait_for_register(dev_priv, EDP_PSR_STATUS,
> > +EDP_PSR_STATUS_STATE_MASK
> > ,
> >  EDP_PSR_STATUS_STATE_IDLE
> > , 2, 50,
> >  out_value);
> >  }
> > -- 
> > 2.17.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms

[Pandiyan, Dhinakaran]

On Thu, 2018-06-14 at 11:59 +0530, Nagaraju, Vathsala wrote:
> 
> On 6/13/2018 11:10 PM, Dhinakaran Pandiyan wrote:
> > 
> > On Wed, 2018-06-13 at 10:32 -0700, Dhinakaran Pandiyan wrote:
> > > 
> > > On Wed, 2018-06-13 at 09:41 +0300, Jani Nikula wrote:
> > > > 
> > > > On Wed, 13 Jun 2018, "Nagaraju, Vathsala"  > > > tel.
> > > > co
> > > > m> wrote:
> > > > > 
> > > > > 
> > > > > On 6/12/2018 2:30 PM, Jani Nikula wrote:
> > > > > > 
> > > > > > 
> > > > > > On Tue, 12 Jun 2018, vathsala nagaraju  > > > > > ntel
> > > > > > .c
> > > > > > om> wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > From: Vathsala Nagaraju 
> > > > > > > 
> > > > > > > Adds new psrwake options defined in the below table.
> > > > > > > Platform  PSR wake options vbt version
> > > > > > > KBL/CFL/WHL   All
> > > > > > > SKL   All PV releases (Check for 203+ might
> > > > > > > help
> > > > > > > but cannot be foolproof)
> > > > > > > BXT   Uses old interpretation.
> > > > > > > CNL/ICL+  All
> > > > > > > GLK   All
> > > > > > > 
> > > > > > > For SKL, we will continue to use older interpretation for
> > > > > > > the
> > > > > > > above reason.
> > > > > > > 
> > > > > > > Cc: Jani Nikula 
> > > > > > > Cc: Rodrigo Vivi 
> > > > > > > Cc: Puthikorn Voravootivat 
> > > > > > > Cc: Dhinakaran Pandiyan 
> > > > > > > 
> > > > > > > Signed-off-by: Vathsala Nagaraju  > > > > > > .com
> > > > > > > ---
> > > > > > >    drivers/gpu/drm/i915/intel_bios.c | 3 ++-
> > > > > > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > > > > > b/drivers/gpu/drm/i915/intel_bios.c
> > > > > > > index 465dff4..010ff68 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > > > > > @@ -710,7 +710,8 @@ static int
> > > > > > > intel_bios_ssc_frequency(struct
> > > > > > > drm_i915_private *dev_priv,
> > > > > > >        * New psr options 0=500us, 1=100us, 2=2500us,
> > > > > > > 3=0us
> > > > > > >        * Old decimal value is wake up time in
> > > > > > > multiples
> > > > > > > of
> > > > > > > 100 us.
> > > > > > >        */
> > > > > > > - if (bdb->version >= 209 && IS_GEN9_BC(dev_priv))
> > > > > > > {
> > > > > > > + if ((INTEL_GEN(dev_priv) >= 10) ||
> > > > > > > + (IS_GEN9_BC(dev_priv) &&
> > > > > > > !IS_SKYLAKE(dev_priv)))
> > > > > > > {
> > > > > > Please keep the version check.
> > > > > Sure. For SKL , shall we use older interpretation for all bdb
> > > > > version as
> > > > > vbt team cannot confirm bdb version for SKL?
> > > > I guess.
> > > > 
> > > Why not change the version check to >= 203, if that's what PV
> > > releases
> > > had as per your commit message? With the current code, Linux and
> > > Windows set 500 us and 2.5 ms respectively on my laptop.
> > Said laptop is a SKL with bdb version 205.
> + ashutosh(VBT team)
> Since VBT team cannot confirm version for SKL ,so skipped for
> skylake.
> I did a copy paste of the table provided by vbt team, will edit for
> skylake.
> 
We are not going to get this right for all combinations, the best we
can do is make sure things work in most cases. I prefer to err on the
side of using the new mapping because when translated incorrectly, 3
out of 4 values lead to >= intended training time. Given the fact that
SKL PV releases also used the new mapping, I suggest you do this

if ((bdb->version >= 203 && IS_GEN9_BC(dev_priv)) ||
IS_GEMINILAKE(dev_priv) ||  INTEL_GEN(dev_priv) >= 10) {
/* new mapping */

}

I don't know what the basis for the current check for version 209 is,
other than it was the version on the KBL you tested.

-DK





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

Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/dp: Move code to check if aux ch is busy to a function

[Pandiyan, Dhinakaran]

On Mon, 2018-04-30 at 23:39 +, Souza, Jose wrote:
> On Thu, 2018-04-26 at 15:51 -0700, Dhinakaran Pandiyan wrote:
> > 
> > 
> > 
> > On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> > > 
> > > This reduces the spaghetti that intel_dp_aux_xfer().
> > > 
> > > Moved doing less changes possible here, improvements to the new
> > > function in further patch.
> > > 
> > > Signed-off-by: José Roberto de Souza 
> > > Cc: Dhinakaran Pandiyan 
> > > ---
> > > 
> > > New patch in this series.
> > > 
> > >  drivers/gpu/drm/i915/intel_dp.c | 52 +--
> > > --
> > >  1 file changed, 34 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 701963a192ee..a11465c62950 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1062,6 +1062,38 @@ static uint32_t
> > > skl_get_aux_send_ctl(struct
> > > intel_dp *intel_dp,
> > >      DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> > >  }
> > >  
> > > +static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_i915_private *dev_priv =
> > > + to_i915(intel_dig_port->base.base.dev);
> > > + i915_reg_t ch_ctl;
> > > + uint32_t status;
> > > + int try;
> > > +
> > > + ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > +
> > > + for (try = 0; try < 3; try++) {
> > > + status = I915_READ_NOTRACE(ch_ctl);
> > > + if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > + break;
> > Did you mean to return false here?
> Oh thanks, I just fixed this in the next patch.
> 
> > 
> > 
> > Anyway, this code here looks very similar to
> > intel_dp_aux_wait_done().
> > Might be worth checking if it can be reused.
> I'm not sure that hardware will send a interruption when it finish a
> aux ch transaction that started by it self, that is why I'm going
> safe
> here and just keep what is working for now.

I should have clarified I meant intel_dp_aux_wait_done(intel_dp,
false).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: enable psr1 on psr2 panels

[Pandiyan, Dhinakaran]

On Wed, 2018-04-11 at 07:40 -0700, Rodrigo Vivi wrote:
> On Wed, Apr 11, 2018 at 03:01:24PM +0530, vathsala nagaraju wrote:
> > 
> > + puthik
> > On Saturday 07 April 2018 12:36 AM, Vivi, Rodrigo wrote:
> > > On Fri, Apr 06, 2018 at 12:10:24PM -0700, Dhinakaran Pandiyan wrote:
> > > > 
> > > > 
> > > > On Sat, 2018-04-07 at 00:12 +0530, vathsala nagaraju wrote:
> > > > > From: Vathsala Nagaraju 
> > > > > 
> > > > > Adds force_psr1 mod parameter to enable psr1 on psr2 panels.
> > > > > useful in cases where psr2 fails and user wants to enable
> > > > > psr1 feature for power saving until a fix
> > > > > is provided for psr2.
> > > The parameters shouldn't be used by users to select a configuration.
> > > They are marked as unsafe. We should only enable the feature when
> > > we are comfortable it doesn't cause trouble.
> > 
> > The idea was to give user the option to switch to psr1 ,if they want to.
> 
> This is exactly the problem that I'm trying to avoid ;)
> 
> But I do understand your perspective since I had the same, at least
> until when Jani showed me an old but gold note from ajax:
> https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
> 
> If we did not validated we shouldn't be allowing the choice.
> 
> Although I'm still in favor of the parameters here because it makes
> our lives easier when developing and debugging. But user should never
> be using those.
> 
> Specially on a feature full of corner cases like PSR. So, while
> we don't really fix all the known bad PSR bugs we should keep it disabled.
> 
> 
> > 
> > > 
> > > > 
> > > > We should perhaps make enable_psr=1 enable just PSR1. I am not
> > > > comfortable that we enable PSR2 at all, there are no tests in IGT for
> > > > selective update, seems like nobody really knows exactly how well it
> > > > works.
> > with enable_psr , we are deciding whether to use psr1/psr2.
> > we can reuse enable_psr.
> > 
> 
> While we are not confident PSR2 ever worked we should not be using that
> at all. So if you want any change like this I would suggest to avoid PSR2
> at all for everybody while we don't fix PSR2.
> 
> But when PSR and PSR2 gets enabled we keep the parameter to allow debug
> and triage... i.e enable_psr=0 disables PSR, enable_psr=1 enables what ever
> PSR is the default for that panel/platform.
> 


Vathsala,

Please make i915.enable_psr=1 to enable only PSR1 at this point. Until
we add new IGT's to test for selective update, PSR2 will not receive
regular testing and as such is not worthy of enabling even with a module
parameter.




> Thanks,
> Rodrigo.
> 
> > > Agreed. Probably good for now to avoid PSR2 in all situations and only
> > > allow PSR2 when we are properly testing it.
> > > 
> > > > 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: José Roberto de Souza 
> > > > > Signed-off-by: Vathsala Nagaraju 
> > > > > ---
> > > > >   drivers/gpu/drm/i915/i915_params.c | 5 +
> > > > >   drivers/gpu/drm/i915/i915_params.h | 1 +
> > > > >   drivers/gpu/drm/i915/intel_psr.c   | 2 ++
> > > > >   3 files changed, 8 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > > > > b/drivers/gpu/drm/i915/i915_params.c
> > > > > index 08108ce..5b6f5af 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_params.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_params.c
> > > > > @@ -95,6 +95,11 @@ struct i915_params i915_modparams __read_mostly = {
> > > > >  "(0=disabled, 1=enabled - link mode chosen per-platform, 2=force 
> > > > > link-standby mode, 3=force link-off mode) "
> > > > >  "Default: -1 (use per-chip default)");
> > > > > 
> > > > > +i915_param_named_unsafe(force_psr1, int, 0600,
> > > > > +   "Enable PSR1 on PSR2 Panel "
> > > > > +   "(0=disabled, 1=enabled) "
> > > > > +   "Default: -1 (use per-chip default)");
> > > > > +
> > > > >   i915_param_named_unsafe(alpha_support, bool, 0400,
> > > > >  "Enable alpha quality driver support for latest hardware. "
> > > > >  "See also CONFIG_DRM_I915_ALPHA_SUPPORT.");
> > > > > diff --git a/drivers/gpu/drm/i915/i915_params.h 
> > > > > b/drivers/gpu/drm/i915/i915_params.h
> > > > > index c963603..1f5dd1c 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_params.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_params.h
> > > > > @@ -44,6 +44,7 @@
> > > > >  param(int, enable_fbc, -1) \
> > > > >  param(int, enable_ppgtt, -1) \
> > > > >  param(int, enable_psr, -1) \
> > > > > +   param(int, force_psr1, -1) \
> > > > >  param(int, disable_power_well, -1) \
> > > > >  param(int, enable_ips, 1) \
> > > > >  param(int, invert_brightness, 0) \
> > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > index 2d53f73..415e377 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > +++ 

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

[Pandiyan, Dhinakaran]

On Thu, 2018-04-05 at 17:19 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> Changes since v2:
> - Only send DPMS off when we're disabling the last sink, and only send
>   DPMS on when we're enabling the first sink - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 +++-
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);



I believe Ville recommended to check for
is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)
here. The question is, are there cases where 
intel_dp->is_mst != is_mst? A disconnect in the middle of a modeset
would cause intel_dp->is_mst to be false, wouldn't it?






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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Enable edp psr error interrupts on bdw+

[Pandiyan, Dhinakaran]

On Thu, 2018-04-05 at 20:38 +, Souza, Jose wrote:
> On Tue, 2018-04-03 at 14:24 -0700, Dhinakaran Pandiyan wrote:
> > From: Ville Syrjälä 
> > 
> > Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr
> > on
> > any transcoder in theory, though the we don't currenty enable PSR
> > except
> > on the EDP transcoder.
> > 
> > v2: From DK
> >  * Rebased on drm-tip
> > v3: Switched author to Ville based on IRC discussion.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> 
> Reviewed-by: Jose Roberto de Souza 
> 
> > Signed-off-by: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c  | 57
> > 
> >  drivers/gpu/drm/i915/i915_reg.h  |  7 +++--
> >  drivers/gpu/drm/i915/intel_display.h |  4 +++
> >  3 files changed, 52 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index c2d3f30778ee..8a894adf2ca1 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2394,20 +2394,34 @@ static void ilk_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> >  static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > *dev_priv)
> 
> nitpick: Like I said in the other patch I would like to have this
> function renamed here.


To intel_psr_irq_handler? I renamed it in patch 3 because the function
was moved out of the file. I would like to leave this patch as it is, as
the original author intended.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

[Pandiyan, Dhinakaran]

On Thu, 2018-04-05 at 16:36 -0400, Lyude Paul wrote:
> When doing a modeset where the sink is transitioning from D3 to D0 , it
> would sometimes be possible for the initial power_up_phy() to start
> timing out. This would only be observed in the last action before the
> sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
> originally thought this might be an issue with us accidentally shutting
> off the aux block when putting the sink into D3, but since the DP spec
> mandates that sinks must wake up within 1ms while we have 100ms to
> respond to an ESI irq, this didn't really add up. Turns out that the
> problem is more subtle then that:
> 
> It turns out that the timeout is from us not enabling DPMS on the MST
> hub before actually trying to initiate sideband communications. This
> would cause the first sideband communication (power_up_phy()), to start
> timing out because the sink wasn't ready to respond. Afterwards, we
> would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
> intel_ddi_pre_enable_dp(), which would actually result in waking up the
> sink so that sideband requests would work again.
> 
> Since DPMS is what lets us actually bring the hub up into a state where
> sideband communications become functional again, we just need to make
> sure to enable DPMS on the display before attempting to perform sideband
> communications.
> 
> Changes since v1:
> - Remove comment above if (!intel_dp->is_mst) - vsryjala
> - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
>   keep enable/disable paths symmetrical
> - Improve commit message - dhnkrn
> 
> Signed-off-by: Lyude Paul 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: Laura Abbott 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
> This email should hopefully actually be picked up by patchwork this
> time, hooray!
> 
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6672a9abd85..c0bf7419e1c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> @@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct 
> intel_encoder *encoder,
>* Power down sink before disabling the port, otherwise we end
>* up getting interrupts from the sink on detecting link loss.
>*/
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (!intel_dp->is_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  
>   intel_disable_ddi_buf(encoder);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c3de0918ee13..2493bd1e0e59 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>*/
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port,
>false);
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);

Needed only when _links goes from 1 -> 0
>  
>   intel_dp->active_mst_links--;
>  
> @@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>  
>   DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
>  
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
Needed only when _links goes from 0 -> 1
>   drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
>   if (intel_dp->active_mst_links == 0)
>   intel_dig_port->base.pre_enable(_dig_port->base,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix audio issue on BXT

[Pandiyan, Dhinakaran]

On Thu, 2018-04-05 at 22:12 +0530, Gaurav K Singh wrote:
> On Apollolake, with stress test warm reboot, audio card
> was not getting enumerated after reboot. This was a
> spurious issue happening on Apollolake. HW codec and
> HD audio controller link was going out of sync for which
> there was a fix in i915 driver but was not getting invoked
> for BXT. Extending this fix to BXT as well.
> 
> Tested on apollolake chromebook by stress test warm reboot
> with 2500 iterations.
> 
> Bspec: 21829
> 

R-B stands.

Btw, it would be easier to spot this patch and pick this up for merging
if you did not send this as a reply. I guess that's okay this time?
Also, a minor nitpick, "drm/i915/audio" would have been a more
appropriate prefix for the patch subject.



> Signed-off-by: Gaurav K Singh 
> Reviewed-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 709d6ca68074..656f6c931341 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -729,7 +729,7 @@ static void 
> i915_audio_component_codec_wake_override(struct device *kdev,
>   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
>   u32 tmp;
>  
> - if (!IS_GEN9_BC(dev_priv))
> + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
>   return;
>  
>   i915_audio_component_get_power(kdev);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-04-04 at 00:54 +, Souza, Jose wrote:
> On Tue, 2018-04-03 at 14:24 -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for
> > debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > There are no locks to serialize PSR debug enabling from
> > irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
> > called only during module initialization/resume and IGT subtests
> > aren't expected to modify PSR debug at those times, we should be
> > safe.
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > v3: Unmask interrupts in postinstall() if debug was still enabled.
> > Avoid RMW (Ville)
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 57 +++--
> > --
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 60
> > +
> >  5 files changed, 116 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1dba2c451255..28f91df5b401 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file
> > *m, void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   DRM_DEBUG_KMS("PSR debug %s\n", enableddisabled(val));
> > +
> > +   intel_runtime_pm_get(dev_priv);
> > +   intel_psr_debug_control(dev_priv, !!val);
> > +   intel_runtime_pm_put(dev_priv);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get,
> > i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -4812,7 +4845,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> 
> 
> same as bellow, why not i915_edp_psr_int_debug?
> 
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5373b171bb96..b97ed0cd4ca9 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -609,6 +609,7 @@ struct i915_psr {
> > bool has_hw_tracking;
> > bool psr2_enabled;
> > u8 sink_sync_latency;
> > +   bool debug;
> 
> maybe change to a name that gives more information about the use of
> this flag? like int_debug?
> 

Enabling interrupts is one part of enabling PSR debug, that is how I
think of it. We'll probably use the same control to enable other debug
mechanisms as well. At the least to update timestamps from psr_activate
and psr_exit for VLV/CHV.


> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a894adf2ca1..714570955196 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   

Re: [Intel-gfx] [stable:v4.15] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

[Pandiyan, Dhinakaran]

On Tue, 2018-04-03 at 19:40 +0200, Greg KH wrote:
> On Tue, Apr 03, 2018 at 10:27:16AM +0300, Jani Nikula wrote:
> > 
> > DK, please start stable backport commit messages with:
> > 
> > commit b1e314462bba76660eec62760bb2e87f28f58866 upstream.
Got it, I'll do that next time onwards since Greg took care of this
patch. Thanks!


> 
> Thank you for that, it helped me figure this out...
> 
> greg k-h

Thanks for fixing up the commit message.

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

Re: [Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

[Pandiyan, Dhinakaran]

On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote:
> There's no reason to track the atomic state three times. Unfortunately,
> this is currently what we're doing, and even worse is that there is only
> one actually correct state pointer: the one in mst_state->base.state.
> mgr->state never seems to be used, along with the one in
> mst_state->state.
> 

Looks like the redundancy got introduced when struct drm_private_state
was added.

Reviewed-by: Dhinakaran Pandiyan 

> This confused me for over 4 hours until I realized there was no magic
> behind these pointers. So, let's save everyone else from the trouble.
> 
> Signed-off-by: Lyude Paul .
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Lyude Paul 
> ---
>  include/drm/drm_dp_mst_helper.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 41a8f08da05d..035963fbcd9d 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -409,7 +409,6 @@ struct drm_dp_payload {
>  struct drm_dp_mst_topology_state {
>   struct drm_private_state base;
>   int avail_slots;
> - struct drm_atomic_state *state;
>   struct drm_dp_mst_topology_mgr *mgr;
>  };
>  
> @@ -497,11 +496,6 @@ struct drm_dp_mst_topology_mgr {
>*/
>   int pbn_div;
>  
> - /**
> -  * @state: State information for topology manager
> -  */
> - struct drm_dp_mst_topology_state *state;
> -
>   /**
>* @funcs: Atomic helper callbacks
>*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

[Pandiyan, Dhinakaran]

On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
> 
> Reviewed-by: Dhinakaran Pandiyan 


Please don't merge this patch yet. While the patch itself is correct,
testing it brings up an interesting problem.

Printing the sink_status() leads to power_get(aux_domain) which wakes up
the display engine from DC5/6. This results in a HW triggered PSR exit,
effectively altering the state that we are trying to read. I would like
to understand the problem fully before merging the patch.


> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1dba2c451255..c9ac946b62c9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
>   return "unknown";
>  }
>  
> +static const char *psr_sink_status(u8 val)
> +{
> + static const char * const sink_status[] = {
> + "inactive",
> + "transition to active, capture and display",
> + "active, display from RFB",
> + "active, capture and display on sink device timings",
> + "transition to inactive, capture and display, timing re-sync",
> + "reserved",
> + "reserved",
> + "sink internal error"
> + };
> +
> + val &= DP_PSR_SINK_STATE_MASK;
> + if (val < ARRAY_SIZE(sink_status))
> + return sink_status[val];
> +
> + return "unknown";
> +}
> +
>  static int i915_edp_psr_status(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
>  psr2, psr2_live_status(psr2));
>   }
> +
> + if (dev_priv->psr.enabled) {
> + struct drm_dp_aux *aux = _priv->psr.enabled->aux;
> + u8 val;
> +
> + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
> + seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
> +psr_sink_status(val));
> + }
>   mutex_unlock(_priv->psr.lock);
>  
>   intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

[Pandiyan, Dhinakaran]

On Mon, 2018-04-02 at 17:21 -0400, Lyude Paul wrote:
> While enabling/disabling DPMS before link training with MST hubs is
> perfectly valid; unfortunately disabling DPMS results in some devices
> disabling their AUX CH block as well. For SST this isn't as much of a
> problem, but for MST we need to be able to continue handling aux
> transactions even when none of the sinks are turned on since it's
> possible for us to have a single atomic commit which results in
> disabling each downstream sink, followed by subsequently re-enabling
> each sink.
> 
> If we don't do this, we'll end up stalling any pending ESI interrupts
> from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> timespan makes it so that link fallback retraining for MST (which I will
> be submitting to the ML shortly) fails due to the channel EQ failure
> interrupts potentially getting dropped. Additionally, when performing a
> modeset that brings the hub status's link status from bad -> good having
> ESIs disabled for that long causes us to miss the hub's response to us
> trying to start link training as well.
> 
> Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> us the hassle of trying to wait until the sink comes back up and just
> never shut the aux block down.
> 
> Signed-off-by: Lyude Paul 
> Cc: Laura Abbott 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")

We've come a full circle on this one :)

1) Originally, we had disable_ddi() setting the branch power state to
D3.
2) Then "Use MST sideband message transactions for dpms control" removed
that as a bug fix for some devices. The sideband solution was chosen
over the D3_AUX_ON approach this patch takes.
3) Next, "Write to SET_POWER dpcd to enable MST hub" effectively took us
back to the original state due to a regression.
4) Now, we are calling (3) a regression and implementing D3_AUX_ON.


I guess, this combination should work for most devices. But, we should
test this on a few different MST hubs before going ahead.

-DK


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..0479c377981b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, 
> int mode)
>   return;
>  
>   if (mode != DRM_MODE_DPMS_ON) {
> + unsigned char data = intel_dp->is_mst ?
> + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> +
>   if (downstream_hpd_needs_d0(intel_dp))
>   return;
>  
> - ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> -  DP_SET_POWER_D3);
> + ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

[Pandiyan, Dhinakaran]

On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> > recommended.
> > So exiting PSR/PSR2 and waiting the transition to inactive to prevent
> > any concurrent access between hardware and software in aux ch
> > registers.

Wouldn't the debugfs interface that you added to read sink PSR status
always show PSR as disabled? Or do you intend to set
intel_dp->exit_psr_on_aux_ch_xfer = true? 


> > 
> > VLV and CHV hardware don't do any aux as software is responsible to
> > do all the buffer tracking and it sends the wake up aux ch message
> > to sink.
> >
> 
> ahh cool... I get back what I said on some previous patch.
> I like where it is going, but...
> 
> > BSpec: 7530, 799 and 7532
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c |  8 
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..fedee4e7ed24 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> > *intel_dp,
> >DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> >  }
> >  
> > +/**
> > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > + *
> > + * By exiting or disabling any hardware feature that can also use the aux 
> > ch
> > + * registers at the same time as driver, this function will give total 
> > control
> > + * of aux ch registers to driver.
> > + */
> > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_get(intel_dp);
> > +   intel_psr_exit(intel_dp, true);
> 
> decision on exit and activate should be inside the block_get and block_put,
> based on current state of the counters.
> 
> > +}
> > +
> > +/**
> > + * intel_dp_aux_ch_put - Release aux ch registers control
> > + *
> > + * It is the intel_dp_aux_ch_get() counterpart.
> > + */
> > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_put(intel_dp);
> > +   /* Usually more than just one aux ch transaction is executed when
> > +* handling some event, activating PSR right way would cause several
> > +* msecs of delay waiting PSR to exit for each aux ch transaction, so
> > +* here asking it to be scheduled.
> > +*/
> > +   intel_psr_activate(intel_dp, true);
> > +}
> > +
> >  static int
> >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >   const uint8_t *send, int send_bytes,
> > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   intel_dp_aux_ch_get(intel_dp);
> > +
> > /* Try to wait for any previous AUX channel activity */
> > for (try = 0; try < 3; try++) {
> > status = I915_READ_NOTRACE(ch_ctl);
> > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > ret = recv_bytes;
> >  out:
> > +   intel_dp_aux_ch_put(intel_dp);
> > pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > if (vdd)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 020b96324135..177478f0b032 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1139,6 +1139,8 @@ struct intel_dp {
> >  
> > /* Displayport compliance testing */
> > struct intel_dp_compliance compliance;
> > +
> > +   bool exit_psr_on_aux_ch_xfer;
> >  };
> >  
> >  struct intel_lspcon {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8702dbafb42d..f88f12246a23 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >   
> > msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> > }
> >  
> > +   /* From all platforms that supports PSR/PSR2 this 2 is the ones that
> > +* don't have restrictions about use of the aux ch while PSR/PSR2 is
> > +* enabled.
> > +*/
> > +   if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > +   intel_dp->exit_psr_on_aux_ch_xfer = 

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

[Pandiyan, Dhinakaran]

On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote:
> > When PSR/PSR2 is enabled hardware can do aux ch transactions by it
> > self.
> > Spec requires that PSR is inactive before do any aux ch transaction
> > in HSW and BDW, for skl+ there is a aux ch mutex but the use is not
> > recommended.
> > So exiting PSR/PSR2 and waiting the transition to inactive to prevent
> > any concurrent access between hardware and software in aux ch
> > registers.
> > 
> > VLV and CHV hardware don't do any aux as software is responsible to
> > do all the buffer tracking and it sends the wake up aux ch message
> > to sink.
> >
> 
> ahh cool... I get back what I said on some previous patch.
> I like where it is going, but...
> 
> > BSpec: 7530, 799 and 7532
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c |  8 
> >  3 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..fedee4e7ed24 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1062,6 +1062,41 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> > *intel_dp,
> >DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> >  }
> >  
> > +/**
> > + * intel_dp_aux_ch_get - Get total control of aux ch registers
> > + *
> > + * By exiting or disabling any hardware feature that can also use the aux 
> > ch
> > + * registers at the same time as driver, this function will give total 
> > control
> > + * of aux ch registers to driver.
> > + */
> > +static void intel_dp_aux_ch_get(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_get(intel_dp);
> > +   intel_psr_exit(intel_dp, true);
> 
> decision on exit and activate should be inside the block_get and block_put,
> based on current state of the counters.
> 

I haven't read the patches yet, but you could use the kref infrastructure for 
reference counting.

> > +}
> > +
> > +/**
> > + * intel_dp_aux_ch_put - Release aux ch registers control
> > + *
> > + * It is the intel_dp_aux_ch_get() counterpart.
> > + */
> > +static void intel_dp_aux_ch_put(struct intel_dp *intel_dp)
> > +{
> > +   if (!intel_dp->exit_psr_on_aux_ch_xfer)
> > +   return;
> > +
> > +   intel_psr_activate_block_put(intel_dp);
> > +   /* Usually more than just one aux ch transaction is executed when
> > +* handling some event, activating PSR right way would cause several
> > +* msecs of delay waiting PSR to exit for each aux ch transaction, so
> > +* here asking it to be scheduled.
> > +*/
> > +   intel_psr_activate(intel_dp, true);
> > +}
> > +
> >  static int
> >  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >   const uint8_t *send, int send_bytes,
> > @@ -1101,6 +1136,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   intel_dp_aux_ch_get(intel_dp);
> > +
> > /* Try to wait for any previous AUX channel activity */
> > for (try = 0; try < 3; try++) {
> > status = I915_READ_NOTRACE(ch_ctl);
> > @@ -1223,6 +1260,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> >  
> > ret = recv_bytes;
> >  out:
> > +   intel_dp_aux_ch_put(intel_dp);
> > pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > if (vdd)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 020b96324135..177478f0b032 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1139,6 +1139,8 @@ struct intel_dp {
> >  
> > /* Displayport compliance testing */
> > struct intel_dp_compliance compliance;
> > +
> > +   bool exit_psr_on_aux_ch_xfer;
> >  };
> >  
> >  struct intel_lspcon {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8702dbafb42d..f88f12246a23 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -665,6 +665,13 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >   
> > msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> > }
> >  
> > +   /* From all platforms that supports PSR/PSR2 this 2 is the ones that
> > +* don't have restrictions about use of the aux ch while PSR/PSR2 is
> > +* enabled.
> > +*/
> > +   if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > +   intel_dp->exit_psr_on_aux_ch_xfer = true;
> > +
> >  unlock:
> > mutex_unlock(_priv->psr.lock);
> >  }
> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

[Pandiyan, Dhinakaran]

On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> > > This was my bad, spec says that the name of this bit is
> > > 'Y-coordinate valid' but the values for it is:
> > > 0: Include Y-coordinate valid eDP1.4a
> > > 1: Do not include Y-coordinate valid eDP 1.4
> > > So renaming the bit and not setting it.
> > > 
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  | 2 +-
> > >  drivers/gpu/drm/i915/intel_psr.c | 5 ++---
> > >  2 files changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 176dca6554f4..19429cb1f3a7 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4058,7 +4058,7 @@ enum {
> > >  #define EDP_PSR2_CTL _MMIO(0x6f900)
> > >  #define   EDP_PSR2_ENABLE(1<<31)
> > >  #define   EDP_SU_TRACK_ENABLE(1<<30)
> > > -#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> > > +#define   EDP_Y_COORDINATE_INVALID   (1<<26) /* GLK and CNL+
> > > */
> > 
> > INVALID isn't the same as asking the source to not send the y-
> > coordinate
> > valid bit. Sorry to be pedantic, please leave the definition as it
> > is.
> 
> I agree with you, if it don't need to send the y-coordinate is
> better just not set EDP_Y_COORDINATE_ENABLE but leave the bit
> definition name as it is, is prone to others do the same error as I
> did.
> 

I'll let Rodrigo take a call on this one.

-DK

> > 
> > Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com> if
> > you
> > remove this hunk.
> > 
> > >  #define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+
> > > */
> > >  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> > >  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 2d53f7398a6d..f12111438bcf 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp
> > > *intel_dp)
> > >* mesh at all with our frontbuffer tracking. And the hw
> > > alone isn't
> > >* good enough. */
> > >   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > > - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > {
> > > - val |= EDP_Y_COORDINATE_VALID |
> > > EDP_Y_COORDINATE_ENABLE;
> > > - }
> > > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > + val |= EDP_Y_COORDINATE_ENABLE;
> > >  
> > >   val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv-
> > > >psr.sink_sync_latency + 1);
> > >  
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

[Pandiyan, Dhinakaran]

On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote:
> This was my bad, spec says that the name of this bit is
> 'Y-coordinate valid' but the values for it is:
> 0: Include Y-coordinate valid eDP1.4a
> 1: Do not include Y-coordinate valid eDP 1.4
> So renaming the bit and not setting it.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 2 +-
>  drivers/gpu/drm/i915/intel_psr.c | 5 ++---
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 176dca6554f4..19429cb1f3a7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4058,7 +4058,7 @@ enum {
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
>  #define   EDP_SU_TRACK_ENABLE(1<<30)
> -#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define   EDP_Y_COORDINATE_INVALID   (1<<26) /* GLK and CNL+ */

INVALID isn't the same as asking the source to not send the y-coordinate
valid bit. Sorry to be pedantic, please leave the definition as it is.

Reviewed-by: Dhinakaran Pandiyan  if you
remove this hunk.

>  #define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
>  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
>  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d53f7398a6d..f12111438bcf 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -400,9 +400,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
>   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> - val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> - }
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + val |= EDP_Y_COORDINATE_ENABLE;
>  
>   val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Fri, 2018-03-30 at 14:15 -0700, Dhinakaran Pandiyan wrote:
> Interrupts other than the one for AUX errors are required only for debug,
> so unmask them via debugfs when the user requests debug.
> 
> User can make such a request with
> echo 1 > /dri/0/i915_edp_psr_debug
> 
> There are no locks to serialize PSR debug enabling from
> irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
> called only during module initialization/resume and IGT subtests
> aren't expected to modify PSR debug at those times, we should be safe.

Let me know what you think, I am not completely sure about this.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

[Pandiyan, Dhinakaran]

On Fri, 2018-03-30 at 19:19 +, Souza, Jose wrote:
> On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> > > IGT tests could be improved with sink status, knowing for sure that
> > > hardware have activate or exit PSR.
> > > 
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
> > > ---
> > > 
> > > v3: rebased
> > > 
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 29
> > > +
> > >  1 file changed, 29 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 1dba2c451255..89dc5b05ec24 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > >   return "unknown";
> > >  }
> > >  
> > > +static const char *psr_sink_self_refresh_status(u8 val)
> > 
> > nit: psr_sink_status() is concise,
> > "psr_self_refresh" sounds
> > redundant.
> > 
> > > +{
> > > + static const char * const sink_status[] = {
> > > + "inactive",
> > > + "transitioning to active",
> > 
> > We muddle the meaning of these statuses by paraphrasing, it is better
> > write these strings exactly as the states are defined in the spec.
> > 
> > > + "active",
> > > + "active receiving selective update",
> > 
> > For example, this state corresponds to the capture of full static
> > frame
> > too.
> 
> 
> It is fine this way?
> 
>   static const char * const sink_status[] = {
>   "inactive",
>   "transition to active, capture and display",
>   "active, display from RFB",
>   "active, capture and display on sink device timings",
>   "transition to inactive, capture and display, timing
> re-sync",
>   "reserved",
>   "reserved",
>   "sink internal error"
>   };
> 
> 
Looks good.

> > 
> > 
> > Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com> with
> > the nits addressed, thanks for the patch.
> > 
> > > + "transitioning to inactive",
> > > + "reserved",
> > > + "reserved",
> > > + "sink internal error"
> > > + };
> > > +
> > > + val &= DP_PSR_SINK_STATE_MASK;
> > > + if (val < ARRAY_SIZE(sink_status))
> > > + return sink_status[val];
> > > +
> > > + return "unknown";
> > > +}
> > > +
> > >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> > >  {
> > >   struct drm_i915_private *dev_priv = node_to_i915(m-
> > > >private);
> > > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > >   seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> > >  psr2, psr2_live_status(psr2));
> > >   }
> > > +
> > > + if (dev_priv->psr.enabled) {
> > > + struct drm_dp_aux *aux = _priv->psr.enabled-
> > > >aux;
> > > + u8 val;
> > > +
> > > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) ==
> > > 1)
> > > + seq_printf(m, "Sink self refresh status:
> > > 0x%x [%s]\n",
> > > +val,
> > > psr_sink_self_refresh_status(val));
> > > + }
> > >   mutex_unlock(_priv->psr.lock);
> > >  
> > >   intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate or exit PSR.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> v3: rebased
> 
>  drivers/gpu/drm/i915/i915_debugfs.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1dba2c451255..89dc5b05ec24 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
>   return "unknown";
>  }
>  
> +static const char *psr_sink_self_refresh_status(u8 val)
nit: psr_sink_status() is concise, "psr_self_refresh" sounds
redundant.

> +{
> + static const char * const sink_status[] = {
> + "inactive",
> + "transitioning to active",

We muddle the meaning of these statuses by paraphrasing, it is better
write these strings exactly as the states are defined in the spec.

> + "active",
> + "active receiving selective update",

For example, this state corresponds to the capture of full static frame
too.


Reviewed-by: Dhinakaran Pandiyan  with
the nits addressed, thanks for the patch.

> + "transitioning to inactive",
> + "reserved",
> + "reserved",
> + "sink internal error"
> + };
> +
> + val &= DP_PSR_SINK_STATE_MASK;
> + if (val < ARRAY_SIZE(sink_status))
> + return sink_status[val];
> +
> + return "unknown";
> +}
> +
>  static int i915_edp_psr_status(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
>  psr2, psr2_live_status(psr2));
>   }
> +
> + if (dev_priv->psr.enabled) {
> + struct drm_dp_aux *aux = _priv->psr.enabled->aux;
> + u8 val;
> +
> + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
> + seq_printf(m, "Sink self refresh status: 0x%x [%s]\n",
> +val, psr_sink_self_refresh_status(val));
> + }
>   mutex_unlock(_priv->psr.lock);
>  
>   intel_runtime_pm_put(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote:
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
> 
> Spec: 7713 and 7720
> 
> Cc: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> v3: rebased
> 
>  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
>  drivers/gpu/drm/i915/intel_psr.c | 16 
>  2 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 33e52cc98d99..9d61ab1288d3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4058,6 +4058,8 @@ enum {
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
>  #define   EDP_SU_TRACK_ENABLE(1<<30)
> +#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
>  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
>  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
>  #define   EDP_PSR2_TP2_TIME_500  (0<<8)
> @@ -7064,6 +7066,7 @@ enum {
>  #define CHICKEN_TRANS_A 0x420c0
>  #define CHICKEN_TRANS_B 0x420c4
>  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> +#define  VSC_DATA_SEL_SOFTWARE_CONTROL   (1<<25) /* GLK and CNL+ */
>  #define  DDI_TRAINING_OVERRIDE_ENABLE(1<<19)
>  #define  DDI_TRAINING_OVERRIDE_VALUE (1<<18)
>  #define  DDIE_TRAINING_OVERRIDE_ENABLE   (1<<17) /* CHICKEN_TRANS_A only 
> */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index fb2d0fe7106b..84e1f8be5c48 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> + val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;

Bspecs says Bit 26 : Y-coordinate valid
1b stands for "Do not include Y-coordinate valid eDP 1.4".

Was "val |= EDP_Y_COORDINATE_VALID" intended?


> + }
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
>   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> @@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp,
>   hsw_psr_setup_aux(intel_dp);
>  
>   if (dev_priv->psr.psr2_support) {
> - u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> -   | PSR2_ADD_VERTICAL_LINE_COUNT;
> + u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> +
> + if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv))
> + chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> +| PSR2_ADD_VERTICAL_LINE_COUNT);
> +
> + else
> + chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
>   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
>  
>   I915_WRITE(EDP_PSR_DEBUG,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 17:37 +, Pandiyan, Dhinakaran wrote:
> 
> 
> On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote:
> > On Tue, Mar 27, 2018 at 06:33:11PM +0000, Pandiyan, Dhinakaran wrote:
> > > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > > > On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > > > > Interrupts other than the one for AUX errors are required only for 
> > > > > debug,
> > > > > so unmask them via debugfs when the user requests debug.
> > > > > 
> > > > > User can make such a request with
> > > > > echo 1 > /dri/0/i915_edp_psr_debug
> > > > > 
> > > > > v2: Unroll loops (Ville)
> > > > > Avoid resetting error mask bits.
> > > > > 
> > > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > > > >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> > > > >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > > > > +++--
> > > > >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> > > > >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > > > > 
> > > > >  5 files changed, 108 insertions(+), 40 deletions(-)
> > > > > 
> 
> > > > >  
> > > > > +void intel_psr_debug_control(struct drm_i915_private *dev_priv, bool 
> > > > > enable)
> > > > > +{
> > > > > + u32 mask;
> > > > > +
> > > > > + /* No PSR interrupts on VLV/CHV */
> > > > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > > + return;
> > > > > +
> > > > > + mask = EDP_PSR_POST_EXIT(TRANSCODER_EDP) |
> > > > > +EDP_PSR_PRE_ENTRY(TRANSCODER_EDP);
> > > > > +
> > > > > + if (INTEL_GEN(dev_priv) >= 8)
> > > > > + mask |= EDP_PSR_POST_EXIT(TRANSCODER_A) |
> > > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_A) |
> > > > > + EDP_PSR_POST_EXIT(TRANSCODER_B) |
> > > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_B) |
> > > > > + EDP_PSR_POST_EXIT(TRANSCODER_C) |
> > > > > + EDP_PSR_PRE_ENTRY(TRANSCODER_C);
> > > > > +
> > > > > + if (enable) {
> > > > > + WRITE_ONCE(dev_priv->psr.debug, true);
> > > > > + I915_WRITE(EDP_PSR_IMR, I915_READ(EDP_PSR_IMR) & ~mask);
> > > > 
> > > > Why RMW?
> > > > 
> > > Avoids updating this function when new PSR error bits are added in
> > > i915_irq.c
> > 
> > The usual rule is "avoid RMW unles there is a really compelling reason
> > for it". There is none in this case AFAICS.
> > 
> > > 
> > > Would you prefer 
> > > 
> > > mask |= EDP_PSR_ERROR(TRANCODER_A) | ...  here? 
> > > 
> > > I think this has started to look ugly already. The loop was concise IMO.
> > > 
> > > The other option is to
> > > 
> > > #define HSW_PSR_INTR_DBG_MASK = 0x7
> > > #define BDW_PSR_INTR_DBG_MASK = 0x07070707 
> > 
> > Not sure what these have to do with the RMW.
> > 
> They don't, that was an alternative to the series of OR's we have to do
> to derive the mask.
> 
> 0x07070707 is the mask of all the relevant bits (error + debug). The
> above definitions could be used as 
> 
> if (INTEL_GEN(dev_priv) > 8)
>   mask = BDW_PSR_INTR_DBG_MASK;
> else
>   mask = HSW_PSR_INTR_DBG_MASK
> 
> 
> if (enable)
>   I915_WRITE(EDP_PSR_IMR, ~mask)
> 
> Anyway, I am not sure how you want this to be written at this point. Can
> you suggest in code what you like to see here?
> 

+   error_mask = EDP_PSR_ERROR(TRANSCODER_EDP);
+   debug_mask = error_mask | EDP_PSR_POST_EXIT(TRANSCODER_EDP) |
+EDP_PSR_PRE_ENTRY(TRANSCODER_EDP);
+
+   if (INTEL_GEN(dev_priv) >= 8) {
+   error_mask |= EDP_PSR_ERROR(TRANSCODER

Re: [Intel-gfx] [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 20:13 +0100, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40)
> > 
> > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> > > As intel_wait_for_register_fw() may use, and if successful only use, a
> > > busy-wait loop, the might_sleep() warning is a little over-zealous.
> > > Restrict it to a might_sleep_if() a slow timeout is specified (and so
> > > the caller authorises use of a usleep).
> > > 
> > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > > ---
> > >  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> > > b/drivers/gpu/drm/i915/intel_uncore.c
> > > index f37ecfc69e49..44c4654443ba 100644
> > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct 
> > > drm_i915_private *dev_priv,
> > >   u32 reg_value;
> > >   int ret;
> > >  
> > > - might_sleep();
> > > + might_sleep_if(slow_timeout_ms);
> > 
> > __wait_for() already has a might_sleep(), why is this needed?
> 
> To document that this routine is a sleeper, irrespective of the
> implementation. Sometimes it is implicit on the implementation and so
> should only be at the low level, sometimes we want to call out the
> requirements explicitly and clearly. We have "wait" in the name so
> shouting out that this may indeed sleep rather than busyspin seems to
> be in order.
> -Chris

Fair enough.

There seems to be a side effect from the second hunk that your commit
message does not explicitly state.

> - if (ret)
> + if (ret && slow_timeout_ms)

This results in a different return value if condition == true and
slow_timeout_ms == 0 after fast_timeout_us was exceeded.

Previously, __intel_wait_for_register would have passed along the 0 from
__wait_for(), now it returns -ETIMEDOUT. Which means this change should
have been a separate patch. 

As the patch itself is sensible, 
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

> ___
> 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] drm/i915: Only warn for might_sleep() before a slow wait_for_register

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> As intel_wait_for_register_fw() may use, and if successful only use, a
> busy-wait loop, the might_sleep() warning is a little over-zealous.
> Restrict it to a might_sleep_if() a slow timeout is specified (and so
> the caller authorises use of a usleep).
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index f37ecfc69e49..44c4654443ba 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private 
> *dev_priv,
>   u32 reg_value;
>   int ret;
>  
> - might_sleep();
> + might_sleep_if(slow_timeout_ms);

__wait_for() already has a might_sleep(), why is this needed?

>  
>   spin_lock_irq(_priv->uncore.lock);
>   intel_uncore_forcewake_get__locked(dev_priv, fw);
> @@ -2008,7 +2008,7 @@ int __intel_wait_for_register(struct drm_i915_private 
> *dev_priv,
>   intel_uncore_forcewake_put__locked(dev_priv, fw);
>   spin_unlock_irq(_priv->uncore.lock);
>  
> - if (ret)
> + if (ret && slow_timeout_ms)
>   ret = __wait_for(reg_value = I915_READ_NOTRACE(reg),
>(reg_value & mask) == value,
>slow_timeout_ms * 1000, 10, 1000);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote:
> On Tue, Mar 27, 2018 at 06:33:11PM +0000, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > > On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > > > Interrupts other than the one for AUX errors are required only for 
> > > > debug,
> > > > so unmask them via debugfs when the user requests debug.
> > > > 
> > > > User can make such a request with
> > > > echo 1 > /dri/0/i915_edp_psr_debug
> > > > 
> > > > v2: Unroll loops (Ville)
> > > > Avoid resetting error mask bits.
> > > > 
> > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > > >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> > > >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > > > +++--
> > > >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> > > >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > > > 
> > > >  5 files changed, 108 insertions(+), 40 deletions(-)
> > > > 

> > > >  
> > > > +void intel_psr_debug_control(struct drm_i915_private *dev_priv, bool 
> > > > enable)
> > > > +{
> > > > +   u32 mask;
> > > > +
> > > > +   /* No PSR interrupts on VLV/CHV */
> > > > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > +   return;
> > > > +
> > > > +   mask = EDP_PSR_POST_EXIT(TRANSCODER_EDP) |
> > > > +  EDP_PSR_PRE_ENTRY(TRANSCODER_EDP);
> > > > +
> > > > +   if (INTEL_GEN(dev_priv) >= 8)
> > > > +   mask |= EDP_PSR_POST_EXIT(TRANSCODER_A) |
> > > > +   EDP_PSR_PRE_ENTRY(TRANSCODER_A) |
> > > > +   EDP_PSR_POST_EXIT(TRANSCODER_B) |
> > > > +   EDP_PSR_PRE_ENTRY(TRANSCODER_B) |
> > > > +   EDP_PSR_POST_EXIT(TRANSCODER_C) |
> > > > +   EDP_PSR_PRE_ENTRY(TRANSCODER_C);
> > > > +
> > > > +   if (enable) {
> > > > +   WRITE_ONCE(dev_priv->psr.debug, true);
> > > > +   I915_WRITE(EDP_PSR_IMR, I915_READ(EDP_PSR_IMR) & ~mask);
> > > 
> > > Why RMW?
> > > 
> > Avoids updating this function when new PSR error bits are added in
> > i915_irq.c
> 
> The usual rule is "avoid RMW unles there is a really compelling reason
> for it". There is none in this case AFAICS.
> 
> > 
> > Would you prefer 
> > 
> > mask |= EDP_PSR_ERROR(TRANCODER_A) | ...  here? 
> > 
> > I think this has started to look ugly already. The loop was concise IMO.
> > 
> > The other option is to
> > 
> > #define HSW_PSR_INTR_DBG_MASK = 0x7
> > #define BDW_PSR_INTR_DBG_MASK = 0x07070707 
> 
> Not sure what these have to do with the RMW.
> 
They don't, that was an alternative to the series of OR's we have to do
to derive the mask.

0x07070707 is the mask of all the relevant bits (error + debug). The
above definitions could be used as 

if (INTEL_GEN(dev_priv) > 8)
mask = BDW_PSR_INTR_DBG_MASK;
else
mask = HSW_PSR_INTR_DBG_MASK


if (enable)
I915_WRITE(EDP_PSR_IMR, ~mask)

Anyway, I am not sure how you want this to be written at this point. Can
you suggest in code what you like to see here?

> > 
> > 
> > 
> > > > +   } else {
> > > > +   I915_WRITE(EDP_PSR_IMR, I915_READ(EDP_PSR_IMR) | mask);
> > > > +   WRITE_ONCE(dev_priv->psr.debug, false);
> > > > +   }
> > > > +}
> > > > +
> > > > +void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 
> > > > psr_iir)
> > > > +{
> > > > +   u32 transcoders = BIT(TRANSCODER_EDP);
> > > > +   enum transcoder cpu_transcoder;
> > > > +
> > > > +   if (INTEL_GEN(dev_priv) >= 8)
> > > > +   transcoders |= BIT(TRANSCODER_A) |
> > > > +   

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Tue, 2018-03-27 at 11:26 +0100, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-27 02:16:22)
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > +++--
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > 
> >  5 files changed, 108 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : 
> > "Disabling");
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> 
> A really useful trick for features like this (that we think should be
> used wherever it can) is just to enable debug while the debugfs file is
> open. igt need only do something like
>   openat(debugfs_dir, "i915_edp_psr_debug", O_RDONLY);

That is neat.

We also want to support user enabling/disabling PSR debug via shell. The
semantics get slightly confusing taking that into consideration.

For example,
1) should cat $debugfs/i915_edp_psr_debug 
also enable debug or just print the current status of debug
2) if the file is already open (debug enabled), should
echo 0 > $debugfs/i915_edp_psr_debug disable debug or check for the
refcount to drop to zero.

Choosing the correct solution and implementing it correctly feels like
we'd be over-engineering.


> and then it will be automatically released and the system returned to
> default when terminated. You can then enforce exclusive access or keep an
> open count.
> -Chris
> ___
> 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 v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > +++--
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > 
> >  5 files changed, 108 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> 
> Can't be < 0.
> 
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> 
> ==1 seems pointless
> enableddisabled() could be used perhaps.
> 

Will do.

> 
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c9c3b2ba6a86..c0224a86344e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -608,6 +608,7 @@ struct i915_psr {
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > +   bool debug;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a894adf2ca1..e5aaf805c6a8 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> > -   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > -   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> > - transcoder_name(cpu_transcoder));
> > -
> > -   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
> > vblanks\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> > -   }
> > -
> > -   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > -

Re: [Intel-gfx] [PATCH 10/12] drm/i915/debugfs: Print sink PSR state and debug info

[Pandiyan, Dhinakaran]

On Fri, 2018-03-23 at 00:06 +, Souza, Jose wrote:
> On Thu, 2018-03-22 at 16:31 -0700, Rodrigo Vivi wrote:
> > On Thu, Mar 22, 2018 at 02:48:46PM -0700, José Roberto de Souza
> > wrote:
> > 
> > please add some justification on why this is useful
> 

The plan is to remove sink crc and use these bits :)

> Okay something like this should be fine?
> 
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate PSR before get the CRC.
> This is also userful to check if hardware is really doing PSR2
> selective update with the y-coordinate.
> 
> 
> > 
> > > Signed-off-by: José Roberto de Souza 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 54
> > > +
> > >  1 file changed, 54 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 16f9977995df..0a0642c61cd0 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2603,6 +2603,44 @@ static const char *psr2_live_status(u32 val)
> > >   return "unknown";
> > >  }
> > >  
> > > +static const char *psr_sink_self_refresh_status(u8 val)
> > > +{
> > > + static const char * const sink_status[] = {
> > > + "inactive",
> > > + "transitioning to active",
> > > + "active",
> > > + "active receiving selective update",
> > > + "transitioning to inactive",
> > > + "reserved",
> > > + "reserved",
> > > + "sink internal error"
> > > + };
> > > +
> > > + val &= DP_PSR_SINK_STATE_MASK;
> > > + if (val < ARRAY_SIZE(sink_status))
> > > + return sink_status[val];
> > > +
> > > + return "unknown";
> > > +}
> > > +
> > > +static void psr_sink_last_received_psr_sdp_sprintf(struct seq_file
> > > *m, u32 val)
> > > +{
> > > + if (val & DP_PSR_STATE_BIT)
> > > + seq_puts(m, "\tPSR active\n");
> > 
> > I'm a bit confused here why we are printing status here again if we
> > are adding the
> > sink_status char * array with some status definition up there.
> > 
> > Any simplification possible?

These values are what the sink received in the SDP, the one from
DP_PSR_STATUS is the current status of the sink.

> 
> Huum yeah, DP_PSR_STATE_BIT and DP_SU_VALID changes will cause the
> status of the sink to change, so I this 2 can be removed.

This should be split as two patches. And more importantly I can't think
of a use case for printing SDP status. The update might be too fast for
making any sense of it. Printing DP_PSR_STATUS should be sufficient for
writing tests.

> 
> > 
> > > + if (val & DP_UPDATE_RFB_BIT)
> > > + seq_puts(m, "\tUpdate RFB\n");
> > > + if (val & DP_CRC_VALID_BIT)
> > > + seq_puts(m, "\tCRC valid\n");
> > > + if (val & DP_SU_VALID)
> > > + seq_puts(m, "\tSU valid\n");
> > > + if (val & DP_FIRST_SCAN_LINE_SU_REGION)
> > > + seq_puts(m, "\tFirst scan line of the SU
> > > region\n");
> > > + if (val & DP_LAST_SCAN_LINE_SU_REGION)
> > > + seq_puts(m, "\tLast scan line of the SU
> > > region\n");
> > > + if (val & DP_Y_COORDINATE_VALID)
> > > + seq_puts(m, "\tY-Coordinate valid\n");
> > > +}
> > > +
> > >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> > >  {
> > >   struct drm_i915_private *dev_priv = node_to_i915(m-
> > > >private);
> > > @@ -2684,6 +2722,22 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > >   seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> > >  psr2, psr2_live_status(psr2));
> > >   }
> > > +
> > > + if (dev_priv->psr.enabled) {
> > > + struct drm_dp_aux *aux = _priv->psr.enabled-
> > > >aux;
> > > + u8 val;
> > > +
> > > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) ==
> > > 1)
> > > + seq_printf(m, "Sink self refresh status:
> > > 0x%x [%s]\n",
> > > +val,
> > > psr_sink_self_refresh_status(val));
> > > +
> > > + if (drm_dp_dpcd_readb(aux,
> > > DP_LAST_RECEIVED_PSR_SDP, )
> > > + == 1) {
> > > + seq_printf(m, "Sink last received PSR SDP:
> > > 0x%x\n",
> > > +val);
> > > + psr_sink_last_received_psr_sdp_sprintf(m,
> > > val);
> > > + }
> > > + }
> > >   mutex_unlock(_priv->psr.lock);
> > >  
> > >   intel_runtime_pm_put(dev_priv);
> > > -- 
> > > 2.16.2
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___

Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement

[Pandiyan, Dhinakaran]

On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote:
> On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> > > Move to only one place the sink requirements that the actual driver
> > > needs to enable PSR2.
> > > 
> > > Also intel_psr2_config_valid() is called every time the crtc config
> > > is computed, wasting some time every time it was checking for
> > > Y coordinate requirement.
> > > 
> > > This allow us to nuke y_cord_support and some of VSC setup code
> > > that
> > > was handling a scenario that would never happen(PSR2 without Y
> > > coordinate).
> > > 
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> > >  drivers/gpu/drm/i915/intel_psr.c | 46 +---
> > > 
> > >  2 files changed, 19 insertions(+), 28 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 7fe00509e51a..cce32686fd75 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -603,7 +603,6 @@ struct i915_psr {
> > >   unsigned busy_frontbuffer_bits;
> > >   bool psr2_support;
> > >   bool link_standby;
> > > - bool y_cord_support;
> > >   bool colorimetry_support;
> > >   bool alpm;
> > >   bool has_hw_tracking;
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index d46320a451d9..23f38ab10636 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp
> > > *intel_dp)
> > >   intel_display_power_put(dev_priv,
> > > psr_aux_domain(intel_dp));
> > >  }
> > >  
> > > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > > *intel_dp)
> > >  {
> > >   uint8_t psr_caps = 0;
> > >  
> > > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > > *intel_dp)
> > >   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > > >psr_dpcd,
> > >sizeof(intel_dp->psr_dpcd));
> > >  
> > > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > > + if (intel_dp->psr_dpcd[0]) {
> > >   dev_priv->psr.sink_support = true;
> > >   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > >   }
> > >  
> > >   if (INTEL_GEN(dev_priv) >= 9 &&
> > > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > > -
> > > - dev_priv->psr.sink_support = true;
> > > - dev_priv->psr.psr2_support = true;
> > > + (intel_dp->psr_dpcd[0] ==
> > > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > > + /*
> > > +  * All panels that supports PSR version 03h (PSR2
> > > +
> > > +  * Y-coordinate) can handle Y-coordinates in VSC
> > > but we are
> > > +  * only sure that it is going to be used when
> > > required by the
> > > +  * panel. This way panel is capable to do
> > > selective update
> > > +  * without a aux frame sync.
> > 
> > Can you cite this from the spec please? just the "panel is capable to
> > do
> > selective update without a aux frame sync" part. Or you could just
> > remove that line so that we can get this patch reviewed and merged.
> 
> There is no such statement in spec like this, the closest that it have
> is:
> "When the Source device includes the optional Y-coordinate in the SDP
> for PSR2 Operation, as described in Table 6-12, the Sink device can
> implement a lower-precision GTC Slave  function, as described in Table
> 7-1."
> 
> But we know that this works by all the previous tests when enabling
> PSR2 and I also tested it.

Please do update the comment to say so. Do you know if these tests for
PSR2 selective update are in IGT? Or were these manual tests?

Rodrigo/Vathsala, any idea how s

Re: [Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync

[Pandiyan, Dhinakaran]

On Fri, 2018-03-23 at 23:49 +, Souza, Jose wrote:
> On Fri, 2018-03-23 at 15:14 -0700, Pandiyan, Dhinakaran wrote:
> > On Thu, 2018-03-22 at 15:57 -0700, Rodrigo Vivi wrote:
> > > On Thu, Mar 22, 2018 at 02:48:39PM -0700, José Roberto de Souza
> > > wrote:
> > > > Without GTC enabled hardware is sending dummy aux frame sync
> > > > value
> > 
> > Curious, is this something you found by testing?
> 
> There this a this bit AUX_FRAME_SYNC Valid in AUX_FRAME_SYNC VALUE
> register in sink, I'm reading this as valid but the value of aux frame
> in sink is always 0, the same as GTC_LIVE register in source side by
> this I guess source is sending 0 in each aux frame sync.
> 
> > 
> > > > that is not useful to sink do selective update, that is why it
> > > > also
> > > > require that sink supports and requires the y-coordinate.
> > > > 
> > > > So removing everything related to aux frame sync, if GTC is
> > > > enabled
> > > > we can bring this back.
> > > > 
> > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > 
> > > Cc: Vathsala Nagaraju <vathsala.nagar...@intel.com>
> > > 
> > > > Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
> > > 
> > > Acked-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > (but I would like to give a time for Vathsala to comment on this)
> > > 
> > 
> > Reading the spec again,
> > 
> > No aux frame sync implies that the driver does not support selective
> > update, irrespective of whether we *support y-coordinate or not*.
> > 
> > Section 7.1 eDP v1.4b
> > "AUX_FRAME_SYNC was added to eDP v1.4 for streamlining the RFB
> > management of a Sink device during PSR2 operation. AUX_FRAME_SYNC is
> > required a for PSR2 when using the Selective Update feature (which is
> > any time that the SU_VALID bit p is set to 1 in the PSR2 VSC SDP).
> > Neither GTC nor AUX_FRAME_SYNC is required for PSR2 when using only
> > the
> > Single-frame Update feature (which means that the SU_VALID bit is
> > always
> > cleared to 0 in the PSR2 VSC SDP)."
> > 
> > Sending y-coordinate only allows for a lower precision aux frame sync
> > functionality, doesn't invalidate the need for aux frame sync.
> > 
> > "When the Source device includes the optional Y-coordinate in the SDP
> > for PSR2 Operation, as described in Table 6-12, the Sink device can
> > implement a lower-precision GTC Slave  function, as described in
> > Table
> > 7-1."
> > 
> > Aside from the still slightly misleading commit message, this in my
> > opinion is a good step. Let's make it obvious and clear that only
> > full
> > frame updates are currently supported. We can then start working on
> > what's required for selective update and do it properly.
> > 
> > 
> > I'd like you to include relevant portions of the above text in the
> > commit message if you agree with the interpretation.
> > 
> > -DK
> 
> I agree with your interpretation of the spec but by the previous
> attempts of enabling of PSR/PSR2 and also by my tests the selective
> update with y-coordinate works at least in the pannels that we have
> access to.

I'll take your word on that. How are you checking selective update is
indeed working?

Vathsala/Rodrigo

Any idea why selective update seems to be working without aux frame
sync?

> And do not makes sense enable any PSR2 if we are going to do full frame
> updates, that is PSR1.

Yeah, but we do want to make sure selective update is working without
aux frame sync.

As the driver doesn't implement aux frame sync, there's not much meaning
in requiring the sink to support it. So, this patch is
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

Please rewrite the commit message stating what's in the spec and include
the contradictory observation you made in the tests. Thanks for all the
work on this patch.

-DK

> 
> > 
> > 
> > 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> > > >  drivers/gpu/drm/i915/intel_psr.c | 23 +--
> > > >  2 files changed, 1 insertion(+), 23 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index c9c3b2ba6a86..7fe00509e51a 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/

Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> Move to only one place the sink requirements that the actual driver
> needs to enable PSR2.
> 
> Also intel_psr2_config_valid() is called every time the crtc config
> is computed, wasting some time every time it was checking for
> Y coordinate requirement.
> 
> This allow us to nuke y_cord_support and some of VSC setup code that
> was handling a scenario that would never happen(PSR2 without Y
> coordinate).
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 46 
> +---
>  2 files changed, 19 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7fe00509e51a..cce32686fd75 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -603,7 +603,6 @@ struct i915_psr {
>   unsigned busy_frontbuffer_bits;
>   bool psr2_support;
>   bool link_standby;
> - bool y_cord_support;
>   bool colorimetry_support;
>   bool alpm;
>   bool has_hw_tracking;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index d46320a451d9..23f38ab10636 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
>   intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
>  }
>  
> -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
>  {
>   uint8_t psr_caps = 0;
>  
> @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
>   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
>sizeof(intel_dp->psr_dpcd));
>  
> - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> + if (intel_dp->psr_dpcd[0]) {
>   dev_priv->psr.sink_support = true;
>   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
>   }
>  
>   if (INTEL_GEN(dev_priv) >= 9 &&
> - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> -
> - dev_priv->psr.sink_support = true;
> - dev_priv->psr.psr2_support = true;
> + (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> + /*
> +  * All panels that supports PSR version 03h (PSR2 +
> +  * Y-coordinate) can handle Y-coordinates in VSC but we are
> +  * only sure that it is going to be used when required by the
> +  * panel. This way panel is capable to do selective update
> +  * without a aux frame sync.

Can you cite this from the spec please? just the "panel is capable to do
selective update without a aux frame sync" part. Or you could just
remove that line so that we can get this patch reviewed and merged.


> +  *
> +  * To support PSR version 02h and PSR version 03h without
> +  * Y-coordinate requirement panels we would need to enable
> +  * GTC first.
> +  */
> + dev_priv->psr.psr2_support = 
> intel_dp_get_y_coord_required(intel_dp);
>   DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not 
> supported");
>  
>   if (dev_priv->psr.psr2_support) {
> - dev_priv->psr.y_cord_support =
> - intel_dp_get_y_cord_status(intel_dp);
>   dev_priv->psr.colorimetry_support =
>   intel_dp_get_colorimetry_status(intel_dp);
>   dev_priv->psr.alpm =
> @@ -191,16 +198,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
>   memset(_vsc, 0, sizeof(psr_vsc));
>   psr_vsc.sdp_header.HB0 = 0;
>   psr_vsc.sdp_header.HB1 = 0x7;
> - if (dev_priv->psr.colorimetry_support &&
> - dev_priv->psr.y_cord_support) {
> + if (dev_priv->psr.colorimetry_support) {
>   psr_vsc.sdp_header.HB2 = 0x5;
>   psr_vsc.sdp_header.HB3 = 0x13;
> - } else if (dev_priv->psr.y_cord_support) {
> + } else {
>   psr_vsc.sdp_header.HB2 = 0x4;
>   psr_vsc.sdp_header.HB3 = 0xe;
> - } else {
> - psr_vsc.sdp_header.HB2 = 0x3;
> - psr_vsc.sdp_header.HB3 = 0xc;
>   }
>   } else {
>   /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
> @@ -458,15 +461,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   return false;
>   }
>  
> - /*

Re: [Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 15:57 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:39PM -0700, José Roberto de Souza wrote:
> > Without GTC enabled hardware is sending dummy aux frame sync value

Curious, is this something you found by testing?

> > that is not useful to sink do selective update, that is why it also
> > require that sink supports and requires the y-coordinate.
> > 
> > So removing everything related to aux frame sync, if GTC is enabled
> > we can bring this back.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> 
> Cc: Vathsala Nagaraju 
> 
> > Signed-off-by: José Roberto de Souza 
> 
> Acked-by: Rodrigo Vivi 
> (but I would like to give a time for Vathsala to comment on this)
> 

Reading the spec again,

No aux frame sync implies that the driver does not support selective
update, irrespective of whether we *support y-coordinate or not*.

Section 7.1 eDP v1.4b
"AUX_FRAME_SYNC was added to eDP v1.4 for streamlining the RFB
management of a Sink device during PSR2 operation. AUX_FRAME_SYNC is
required a for PSR2 when using the Selective Update feature (which is
any time that the SU_VALID bit p is set to 1 in the PSR2 VSC SDP).
Neither GTC nor AUX_FRAME_SYNC is required for PSR2 when using only the
Single-frame Update feature (which means that the SU_VALID bit is always
cleared to 0 in the PSR2 VSC SDP)."

Sending y-coordinate only allows for a lower precision aux frame sync
functionality, doesn't invalidate the need for aux frame sync.

"When the Source device includes the optional Y-coordinate in the SDP
for PSR2 Operation, as described in Table 6-12, the Sink device can
implement a lower-precision GTC Slave  function, as described in Table
7-1."

Aside from the still slightly misleading commit message, this in my
opinion is a good step. Let's make it obvious and clear that only full
frame updates are currently supported. We can then start working on
what's required for selective update and do it properly.


I'd like you to include relevant portions of the above text in the
commit message if you agree with the interpretation.

-DK



> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> >  drivers/gpu/drm/i915/intel_psr.c | 23 +--
> >  2 files changed, 1 insertion(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c9c3b2ba6a86..7fe00509e51a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -602,7 +602,6 @@ struct i915_psr {
> > struct delayed_work work;
> > unsigned busy_frontbuffer_bits;
> > bool psr2_support;
> > -   bool aux_frame_sync;
> > bool link_standby;
> > bool y_cord_support;
> > bool colorimetry_support;
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index b8e083e10029..d46320a451d9 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -137,16 +137,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> >  
> > if (INTEL_GEN(dev_priv) >= 9 &&
> > (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > -   uint8_t frame_sync_cap;
> >  
> > dev_priv->psr.sink_support = true;
> > -   if (drm_dp_dpcd_readb(_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > - _sync_cap) != 1)
> > -   frame_sync_cap = 0;
> > -   dev_priv->psr.aux_frame_sync = frame_sync_cap & 
> > DP_AUX_FRAME_SYNC_CAP;
> > -   /* PSR2 needs frame sync as well */
> > -   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> > +   dev_priv->psr.psr2_support = true;
> > DRM_DEBUG_KMS("PSR2 %s on sink",
> >   dev_priv->psr.psr2_support ? "supported" : "not 
> > supported");
> >  
> > @@ -269,11 +262,6 @@ static void hsw_psr_enable_sink(struct intel_dp 
> > *intel_dp)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >  
> >  
> > -   /* Enable AUX frame sync at sink */
> > -   if (dev_priv->psr.aux_frame_sync)
> > -   drm_dp_dpcd_writeb(_dp->aux,
> > -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> > -   DP_AUX_FRAME_SYNC_ENABLE);
> > /* Enable ALPM at sink for psr2 */
> > if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
> > drm_dp_dpcd_writeb(_dp->aux,
> > @@ -712,11 +700,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> > i915_reg_t psr_status;
> > u32 psr_status_mask;
> >  
> > -   if (dev_priv->psr.aux_frame_sync)
> > -   drm_dp_dpcd_writeb(_dp->aux,
> > -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> > -   0);
> > -
> >   

Re: [Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit

[Pandiyan, Dhinakaran]

On Fri, 2018-03-23 at 00:16 +, Souza, Jose wrote:
> On Thu, 2018-03-22 at 16:43 -0700, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> > > On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza
> > > wrote:
> > > > This will be helpful to debug what hardware is actually tracking.
> > > > 
> > > > Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
> > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 47
> > > > +
> > > >  drivers/gpu/drm/i915/i915_reg.h | 18 ++
> > > >  2 files changed, 65 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 0a0642c61cd0..3182e9a7cc5d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -2641,6 +2641,43 @@ static void
> > > > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32
> > > > val)
> > > > seq_puts(m, "\tY-Coordinate valid\n");
> > > >  }
> > > >  
> > > > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > > > +  bool psr2_enabled)
> > > > +{
> > > > +   if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > > +   seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > > > +   if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > > > +   seq_puts(m, "\tPSR2 disabled\n");
> > > > +   if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > > +   seq_puts(m, "\tSU dirty FIFO underrun\n");
> > > > +   if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > > +   seq_puts(m, "\tSU CRC FIFO underrun\n");
> > > > +   if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > > > +   seq_puts(m, "\tGraphics reset\n");
> > > > +   if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > > > +   seq_puts(m, "\tPCH interrupt\n");
> > > > +   if (val & EDP_PSR_EVENT_MEMORY_UP)
> > > > +   seq_puts(m, "\tMemory up\n");
> > > > +   if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > > +   seq_puts(m, "\tFront buffer modification\n");
> > > > +   if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > > > +   seq_puts(m, "\tPSR watchdog timer expired\n");
> > > > +   if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > > > +   seq_puts(m, "\tPIPE registers updated\n");
> > > > +   if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > > > +   seq_puts(m, "\tRegister update\n");
> > > > +   if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > > > +   seq_puts(m, "\tHDCP enabled\n");
> > > > +   if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > > > +   seq_puts(m, "\tKVMR session enabled\n");
> > > > +   if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > > > +   seq_puts(m, "\tVBI enabled\n");
> > > > +   if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > > > +   seq_puts(m, "\tLPSP mode exited\n");
> > > > +   if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > > > +   seq_puts(m, "\tPSR disabled\n");
> > > > +}
> > > > +
> > > >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > >  {
> > > > struct drm_i915_private *dev_priv = node_to_i915(m-
> > > > >private);
> > > > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct
> > > > seq_file *m, void *data)
> > > >  
> > > > seq_printf(m, "Performance_Counter: %u\n",
> > > > psrperf);
> > > > }
> > > > +
> > > > +   if (INTEL_GEN(dev_priv) >= 9) {
> > > > +   u32 val = I915_READ(EDP_PSR_EVENT);
> > > 
> > > What I'm afraid here is that this really shows the last event or
> > > the first one after we cleared.
> > > 
> > 
> > Both, the bits remain set unless cleared. I have plans of printing
> > the
> > events out of the PSR exit irq handler. This really was one of the
> > main
> > reasons to implement PSR interrupts. Since we get interrupt for each
> > PSR
> > exit, we'll also print out the correct event that caused exit.
> > 
> 
> Exactly that, so should I drop this one?
> Are you planning send a patch later showing the reasons in the debugfs?

Yeah, I was planning to do it after the interrupt series is merged.
Since you've already done all the work for this patch, I think it makes
sense for you to one this one on top of PSR interrupts.

> This way we could improve and write new IGT tests.
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 13:33 +0200, Ville Syrjälä wrote:
> On Thu, Mar 22, 2018 at 01:19:19AM +0000, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > 
> > > > 
> > > > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > From: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > > > 
> > > > > > The definitions for the error register should be valid on bdw/skl 
> > > > > > too,
> > > > > > but there we haven't even enabled DE_MISC handling yet.
> > > > > > 
> > > > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have 
> > > > > > been
> > > > > > on bdw.
> > > > > > 
> > > > > > v2: Fixes from Ville.
> > > > > > 
> > > > > > v3: From DK
> > > > > >  * Rebased on drm-tip
> > > > > >  * Removed BDW IIR bit definition, looks like an unintentional 
> > > > > > change that
> > > > > > should be in the following patch.
> > > > > > 
> > > > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_irq.c  | 34 
> > > > > > ++
> > > > > >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> > > > > >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> > > > > >  3 files changed, 44 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index 44eef355e12c..e94a835b7515 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > > > > > drm_i915_private *dev_priv,
> > > > > > ironlake_rps_change_irq_handler(dev_priv);
> > > > > >  }
> > > > > >  
> > > > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private 
> > > > > > *dev_priv)
> > > > > > +{
> > > > > > +   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > > > +
> > > > > > +   if (edp_psr_iir & EDP_PSR_ERROR)
> > > > > > +   DRM_DEBUG_KMS("PSR error\n");
> > > > > > +
> > > > > > +   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > > > +   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > > > 
> > > > > I doubt we want to have the entry/exit interrupts generate all this
> > > > > noise in dmesg all the time. We should probably only enable the
> > > > > interrupts for testing. The error interrupt I suppose we want always,
> > > > > might even want DRM_ERROR on it.
> > > > 
> > > > I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.
> > > 
> > > Right. It's a bit hard to read this with stuff getting
> > > added/remove/moved more or less randomly.
> > > 
> > > > 
> > > > > 
> > > > > > +   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > > > > +   }
> > > > > > +
> > > > > > +   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > > > +   DRM_DEBUG_KMS("PSR exit completed\n");
> > > > > > +   I915_WRITE(EDP_PSR_IMR, 0);
> > > > > > +   }
> > > > > > +
> > > > > > +   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
&g

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 21:08 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-20 22:41:51)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 64ecea80438d..a83d95b1b587 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 psr_iir)
> >  {
> > u32 transcoders = BIT(TRANSCODER_EDP);
> > enum transcoder cpu_transcoder;
> > +   ktime_t time_ns =  ktime_get();
> > +   unsigned long flags = 0;
> >  
> > if (INTEL_GEN(dev_priv) >= 8)
> > transcoders |= BIT(TRANSCODER_A) |
> >BIT(TRANSCODER_B) |
> >BIT(TRANSCODER_C);
> >  
> > +   write_seqlock_irqsave(_priv->psr.debug_lock, flags);
> 
> You are inside a hardirq handler. irqsave/irqrestore are not required.
> 
> Even a seqlock here looks overkill, but whatever. (I don't buy that you
> need that precise level of coordination for a slow debugfs interface.)
> 

Looks like I'll make two reviewers happy without the seqlock, will
remove it in the next version :)

> > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, 
> > transcoders) {
> > +   bool handled = false;
> > +
> > +   /* PSR supported only on one transcoder currently */
> > +   WARN_ON_ONCE(handled);
> 
> Now this is just silly. At least get the check right.

Argh, I should have caught it. Thanks.


> -Chris
> ___
> 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 11/12] drm/i915/debugfs: Print information about what caused a PSR exit

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza wrote:
> > This will be helpful to debug what hardware is actually tracking.
> > 
> > Signed-off-by: José Roberto de Souza 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 47 
> > +
> >  drivers/gpu/drm/i915/i915_reg.h | 18 ++
> >  2 files changed, 65 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 0a0642c61cd0..3182e9a7cc5d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2641,6 +2641,43 @@ static void 
> > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32 val)
> > seq_puts(m, "\tY-Coordinate valid\n");
> >  }
> >  
> > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > +  bool psr2_enabled)
> > +{
> > +   if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > +   seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > +   if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > +   seq_puts(m, "\tPSR2 disabled\n");
> > +   if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > +   seq_puts(m, "\tSU dirty FIFO underrun\n");
> > +   if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > +   seq_puts(m, "\tSU CRC FIFO underrun\n");
> > +   if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > +   seq_puts(m, "\tGraphics reset\n");
> > +   if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > +   seq_puts(m, "\tPCH interrupt\n");
> > +   if (val & EDP_PSR_EVENT_MEMORY_UP)
> > +   seq_puts(m, "\tMemory up\n");
> > +   if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > +   seq_puts(m, "\tFront buffer modification\n");
> > +   if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > +   seq_puts(m, "\tPSR watchdog timer expired\n");
> > +   if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > +   seq_puts(m, "\tPIPE registers updated\n");
> > +   if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > +   seq_puts(m, "\tRegister update\n");
> > +   if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > +   seq_puts(m, "\tHDCP enabled\n");
> > +   if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > +   seq_puts(m, "\tKVMR session enabled\n");
> > +   if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > +   seq_puts(m, "\tVBI enabled\n");
> > +   if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > +   seq_puts(m, "\tLPSP mode exited\n");
> > +   if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > +   seq_puts(m, "\tPSR disabled\n");
> > +}
> > +
> >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> >  
> > seq_printf(m, "Performance_Counter: %u\n", psrperf);
> > }
> > +
> > +   if (INTEL_GEN(dev_priv) >= 9) {
> > +   u32 val = I915_READ(EDP_PSR_EVENT);
> 
> What I'm afraid here is that this really shows the last event or the first 
> one after we cleared.
> 
Both, the bits remain set unless cleared. I have plans of printing the
events out of the PSR exit irq handler. This really was one of the main
reasons to implement PSR interrupts. Since we get interrupt for each PSR
exit, we'll also print out the correct event that caused exit.

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-22 at 11:21 +0200, Ville Syrjälä wrote:
> On Thu, Mar 22, 2018 at 01:05:24AM +0000, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> > > > Timestamps are useful for IGT tests that trigger PSR exit and/or wait 
> > > > for
> > > > PSR entry.
> > > > 
> > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 12 
> > > >  drivers/gpu/drm/i915/i915_drv.h |  3 +++
> > > >  drivers/gpu/drm/i915/intel_psr.c| 21 +++--
> > > >  3 files changed, 34 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 669f3d56054a..d28dc4d8388e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -2686,6 +2686,18 @@ static int i915_edp_psr_status(struct seq_file 
> > > > *m, void *data)
> > > > }
> > > > mutex_unlock(_priv->psr.lock);
> > > >  
> > > > +   if (READ_ONCE(dev_priv->psr.debug)) {
> > > > +   unsigned int seq;
> > > > +
> > > > +   do {
> > > > +   seq = read_seqbegin(_priv->psr.debug_lock);
> > > > +   seq_printf(m, "Last attempted entry at: %lld\n",
> > > > +  dev_priv->psr.last_entry_attempt);
> > > > +   seq_printf(m, "Last exit at: %lld\n",
> > > > +  dev_priv->psr.last_exit);
> > > > +   } while (read_seqretry(_priv->psr.debug_lock, seq));
> > > 
> > > What does the seqlock buy us?
> > 
> > Reading debugfs wouldn't block the update inside the irq handler,
> > compared to using a spinlock. We need to serialize the read and update
> > parts, don't we? Otherwise tests might end up reading partial updates.
> 
> Hmm. ktime_t is 64 bits so I guess on 32bit systems it could be a slight
> issue. Not sure we should care that much about PSR debug on 32bit though.
> It's a rather unlikely configuration, and at least we don't do that in 
> the ci.
> 

Another thing is, if two IIR bits are set at the same time. EXIT and
PRE_ENTRY probably won't be though. How about if an earlier interrupt
was not handled? Won't multiple IIR bits be set? Implementing the lock
is slightly future proof and doesn't slow down irq handling.

> > 
> > > 
> > > > +   }
> > > > +
> > > > intel_runtime_pm_put(dev_priv);
> > > > return 0;
> > > >  }
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 136fa2267a66..b8170882e1ab 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -609,6 +609,9 @@ struct i915_psr {
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > bool debug;
> > > > +   ktime_t last_entry_attempt;
> > > > +   ktime_t last_exit;
> > > > +   seqlock_t debug_lock;
> > > >  
> > > > void (*enable_source)(struct intel_dp *,
> > > >   const struct intel_crtc_state *);
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 64ecea80438d..a83d95b1b587 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct 
> > > > drm_i915_private *dev_priv, u32 psr_iir)
> > > >  {
> > > > u32 transcoders = BIT(TRANSCODER_EDP);
> > > > enum transcoder cpu_transcoder;
> > > > +   ktime_t time_ns =  ktime_get();
> > > > +   unsigned long flags = 0;
> > > >  
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-15 at 11:28 +0100, Maarten Lankhorst wrote:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_status to force
> a certain value without a modeset.
> 
> To retain compatibility with older userspace, we also still allow
> the override through the module parameter, and add some tracking
> to check whether a debugfs mode is specified.
> 

While this is something we want to be able to do, I am concerned about
adding more complexity to a feature that has barely been tested.

How about doing a modeset before frontbuffer_tracking PSR subtests and
one at the end? I'm assuming all of them are grouped together.

Comments on this patch itself.
1) please split intel_psr_default_link_standby() into a separate patch.
2) how does the user know what values to write without looking at the
code?
3) Can the connector and crtc be stored somewhere to avoid loops?
4) Has this been tested on any platforms with PSR?
5) Do subtests need a finer control of PSR i.e., psr_exit() and
psr_activate() instead of enable and disable

> Changes since v1:
> - Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled.
> - Fix i915_psr_debugfs_mode to match the writes to debugfs.
> - Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify
>   it and move it to intel_psr.c. This keeps all internals in intel_psr.c
> - Perform an interruptible wait for hw completion outside of the psr
>   lock, instead of being forced to trywait and return -EBUSY.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  73 +-
>  drivers/gpu/drm/i915/i915_drv.h |  11 +-
>  drivers/gpu/drm/i915/intel_drv.h|   3 +
>  drivers/gpu/drm/i915/intel_psr.c| 262 
> +++-
>  4 files changed, 281 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 574fcf234007..98e169636f86 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2546,16 +2546,13 @@ static const char *psr2_live_status(u32 val)
>  
>  static int i915_edp_psr_status(struct seq_file *m, void *data)
>  {
> - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct drm_i915_private *dev_priv = m->private;
>   u32 psrperf = 0;
>   u32 stat[3];
>   enum pipe pipe;
>   bool enabled = false;
>   bool sink_support;
>  
> - if (!HAS_PSR(dev_priv))
> - return -ENODEV;
> -
>   sink_support = dev_priv->psr.sink_support;
>   seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
>   if (!sink_support)
> @@ -2564,7 +2561,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>   intel_runtime_pm_get(dev_priv);
>  
>   mutex_lock(_priv->psr.lock);
> - seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> + seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
>   seq_printf(m, "Re-enable work scheduled: %s\n",
> @@ -2631,6 +2628,70 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   return 0;
>  }
>  
> +static ssize_t i915_edp_psr_write(struct file *file, const char __user *ubuf,
> +   size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct drm_i915_private *dev_priv = m->private;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret, val;
> +
> + if (!dev_priv->psr.sink_support)
> + return -ENODEV;
> +
> + ret = kstrtoint_from_user(ubuf, len, 10, );
> + if (ret < 0) {
> + bool enable;
> + ret = kstrtobool_from_user(ubuf, len, );
> +
> + if (ret < 0)
> + return ret;
> +
> + val = enable;
> + }
> +
> + if (val < -1 || val > 3)
> + return -EINVAL;
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> +
> +retry:
> + ret = intel_psr_set_debugfs_mode(dev_priv, , val);
> + if (ret == -EBUSY) {
> + ret = drm_modeset_backoff();
> + if (!ret)
> + goto retry;
> + }
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + intel_runtime_pm_put(dev_priv);
> +
> + return ret ?: len;
> +}
> +
> +static int i915_edp_psr_open(struct inode *inode, struct file *file)
> +{
> + struct drm_i915_private *dev_priv = inode->i_private;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + return single_open(file, i915_edp_psr_status, dev_priv);
> +}
> +
> +static const struct file_operations i915_edp_psr_ops = {
> + .owner 

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> On Wed, Mar 21, 2018 at 07:19:53PM +0000, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > From: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > 
> > > > The definitions for the error register should be valid on bdw/skl too,
> > > > but there we haven't even enabled DE_MISC handling yet.
> > > > 
> > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > > > on bdw.
> > > > 
> > > > v2: Fixes from Ville.
> > > > 
> > > > v3: From DK
> > > >  * Rebased on drm-tip
> > > >  * Removed BDW IIR bit definition, looks like an unintentional change 
> > > > that
> > > > should be in the following patch.
> > > > 
> > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > Cc: Daniel Vetter <daniel.vet...@intel.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_irq.c  | 34 
> > > > ++
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> > > >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> > > >  3 files changed, 44 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 44eef355e12c..e94a835b7515 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > > > drm_i915_private *dev_priv,
> > > > ironlake_rps_change_irq_handler(dev_priv);
> > > >  }
> > > >  
> > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > > > +{
> > > > +   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_ERROR)
> > > > +   DRM_DEBUG_KMS("PSR error\n");
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > +   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > 
> > > I doubt we want to have the entry/exit interrupts generate all this
> > > noise in dmesg all the time. We should probably only enable the
> > > interrupts for testing. The error interrupt I suppose we want always,
> > > might even want DRM_ERROR on it.
> > 
> > I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.
> 
> Right. It's a bit hard to read this with stuff getting
> added/remove/moved more or less randomly.
> 
> > 
> > > 
> > > > +   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > > +   }
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > +   DRM_DEBUG_KMS("PSR exit completed\n");
> > > > +   I915_WRITE(EDP_PSR_IMR, 0);
> > > > +   }
> > > > +
> > > > +   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > > +}
> > > > +
> > > >  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
> > > > u32 de_iir)
> > > >  {
> > > > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> > > > drm_i915_private *dev_priv,
> > > > if (de_iir & DE_ERR_INT_IVB)
> > > > ivb_err_int_handler(dev_priv);
> > > >  
> > > > +   if (de_iir & DE_EDP_PSR_INT_HSW)
> > > > +   hsw_edp_psr_irq_handler(dev_priv);
> > > > +
> > > > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > > > dp_aux_irq_handler(dev_priv);
> > > >  
> > > > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device 
> > > > *dev)
> > > > if (IS_GEN7(de

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> > Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
> > PSR entry.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 12 
> >  drivers/gpu/drm/i915/i915_drv.h |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c| 21 +++--
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 669f3d56054a..d28dc4d8388e 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2686,6 +2686,18 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > }
> > mutex_unlock(_priv->psr.lock);
> >  
> > +   if (READ_ONCE(dev_priv->psr.debug)) {
> > +   unsigned int seq;
> > +
> > +   do {
> > +   seq = read_seqbegin(_priv->psr.debug_lock);
> > +   seq_printf(m, "Last attempted entry at: %lld\n",
> > +  dev_priv->psr.last_entry_attempt);
> > +   seq_printf(m, "Last exit at: %lld\n",
> > +  dev_priv->psr.last_exit);
> > +   } while (read_seqretry(_priv->psr.debug_lock, seq));
> 
> What does the seqlock buy us?

Reading debugfs wouldn't block the update inside the irq handler,
compared to using a spinlock. We need to serialize the read and update
parts, don't we? Otherwise tests might end up reading partial updates.

> 
> > +   }
> > +
> > intel_runtime_pm_put(dev_priv);
> > return 0;
> >  }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 136fa2267a66..b8170882e1ab 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -609,6 +609,9 @@ struct i915_psr {
> > bool alpm;
> > bool has_hw_tracking;
> > bool debug;
> > +   ktime_t last_entry_attempt;
> > +   ktime_t last_exit;
> > +   seqlock_t debug_lock;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 64ecea80438d..a83d95b1b587 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 psr_iir)
> >  {
> > u32 transcoders = BIT(TRANSCODER_EDP);
> > enum transcoder cpu_transcoder;
> > +   ktime_t time_ns =  ktime_get();
> > +   unsigned long flags = 0;
> >  
> > if (INTEL_GEN(dev_priv) >= 8)
> > transcoders |= BIT(TRANSCODER_A) |
> >BIT(TRANSCODER_B) |
> >BIT(TRANSCODER_C);
> >  
> > +   write_seqlock_irqsave(_priv->psr.debug_lock, flags);
> > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> > +   bool handled = false;
> > +
> > +   /* PSR supported only on one transcoder currently */
> > +   WARN_ON_ONCE(handled);
> > +
> > /* FIXME: Exit PSR when this happens. */
> > -   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > +   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> > +   handled = true;
> > DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
> >   transcoder_name(cpu_transcoder));
> >  
> > +   }
> > +
> > if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("[transcoder %s] PSR entry in 2 
> > vblanks\n",
> > +   handled = true;
> > +   dev_priv->psr.last_entry_attempt = time_ns;
> > +   DRM_DEBUG_KMS("[transcoder %s] PSR entry attempt in 2 
> > vblanks\n",
> >   transcoder_name(cpu_transcoder));
> > }
> >  
> > if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > +   handled = true;
> > +   dev_priv->psr.last_exit = time_ns;
> > DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
> >   transcoder_name(cpu_transcoder));
> > }
> > }
> > +   write_sequnlock_irqrestore(_priv->psr.debug_lock, flags);
> >  }
> >  
> >  static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > @@ -1160,6 +1176,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> >  
> > INIT_DELAYED_WORK(_priv->psr.work, intel_psr_work);
> > mutex_init(_priv->psr.lock);
> > +   

Re: [Intel-gfx] [PATCH 4/5] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:45 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 68 
> > -
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 56 ++
> >  5 files changed, 123 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 964ea1a12357..669f3d56054a 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e27ba8fb64e6..136fa2267a66 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -608,6 +608,7 @@ struct i915_psr {
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > +   bool debug;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 56228e8ed980..94941b52f1cf 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2392,40 +2392,6 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> > -   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > -   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> > - transcoder_name(cpu_transcoder));
> > -
> > -   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
> > vblanks\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> > -   }
> > -
> > -   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr &= 

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > From: Daniel Vetter 
> > 
> > The definitions for the error register should be valid on bdw/skl too,
> > but there we haven't even enabled DE_MISC handling yet.
> > 
> > Somewhat confusing the the moved register offset on bdw is only for
> > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > on bdw.
> > 
> > v2: Fixes from Ville.
> > 
> > v3: From DK
> >  * Rebased on drm-tip
> >  * Removed BDW IIR bit definition, looks like an unintentional change that
> > should be in the following patch.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c  | 34 ++
> >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> >  3 files changed, 44 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 44eef355e12c..e94a835b7515 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > +{
> > +   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > +
> > +   if (edp_psr_iir & EDP_PSR_ERROR)
> > +   DRM_DEBUG_KMS("PSR error\n");
> > +
> > +   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > +   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> 
> I doubt we want to have the entry/exit interrupts generate all this
> noise in dmesg all the time. We should probably only enable the
> interrupts for testing. The error interrupt I suppose we want always,
> might even want DRM_ERROR on it.

I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.

> 
> > +   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > +   }
> > +
> > +   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > +   DRM_DEBUG_KMS("PSR exit completed\n");
> > +   I915_WRITE(EDP_PSR_IMR, 0);
> > +   }
> > +
> > +   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > +}
> > +
> >  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
> > u32 de_iir)
> >  {
> > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > if (de_iir & DE_ERR_INT_IVB)
> > ivb_err_int_handler(dev_priv);
> >  
> > +   if (de_iir & DE_EDP_PSR_INT_HSW)
> > +   hsw_edp_psr_irq_handler(dev_priv);
> > +
> > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > dp_aux_irq_handler(dev_priv);
> >  
> > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device 
> > *dev)
> > if (IS_GEN7(dev_priv))
> > I915_WRITE(GEN7_ERR_INT, 0x);
> >  
> > +   if (IS_HASWELL(dev_priv)) {
> > +   I915_WRITE(EDP_PSR_IMR, 0x);
> > +   I915_WRITE(EDP_PSR_IIR, 0x);
> > +   }
> > +
> > gen5_gt_irq_reset(dev_priv);
> >  
> > ibx_irq_reset(dev_priv);
> > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct 
> > drm_device *dev)
> >   DE_DP_A_HOTPLUG);
> > }
> >  
> > +   if (IS_HASWELL(dev_priv)) {
> > +   gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > +   I915_WRITE(EDP_PSR_IMR, 0);
> > +   display_mask |= DE_EDP_PSR_INT_HSW;
> > +   }
> > +
> > dev_priv->irq_mask = ~display_mask;
> >  
> > ibx_irq_pre_postinstall(dev);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 1e000f3004cb..3447f03eac3d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3828,6 +3828,13 @@ enum {
> >  #define   EDP_PSR_TP1_TIME_0us (3<<4)
> >  #define   EDP_PSR_IDLE_FRAME_SHIFT 0
> >  
> > +/* Bspec claims those aren't shifted but stay at 0x64800 */
> > +#define EDP_PSR_IMR_MMIO(0x64834)
> > +#define EDP_PSR_IIR_MMIO(0x64838)
> > +#define   EDP_PSR_ERROR(1<<2)
> > +#define   EDP_PSR_POST_EXIT(1<<1)
> > +#define   EDP_PSR_PRE_ENTRY(1<<0)
> > +
> >  #define EDP_PSR_AUX_CTL
> > _MMIO(dev_priv->psr_mmio_base + 0x10)
> >  #define EDP_PSR_AUX_DATA(i)
> > _MMIO(dev_priv->psr_mmio_base + 0x14 + (i) * 4) /* 5 registers */
> >  
> > @@ -6628,6 +6635,7 @@ enum {
> >  #define 

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915/psr: Simply PSR computed state

[Pandiyan, Dhinakaran]

On Fri, 2018-03-16 at 16:30 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 16, 2018 at 04:05:01PM -0700, José Roberto de Souza wrote:
> > Having has_psr and has_psr2 can be ambiguous and also uses one more
> > byte than needed(not taking in care struct alignment).
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > v2: Grouped the 2 bools into one u8 as suggested by Dhinakaran Pandiyan.
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  3 +--
> >  drivers/gpu/drm/i915/intel_psr.c | 14 --
> >  2 files changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index a215aa78b0be..a7383235f90a 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -807,8 +807,7 @@ struct intel_crtc_state {
> > struct intel_link_m_n dp_m2_n2;
> > bool has_drrs;
> >  
> > -   bool has_psr;
> > -   bool has_psr2;
> > +   u8 psr;

/* 0 = disabled, 1 = PSR1, 2 = PSR2 */

> >  
> > /*
> >  * Frequence the dpll for the port should run at. Differs from the
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index aa4e03f65386..78b5c0c88261 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -563,9 +563,11 @@ void intel_psr_compute_config(struct intel_dp 
> > *intel_dp,
> > return;
> > }
> >  
> > -   crtc_state->has_psr = true;
> > -   crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> > -   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
> > +   if (intel_psr2_config_valid(intel_dp, crtc_state))
> > +   crtc_state->psr = DP_PSR2_IS_SUPPORTED;

We can avoid the dependency on an unrelated macro definition if you
explicitly set it to 1 or 2.

> > +   else
> > +   crtc_state->psr = DP_PSR_IS_SUPPORTED;
> > +   DRM_DEBUG_KMS("Enabling PSR%d\n", crtc_state->psr);

Also I think you should initialize ->psr = 0
> 
> Could we still continue writing "PSR" instead of "PSR1" ?
> 
> otherwise patch lgtm...
> 
> >  }
> >  
> >  static void intel_psr_activate(struct intel_dp *intel_dp)
> > @@ -635,7 +637,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > struct drm_device *dev = intel_dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >  
> > -   if (!crtc_state->has_psr)
> > +   if (!crtc_state->psr)
> > return;
> >  
> > if (WARN_ON(!CAN_PSR(dev_priv)))
> > @@ -648,7 +650,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > goto unlock;
> > }
> >  
> > -   dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
> > +   dev_priv->psr.psr2_enabled = (crtc_state->psr == DP_PSR2_IS_SUPPORTED);
> > dev_priv->psr.busy_frontbuffer_bits = 0;
> >  
> > dev_priv->psr.setup_vsc(intel_dp, crtc_state);
> > @@ -770,7 +772,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
> > struct drm_device *dev = intel_dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >  
> > -   if (!old_crtc_state->has_psr)
> > +   if (!old_crtc_state->psr)
> > return;
> >  
> > if (WARN_ON(!CAN_PSR(dev_priv)))
> > -- 
> > 2.16.2
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/psr/cnl: Enable Y-coordinate support in source

[Pandiyan, Dhinakaran]

On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> From: "Souza, Jose" 
> 
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
> 
> Spec: 7713
> 
> Cc: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> v2: This is specific to Geminilake and Cannonlake+
> 
>  drivers/gpu/drm/i915/i915_reg.h  | 2 ++
>  drivers/gpu/drm/i915/intel_psr.c | 6 --
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1e000f3004cb..bac54f744913 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3869,6 +3869,8 @@ enum {
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
>  #define   EDP_SU_TRACK_ENABLE(1<<30)
> +#define   EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
> +#define   EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
>  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
>  #define   EDP_MAX_SU_DISABLE_TIME_MASK   (0x1f<<20)
>  #define   EDP_PSR2_TP2_TIME_500  (0<<8)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 5593d1f3049a..c5eeb13cbcfd 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -417,8 +417,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> + val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> + }

The corresponding bits for gen-9 are set in hsw_psr_enable_source.


>  
>   if (drm_dp_dpcd_readb(_dp->aux,
>   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/psr: Tie PSR2 support to Y coordinate requirement in intel_psr_init_dpcd()

[Pandiyan, Dhinakaran]

On Fri, 2018-03-16 at 16:25 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 16, 2018 at 04:04:58PM -0700, José Roberto de Souza wrote:
> > Move to only one place the sink requirements that the actual driver
> > needs to enable PSR2.
> > 
> > Also intel_psr2_config_valid() is called every time the crtc config
> > is computed, wasting some time every time it was checking for
> > Y coordinate requirement.
> > 
> > This allow us to nuke y_cord_support and some of VSC setup code that
> > was handling a scenario that would never happen(PSR2 without Y
> > coordinate).
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> 
> Reviewed-by: Rodrigo Vivi 
> 
> > ---
> > 
> > v2: Changes in comment requested by Rodrigo Vivi
> > 
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> >  drivers/gpu/drm/i915/intel_psr.c | 56 
> > +---
> >  2 files changed, 29 insertions(+), 28 deletions(-)
> > 

> >  
> > @@ -586,14 +590,12 @@ static void hsw_psr_enable_source(struct intel_dp 
> > *intel_dp,
> > struct drm_device *dev = dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > -   u32 chicken;
> >  
> > psr_aux_io_power_get(intel_dp);
> >  
> > if (dev_priv->psr.psr2_support) {
> > -   chicken = PSR2_VSC_ENABLE_PROG_HEADER;
> > -   if (dev_priv->psr.y_cord_support)
> > -   chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
> > +   u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
> > + | PSR2_ADD_VERTICAL_LINE_COUNT;


I think I answered my own question.

Please check the bits on these register. Seems like these bits were
replaced by

PSR2_CTL[EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE] bits on gen10


If I am correct, this register should be set only for gen-9. It'd be
nice to fix PSR2 while making these changes :)




> > I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
> >  
> > I915_WRITE(EDP_PSR_DEBUG,
> > -- 
> > 2.16.2
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/psr: Tie PSR2 support to Y coordinate requirement in intel_psr_init_dpcd()

[Pandiyan, Dhinakaran]

On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> Move to only one place the sink requirements that the actual driver
> needs to enable PSR2.
> 
> Also intel_psr2_config_valid() is called every time the crtc config
> is computed, wasting some time every time it was checking for
> Y coordinate requirement.
> 
> This allow us to nuke y_cord_support and some of VSC setup code that
> was handling a scenario that would never happen(PSR2 without Y
> coordinate).
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> v2: Changes in comment requested by Rodrigo Vivi
> 
>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 56 
> +---
>  2 files changed, 29 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8a584273f897..d4bc8d18f56c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -603,7 +603,6 @@ struct i915_psr {
>   unsigned busy_frontbuffer_bits;
>   bool psr2_support;
>   bool link_standby;
> - bool y_cord_support;
>   bool colorimetry_support;
>   bool alpm;
>   bool has_hw_tracking;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 9811f5f0bc75..5593d1f3049a 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
>   intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
>  }
>  
> -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
>  {
>   uint8_t psr_caps = 0;
>  
> @@ -137,22 +137,39 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
>  
>   if (INTEL_GEN(dev_priv) >= 9 &&
>   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> - uint8_t frame_sync_cap;
> + uint8_t frame_sync_cap, y_coord_req;
>  
>   dev_priv->psr.sink_support = true;
> +
> + /* PSR2 needs frame sync to do selective updates */
>   if (drm_dp_dpcd_readb(_dp->aux,
> DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> _sync_cap) != 1)
>   frame_sync_cap = 0;
>   frame_sync_cap = (frame_sync_cap & DP_AUX_FRAME_SYNC_CAP);
> - /* PSR2 needs frame sync as well */
> - dev_priv->psr.psr2_support = frame_sync_cap;
> - DRM_DEBUG_KMS("PSR2 %s on sink",
> -   dev_priv->psr.psr2_support ? "supported" : "not 
> supported");
> +
> + /*
> +  * All panels that supports PSR version 03h (PSR2 +
> +  * Y-coordinate) 

nit: Perhaps check for PSR version 03h as a minimum requirement for
PSR2, a bit redundant but is useful documentation in code.



> support can handle Y-coordinates in VSC
> +  * but we are only sure that it is going to be used when
> +  * required by the panel. This way panel is capable to do
> +  * selective update even without a valid aux frame sync.
> +  *
> +  * To support PSR version 02h and PSR version 03h without
> +  * Y-coordinate requirement panels we would need to enable
> +  * GTC first.
> +  */
> + y_coord_req = intel_dp_get_y_coord_required(intel_dp);
> +
> + dev_priv->psr.psr2_support = frame_sync_cap && y_coord_req;
> + if (dev_priv->psr.psr2_support)
> + DRM_DEBUG_KMS("PSR2 supported on sink\n");
> + else
> + DRM_DEBUG_KMS("PSR2 not supported on sink"
> +   "(frame sync: %d Y-coord required: %d)\n",
> +   frame_sync_cap, y_coord_req);
>  
>   if (dev_priv->psr.psr2_support) {
> - dev_priv->psr.y_cord_support =
> - intel_dp_get_y_cord_status(intel_dp);
>   dev_priv->psr.colorimetry_support =
>   intel_dp_get_colorimetry_status(intel_dp);
>   dev_priv->psr.alpm =
> @@ -198,16 +215,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
>   memset(_vsc, 0, sizeof(psr_vsc));
>   psr_vsc.sdp_header.HB0 = 0;
>   psr_vsc.sdp_header.HB1 = 0x7;
> - if (dev_priv->psr.colorimetry_support &&
> - dev_priv->psr.y_cord_support) {
> + if (dev_priv->psr.colorimetry_support) {
>   psr_vsc.sdp_header.HB2 = 0x5;
>   psr_vsc.sdp_header.HB3 = 0x13;
> - } else if (dev_priv->psr.y_cord_support) {

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/psr: Nuke aux_frame_sync

[Pandiyan, Dhinakaran]

On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> PSR2 selective update requires aux frame sync(even though we don't
> support it in i915)

Any chance I could get you to fix this line? 

i915 does not support aux frame sync ^
PSR2 panel needs to support aux frame sync (see below)

I find this contradictory, please explain what you believe is going on.


>  and do not makes sense active PSR2 to only do
> full screen updates aka PSR1.
> Having aux_frame_sync flag could cause it be set to true even when
> the PSR1 is being used, see intel_psr2_config_valid().
> 
> Cc: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 10 +-
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e27ba8fb64e6..8a584273f897 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -602,7 +602,6 @@ struct i915_psr {
>   struct delayed_work work;
>   unsigned busy_frontbuffer_bits;
>   bool psr2_support;
> - bool aux_frame_sync;
>   bool link_standby;
>   bool y_cord_support;
>   bool colorimetry_support;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 317cb4a12693..9811f5f0bc75 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -144,9 +144,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> _sync_cap) != 1)
>   frame_sync_cap = 0;
> - dev_priv->psr.aux_frame_sync = frame_sync_cap & 
> DP_AUX_FRAME_SYNC_CAP;
> + frame_sync_cap = (frame_sync_cap & DP_AUX_FRAME_SYNC_CAP);
>   /* PSR2 needs frame sync as well */
> - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> + dev_priv->psr.psr2_support = frame_sync_cap;
>   DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not 
> supported");
>  
> @@ -269,7 +269,7 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
>   aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
>  
>   /* Enable AUX frame sync at sink */
> - if (dev_priv->psr.aux_frame_sync)
> + if (dev_priv->psr.psr2_support)
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
>   DP_AUX_FRAME_SYNC_ENABLE);
> @@ -714,7 +714,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   i915_reg_t psr_status;
>   u32 psr_status_mask;
>  
> - if (dev_priv->psr.aux_frame_sync)
> + if (dev_priv->psr.psr2_support)
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
>   0);
> @@ -862,7 +862,7 @@ static void intel_psr_exit(struct drm_i915_private 
> *dev_priv)
>   return;
>  
>   if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.aux_frame_sync)
> + if (dev_priv->psr.psr2_support)
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
>   0);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915/psr: Rename intel_crtc_state has_psr to can_psr

[Pandiyan, Dhinakaran]

On Wed, 2018-03-14 at 15:36 -0700, José Roberto de Souza wrote:
> This value is a match of hardware and sink has PSR + if it can be
> enabled by the requested state, see intel_psr_compute_config().
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
>  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index a215aa78b0be..cccaf84415ab 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -807,8 +807,8 @@ struct intel_crtc_state {
>   struct intel_link_m_n dp_m2_n2;
>   bool has_drrs;
>  
> - bool has_psr;
> - bool has_psr2;
> + bool can_psr;
> + bool can_psr2;


I am not convinced by this change, the computed state either has PSR1 or
PSR2, "can" connotes ambiguity in my opinion.


I was thinking of converting this to an u8 psr = [0,1,2] to mean no PSR,
PSR1 and PSR2 respectively. We can do away with the has/can confusion :)

Using bool does save us 6 bits though depending on how the structure is
packed. 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915/psr: Enable aux frame sync in source

[Pandiyan, Dhinakaran]

On Wed, 2018-03-14 at 15:36 -0700, José Roberto de Souza wrote:
> Even with GTC not enabled lets send the aux frame sync.

If this was never enabled on the source side, why do we place a
requirement on the sink to support aux frame sync?



> Hardware is going to send dummy values but this way we can get rid of
> this workarround in PSR exit: 'drm/i915/psr: disable aux_frame_sync
> on psr2 exit'.
> Also moving the line disabling aux frame sync in sink to after report
> that PSR2 has exit to avoid.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 15 ++-
>  2 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e9fc1722c0fb..5a2364656aa5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4132,6 +4132,7 @@ enum {
>  #define EDP_PSR2_CTL _MMIO(0x6f900)
>  #define   EDP_PSR2_ENABLE(1<<31)
>  #define   EDP_SU_TRACK_ENABLE(1<<30)
> +#define   EDP_AUX_FRAME_SYNC_ENABLE  (1<<27)
>  #define   EDP_Y_COORDINATE_VALID (1<<26)
>  #define   EDP_Y_COORDINATE_ENABLE(1<<25)
>  #define   EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index d622e37894d4..7aab66b5bc91 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -418,6 +418,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* good enough. */
>   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>   val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> + val |= EDP_AUX_FRAME_SYNC_ENABLE;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
>   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> @@ -715,11 +716,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   i915_reg_t psr_status;
>   u32 psr_status_mask;
>  
> - if (dev_priv->psr.psr2_enabled)
> - drm_dp_dpcd_writeb(_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> - 0);
> -
>   if (dev_priv->psr.psr2_enabled) {
>   psr_status = EDP_PSR2_STATUS;
>   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> @@ -742,6 +738,11 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   2000))
>   DRM_ERROR("Timed out waiting for PSR Idle State\n");
>  
> + if (dev_priv->psr.psr2_enabled)
> + drm_dp_dpcd_writeb(_dp->aux,
> +DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> +0);
> +
>   dev_priv->psr.active = false;
>   } else {
>   if (dev_priv->psr.psr2_enabled)
> @@ -863,10 +864,6 @@ static void intel_psr_exit(struct drm_i915_private 
> *dev_priv)
>   return;
>  
>   if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_enabled)
> - drm_dp_dpcd_writeb(_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> - 0);
>   if (dev_priv->psr.psr2_enabled) {
>   val = I915_READ(EDP_PSR2_CTL);
>   WARN_ON(!(val & EDP_PSR2_ENABLE));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915/psr: Enable Y-coordinate support in source

[Pandiyan, Dhinakaran]

On Thu, 2018-03-15 at 17:28 -0700, Rodrigo Vivi wrote:
> drm/i915/cnl:
> 
> On Wed, Mar 14, 2018 at 03:36:14PM -0700, José Roberto de Souza wrote:
> > We are requiring that sink requires Y-coordinate but we are not
> > sending it in the main-link.
> 
> Also add on CNL here
> 
> > Even if hardware tracking isn't good enough it will not cause
> > any more issues enabling it.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 2 ++
> >  drivers/gpu/drm/i915/intel_psr.c | 4 ++--
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a15db41a208a..e9fc1722c0fb 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4132,6 +4132,8 @@ enum {
> >  #define EDP_PSR2_CTL   _MMIO(0x6f900)
> >  #define   EDP_PSR2_ENABLE  (1<<31)
> >  #define   EDP_SU_TRACK_ENABLE  (1<<30)
> > +#define   EDP_Y_COORDINATE_VALID   (1<<26)
> > +#define   EDP_Y_COORDINATE_ENABLE  (1<<25)
> 
> probably good add CNL_ prefix on these bits...
> 
> >  #define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)<<20)
> >  #define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> >  #define   EDP_PSR2_TP2_TIME_500(0<<8)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 62d97d5576d1..c9da1390a727 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -416,8 +416,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> > /* FIXME: selective update is probably totally broken because it doesn't
> >  * mesh at all with our frontbuffer tracking. And the hw alone isn't
> >  * good enough. */
> > -   val |= EDP_PSR2_ENABLE |
> > -   EDP_SU_TRACK_ENABLE;
> > +   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > +   val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> 
> if (INTEL_GEN(dev_priv) >= 10)
>   val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> 
> since those bits were reserved before CNL.
> 

How does this work on pre-CNL platforms without the enable bit?

> With those changes:
> 
> Reviewed-by: Rodrigo Vivi 
> 
> >  
> > if (drm_dp_dpcd_readb(_dp->aux,
> > DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> > -- 
> > 2.16.2
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+

[Pandiyan, Dhinakaran]

On Mon, 2018-03-05 at 19:41 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We don't use the enum i9xx_plane_id namespace on SKL+ anymore, so
> do not initialize the related plane_to_crtc_mapping[] table either.
> 
> Actually the only remaining user of that table is the pre-g4x
> watermark code, but no harm in initializing the table on all
> pre-SKL platforms.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index fb08590b4d40..435462bfc719 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13572,10 +13572,17 @@ static int intel_crtc_init(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   /* initialize shared scalers */
>   intel_crtc_init_scalers(intel_crtc, crtc_state);
>  
> - BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
> -dev_priv->plane_to_crtc_mapping[primary->i9xx_plane] != NULL);
> - dev_priv->plane_to_crtc_mapping[primary->i9xx_plane] = intel_crtc;
> - dev_priv->pipe_to_crtc_mapping[intel_crtc->pipe] = intel_crtc;
> + BUG_ON(pipe >= ARRAY_SIZE(dev_priv->pipe_to_crtc_mapping) ||
> +dev_priv->pipe_to_crtc_mapping[pipe] != NULL);
> + dev_priv->pipe_to_crtc_mapping[pipe] = intel_crtc;
> +
> + if (INTEL_GEN(dev_priv) < 9) {
> + enum i9xx_plane_id i9xx_plane = primary->i9xx_plane;
> +
> + BUG_ON(i9xx_plane >= 
> ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
> +dev_priv->plane_to_crtc_mapping[i9xx_plane] != NULL);
> + dev_priv->plane_to_crtc_mapping[i9xx_plane] = intel_crtc;


Verified that plane_to_crtc_mapping[i9xx_plane] is used only in pre-gen9
code. Patch looks harmless 
Reviewed-by: Dhinakaran Pandiyan 

Should intel_get_crtc_for_plane be renamed to i9xx_get_crtc_for_plane()?
and the table as i9xx_plane_to_crtc_mapping[]?





> + }
>  
>   drm_crtc_helper_add(_crtc->base, _helper_funcs);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

[Pandiyan, Dhinakaran]

On Wed, 2018-03-14 at 23:09 +0100, Hans de Goede wrote:
> Hi,
> 
> On 14-03-18 21:49, Pandiyan, Dhinakaran wrote:
> > 
> > On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 12-02-18 18:42, Pandiyan, Dhinakaran wrote:
> >>> On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote:
> >>>> Hi,
> >>>>
> >>>> On 12-02-18 07:08, Dhinakaran Pandiyan wrote:
> >>>>> PSR currently when enabled results in semi-permanent freezes or 
> >>>>> noticeable
> >>>>> cursor lags.
> >>>>>
> >>>>> https://patchwork.freedesktop.org/series/37598/ will fix long freezes 
> >>>>> due
> >>>>> to frame counter resets.
> >>>>>
> >>>>> This series has three more fixes -
> >>>>> Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do 
> >>>>> it.
> >>>>> Patch 2 fixes cusor move lag by relying on HW to exit PSR.
> >>>>> Patch 3 fixes temporary freeze seen with fbdev.
> >>>>>
> >>>>> With both the series applied, PSR on my SKL ThinkPad feels pretty good.
> >>>>
> >>>> Thank you for your great work on this.
> >>>>
> >>>> Are there any more PSR fixes in the pipeline?
> >>>
> >>> Yeah, there are a few more fixes that I hope will appear on the list in
> >>> the next two weeks or so.
> >>
> >> Ok, can you send a mail when you're done (in sofar any software is ever
> >> "done") and you would like me to ask all people who have been kind enough
> >> to test PSR to retest ?
> >>
> > 
> > Hi Hans,
> > 
> > Thanks for your patience and help. I believe the current drm-tip is in a
> > decent shape to retest PSR. Booting with i915.enable_psr = 1 is still
> > needed. The fixes have been mostly developed/tested on gen-9 hardware
> > but they apply to other platforms too.
> 
> Cool, thank you. Current drm-tip will all be merged into 4.17-rc1, right?

Rodrigo,

Can you help me answer that?


> 
> Then I think I will just wait for that, most distros already provide rc builds
> for testing, so that way it will be easy for people to test.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> > 
> > -DK
> > 
> >>>> If not I think I should do
> >>>> a custom Fedora kernel build based on 4.15 + recent fixes and ask all my
> >>>> testers to retest with that.
> >>>>
> >>>> I do have some questions before I do this:
> >>>>
> >>>> 1) I believe that only testers with skylake (normal or LP) or newer 
> >>>> should
> >>>> re-test, correct?
> >>>
> >>> These fixes do apply for HSW/BDW, so essentially all the big cores
> >>> supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction
> >>> also. I haven't looked into CHV/VLV.
> >>>
> >>>>
> >>>> 2) I know there are 2 series (including this one), can someone provide a 
> >>>> link
> >>>> to the latest patchwork version of those 2 series, or even better a git
> >>>> branch with 4.15 + those patches? Any patches I'm missing if I pick up 
> >>>> these
> >>>> 2 series?
> >>>
> >>> https://patchwork.freedesktop.org/series/37598/
> >>> https://patchwork.freedesktop.org/series/38067/
> >>>
> >>>
> >>>> 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel 
> >>>> instead
> >>>> if that would be better, would that be better ?
> >>>
> >>> I can't think of any diff that would affect PSR, but the latest is
> >>> better I suppose.
> >>
> >> Ok.
> >>
> >> Regards,
> >>
> >> Hans
> >> ___
> >> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-14 at 13:47 -0700, Rodrigo Vivi wrote:
> On Wed, Mar 14, 2018 at 01:24:13PM -0700, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote:
> > > The immediate enabling is actually not an issue for the
> > > HW perspective for core platforms that have HW tracking.
> > > HW will wait few identical idle frames before transitioning
> > > to actual psr active anyways.
> > > 
> > > Note that this patch also remove the delayed activation
> > > on HSW and BDW introduced by commit 'd0ac896a477d
> > > ("drm/i915: Delay first PSR activation.")'. This was
> > > introduced to fix a blank screen on VLV/CHV and also
> > > masked some frozen screens on other core platforms.
> > > Probably the same that we are now properly hunting and fixing.
> > > 
> > > Furthermore, if we stop using delayed activation on core
> > > platforms we will be able, on following up patches,
> > > to use available workarounds to make HW tracking properly
> > > exit PSR instead of the big nuke of disabling psr and
> > > re-enable on exit and activate respectively.
> > > At least on few reliable cases.
> > > 
> > > v2:(DK): Remove unnecessary WARN_ONs and make some other
> > >VLV | CHV more readable.
> > > v3: Do it regardless the timer rework.
> > > v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
> > > v5: Kill remaining items and fully rework activation functions.
> > > 
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c |  20 +++---
> > >  drivers/gpu/drm/i915/i915_drv.h |   3 +-
> > >  drivers/gpu/drm/i915/intel_psr.c| 134 
> > > ++--
> > >  3 files changed, 65 insertions(+), 92 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 972014b2497d..7dfada863f9c 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2567,15 +2567,14 @@ static int i915_edp_psr_status(struct seq_file 
> > > *m, void *data)
> > >   seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > >   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > >  dev_priv->psr.busy_frontbuffer_bits);
> > > - seq_printf(m, "Re-enable work scheduled: %s\n",
> > > -yesno(work_busy(_priv->psr.work.work)));
> > >  
> > > - if (HAS_DDI(dev_priv)) {
> > > - if (dev_priv->psr.psr2_support)
> > > - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > > - else
> > > - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > > - } else {
> > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > + bool scheduled;
> > > +
> > > + scheduled = work_busy(_priv->psr.vlv_activate_work.work);
> > > + seq_printf(m, "Re-enable work scheduled: %s\n",
> > > +yesno(scheduled));
> > > +
> > >   for_each_pipe(dev_priv, pipe) {
> > >   enum transcoder cpu_transcoder =
> > >   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > > @@ -2594,6 +2593,11 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > > void *data)
> > >  
> > >   intel_display_power_put(dev_priv, power_domain);
> > >   }
> > > + } else {
> > > + if (dev_priv->psr.psr2_support)
> > > + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > > + else
> > > + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > >   }
> > >  
> > >   seq_printf(m, "Main link in standby mode: %s\n",
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 74b0e9d8ff62..409997f29e07 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -598,7 +598,7 @@ struct i915_psr {
> > >   bool sink_support;
> > >   struct intel_dp *enabled;
> > >   bool active;
> >

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

[Pandiyan, Dhinakaran]

On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote:
> Hi,
> 
> On 12-02-18 18:42, Pandiyan, Dhinakaran wrote:
> > On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 12-02-18 07:08, Dhinakaran Pandiyan wrote:
> >>> PSR currently when enabled results in semi-permanent freezes or noticeable
> >>> cursor lags.
> >>>
> >>> https://patchwork.freedesktop.org/series/37598/ will fix long freezes due
> >>> to frame counter resets.
> >>>
> >>> This series has three more fixes -
> >>> Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do 
> >>> it.
> >>> Patch 2 fixes cusor move lag by relying on HW to exit PSR.
> >>> Patch 3 fixes temporary freeze seen with fbdev.
> >>>
> >>> With both the series applied, PSR on my SKL ThinkPad feels pretty good.
> >>
> >> Thank you for your great work on this.
> >>
> >> Are there any more PSR fixes in the pipeline?
> > 
> > Yeah, there are a few more fixes that I hope will appear on the list in
> > the next two weeks or so.
> 
> Ok, can you send a mail when you're done (in sofar any software is ever
> "done") and you would like me to ask all people who have been kind enough
> to test PSR to retest ?
> 

Hi Hans,

Thanks for your patience and help. I believe the current drm-tip is in a
decent shape to retest PSR. Booting with i915.enable_psr = 1 is still
needed. The fixes have been mostly developed/tested on gen-9 hardware
but they apply to other platforms too.

-DK

> >> If not I think I should do
> >> a custom Fedora kernel build based on 4.15 + recent fixes and ask all my
> >> testers to retest with that.
> >>
> >> I do have some questions before I do this:
> >>
> >> 1) I believe that only testers with skylake (normal or LP) or newer should
> >> re-test, correct?
> > 
> > These fixes do apply for HSW/BDW, so essentially all the big cores
> > supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction
> > also. I haven't looked into CHV/VLV.
> > 
> >>
> >> 2) I know there are 2 series (including this one), can someone provide a 
> >> link
> >> to the latest patchwork version of those 2 series, or even better a git
> >> branch with 4.15 + those patches? Any patches I'm missing if I pick up 
> >> these
> >> 2 series?
> > 
> > https://patchwork.freedesktop.org/series/37598/
> > https://patchwork.freedesktop.org/series/38067/
> > 
> > 
> >> 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel 
> >> instead
> >> if that would be better, would that be better ?
> > 
> > I can't think of any diff that would affect PSR, but the latest is
> > better I suppose.
> 
> Ok.
> 
> Regards,
> 
> Hans
> ___
> 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] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.

[Pandiyan, Dhinakaran]

On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote:
> The immediate enabling is actually not an issue for the
> HW perspective for core platforms that have HW tracking.
> HW will wait few identical idle frames before transitioning
> to actual psr active anyways.
> 
> Note that this patch also remove the delayed activation
> on HSW and BDW introduced by commit 'd0ac896a477d
> ("drm/i915: Delay first PSR activation.")'. This was
> introduced to fix a blank screen on VLV/CHV and also
> masked some frozen screens on other core platforms.
> Probably the same that we are now properly hunting and fixing.
> 
> Furthermore, if we stop using delayed activation on core
> platforms we will be able, on following up patches,
> to use available workarounds to make HW tracking properly
> exit PSR instead of the big nuke of disabling psr and
> re-enable on exit and activate respectively.
> At least on few reliable cases.
> 
> v2:(DK): Remove unnecessary WARN_ONs and make some other
>VLV | CHV more readable.
> v3: Do it regardless the timer rework.
> v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
> v5: Kill remaining items and fully rework activation functions.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  20 +++---
>  drivers/gpu/drm/i915/i915_drv.h |   3 +-
>  drivers/gpu/drm/i915/intel_psr.c| 134 
> ++--
>  3 files changed, 65 insertions(+), 92 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 972014b2497d..7dfada863f9c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2567,15 +2567,14 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
>  
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_support)
> - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> - else
> - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> - } else {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + bool scheduled;
> +
> + scheduled = work_busy(_priv->psr.vlv_activate_work.work);
> + seq_printf(m, "Re-enable work scheduled: %s\n",
> +yesno(scheduled));
> +
>   for_each_pipe(dev_priv, pipe) {
>   enum transcoder cpu_transcoder =
>   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> @@ -2594,6 +2593,11 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>  
>   intel_display_power_put(dev_priv, power_domain);
>   }
> + } else {
> + if (dev_priv->psr.psr2_support)
> + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> + else
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>   }
>  
>   seq_printf(m, "Main link in standby mode: %s\n",
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 74b0e9d8ff62..409997f29e07 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -598,7 +598,7 @@ struct i915_psr {
>   bool sink_support;
>   struct intel_dp *enabled;
>   bool active;
> - struct delayed_work work;
> + struct delayed_work vlv_activate_work;
>   unsigned busy_frontbuffer_bits;
>   bool psr2_support;
>   bool aux_frame_sync;
> @@ -613,7 +613,6 @@ struct i915_psr {
>   void (*disable_source)(struct intel_dp *,
>  const struct intel_crtc_state *);
>   void (*enable_sink)(struct intel_dp *);
> - void (*activate)(struct intel_dp *);
>   void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 317cb4a12693..bc7b94a06417 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -311,24 +311,6 @@ static void vlv_psr_enable_source(struct intel_dp 
> *intel_dp,
>  VLV_EDP_PSR_ENABLE);
>  }
>  
> -static void vlv_psr_activate(struct intel_dp *intel_dp)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_crtc *crtc = dig_port->base.base.crtc;
> - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> -
> - /*
> -  * Let's 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote:
> > If bios sets up an MST output and hardware state readout code sees this is
> > an SST configuration, when disabling the encoder we end up calling
> > ->post_disable_dp() hook instead of the MST version. Consequently, we write
> > to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
> > enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
> > the MST hub. This results in continuous link training failures which keep
> > the system busy delaying boot. We could identify bios MST boot discrepancy
> > and handle it accordingly but a simple way to solve this is to write to the
> > DP_SET_POWER dpcd for MST too.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
> > Cc: Ville Syrjälä 
> > Cc: Jani Nikula 

Reported-by: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message
transactions for dpms control")

> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index dbcf1a0586f9..8c2d778560f0 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2205,8 +2205,7 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder, crtc_state);
> >  
> > intel_ddi_init_dp_buf_reg(encoder);
> > -   if (!is_mst)
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> 
> The spec is perhaps a bit unclear on this. 
> 
> "If the message is sent as a path request, all DP nodes from the source
>  immediate downstream device and the targeted DP node will be placed in
>  the D0 power state."
> 
> Doesn't quite tell me whether the immediate downstream device is
> included in that list of nodes.
> 
> However the spec goes on to say
> "Each nodes immediate upstream device will use Native AUX writes to the
>  SET_POWER & SET_DP_PWR_VOLTAGE register (DPCD Address 00600h) to set
>  the power state of the downstream node."
> 
> and since we are the immediate upstream for that device I guess it makes
> sense that we should still do the DP_SET_POWER manually.
> 
> But I have to wonder what the original issue was before we started to use
> POWER_UP/DOWN_PHY. I suppose somehow some further downstream device
> wasn't in D0 when we needed it.

Correct, sinks farther downstream weren't lighting up.

>  But that is a bit weird as I believe all
> devices should really start up in D0.
> 
> Anyways based on my reading of the spec I can justify this so
> Reviewed-by: Ville Syrjälä 
> 

Thanks for the review.

> I presume we want cc:stable + fixes: on this?

Yeah, I suppose we should wait for the reporter to confirm that this
indeed fixes the bug. It does fix the problem on the Thinkpad laptop +
dock I tested it on.


> 
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -2304,14 +2303,12 @@ static void intel_ddi_post_disable_dp(struct 
> > intel_encoder *encoder,
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > struct intel_dp *intel_dp = _port->dp;
> > -   bool is_mst = intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST);
> >  
> > /*
> >  * Power down sink before disabling the port, otherwise we end
> >  * up getting interrupts from the sink on detecting link loss.
> >  */
> > -   if (!is_mst)
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >  
> > intel_disable_ddi_buf(encoder);
> >  
> > -- 
> > 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

[Pandiyan, Dhinakaran]

On Tue, 2018-03-13 at 04:23 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's 
> own function.
> URL   : https://patchwork.freedesktop.org/series/39825/
> State : warning
> 
> == Summary ==
> 
> Series 39825v1 series starting with [1/2] drm/i915/psr: Move PSR aux setup to 
> it's own function.
> https://patchwork.freedesktop.org/api/1.0/series/39825/revisions/1/mbox/
> 
>  Possible new issues:
> 
> Test drv_module_reload:
> Subgroup basic-reload:
> pass   -> DMESG-WARN (fi-elk-e7500)

Platform does not have PSR, error looks spurious.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Use more PSR HW tracking.

[Pandiyan, Dhinakaran]

On Mon, 2018-03-12 at 23:16 +, Souza, Jose wrote:
> What if FBC is disabled? Or FBC can not be activate by any of the
> reasons in intel_fbc_can_activate(). The hardware tracking would never
> trigger a PSR exit by it self?!
> 

Only frontbuffer tracking is tied to FBC, PSR exit on plane/pipe MMIO
writes, vblank enable should happen even without FBC.



> On Tue, 2018-03-06 at 19:34 -0800, Dhinakaran Pandiyan wrote:
> > From: Rodrigo Vivi 
> > 
> > So far we are using frontbuffer tracking for everything
> > and ignoring that PSR has a HW capable HW tracking for many
> > modern usages of GPU on Core platforms and newer Atom ones.
> > 
> > One reason for that is that we were trying to keep same
> > infrastructure in place for VLV/CHV than the rest of platforms.
> > But also because when this infrastructure was created
> > the front-buffer-tracking origin wasn't that good and stable
> > how it is today after Paulo reworked it to attend FBC cases.
> > 
> > However this PSR implementation without HW tracking died
> > on gen8LP. And newer platforms are starting to demand more HW
> > tracking specially with PSR2 cases in mind.
> > 
> > By disabling and re-enabling PSR totally every time we believe
> > someone is going to change the front buffer content we don't
> > allow PSR HW tracking to do this job and specially compromising
> > the whole idea of PSR2 case where the HW tracking detect only
> > the damaged area and do a partial screen update.
> > 
> > So, from now on, on the platforms that has hw_tracking let's
> > rely more on HW tracking.
> > 
> > This also is the case in used by other drivers and more validated
> > by SV teams. So I hope that this will lead us to less misterious
> > bugs.
> > 
> > v2: Only do this for platform that actually has hw tracking.
> > 
> > v3 from DK
> > Do this only for flips, small gradual changes are better.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Jim Bride 
> > Cc: Vathsala Nagaraju 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >  drivers/gpu/drm/i915/intel_frontbuffer.c |  2 +-
> >  drivers/gpu/drm/i915/intel_psr.c | 10 +-
> >  4 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7eec99d7fad4..6aab929f354c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -772,6 +772,7 @@ struct i915_psr {
> > bool y_cord_support;
> > bool colorimetry_support;
> > bool alpm;
> > +   bool has_hw_tracking;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1a7c5addcec3..fdf7dd100dfe 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1873,7 +1873,8 @@ void intel_psr_enable(struct intel_dp
> > *intel_dp,
> >  void intel_psr_disable(struct intel_dp *intel_dp,
> >   const struct intel_crtc_state
> > *old_crtc_state);
> >  void intel_psr_invalidate(struct drm_i915_private *dev_priv,
> > - unsigned frontbuffer_bits);
> > + unsigned frontbuffer_bits,
> > + enum fb_op_origin origin);
> >  void intel_psr_flush(struct drm_i915_private *dev_priv,
> >  unsigned frontbuffer_bits,
> >  enum fb_op_origin origin);
> > diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> > b/drivers/gpu/drm/i915/intel_frontbuffer.c
> > index 3a8d3d06c26a..7fff0a0eceb4 100644
> > --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> > @@ -80,7 +80,7 @@ void __intel_fb_obj_invalidate(struct
> > drm_i915_gem_object *obj,
> > }
> >  
> > might_sleep();
> > -   intel_psr_invalidate(dev_priv, frontbuffer_bits);
> > +   intel_psr_invalidate(dev_priv, frontbuffer_bits, origin);
> > intel_edp_drrs_invalidate(dev_priv, frontbuffer_bits);
> > intel_fbc_invalidate(dev_priv, frontbuffer_bits, origin);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 05770790a4e9..16b77e19c28e 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -948,6 +948,7 @@ void intel_psr_single_frame_update(struct
> > drm_i915_private *dev_priv,
> >   * intel_psr_invalidate - Invalidade PSR
> >   * @dev_priv: i915 device
> >   * @frontbuffer_bits: frontbuffer plane tracking bits
> > + * @origin: which operation caused the invalidate
> >   *
> >   * Since the hardware frontbuffer tracking has gaps we 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Kill scheduled work for Core platforms.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 17:17 -0800, Rodrigo Vivi wrote:
> The immediate enabling is actually not an issue for the
> HW perspective for core platforms that have HW tracking.
> HW will wait few identical idle frames before transitioning
> to actual psr active anyways.
> 
> Note that this patch also remove the delayed activation
> on HSW and BDW introduced by commit 'd0ac896a477d
> ("drm/i915: Delay first PSR activation.")'. This was
> introduced to fix a blank screen on VLV/CHV and also
> masked some frozen screens on other core platforms.
> Probably the same that we are now properly hunting and fixing.
> 
> Furthermore, if we stop using delayed activation on core
> platforms we will be able, on following up patches,
> to use available workarounds to make HW tracking properly
> exit PSR instead of the big nuke of disabling psr and
> re-enable on exit and activate respectively.
> At least on few reliable cases.
> 
> v2:(DK): Remove unnecessary WARN_ONs and make some other
>VLV | CHV more readable.
> v3: Do it regardless the timer rework.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 17 +
>  drivers/gpu/drm/i915/intel_psr.c| 22 ++
>  2 files changed, 23 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e838c765b251..2fd6f98364d3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2572,15 +2572,11 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
>  
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_support)
> - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> - else
> - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> - } else {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + seq_printf(m, "Re-enable work scheduled: %s\n",
> +yesno(work_busy(_priv->psr.work.work)));
> +
>   for_each_pipe(dev_priv, pipe) {
>   enum transcoder cpu_transcoder =
>   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> @@ -2599,6 +2595,11 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>  
>   intel_display_power_put(dev_priv, power_domain);
>   }
> + } else {
> + if (dev_priv->psr.psr2_support)
> + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> + else
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>   }
>  
>   seq_printf(m, "Main link in standby mode: %s\n",
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index b0286722a72f..9705d89c5ebf 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -652,9 +652,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   dev_priv->psr.enable_source(intel_dp, crtc_state);
>   dev_priv->psr.enabled = intel_dp;
>  
> - if (INTEL_GEN(dev_priv) >= 9) {
> - intel_psr_activate(intel_dp);
> - } else {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   /*
>* FIXME: Activation should happen immediately since this
>* function is just called after pipe is fully trained and
> @@ -667,6 +665,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>*/
>   schedule_delayed_work(_priv->psr.work,
> 
> msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> + } else {
> + intel_psr_activate(intel_dp);
>   }
>  

I think we should split this into a separate patch.

>  unlock:
> @@ -1045,10 +1045,15 @@ void intel_psr_flush(struct drm_i915_private 
> *dev_priv,
>   }
>   }
>  
> - if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> - if (!work_busy(_priv->psr.work.work))
> - schedule_delayed_work(_priv->psr.work,
> -   msecs_to_jiffies(100));
> + if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + if (!work_busy(_priv->psr.work.work))


These conditions have become extremely hard to read, we need to rework
them into functions and/or re-evaluate some of the conditions. I don't
follow the logic 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Pandiyan, Dhinakaran]

On Mon, 2018-03-12 at 20:49 +0200, Ville Syrjälä wrote:
> On Mon, Mar 12, 2018 at 06:40:26PM +0000, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Mon, 2018-03-12 at 20:29 +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 08, 2018 at 04:52:18PM -0800, Rodrigo Vivi wrote:
> > > > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > > > the CPU host modify writes may not get updated on the Display
> > > > as expected.
> > > > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > > > host modify write to trigger PSR exit."
> > > > 
> > > > We can also find on spec other cases where they describe
> > > > bogus writes to cursor registers to force PSR exit with
> > > > HW tracking. And it was confirmed by HW engineers that
> > > > this Wa can be safely applied for any frontbuffer activity.
> > > > 
> > > > So let's use this more and more here instead of forcibly
> > > > disable and re-enable PSR everytime that we have a simple
> > > > reliable flush case.
> > > > 
> > > > Other commits improve the fbcon/fbdev use a lot, but this
> > > > approach is the only when where we can get a fully reliable
> > > > console with no slowness or missed frames and PSR still
> > > > enabled and active.
> > > > 
> > > > v2: - Rebase on drm-tip
> > > > - (DK) Add a comment to explain that WA
> > > > tells about writing 0 to CUR_SURFLIVE_A but we write to
> > > > CUR_SURFLIVE(pipe).
> > > > v3: Wa doesn't work on PSR2.
> > > > 
> > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> > > >  drivers/gpu/drm/i915/intel_psr.c | 19 +--
> > > >  2 files changed, 20 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index e6a8c0ee7df1..abdc513a9edd 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -6032,6 +6032,9 @@ enum {
> > > >  #define IVB_CURSOR_B_OFFSET 0x71080
> > > >  #define IVB_CURSOR_C_OFFSET 0x72080
> > > >  
> > > > +#define _CUR_SURLIVE   0x700AC
> > > > +#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
> > > 
> > > There should be a better place for this.
> > > 
> > > > +
> > > >  /* Display A control */
> > > >  #define _DSPACNTR  0x70180
> > > >  #define   DISPLAY_PLANE_ENABLE (1<<31)
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 30932527e663..b0286722a72f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private 
> > > > *dev_priv,
> > > > dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> > > >  
> > > > /* By definition flush = invalidate + flush */
> > > > -   if (frontbuffer_bits)
> > > > -   intel_psr_exit(dev_priv);
> > > > +   if (frontbuffer_bits) {
> > > > +   if (dev_priv->psr.psr2_support ||
> > > > +   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) 
> > > > {
> > > > +   intel_psr_exit(dev_priv);
> > > > +   } else {
> > > > +   /*
> > > > +* Display WA #0884: all
> > > > +* This documented WA for bxt can be safely 
> > > > applied
> > > > +* broadly so we can force HW tracking to exit 
> > > > PSR
> > > > +* instead of disabling and re-enabling.
> > > > +* Workaround tells us to write 0 to 
> > > > CUR_SURLIVE_A,
> > > > +* but it makes more sense write to the current 
> > > > active
> > > > +

Re: [Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Pandiyan, Dhinakaran]

On Mon, 2018-03-12 at 11:45 -0700, Rodrigo Vivi wrote:
> On Mon, Mar 12, 2018 at 11:07:55AM -0700, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Thu, 2018-03-08 at 16:52 -0800, Rodrigo Vivi wrote:
> > > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > > the CPU host modify writes may not get updated on the Display
> > > as expected.
> > > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > > host modify write to trigger PSR exit."
> > > 
> > > We can also find on spec other cases where they describe
> > > bogus writes to cursor registers to force PSR exit with
> > > HW tracking. And it was confirmed by HW engineers that
> > > this Wa can be safely applied for any frontbuffer activity.
> > > 
> > > So let's use this more and more here instead of forcibly
> > > disable and re-enable PSR everytime that we have a simple
> > > reliable flush case.
> > > 
> > > Other commits improve the fbcon/fbdev use a lot, but this
> > > approach is the only when where we can get a fully reliable
> > > console with no slowness or missed frames and PSR still
> > > enabled and active.
> > > 
> > > v2: - Rebase on drm-tip
> > > - (DK) Add a comment to explain that WA
> > > tells about writing 0 to CUR_SURFLIVE_A but we write to
> > > CUR_SURFLIVE(pipe).
> > > v3: Wa doesn't work on PSR2.
> > > 
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> > >  drivers/gpu/drm/i915/intel_psr.c | 19 +--
> > >  2 files changed, 20 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index e6a8c0ee7df1..abdc513a9edd 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6032,6 +6032,9 @@ enum {
> > >  #define IVB_CURSOR_B_OFFSET 0x71080
> > >  #define IVB_CURSOR_C_OFFSET 0x72080
> > >  
> > > +#define _CUR_SURLIVE 0x700AC
> > > +#define CUR_SURLIVE(pipe)_CURSOR2(pipe, _CUR_SURLIVE)
> > > +
> > >  /* Display A control */
> > >  #define _DSPACNTR0x70180
> > >  #define   DISPLAY_PLANE_ENABLE   (1<<31)
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 30932527e663..b0286722a72f 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private 
> > > *dev_priv,
> > >   dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> > >  
> > >   /* By definition flush = invalidate + flush */
> > > - if (frontbuffer_bits)
> > > - intel_psr_exit(dev_priv);
> > > + if (frontbuffer_bits) {
> > > + if (dev_priv->psr.psr2_support ||
> > > + IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > 
> > I forgot if I asked you already about this, why not
> > psr.has_hw_tracking? 
> 
> because we don't have that yet ;)
> 
> I wonder if we should do this change in a separated patch
> 
> > 
> > My interpretation of the flag is - any platform that can exit PSR by 
> > - driver writing to some pipe/plane MMIO
> > - HW tracking frontbuffer modifications
> > - enabling vblanks 
> > 
> > The patch works well on my SKL laptop with fbcon.
> > 
> > Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> 
> Thanks. Pushed to dinq.
> 
Can the frontbuffer patches
(https://patchwork.freedesktop.org/series/39502/) be pushed too? We
should have PSR usable on SKL with the frontbuffer patches on top of
this one.



> > 
> > 
> > 
> > 
> > 
> > > + intel_psr_exit(dev_priv);
> > > + } else {
> > > + /*
> > > +  * Display WA #0884: all
> > > +  * This documented WA for bxt can be safely applied
> > > +  * broadly so we can force HW tracking to exit PSR
> > > +  * instead of disabling and re-enabling.
> > > +  * Workaround tells us to write 0 to CUR_SURLIVE_A,
> > > +  * but it makes more sense write to the current active
> > > +  * pipe.
> > > +  */
> > > + I915_WRITE(CUR_SURLIVE(pipe), 0);
> > > + }
> > > + }
> > >  
> > >   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> > >   if (!work_busy(_priv->psr.work.work))
> ___
> 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] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Pandiyan, Dhinakaran]

On Mon, 2018-03-12 at 20:29 +0200, Ville Syrjälä wrote:
> On Thu, Mar 08, 2018 at 04:52:18PM -0800, Rodrigo Vivi wrote:
> > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > the CPU host modify writes may not get updated on the Display
> > as expected.
> > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > host modify write to trigger PSR exit."
> > 
> > We can also find on spec other cases where they describe
> > bogus writes to cursor registers to force PSR exit with
> > HW tracking. And it was confirmed by HW engineers that
> > this Wa can be safely applied for any frontbuffer activity.
> > 
> > So let's use this more and more here instead of forcibly
> > disable and re-enable PSR everytime that we have a simple
> > reliable flush case.
> > 
> > Other commits improve the fbcon/fbdev use a lot, but this
> > approach is the only when where we can get a fully reliable
> > console with no slowness or missed frames and PSR still
> > enabled and active.
> > 
> > v2: - Rebase on drm-tip
> > - (DK) Add a comment to explain that WA
> > tells about writing 0 to CUR_SURFLIVE_A but we write to
> > CUR_SURFLIVE(pipe).
> > v3: Wa doesn't work on PSR2.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c | 19 +--
> >  2 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e6a8c0ee7df1..abdc513a9edd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6032,6 +6032,9 @@ enum {
> >  #define IVB_CURSOR_B_OFFSET 0x71080
> >  #define IVB_CURSOR_C_OFFSET 0x72080
> >  
> > +#define _CUR_SURLIVE   0x700AC
> > +#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
> 
> There should be a better place for this.
> 
> > +
> >  /* Display A control */
> >  #define _DSPACNTR  0x70180
> >  #define   DISPLAY_PLANE_ENABLE (1<<31)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 30932527e663..b0286722a72f 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private 
> > *dev_priv,
> > dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >  
> > /* By definition flush = invalidate + flush */
> > -   if (frontbuffer_bits)
> > -   intel_psr_exit(dev_priv);
> > +   if (frontbuffer_bits) {
> > +   if (dev_priv->psr.psr2_support ||
> > +   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > +   intel_psr_exit(dev_priv);
> > +   } else {
> > +   /*
> > +* Display WA #0884: all
> > +* This documented WA for bxt can be safely applied
> > +* broadly so we can force HW tracking to exit PSR
> > +* instead of disabling and re-enabling.
> > +* Workaround tells us to write 0 to CUR_SURLIVE_A,
> > +* but it makes more sense write to the current active
> > +* pipe.
> > +*/
> 
> Might want to note that SURFLIVE is read only so the write should not
> not have any other side effects, or at least I hope that is the case.
> 
> I don't really understand why we're doing PSR exit in the frontbuffer
> flush though. Shouldn't we have already exited on invalidate?

fbdev code doesn't call invalidate at all and cannot call because the
buffer modification functions are all in atomic contexts.


> 
> > +   I915_WRITE(CUR_SURLIVE(pipe), 0);
> > +   }
> > +   }
> >  
> > if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> > if (!work_busy(_priv->psr.work.work))
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Kill scheduled work for Core platforms.

[Pandiyan, Dhinakaran]

On Fri, 2018-03-09 at 01:42 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/psr: Kill scheduled work for Core platforms.
> URL   : https://patchwork.freedesktop.org/series/39650/
> State : failure
> 
> == Summary ==
> 
> Applying: drm/i915/psr: Kill scheduled work for Core platforms.
> error: sha1 information is lacking or useless 
> (drivers/gpu/drm/i915/intel_psr.c).
> error: could not build fake ancestor
> Patch failed at 0001 drm/i915/psr: Kill scheduled work for Core platforms.

Was this supposed to be applied on another patch?


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

Re: [Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 16:52 -0800, Rodrigo Vivi wrote:
> WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> the CPU host modify writes may not get updated on the Display
> as expected.
> WA: Write 0x to CUR_SURFLIVE_A with every CPU
> host modify write to trigger PSR exit."
> 
> We can also find on spec other cases where they describe
> bogus writes to cursor registers to force PSR exit with
> HW tracking. And it was confirmed by HW engineers that
> this Wa can be safely applied for any frontbuffer activity.
> 
> So let's use this more and more here instead of forcibly
> disable and re-enable PSR everytime that we have a simple
> reliable flush case.
> 
> Other commits improve the fbcon/fbdev use a lot, but this
> approach is the only when where we can get a fully reliable
> console with no slowness or missed frames and PSR still
> enabled and active.
> 
> v2: - Rebase on drm-tip
> - (DK) Add a comment to explain that WA
> tells about writing 0 to CUR_SURFLIVE_A but we write to
> CUR_SURFLIVE(pipe).
> v3: Wa doesn't work on PSR2.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
>  drivers/gpu/drm/i915/intel_psr.c | 19 +--
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e6a8c0ee7df1..abdc513a9edd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6032,6 +6032,9 @@ enum {
>  #define IVB_CURSOR_B_OFFSET 0x71080
>  #define IVB_CURSOR_C_OFFSET 0x72080
>  
> +#define _CUR_SURLIVE 0x700AC
> +#define CUR_SURLIVE(pipe)_CURSOR2(pipe, _CUR_SURLIVE)
> +
>  /* Display A control */
>  #define _DSPACNTR0x70180
>  #define   DISPLAY_PLANE_ENABLE   (1<<31)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 30932527e663..b0286722a72f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
>  
>   /* By definition flush = invalidate + flush */
> - if (frontbuffer_bits)
> - intel_psr_exit(dev_priv);
> + if (frontbuffer_bits) {
> + if (dev_priv->psr.psr2_support ||
> + IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {

I forgot if I asked you already about this, why not
psr.has_hw_tracking? 

My interpretation of the flag is - any platform that can exit PSR by 
- driver writing to some pipe/plane MMIO
- HW tracking frontbuffer modifications
- enabling vblanks 

The patch works well on my SKL laptop with fbcon.

Reviewed-by: Dhinakaran Pandiyan 





> + intel_psr_exit(dev_priv);
> + } else {
> + /*
> +  * Display WA #0884: all
> +  * This documented WA for bxt can be safely applied
> +  * broadly so we can force HW tracking to exit PSR
> +  * instead of disabling and re-enabling.
> +  * Workaround tells us to write 0 to CUR_SURLIVE_A,
> +  * but it makes more sense write to the current active
> +  * pipe.
> +  */
> + I915_WRITE(CUR_SURLIVE(pipe), 0);
> + }
> + }
>  
>   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
>   if (!work_busy(_priv->psr.work.work))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 15:34 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > plane MMIOs are written to. But this flush should not be necessary for
> > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > for FBC, the spec says "Flips or changes to plane size and panning" cause
> > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > cursor updates in their frontbuffer_flush implementations.
> > > 
> > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > "Compressing: yes" when I move the cursor around.
> > > 
> > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Ville Syrjälä 
> > > Cc: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 91ce8a0522a3..18b08e263ee1 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > *plane,
> > > if (ret)
> > > goto out_unlock;
> > >  
> > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > 
> > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > aiui.
> > -Chris
> 
> 
> That was the idea but there's a problem with not knowing if PSR exit is
> fully complete before we begin updating the plane registers in
> pipe_update_start().
> 
> Let's say PSR was active and display is in DC6. A flip comes in, without
> _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> enabling that happens in pipe_update_start.

Correction, _flush(DIRTYFB) in prepare_plane_fb() has no effect because
the gem object has no frontbuffer bits set. We should just remove that
misleading call.

>  We immediately follow that
> with programming the plane MMIO's without checking if PSR fully exited.
> If PSR and DC6 happen to exit while we were in the middle of programming
> plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> to exit PSR fully by starting early.
> 
> As for legacy_cursor_update(), since there is no vblank enabling
> involved, we avoid updating the MMIO's in the midst of PSR exit
> 
> 
> > ___
> > 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] drm/i915: Handle changing enable_psr parameter at runtime better

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote:
> Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
> >
> >
> > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> >>>> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> >>>> changed. The easiest fix is to pretend enable_psr is ignored at
> >>>> configure time, and never activate it for !enable_psr, so both cases
> >>>> are handled without modesets.
> >>> What about cases where psr_flush() is not called and consequently the
> >>> module parameter is not checked? With HW tracking, PSR is
> >>> enabled/disabled during modeset and the hardware is expected to exit and
> >>> activate PSR without driver intervention.
> >> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
> >> so we at least get a PSR toggle after every atomic commit?
> > I have a patch to remove flush() from legacy_cursor_update(). We end up
> > with an inconsistent behavior when that patch gets merged,
> > cursor moves -> trigger psr exit but don't read module parameter
> > commits -> trigger psr exit but read module parameter
> Legacy cursor updates are special, I don't mind them not changing PSR.
> > Eventually, when we get to removing flush() from commits, then this
> > patch won't really be useful. And tests disabling/enabling PSR at
> > runtime will probably fail.
> Could we transition to debugfs for changing it at runtime?

That does sound like a better idea.

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> > On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> >> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> >> changed. The easiest fix is to pretend enable_psr is ignored at
> >> configure time, and never activate it for !enable_psr, so both cases
> >> are handled without modesets.
> > What about cases where psr_flush() is not called and consequently the
> > module parameter is not checked? With HW tracking, PSR is
> > enabled/disabled during modeset and the hardware is expected to exit and
> > activate PSR without driver intervention.
> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
> so we at least get a PSR toggle after every atomic commit?

I have a patch to remove flush() from legacy_cursor_update(). We end up
with an inconsistent behavior when that patch gets merged,
cursor moves -> trigger psr exit but don't read module parameter
commits -> trigger psr exit but read module parameter

Eventually, when we get to removing flush() from commits, then this
patch won't really be useful. And tests disabling/enabling PSR at
runtime will probably fail.


> 
> ~Maarten
> 
> >> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> >> Tested-by: Benjamin Berg <bb...@redhat.com>
> >> Cc: Benjamin Berg <bb...@redhat.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_psr.c | 19 ++-
> >>  1 file changed, 10 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> >> b/drivers/gpu/drm/i915/intel_psr.c
> >> index 23175c5c4a50..ac3ce7a1c2a7 100644
> >> --- a/drivers/gpu/drm/i915/intel_psr.c
> >> +++ b/drivers/gpu/drm/i915/intel_psr.c
> >> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp 
> >> *intel_dp,
> >>if (!CAN_PSR(dev_priv))
> >>return;
> >>  
> >> -  if (!i915_modparams.enable_psr) {
> >> -  DRM_DEBUG_KMS("PSR disable by flag\n");
> >> -  return;
> >> -  }
> >> -
> >>/*
> >> * HSW spec explicitly says PSR is tied to port A.
> >> * BDW+ platforms with DDI implementation of PSR have different
> >> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp 
> >> *intel_dp,
> >>  
> >>crtc_state->has_psr = true;
> >>crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> >> -  DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
> >> +  if (i915_modparams.enable_psr)
> >> +  DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : 
> >> "");
> >> +  else
> >> +  DRM_DEBUG_KMS("PSR disable by flag\n");
> >>  }
> >>  
> >>  static void intel_psr_activate(struct intel_dp *intel_dp)
> >> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >>dev_priv->psr.enable_source(intel_dp, crtc_state);
> >>dev_priv->psr.enabled = intel_dp;
> >>  
> >> -  if (INTEL_GEN(dev_priv) >= 9) {
> >> +  if (!i915_modparams.enable_psr) {
> >> +  DRM_DEBUG_KMS("PSR disable by flag\n");
> >> +  } else if (INTEL_GEN(dev_priv) >= 9) {
> >>intel_psr_activate(intel_dp);
> >>} else {
> >>/*
> >> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
> >> * recheck. Since psr_flush first clears this and then reschedules we
> >> * won't ever miss a flush when bailing out here.
> >> */
> >> -  if (dev_priv->psr.busy_frontbuffer_bits)
> >> +  if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
> >>goto unlock;
> >>  
> >>intel_psr_activate(intel_dp);
> >> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private 
> >> *dev_priv,
> >>return;
> >>  
> >>mutex_lock(_priv->psr.lock);
> >> -  if (!dev_priv->psr.enabled) {
> >> +  if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
> >> +  intel_psr_exit(dev_priv);
> >>mutex_unlock(_priv->psr.lock);
> >>return;
> >>}
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 14:58 +0200, Ville Syrjälä wrote:
> On Wed, Mar 07, 2018 at 09:41:06PM +0000, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > 
> > > AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
> > > was dropped. We still have some code leftovers from those early days.
> > > Eliminate them.
> > > 
> > 
> > Not much in the spec about HBR2 other than the support for TP3. Since we
> > don't support HBR2 on CHV, removing the unused TPS3 bits looks correct.
> > 
> > 
> > 
> > > The extra bit for the training pattern seems to be dead in the hardware.
> > > I can set it (in fact I can set almost any reserved bit in the
> > > registers) but it doesn't seem to interfere with the operation of the
> > > hardware. Either that or I'm very lucky that my displays complete link
> > > training with the incorrect pattern being sent out.
> > > 
> > 
> > I don't think I follow this, are you saying there's no need to clear the
> > TPS3 bit? Isn't it better to have the mask include 1 << 14, so that
> > _intel_dp_set_link_train() clears the bit?
> 
> I'm saying the bit doesn't actually seem to exist in hardware. In fact
> most of my specs don't list it either. Looks like only the "K0" specs
> have it.
> 

Thanks for clarifying.

Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

> > 
> > 
> > 
> > > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h |  2 --
> > >  drivers/gpu/drm/i915/intel_dp.c | 20 
> > >  2 files changed, 4 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 95a2e51ecbb0..f3efc242df2d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5250,8 +5250,6 @@ enum {
> > >  #define   DP_LINK_TRAIN_OFF  (3 << 28)
> > >  #define   DP_LINK_TRAIN_MASK (3 << 28)
> > >  #define   DP_LINK_TRAIN_SHIFT28
> > > -#define   DP_LINK_TRAIN_PAT_3_CHV(1 << 14)
> > > -#define   DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
> > >  
> > >  /* CPT Link training mode */
> > >  #define   DP_LINK_TRAIN_PAT_1_CPT(0 << 8)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index aba2f45819d8..df1772044208 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = {
> > >   { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
> > >   { 27,   /* m2_int = 27, m2_fraction = 0 */
> > >   { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
> > > - { 54,   /* m2_int = 27, m2_fraction = 0 */
> > > - { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
> > >  };
> > >  
> > >  /**
> > > @@ -2908,10 +2906,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > >   }
> > >  
> > >   } else {
> > > - if (IS_CHERRYVIEW(dev_priv))
> > > - *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > - else
> > > - *DP &= ~DP_LINK_TRAIN_MASK;
> > > + *DP &= ~DP_LINK_TRAIN_MASK;
> > >  
> > >   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > >   case DP_TRAINING_PATTERN_DISABLE:
> > > @@ -2924,12 +2919,8 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > >   *DP |= DP_LINK_TRAIN_PAT_2;
> > >   break;
> > >   case DP_TRAINING_PATTERN_3:
> > > - if (IS_CHERRYVIEW(dev_priv)) {
> > > - *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > > - } else {
> > > - DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> > > instead\n");
> > > - *DP |= DP_LINK_TRAIN_PAT_2;
> > > - }
> > > + DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> > > instead\n");
> > > + *DP |= DP_LINK_TRAIN_PAT_2;
> > >   break;
> > >   }
> > >   }
> > > @@ -3668,10 +3659,7 @@ intel_dp_link_down(struct intel_encoder *encoder,
> > >   DP &= ~DP_LINK_TRAIN_MASK_CPT;
> > >   DP |= DP_LINK_TRAIN_PAT_IDLE_CPT;
> > >   } else {
> > > - if (IS_CHERRYVIEW(dev_priv))
> > > - DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > - else
> > > - DP &= ~DP_LINK_TRAIN_MASK;
> > > + DP &= ~DP_LINK_TRAIN_MASK;
> > >   DP |= DP_LINK_TRAIN_PAT_IDLE;
> > >   }
> > >   I915_WRITE(intel_dp->output_reg, DP);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote:
> > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > > > plane MMIOs are written to. But this flush should not be necessary for
> > > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > > > for FBC, the spec says "Flips or changes to plane size and panning" 
> > > > > cause
> > > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > > > cursor updates in their frontbuffer_flush implementations.
> > > > > 
> > > > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > > > "Compressing: yes" when I move the cursor around.
> > > > > 
> > > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush 
> > > > > frontbuffer.
> > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > > 
> > > > > Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> > > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > > Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > > > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 91ce8a0522a3..18b08e263ee1 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > > > *plane,
> > > > > if (ret)
> > > > > goto out_unlock;
> > > > >  
> > > > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > > > 
> > > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > > > aiui.
> > > > -Chris
> > > 
> > > 
> > > That was the idea but there's a problem with not knowing if PSR exit is
> > > fully complete before we begin updating the plane registers in
> > > pipe_update_start().
> > > 
> > > Let's say PSR was active and display is in DC6. A flip comes in, without
> > > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> > > enabling that happens in pipe_update_start. We immediately follow that
> > > with programming the plane MMIO's without checking if PSR fully exited.
> > > If PSR and DC6 happen to exit while we were in the middle of programming
> > > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> > > partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> > > to exit PSR fully by starting early.
> > > 
> > > As for legacy_cursor_update(), since there is no vblank enabling
> > > involved, we avoid updating the MMIO's in the midst of PSR exit
> > 
> > I don't believe you will be ever in a case that you write to any register
> > and get any flip or anything without exiting DC6 before that happens.
> > 
> > Or the CSR mechanism of DC6 will be simply wrong.
> > 
> > Would this be enough?
> 
> ok... just ignore my previous comment...
> I believe we can move with the safest side and maybe revisit this later.
> 
> From what I remember of the FBC nuke needs as well I believe this is
> the right move.
> 
> Although I'm asking myself now if we are not changing the meaning of the
> ORIGINS here. Shouldn't we add a new origin and update the handling?
> 
> of "flip" is a good description for this call?
> 

The action taken for this frontbuffer_flush() is the same as origin ==
FLIP. I think it is better to add a new one when we want the features
(psr,fbc) to distinguish and react differently. 


> > 
> > > 
> > > 
> > > > ___
> > > > 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
> > ___
> > 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