Re: [Intel-gfx] [PATCH v3 11/11] drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
On Fri, 2019-10-04 at 16:52 -0700, Matt Roper wrote:
> On Fri, Sep 27, 2019 at 03:28:37PM -0700, Radhakrishna Sripada wrote:
> > Render Decompression is supported with Y-Tiled main surface. The CCS is
> > linear and has 4 bits of data for each main surface cache line pair, a
> > ratio of 1:256. Additional Clear Color information is passed from the
> > user-space through an offset in the GEM BO. Add a new modifier to identify
> > and parse new Clear Color information and extend Gen12 render decompression
> > functionality to the newly added modifier.
> >
> > v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
> > plane config(Matt). Fix Lookup error.
> > v3: Fix the panic while running kms_cube
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Ville Syrjala
> > Cc: Shashank Sharma
> > Cc: Rafael Antognolli
> > Cc: Matt Roper
> > Cc: Nanley G Chery
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 52 +++
> > .../drm/i915/display/intel_display_types.h| 3 ++
> > drivers/gpu/drm/i915/display/intel_sprite.c | 11 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 12 +
> > 4 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 4971c296f951..822237e98f00 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1919,6 +1919,10 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int color_plane)
> > if (color_plane == 1)
> > return 64;
> > /* fall through */
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > + if (color_plane == 1 || color_plane == 2)
> > + return 64;
> > + /* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > if (IS_GEN(dev_priv, 2) || HAS_128_BYTE_Y_TILING(dev_priv))
> > return 128;
> > @@ -2060,6 +2064,7 @@ static unsigned int intel_surf_alignment(const struct
> > drm_framebuffer *fb,
> > return 256 * 1024;
> > return 0;
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > return 16 * 1024;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > case I915_FORMAT_MOD_Yf_TILED_CCS:
> > @@ -2265,6 +2270,8 @@ static bool is_surface_linear(u64 modifier, int
> > color_plane)
> > return true;
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > return color_plane == 1;
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > + return color_plane == 1 || color_plane == 2;
> > case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > return color_plane == 1 || color_plane == 3;
> > default:
> > @@ -2458,6 +2465,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> > fb_modifier)
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > return I915_TILING_Y;
> > default:
> > return I915_TILING_NONE;
> > @@ -2511,6 +2519,25 @@ static const struct drm_format_info
> > gen12_ccs_formats[] = {
> > .cpp = { 1, 1, 2, 1}, .hsub = 2, .vsub = 2, .is_yuv = true },
> > };
> >
> > +/*
> > + * Gen-12 compression uses 4 bits of CCS data for each cache line pair in
> > the
> > + * main surface. And each 64B CCS cache line represents an area of 4x1
> > Y-tiles
> > + * in the main surface. With 4 byte pixels and each Y-tile having
> > dimensions of
> > + * 32x32 pixels, the ratio turns out to 1B in the CCS for every 2 x 32
> > pixels in
> > + * the main surface. Additional surface is used to pass the Clear Color
> > + * structure for the driver to program the DE.
> > + */
>
> Rather than duplicating the previous comment's text I'd just say
>
> "Same as gen12_ccs_formats[] above, but with an additional surface used
> to pass..."
>
> > +static const struct drm_format_info gen12_ccs_cc_formats[] = {
> > + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 3,
> > + .cpp = { 4, 1, 0, }, .hsub = 2, .vsub = 32, },
> > + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 3,
&g
Re: [Intel-gfx] [PATCH v2 10/11] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
On Mon, 2019-09-23 at 17:03 -0700, Radhakrishna Sripada wrote:
> Gen12 display can decompress surfaces compressed by render engine with Clear
> Color, add
> a new modifier as the driver needs to know the surface was compressed by
> render engine.
>
> V2: Description changes as suggested by Rafael.
>
> Cc: Ville Syrjala
> Cc: Dhinakaran Pandiyan
> Cc: Kalyan Kondapally
> Cc: Rafael Antognolli
> Cc: Nanley Chery
> Signed-off-by: Radhakrishna Sripada
> ---
> include/uapi/drm/drm_fourcc.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index c4a4e0fdbee5..99c61ee9b61f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -434,6 +434,17 @@ extern "C" {
> */
> #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
>
> +/*
> + * Intel color control surfaces Clear Color(CCS_CC) for Gen-12 render
> compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS_CC is
> linear
> + * and at index 1.
Clear color data is fixed size - 64b, that should be in the documentation here.
> The clear color is stored at index 2, and the pitch should
> + * be ignored. A CCS_CC cache line corresponds to an area of 4x1 tiles in the
That's a CCS cache line, not a CCS_CC cache line, right?
> + * main surface. The main surface pitch is required to be a multiple of 4
> tile
> + * widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> +
> /*
> * 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 v4 9/9] Gen-12 display can decompress surfaces compressed by the media engine.
On Fri, 2019-10-04 at 18:36 +0300, Ville Syrjälä wrote:
> On Thu, Sep 26, 2019 at 03:55:12AM -0700, Dhinakaran Pandiyan wrote:
> > Detect the modifier corresponding to media compression to enable
> > display decompression for YUV and xRGB packed formats. A new modifier is
> > added so that the driver can distinguish between media and render
> > compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
> > support media decompression.
> >
> > v2: Fix checkpatch warnings on code style (Lucas)
> >
> > From DK:
> > Separate modifier array for planes that cannot decompress media (Ville)
> >
> > v3: Support planar formats
> > v4: Switch plane order
> >
> > Cc: Nanley G Chery
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Signed-off-by: Dhinakaran Pandiyan
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 290 +-
> > .../drm/i915/display/intel_display_types.h| 2 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 55 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 4 files changed, 267 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8ea55d67442c..df3ebaa167ab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1888,6 +1888,22 @@ static void intel_disable_pipe(const struct
> > intel_crtc_state
> > *old_crtc_state)
> > intel_wait_for_pipe_off(old_crtc_state);
> > }
> >
> > +bool is_ccs_modifier(u64 modifier)
> > +{
> > + return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
> > + modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
> > + modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > + modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> > +}
> > +
> > +static bool is_ccs_plane(const struct drm_framebuffer *fb, int color_plane)
> > +{
> > + if (!is_ccs_modifier(fb->modifier))
> > + return false;
>
> A comment here could help clarify things for the reader. Eg.:
> /*
> * [0] RGB
> * [1] RGB CCS
> * or
> * [0] Y
> * [1] CbCr
> * [2] Y CCS
> * [3] CbCr CCS
> */
>
Will do.
> > +
> > + return color_plane >= fb->format->num_planes / 2;
> > +}
> > +
> > static unsigned int intel_tile_size(const struct drm_i915_private
> > *dev_priv)
> > {
> > return IS_GEN(dev_priv, 2) ? 2048 : 4096;
> > @@ -1908,11 +1924,13 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int
> > color_plane)
> > else
> > return 512;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 128;
> > /* fall through */
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > + /* fall through */
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 64;
> > /* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > @@ -1921,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int color_plane)
> > else
> > return 512;
> > case I915_FORMAT_MOD_Yf_TILED_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 128;
> > /* fall through */
> > case I915_FORMAT_MOD_Yf_TILED:
> > @@ -1949,8 +1967,9 @@ static unsigned int
> > intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
> > {
> > switch (fb->modifier) {
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 1;
> > /* fall through */
> > default:
> > @@ -2055,6 +2074,7 @@ static unsigned int intel_surf_alignment(const struct
> > drm_framebuffer *fb,
> > if (INTEL_GEN(dev_priv) >= 9)
> > return 256 * 1024;
> > return 0;
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > case I915_FORMAT_M
Re: [Intel-gfx] [PATCH v4 9/9] Gen-12 display can decompress surfaces compressed by the media engine.
On Fri, 2019-10-04 at 13:27 -0700, Matt Roper wrote:
> On Thu, Sep 26, 2019 at 03:55:12AM -0700, Dhinakaran Pandiyan wrote:
> > Detect the modifier corresponding to media compression to enable
> > display decompression for YUV and xRGB packed formats. A new modifier is
> > added so that the driver can distinguish between media and render
> > compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
> > support media decompression.
> >
> > v2: Fix checkpatch warnings on code style (Lucas)
> >
> > From DK:
> > Separate modifier array for planes that cannot decompress media (Ville)
> >
> > v3: Support planar formats
> > v4: Switch plane order
> >
> > Cc: Nanley G Chery
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Signed-off-by: Dhinakaran Pandiyan
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 290 +-
> > .../drm/i915/display/intel_display_types.h| 2 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 55 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 4 files changed, 267 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8ea55d67442c..df3ebaa167ab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1888,6 +1888,22 @@ static void intel_disable_pipe(const struct
> > intel_crtc_state
> > *old_crtc_state)
> > intel_wait_for_pipe_off(old_crtc_state);
> > }
> >
> > +bool is_ccs_modifier(u64 modifier)
> > +{
> > + return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
> > + modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
> > + modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > + modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> > +}
> > +
> > +static bool is_ccs_plane(const struct drm_framebuffer *fb, int color_plane)
> > +{
> > + if (!is_ccs_modifier(fb->modifier))
> > + return false;
> > +
> > + return color_plane >= fb->format->num_planes / 2;
> > +}
>
> This appears to contradict what you indicated on the modifier patch:
>
> + * 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.
>
> Based on that comment I'd expect something more like (color_plane % 2).
I need to update the comment in the modifier patch, thanks for catching this.
The major change in
this version is
for planar formats: planes 2 and 3 will be used for CCS instead of 1 and 3.
for packed formats: plane 1 will be used for CCS
>
>
> > +
> > static unsigned int intel_tile_size(const struct drm_i915_private
> > *dev_priv)
> > {
> > return IS_GEN(dev_priv, 2) ? 2048 : 4096;
> > @@ -1908,11 +1924,13 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int
> > color_plane)
> > else
> > return 512;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 128;
> > /* fall through */
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > + /* fall through */
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 64;
> > /* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > @@ -1921,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int color_plane)
> > else
> > return 512;
> > case I915_FORMAT_MOD_Yf_TILED_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return 128;
> > /* fall through */
> > case I915_FORMAT_MOD_Yf_TILED:
> > @@ -1949,8 +1967,9 @@ static unsigned int
> > intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
> > {
> > switch (fb->modifier) {
> > + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > - if (color_plane == 1)
> > + if (is_ccs_plane(fb, color_plane))
> > return
Re: [Intel-gfx] [RFC v3 7/9] drm/i915: Skip rotated offset adjustment for unsupported modifiers
On Mon, 2019-09-23 at 03:29 -0700, Dhinakaran Pandiyan wrote:
> During framebuffer creation, we pre-compute offsets for 90/270 plane
> rotation. However, only Y and Yf modifiers support 90/270 rotation. So,
> skip the calculations for other modifiers.
>
> Cc: Matt Roper
> Cc: Ville Syrjälä
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7447001c1f85..6f0f38157697 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2784,7 +2784,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> tile_size);
> offset /= tile_size;
>
> - if (!is_surface_linear(fb->modifier, i)) {
> + /* Y or Yf modifiers required for 90/270 rotation */
> + if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
This is wrong, as CI results clearly show
igt@kms_addfb_basic@bo-too-small-due-to-tiling fails.
Please ignore this patch.
-DK
> unsigned int tile_width, tile_height;
> unsigned int pitch_tiles;
> struct drm_rect r;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 9/9] Gen-12 display can decompress surfaces compressed by the media engine.
Detect the modifier corresponding to media compression to enable
display decompression for YUV and xRGB packed formats. A new modifier is
added so that the driver can distinguish between media and render
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
support media decompression.
v2: Fix checkpatch warnings on code style (Lucas)
From DK:
Separate modifier array for planes that cannot decompress media (Ville)
v3: Support planar formats
v4: Switch plane order
Cc: Nanley G Chery
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 290 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 55 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 267 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8ea55d67442c..df3ebaa167ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1888,6 +1888,22 @@ static void intel_disable_pipe(const struct
intel_crtc_state *old_crtc_state)
intel_wait_for_pipe_off(old_crtc_state);
}
+bool is_ccs_modifier(u64 modifier)
+{
+ return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
+static bool is_ccs_plane(const struct drm_framebuffer *fb, int color_plane)
+{
+ if (!is_ccs_modifier(fb->modifier))
+ return false;
+
+ return color_plane >= fb->format->num_planes / 2;
+}
+
static unsigned int intel_tile_size(const struct drm_i915_private *dev_priv)
{
return IS_GEN(dev_priv, 2) ? 2048 : 4096;
@@ -1908,11 +1924,13 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int color_plane)
else
return 512;
case I915_FORMAT_MOD_Y_TILED_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 64;
/* fall through */
case I915_FORMAT_MOD_Y_TILED:
@@ -1921,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
else
return 512;
case I915_FORMAT_MOD_Yf_TILED_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 128;
/* fall through */
case I915_FORMAT_MOD_Yf_TILED:
@@ -1949,8 +1967,9 @@ static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
switch (fb->modifier) {
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 1;
/* fall through */
default:
@@ -2055,6 +2074,7 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
@@ -2254,10 +2274,17 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
return new_offset;
}
-static bool is_surface_linear(u64 modifier, int color_plane)
+static bool is_surface_linear(const struct drm_framebuffer *fb, int
color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR ||
- (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ return true;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ return is_ccs_plane(fb, color_plane);
+ default:
+ return false;
+ }
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2272,7 +2299,7 @@ static u32 intel_adjust_aligned_offset(int *x, int *y,
WARN_ON(new_offset > old_offset);
- if (!is_surface_linear(fb->modifier, color_plane)) {
+ if (!is_surface_linear(fb, color_plane)) {
unsigned int tile_size, tile_width, tile_height;
uns
[Intel-gfx] [RFC v3 9/9] Gen-12 display can decompress surfaces compressed by the media engine.
Detect the modifier corresponding to media compression to enable
display decompression for YUV and xRGB packed formats. A new modifier is
added so that the driver can distinguish between media and render
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
support media decompression.
v2: Fix checkpatch warnings on code style (Lucas)
From DK:
Separate modifier array for planes that cannot decompress media (Ville)
v3: Support planar formats
Cc: Nanley G Chery
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 239 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 44 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 222 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6f0f38157697..e55ef715b53d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1911,6 +1911,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ if (color_plane == 3)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
if (color_plane == 1)
return 64;
@@ -2256,8 +2260,16 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
static bool is_surface_linear(u64 modifier, int color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR ||
- (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
+ switch (modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ return true;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ return color_plane == 1;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ return color_plane == 1 || color_plane == 3;
+ default:
+ return false;
+ }
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2445,6 +2457,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
return I915_TILING_Y;
default:
return I915_TILING_NONE;
@@ -2492,6 +2505,10 @@ static const struct drm_format_info gen12_ccs_formats[]
= {
.cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
{ .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
.cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
+ { .format = DRM_FORMAT_YUYV, .num_planes = 2,
+ .cpp = { 2, 1, }, .hsub = 4, .vsub = 32, .is_yuv = true },
+ { .format = DRM_FORMAT_NV12, .num_planes = 4,
+ .cpp = { 1, 1, 2, 1}, .hsub = 2, .vsub = 2, .is_yuv = true },
};
static const struct drm_format_info *
@@ -2529,6 +2546,7 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
bool is_ccs_modifier(u64 modifier)
{
return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
}
@@ -2592,7 +2610,7 @@ intel_fb_stride_alignment(const struct drm_framebuffer
*fb, int color_plane)
}
tile_width = intel_tile_width_bytes(fb, color_plane);
- if (is_ccs_modifier(fb->modifier) && color_plane == 0) {
+ if (is_ccs_modifier(fb->modifier)) {
/*
* Display WA #0531: skl,bxt,kbl,glk
*
@@ -2602,7 +2620,7 @@ intel_fb_stride_alignment(const struct drm_framebuffer
*fb, int color_plane)
* require the entire fb to accommodate that to avoid
* potential runtime errors at plane configuration time.
*/
- if (IS_GEN(dev_priv, 9) && fb->width > 3840)
+ if (IS_GEN(dev_priv, 9) && color_plane == 0 && fb->width > 3840)
tile_width *= 4;
/*
* The main surface pitch must be padded to a multiple of four
@@ -2682,25 +2700,71 @@ static bool intel_plane_needs_remap(const struct
intel_plane_state *plane_state)
return stride > max_stride;
}
+static void
+intel_fb_plane_get_subsampling(int *hsub, int *vsub, const struct
drm_framebuffer *fb, int color_plane)
+{
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS) {
+
[Intel-gfx] [RFC v3 7/9] drm/i915: Skip rotated offset adjustment for unsupported modifiers
During framebuffer creation, we pre-compute offsets for 90/270 plane
rotation. However, only Y and Yf modifiers support 90/270 rotation. So,
skip the calculations for other modifiers.
Cc: Matt Roper
Cc: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7447001c1f85..6f0f38157697 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2784,7 +2784,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
tile_size);
offset /= tile_size;
- if (!is_surface_linear(fb->modifier, i)) {
+ /* Y or Yf modifiers required for 90/270 rotation */
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
unsigned int tile_width, tile_height;
unsigned int pitch_tiles;
struct drm_rect r;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 0/9] Gen12 E2E compression
Patches in this series are at two levels of completion. The render decompression patches 1, 2, 3 and 4 address feedback provided for https://patchwork.freedesktop.org/series/66367/ Media decompression patches 5, 6, 7, 8 and 9 are a complete rewrite to handle planar formats and have not been tested. I would like to get feedback on the approach before finishing the implementation. Dhinakaran Pandiyan (9): drm/framebuffer: Format modifier for Intel Gen-12 render compression drm/i915: Use intel_tile_height() instead of re-implementing drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment drm/i915/tgl: Gen-12 render decompression drm/i915: Extract framebufer CCS offset checks into a function drm/framebuffer: Format modifier for Intel Gen-12 media compression drm/i915: Skip rotated offset adjustment for unsupported modifiers drm/fb: Extend format_info member arrays to handle four planes Gen-12 display can decompress surfaces compressed by the media engine. drivers/gpu/drm/i915/display/intel_display.c | 388 +- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_sprite.c | 61 ++- drivers/gpu/drm/i915/i915_reg.h | 2 + include/drm/drm_fourcc.h | 8 +- include/uapi/drm/drm_fourcc.h | 22 + 6 files changed, 368 insertions(+), 115 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 6/9] drm/framebuffer: Format modifier for Intel Gen-12 media compression
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ä
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
*
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 2/9] drm/i915: Use intel_tile_height() instead of re-implementing
intel_tile_dims() computes tile height using size and width, when there is already a function to do just that - intel_tile_height() Cc: Ville Syrjälä Cc: Matt Roper Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 5ecf54270181..a94d145dd048 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -1957,7 +1957,7 @@ static void intel_tile_dims(const struct drm_framebuffer *fb, int color_plane, unsigned int cpp = fb->format->cpp[color_plane]; *tile_width = tile_width_bytes / cpp; - *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes; + *tile_height = intel_tile_height(fb, color_plane); } unsigned int -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 8/9] drm/fb: Extend format_info member arrays to handle four planes
addfb() uAPI has supported four planes for a while now, make format_info
compatible with that.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
include/drm/drm_fourcc.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 306d1efeb5e0..156b122c0ad5 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -78,7 +78,7 @@ struct drm_format_info {
* triplet @char_per_block, @block_w, @block_h for better
* describing the pixel format.
*/
- u8 cpp[3];
+ u8 cpp[4];
/**
* @char_per_block:
@@ -104,7 +104,7 @@ struct drm_format_info {
* information from their drm_mode_config.get_format_info hook
* if they want the core to be validating the pitch.
*/
- u8 char_per_block[3];
+ u8 char_per_block[4];
};
/**
@@ -113,7 +113,7 @@ struct drm_format_info {
* Block width in pixels, this is intended to be accessed through
* drm_format_info_block_width()
*/
- u8 block_w[3];
+ u8 block_w[4];
/**
* @block_h:
@@ -121,7 +121,7 @@ struct drm_format_info {
* Block height in pixels, this is intended to be accessed through
* drm_format_info_block_height()
*/
- u8 block_h[3];
+ u8 block_h[4];
/** @hsub: Horizontal chroma subsampling factor */
u8 hsub;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 4/9] drm/i915/tgl: Gen-12 render decompression
Gen-12 display decompression operates on Y-tiled compressed main surface.
The CCS is linear and has 4 bits of metadata for each main surface cache
line pair, a size ratio of 1:256. Gen-12 display decompression is
incompatible with buffers compressed by earlier GPUs, so make use of a new
modifier to identify gen-12 compression. Another notable change is that
render decompression is supported on all planes except cursor and on all
pipes. Start by adding render decompression support for [A,X]BGR888 pixel
formats.
v2: Fix checkpatch warnings (Lucas)
v3:
Rebase, disable color clear, styling changes and modify
intel_tile_width_bytes and intel_tile_height to handle linear CCS
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 85
drivers/gpu/drm/i915/display/intel_sprite.c | 23 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
3 files changed, 84 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c437f00c2072..6fec43cdddf4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1911,6 +1911,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ if (color_plane == 1)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN(dev_priv, 2) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
@@ -1944,8 +1948,15 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
- return intel_tile_size(to_i915(fb->dev)) /
- intel_tile_width_bytes(fb, color_plane);
+ switch (fb->modifier) {
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ if (color_plane == 1)
+ return 1;
+ /* fall through */
+ default:
+ return intel_tile_size(to_i915(fb->dev)) /
+ intel_tile_width_bytes(fb, color_plane);
+ }
}
/* Return the tile dimensions in pixel units */
@@ -2044,6 +2055,8 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
@@ -2243,7 +2256,8 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
static bool is_surface_linear(u64 modifier, int color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR;
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2430,6 +2444,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
return I915_TILING_X;
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return I915_TILING_Y;
default:
return I915_TILING_NONE;
@@ -2450,7 +2465,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
* us a ratio of one byte in the CCS for each 8x16 pixels in the
* main surface.
*/
-static const struct drm_format_info ccs_formats[] = {
+static const struct drm_format_info skl_ccs_formats[] = {
{ .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
{ .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
@@ -2461,6 +2476,24 @@ static const struct drm_format_info ccs_formats[] = {
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
};
+/*
+ * Gen-12 compression uses 4 bits of CCS data for each cache line pair in the
+ * main surface. And each 64B CCS cache line represents an area of 4x1 Y-tiles
+ * in the main surface. With 4 byte pixels and each Y-tile having dimensions of
+ * 32x32 pixels, the ratio turns out to 1B in the CCS for every 2x32 pixels in
+ * the main surface.
+ */
+static const struct drm_format_info gen12_ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .
[Intel-gfx] [RFC v3 3/9] drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment
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;
+
+ 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
[Intel-gfx] [RFC v3 1/9] drm/framebuffer: Format modifier for Intel Gen-12 render compression
Gen-12 has a new compression format, add a new modifier to indicate that.
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..1f0fbf0398f6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -410,6 +410,17 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render 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.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 5/9] drm/i915: Extract framebufer CCS offset checks into a function
intel_fill_fb_info() has grown quite large and wrapping the offset checks
into a separate function makes the loop a bit easier to follow.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 69
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6fec43cdddf4..7447001c1f85 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2682,6 +2682,43 @@ static bool intel_plane_needs_remap(const struct
intel_plane_state *plane_state)
return stride > max_stride;
}
+static int
+intel_fb_check_ccs_xy(struct drm_framebuffer *fb, int x, int y)
+{
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ int hsub = fb->format->hsub;
+ int vsub = fb->format->vsub;
+ int tile_width, tile_height;
+ int ccs_x, ccs_y;
+ int main_x, main_y;
+
+ intel_tile_dims(fb, 1, _width, _height);
+
+ tile_width *= hsub;
+ tile_height *= vsub;
+
+ ccs_x = (x * hsub) % tile_width;
+ ccs_y = (y * vsub) % tile_height;
+ main_x = intel_fb->normal[0].x % tile_width;
+ main_y = intel_fb->normal[0].y % tile_height;
+
+ /*
+ * CCS doesn't have its own x/y offset register, so the intra CCS tile
+ * x/y offsets must match between CCS and the main surface.
+ */
+ if (main_x != ccs_x || main_y != ccs_y) {
+ DRM_DEBUG_KMS("Bad CCS x/y (main %d,%d ccs %d,%d) full (main
%d,%d ccs %d,%d)\n",
+ main_x, main_y,
+ ccs_x, ccs_y,
+ intel_fb->normal[0].x,
+ intel_fb->normal[0].y,
+ x, y);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -2713,35 +2750,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
}
if (is_ccs_modifier(fb->modifier) && i == 1) {
- int hsub = fb->format->hsub;
- int vsub = fb->format->vsub;
- int tile_width, tile_height;
- int main_x, main_y;
- int ccs_x, ccs_y;
-
- intel_tile_dims(fb, i, _width, _height);
-
- tile_width *= hsub;
- tile_height *= vsub;
-
- ccs_x = (x * hsub) % tile_width;
- ccs_y = (y * vsub) % tile_height;
- main_x = intel_fb->normal[0].x % tile_width;
- main_y = intel_fb->normal[0].y % tile_height;
-
- /*
-* CCS doesn't have its own x/y offset register, so the
intra CCS tile
-* x/y offsets must match between CCS and the main
surface.
-*/
- if (main_x != ccs_x || main_y != ccs_y) {
- DRM_DEBUG_KMS("Bad CCS x/y (main %d,%d ccs
%d,%d) full (main %d,%d ccs %d,%d)\n",
- main_x, main_y,
- ccs_x, ccs_y,
- intel_fb->normal[0].x,
- intel_fb->normal[0].y,
- x, y);
- return -EINVAL;
- }
+ ret = intel_fb_check_ccs_xy(fb, x, y);
+ if (ret)
+ return ret;
}
/*
--
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/framebuffer: Format modifier for Intel Gen-12 render compression
On Sat, 2019-09-07 at 00:21 -0700, Dhinakaran Pandiyan wrote:
> Gen-12 has a new compression format, add a new modifier to indicate that.
>
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Nanley G Chery
> Cc: Jason Ekstrand
Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan
> Signed-off-by: Lucas De Marchi
> ---
> include/uapi/drm/drm_fourcc.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..1f0fbf0398f6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -410,6 +410,17 @@ extern "C" {
> #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> #define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
>
> +/*
> + * Intel color control surfaces (CCS) for Gen-12 render 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.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
> +
> /*
> * 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
[Intel-gfx] [PATCH 2/2] drm/i915/tgl: Gen-12 render decompression
Gen-12 display decompression operates on Y-tiled compressed main surface.
The CCS is linear and has 4 bits of metadata for each main surface cache
line pair, a size ratio of 1:256. Gen-12 display decompression is
incompatible with buffers compressed by earlier GPUs, so make use of a new
modifier to identify gen-12 compression. Another notable change is that
render decompression is supported on all planes except cursor and on all
pipes. Start by adding render decompression support for [A,X]BGR888 pixel
formats.
v2: Fix checkpatch warnings (Lucas)
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 63 +---
drivers/gpu/drm/i915/display/intel_sprite.c | 23 ---
2 files changed, 71 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3b5275ab66cf..303e1d2e97a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1911,6 +1911,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ if (color_plane == 1)
+ return cpp;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN(dev_priv, 2) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
@@ -2044,6 +2048,8 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ return 4 * 4 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
@@ -2243,7 +2249,8 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
static bool is_surface_linear(u64 modifier, int color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR;
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2430,6 +2437,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
return I915_TILING_X;
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return I915_TILING_Y;
default:
return I915_TILING_NONE;
@@ -2450,7 +2458,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
* us a ratio of one byte in the CCS for each 8x16 pixels in the
* main surface.
*/
-static const struct drm_format_info ccs_formats[] = {
+static const struct drm_format_info skl_ccs_formats[] = {
{ .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
{ .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
@@ -2461,6 +2469,24 @@ static const struct drm_format_info ccs_formats[] = {
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
};
+/*
+ * Gen-12 compression uses 4 bits of CCS data for each cache line pair in the
+ * main surface. And each 64B CCS cache line represents an area of 4x1 Y-tiles
+ * in the main surface. With 4 byte pixels and each Y-tile having dimensions of
+ * 32x32 pixels, the ratio turns out to 1B in the CCS for every 2x32 pixels in
+ * the main surface.
+ */
+static const struct drm_format_info gen12_ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
+};
+
static const struct drm_format_info *
lookup_format_info(const struct drm_format_info formats[],
int num_formats, u32 format)
@@ -2481,8 +2507,12 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
switch (cmd->modifier[0]) {
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
- return lookup_format_info(ccs_formats,
- ARRAY_SIZE(ccs_formats),
+ return lookup_format_info(skl_ccs_formats,
+
[Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen-12 render compression
Gen-12 has a new compression format, add a new modifier to indicate that.
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..1f0fbf0398f6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -410,6 +410,17 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render 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.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support
On Wed, 2019-08-28 at 19:25 +0300, Ville Syrjälä wrote:
> On Tue, Aug 27, 2019 at 01:45:16AM -0700, Dhinakaran Pandiyan wrote:
> > Yf tiling was removed in gen-12, so do not expose Yf modifiers to user
> > space. Gen-12 display also is incompatible with pre-gen12 Y-tiled
> > CCS, so do not expose I915_FORMAT_MOD_Y_TILED_CCS.
> >
> > v2: Rebase to carry forward recently added gen11 formats.
> >
> > Cc: Ville Syrjälä
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: Dhinakaran Pandiyan
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Ville Syrjälä
Thanks for reviewing this patch again, I'll rebase and send the render
decompression patches next.
Lucas,
Thanks for pushing the patch, I was attempting learn dim again :)
-DK
>
> > ---
> > drivers/gpu/drm/i915/display/intel_sprite.c | 86 +++--
> > 1 file changed, 80 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index dea63be1964f..8ca2fbc2af1d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -2157,6 +2157,13 @@ static const u64 skl_plane_format_modifiers_ccs[] = {
> > DRM_FORMAT_MOD_INVALID
> > };
> >
> > +static const u64 gen12_plane_format_modifiers_noccs[] = {
> > + I915_FORMAT_MOD_Y_TILED,
> > + I915_FORMAT_MOD_X_TILED,
> > + DRM_FORMAT_MOD_LINEAR,
> > + DRM_FORMAT_MOD_INVALID
> > +};
> > +
> > static bool g4x_sprite_format_mod_supported(struct drm_plane *_plane,
> > u32 format, u64 modifier)
> > {
> > @@ -2305,6 +2312,55 @@ static bool skl_plane_format_mod_supported(struct
> > drm_plane *_plane,
> > }
> > }
> >
> > +static bool gen12_plane_format_mod_supported(struct drm_plane *_plane,
> > +u32 format, u64 modifier)
> > +{
> > + switch (modifier) {
> > + case DRM_FORMAT_MOD_LINEAR:
> > + case I915_FORMAT_MOD_X_TILED:
> > + case I915_FORMAT_MOD_Y_TILED:
> > + break;
> > + default:
> > + return false;
> > + }
> > +
> > + switch (format) {
> > + case DRM_FORMAT_XRGB:
> > + case DRM_FORMAT_XBGR:
> > + case DRM_FORMAT_ARGB:
> > + case DRM_FORMAT_ABGR:
> > + case DRM_FORMAT_RGB565:
> > + case DRM_FORMAT_XRGB2101010:
> > + case DRM_FORMAT_XBGR2101010:
> > + case DRM_FORMAT_YUYV:
> > + case DRM_FORMAT_YVYU:
> > + case DRM_FORMAT_UYVY:
> > + case DRM_FORMAT_VYUY:
> > + case DRM_FORMAT_NV12:
> > + case DRM_FORMAT_P010:
> > + case DRM_FORMAT_P012:
> > + case DRM_FORMAT_P016:
> > + case DRM_FORMAT_XVYU2101010:
> > + case DRM_FORMAT_C8:
> > + case DRM_FORMAT_XBGR16161616F:
> > + case DRM_FORMAT_ABGR16161616F:
> > + case DRM_FORMAT_XRGB16161616F:
> > + case DRM_FORMAT_ARGB16161616F:
> > + case DRM_FORMAT_Y210:
> > + case DRM_FORMAT_Y212:
> > + case DRM_FORMAT_Y216:
> > + case DRM_FORMAT_XVYU12_16161616:
> > + case DRM_FORMAT_XVYU16161616:
> > + if (modifier == DRM_FORMAT_MOD_LINEAR ||
> > + modifier == I915_FORMAT_MOD_X_TILED ||
> > + modifier == I915_FORMAT_MOD_Y_TILED)
> > + return true;
> > + /* fall through */
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > static const struct drm_plane_funcs g4x_sprite_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > @@ -2341,6 +2397,15 @@ static const struct drm_plane_funcs skl_plane_funcs
> > = {
> > .format_mod_supported = skl_plane_format_mod_supported,
> > };
> >
> > +static const struct drm_plane_funcs gen12_plane_funcs = {
> > + .update_plane = drm_atomic_helper_update_plane,
> > + .disable_plane = drm_atomic_helper_disable_plane,
> > + .destroy = intel_plane_destroy,
> > + .atomic_duplicate_state = intel_plane_duplicate_state,
> > + .atomic_destroy_state = intel_plane_destroy_state,
> > + .format_mod_supported = gen12_plane_format_mod_supported,
> > +};
> > +
> > static bool skl_plane_has_fbc(struct drm_i915_private *dev_priv,
> > enum pipe pipe, enum plane_id plane_id)
> > {
> > @@ -2429,6 +2494,7 @@ struct intel_plane *
> > sk
[Intel-gfx] [PATCH v2] drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support
Yf tiling was removed in gen-12, so do not expose Yf modifiers to user
space. Gen-12 display also is incompatible with pre-gen12 Y-tiled
CCS, so do not expose I915_FORMAT_MOD_Y_TILED_CCS.
v2: Rebase to carry forward recently added gen11 formats.
Cc: Ville Syrjälä
Cc: Stanislav Lisovskiy
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_sprite.c | 86 +++--
1 file changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index dea63be1964f..8ca2fbc2af1d 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2157,6 +2157,13 @@ static const u64 skl_plane_format_modifiers_ccs[] = {
DRM_FORMAT_MOD_INVALID
};
+static const u64 gen12_plane_format_modifiers_noccs[] = {
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static bool g4x_sprite_format_mod_supported(struct drm_plane *_plane,
u32 format, u64 modifier)
{
@@ -2305,6 +2312,55 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
}
}
+static bool gen12_plane_format_mod_supported(struct drm_plane *_plane,
+u32 format, u64 modifier)
+{
+ switch (modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ return false;
+ }
+
+ switch (format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_FORMAT_P016:
+ case DRM_FORMAT_XVYU2101010:
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ case DRM_FORMAT_XVYU12_16161616:
+ case DRM_FORMAT_XVYU16161616:
+ if (modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED ||
+ modifier == I915_FORMAT_MOD_Y_TILED)
+ return true;
+ /* fall through */
+ default:
+ return false;
+ }
+}
+
static const struct drm_plane_funcs g4x_sprite_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -2341,6 +2397,15 @@ static const struct drm_plane_funcs skl_plane_funcs = {
.format_mod_supported = skl_plane_format_mod_supported,
};
+static const struct drm_plane_funcs gen12_plane_funcs = {
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
+ .destroy = intel_plane_destroy,
+ .atomic_duplicate_state = intel_plane_duplicate_state,
+ .atomic_destroy_state = intel_plane_destroy_state,
+ .format_mod_supported = gen12_plane_format_mod_supported,
+};
+
static bool skl_plane_has_fbc(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id)
{
@@ -2429,6 +2494,7 @@ struct intel_plane *
skl_universal_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id)
{
+ static const struct drm_plane_funcs *plane_funcs;
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
@@ -2471,11 +2537,19 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
formats = skl_get_plane_formats(dev_priv, pipe,
plane_id, _formats);
- plane->has_ccs = skl_plane_has_ccs(dev_priv, pipe, plane_id);
- if (plane->has_ccs)
- modifiers = skl_plane_format_modifiers_ccs;
- else
- modifiers = skl_plane_format_modifiers_noccs;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ /* TODO: Implement support for gen-12 CCS modifiers */
+ plane->has_ccs = false;
+ modifiers = gen12_plane_format_modifiers_noccs;
+ plane_funcs = _plane_funcs;
+ } else {
+ plane->has_ccs = skl_plane_has_ccs(dev_priv, pipe, plane_id);
+ if (plane->has_ccs)
+ modifiers = skl_plane_fo
[Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section
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)
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1dc8d03ff127..ee6fa75d65a2 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -762,7 +762,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/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index fdbbb9a53804..796c070bbe6f 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -772,13 +772,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] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section
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
---
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] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section
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
---
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
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/psr: Make PSR registers relative to transcoders
On Mon, 2019-06-24 at 14:11 -0700, Souza, Jose wrote:
> > > > +#define _HSW_EDP_PSR_BASE0x64800
> > > > +#define _SRD_CTL_A 0x60800
> > > > +#define _SRD_CTL_EDP 0x6f800
> > > > +#define _HSW_PSR_ADJ(reg)((reg) -
> > > > _SRD_CTL_A +
> > > > _HSW_EDP_PSR_BASE)
> > > > +#define _PSR_ADJ(tran, reg) (IS_HASWELL(dev
> > > > _priv) ? _HSW_PSR_ADJ(reg) : _TRANS2(tran, reg))
> > > > +#define EDP_PSR_CTL(tran)_MMIO(_PSR_ADJ(
> > > > tran,
> > > > _SRD_CTL_A))
> > >
> > > There are currently three instances of platform/gen checks in
> > > i915_reg.h. They are the exception, and they're in individual
> > > macros
> > > that aren't even register offset definitions let alone helpers that
> > > get
> > > proliferated to several other macros.
> > >
> > > This change here is quite a big precedent in that regard, and not
> > > to
> > > be
> > > done lightly. Usually the case is others will follow suit, so this
> > > is
> > > not just about this one instance. It's about deciding whether this
> > > is
> > > the direction we want to take. How far are we prepared to go and
> > > how
> > > do
> > > we stop there?
> > >
> > > There's really no way to set the psr->transcoder such on HSW that
> > > it
> > > would work with MMIO_TRANS2()?
> >
> > I'm going to think about but right now the only other option that
> > comes
> > in my mind is to have the transcoder offset as macro parameter:
> >
> > #define _SRD_CTL 0x800
> > #define EDP_PSR_CTL(trans) _MMIO(trans + _SRD_CTL)
> >
> > But we would lose the full offset address of PSR registers.
>
> This is the only other good option that I can think about.
>
> Any other idea DK?
No good ones unfortunately. This is the simplest one I could think of
intel_psr_init()
{
...
if(IS_HASWELL(dev_priv))
dev_priv->psr.hsw_adjust = _SRD_CTL_EDP - _HSW_EDP_PSR_BASE;
...
}
#define _MMIO_PSR(tran, reg) _MMIO_TRANS2(tran, reg - dev_priv.psr.hsw_adjust)
#define EDP_PSR_CTL(tran) _MMIO_PSR(tran, _SRD_CTL_A)
should work because tran == TRANSCODER_EDP for HSW
-DK
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/connector: Allow max possible encoders to attach to a connector
On Wed, 2019-06-26 at 16:31 +0200, Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 04:43:28PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 25, 2019 at 04:40:45PM -0700, Dhinakaran Pandiyan wrote:
> > > Currently we restrict the number of encoders that can be linked to
> > > a connector to 3, increase it to match the maximum number of encoders
> > > that can be initialized - 32. The current limitation looks artificial.
> > > Increasing the limit to 32 does however increases the size of the static
> > > u32 array keeping track of the encoder IDs.
> > >
> > > Cc: José Roberto de Souza
> > > Cc: Ville Syrjälä
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Dhinakaran Pandiyan
> > > ---
> > > include/drm/drm_connector.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index ca745d9feaf5..91455b4a9360 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -1278,7 +1278,7 @@ struct drm_connector {
> > > /** @override_edid: has the EDID been overwritten through debugfs for
> > > testing? */
> > > bool override_edid;
> > >
> > > -#define DRM_CONNECTOR_MAX_ENCODER 3
> > > +#define DRM_CONNECTOR_MAX_ENCODER 32
> > > /**
> > >* @encoder_ids: Valid encoders for this connector. Please only use
> > >* drm_connector_for_each_possible_encoder() to enumerate these.
> >
> > I wonder if we couldn't just replace this array with a bitmask?
> > I think the for_each_possible_encoder() thing I did a while back
> > should make this easier potentially because most driver code just
> > uses that.
>
> +1 on possible encoders bitmask. More consistent at least.
Agreed, I'll make this change.
-DK
> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/connector: Allow max possible encoders to attach to a connector
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized - 32. The current limitation looks artificial.
Increasing the limit to 32 does however increases the size of the static
u32 array keeping track of the encoder IDs.
Cc: José Roberto de Souza
Cc: Ville Syrjälä
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan
---
include/drm/drm_connector.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ca745d9feaf5..91455b4a9360 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1278,7 +1278,7 @@ struct drm_connector {
/** @override_edid: has the EDID been overwritten through debugfs for
testing? */
bool override_edid;
-#define DRM_CONNECTOR_MAX_ENCODER 3
+#define DRM_CONNECTOR_MAX_ENCODER 32
/**
* @encoder_ids: Valid encoders for this connector. Please only use
* drm_connector_for_each_possible_encoder() to enumerate these.
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: Make PSR registers relative to transcoders
"drm/i915/psr" in the subject.
On Sat, 2019-04-20 at 13:55 -0700, José Roberto de Souza wrote:
> PSR registers are a mess, some have the full address while others just
> have the additional offset from psr_mmio_base.
>
> For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
> 0x800 and using it makes more difficult for people with an PSR
> register address or PSR register name from from BSpec as i915 also
> don't match the BSpec names.
> For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are
> only available in DDIA.
>
> Other reason to make relative to transcoder is that since BDW every
> transcoder have PSR registers, so in theory it should be possible to
> have PSR enabled in a non-eDP transcoder.
>
> So for BDW+ we can use _TRANS2() to get the register offset of any
> PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
> that will calculate the register offset for the single PSR instance,
> noting that we are already guarded about trying to enable PSR in other
> port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in
> intel_psr_compute_config(), this check should only be valid for HSW
> and will be changed in future.
> PSR2 registers and PSR_EVENT was added after Haswell so that is why
> _PSR_ADJ() is not used in some macros.
>
> The only registers that can not be relative to transcoder are
> PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
> hardcoded.
>
> Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
> is the only PSR register that GVT have.
>
> v5:
> - Macros changed to be more explicit about HSW (Dhinakaran)
> - Squashed with the patch that added the tran parameter to the
> macros (Dhinakaran)
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Zhi Wang
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 1 -
> drivers/gpu/drm/i915/i915_debugfs.c | 18 +
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/i915_reg.h | 57 -
> drivers/gpu/drm/i915/intel_psr.c| 55
> 5 files changed, 83 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 18f01eeb2510..749e3e4204f2 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2776,7 +2776,6 @@ static int init_broadwell_mmio_info(struct intel_gvt
> *gvt)
> MMIO_D(CHICKEN_PIPESL_1(PIPE_C), D_BDW_PLUS);
>
> MMIO_D(WM_MISC, D_BDW);
> - MMIO_D(_MMIO(BDW_EDP_PSR_BASE), D_BDW);
Change this to _SRD_CTL_EDP to keep the change non-functional? Any case, we'll
need an ack to modify this.
> MMIO_D(_MMIO(0x66c00), D_BDW_PLUS);
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5823ffb17821..2a0f5871e9a8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2470,7 +2470,7 @@ psr_source_status(struct drm_i915_private *dev_priv,
> struct seq_file *m)
> "BUF_ON",
> "TG_ON"
> };
> - val = I915_READ(EDP_PSR2_STATUS);
> + val = I915_READ(EDP_PSR2_STATUS(dev_priv->psr.transcoder));
> status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> EDP_PSR2_STATUS_STATE_SHIFT;
> if (status_val < ARRAY_SIZE(live_status))
> @@ -2486,7 +2486,7 @@ psr_source_status(struct drm_i915_private *dev_priv,
> struct seq_file *m)
> "SRDOFFACK",
> "SRDENT_ON",
> };
> - val = I915_READ(EDP_PSR_STATUS);
> + val = I915_READ(EDP_PSR_STATUS(dev_priv->psr.transcoder));
> status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> EDP_PSR_STATUS_STATE_SHIFT;
> if (status_val < ARRAY_SIZE(live_status))
> @@ -2529,10 +2529,10 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> goto unlock;
>
> if (psr->psr2_enabled) {
> - val = I915_READ(EDP_PSR2_CTL);
> + val = I915_READ(EDP_PSR2_CTL(dev_priv->psr.transcoder));
> enabled = val & EDP_PSR2_ENABLE;
> } else {
> - val = I915_READ(EDP_PSR_CTL);
> + val = I915_READ(EDP_PSR_CTL(dev_priv->psr.transcoder));
> enabled = val & EDP_PSR_ENABLE;
> }
> seq_printf
Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make PSR registers relative to transcoders
On Wed, 2019-04-17 at 15:37 -0700, José Roberto de Souza wrote:
> PSR registers are a mess, some have the full address while others just
> have the additional offset from psr_mmio_base.
>
> psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET + 0x800 and
> using it makes more difficult for people with an PSR register address
> or PSR register name from from BSpec as i915 also don't match the
> name.
I'd like this to be rewritten for clarity.
>
> Other reason to make relative to transcoder is that since BDW every
> transcoder have PSR registers, so in theory it should be possible to
> have PSR enabled in a non-eDP transcoder.
>
> For Haswell PSR registers are relative to 0x64000, so
> mmio_base_adjust and _TRANS2_PSR() was added so we can overcome
> this limitation in a single place.
> PSR2 registers and PSR_EVENT was added after Haswell so that is why
> _TRANS2_PSR() is not used in some macros.
>
> The only registers that can not be relative to transcoder are
> PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
> hardcoded.
>
> Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
> is the only PSR register that GVT have.
>
> v4:
> - Moved definition of _TRANS2_PSR() and _MMIO_TRANS2_PSR() to the
> beginning of i915_reg.h (Jani)
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Zhi Wang
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 1 -
> drivers/gpu/drm/i915/i915_drv.h | 5 +--
> drivers/gpu/drm/i915/i915_reg.h | 48 -
> drivers/gpu/drm/i915/intel_psr.c| 11 +--
> 4 files changed, 45 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 18f01eeb2510..749e3e4204f2 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2776,7 +2776,6 @@ static int init_broadwell_mmio_info(struct intel_gvt
> *gvt)
> MMIO_D(CHICKEN_PIPESL_1(PIPE_C), D_BDW_PLUS);
>
> MMIO_D(WM_MISC, D_BDW);
> - MMIO_D(_MMIO(BDW_EDP_PSR_BASE), D_BDW);
>
> MMIO_D(_MMIO(0x6671c), D_BDW_PLUS);
> MMIO_D(_MMIO(0x66c00), D_BDW_PLUS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 066fd2a12851..58748f23511f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -494,6 +494,8 @@ struct i915_drrs {
> };
>
> struct i915_psr {
> + /* different than zero only on HSW see _TRANS2_PSR() for more info */
> + u32 mmio_base_adjust;
If you rename this to hsw_base_adjust, the name becomes self-documenting and we
can get rid of the comment.
> struct mutex lock;
>
> #define I915_PSR_DEBUG_MODE_MASK 0x0f
> @@ -508,6 +510,7 @@ struct i915_psr {
> bool enabled;
> struct intel_dp *dp;
> enum pipe pipe;
> + enum transcoder transcoder;
> bool active;
> struct work_struct work;
> unsigned busy_frontbuffer_bits;
> @@ -1534,8 +1537,6 @@ struct drm_i915_private {
> /* MMIO base address for MIPI regs */
> u32 mipi_mmio_base;
>
> - u32 psr_mmio_base;
> -
> u32 pps_mmio_base;
>
> wait_queue_head_t gmbus_wait_queue;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9ef306b79e0d..987006946802 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -258,6 +258,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> INTEL_INFO(dev_priv)-
> >cursor_offsets[PIPE_A] + (reg) + \
> DISPLAY_MMIO_BASE(dev_priv))
>
> +/* PSR registers on HSW is not relative to eDP transcoder */
> +#define _TRANS2_PSR(reg) (_TRANS2(dev_priv->psr.transcoder, (reg)) -
> dev_priv->psr.mmio_base_adjust)
> +#define _MMIO_TRANS2_PSR(reg)_MMIO(_TRANS2_PSR(reg))
> +
I think the macro should be defined in it's final form in this commit. While I
understand you want to split the patch for making review easy, not convinced we
it's a good idea to add macros that change in the next patch.
We can define the macro to accept (tran, reg) as arguments in this patch but
have intel_psr_compute_config() reject non-eDP transcoders.
intel_psr_compute_config(intel_dp, crtc_state)
{
if (crtc_state->cpu_transcoder
!= TRANSCODER_EDP)
return;
...
}
This allows you to add the macro without changing any functionality.
If you insist on not making changes to intel_psr.c, how about introducing the
full macro in th
Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Add _TRANS2()
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 v4 1/4] drm/i915/bdw+: Move misc display IRQ handling to it own function
On Wed, 2019-04-17 at 15:37 -0700, José Roberto de Souza wrote:
> Just moving it to reduce the tabs and avoid break code lines.
> No behavior changes intended here.
>
> v2:
> - Reading misc display IRQ outside of gen8_de_misc_irq_handler() as
> other irq handlers (Dhinakaran)
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_irq.c | 45 ++---
> 1 file changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b92cfd69134b..a1299f10ed49 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2768,6 +2768,28 @@ static u32 gen8_de_port_aux_mask(struct
> drm_i915_private *dev_priv)
> return mask;
> }
>
> +static void
> +gen8_de_misc_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
> +{
> + bool found = false;
> +
> + if (iir & GEN8_DE_MISC_GSE) {
> + intel_opregion_asle_intr(dev_priv);
> + found = true;
> + }
> +
> + if (iir & GEN8_DE_EDP_PSR) {
> + u32 psr_iir = I915_READ(EDP_PSR_IIR);
> +
> + intel_psr_irq_handler(dev_priv, psr_iir);
> + I915_WRITE(EDP_PSR_IIR, psr_iir);
Two things unrelated to your refactoring,
1) we can ack the irq right after reading the iir bits. I had noticed this a
while back but never got to changing it.
2) we don't DRM_ERROR() for unexpected PSR interrupts like how other handlers
do. Not sure what's the point though, other than getting to know that the
hardware is broken.
Ville, any idea why unexpected interrupts warrant DRM_ERROR().
This patch is
Reviewed-by: Dhinakaran Pandiyan
> + found = true;
> + }
> +
> + if (!found)
> + DRM_ERROR("Unexpected DE Misc interrupt\n");
> +}
> +
> static irqreturn_t
> gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> {
> @@ -2778,29 +2800,12 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (master_ctl & GEN8_DE_MISC_IRQ) {
> iir = I915_READ(GEN8_DE_MISC_IIR);
> if (iir) {
> - bool found = false;
> -
> I915_WRITE(GEN8_DE_MISC_IIR, iir);
> ret = IRQ_HANDLED;
> -
> - if (iir & GEN8_DE_MISC_GSE) {
> - intel_opregion_asle_intr(dev_priv);
> - found = true;
> - }
> -
> - if (iir & GEN8_DE_EDP_PSR) {
> - u32 psr_iir = I915_READ(EDP_PSR_IIR);
> -
> - intel_psr_irq_handler(dev_priv, psr_iir);
> - I915_WRITE(EDP_PSR_IIR, psr_iir);
> - found = true;
> - }
> -
> - if (!found)
> - DRM_ERROR("Unexpected DE Misc interrupt\n");
> - }
> - else
> + gen8_de_misc_irq_handler(dev_priv, iir);
> + } else {
> DRM_ERROR("The master control interrupt lied (DE
> MISC)!\n");
> + }
> }
>
> if (INTEL_GEN(dev_priv) >= 11 && (master_ctl & GEN11_DE_HPD_IRQ)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
On Tue, 2019-04-09 at 23:38 +0300, Ville Syrjälä wrote:
> On Tue, Apr 09, 2019 at 01:28:18PM -0700, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> > > the minimum is 8bpc. Set our lower limit accordingly.
> >
> > Patch doesn't apply anymore, got a conflict in intel_drv.h.
> >
> >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 10 +-
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > > 3 files changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 2aee526ed632..149fdfbcb343 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2002,6 +2002,14 @@ static int intel_dp_dsc_compute_config(struct
> > > intel_dp
> > > *intel_dp,
> > > return 0;
> > > }
> > >
> > > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> > > + return 6 * 3;
> > > + else
> > > + return 8 * 3;
> >
> > Code matches spec, however I think there is a possibility of min_bpp
> > becoming
> > greater than max_bpp. The max_bpc property allows user space to set a value
> > of 6
> > and limits.min_bpp can become 24 because of the code above. Add a check for
> > that
> > in compute_link_config()? Probably would mess up the compute_config() loop
> > too.
>
> The code looks correct. Ie. should just end up with -EINVAL.
Yup, it does now as I read it carefully again :)
Reviewed-by: Dhinakaran Pandiyan
However, I don't like the fact we are hiding the detail that min_bpp can be >
max_bpp. If someone decides add a link config optimization starting from
min_bpp, it's easy to miss this detail.
-DK
>
> >
> >
> > > +}
> > > +
> > > static int
> > > intel_dp_compute_link_config(struct intel_encoder *encoder,
> > >struct intel_crtc_state *pipe_config,
> > > @@ -2025,7 +2033,7 @@ intel_dp_compute_link_config(struct intel_encoder
> > > *encoder,
> > > limits.min_lane_count = 1;
> > > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> > >
> > > - limits.min_bpp = 6 * 3;
> > > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > > limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> > >
> > > if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 6d2af7cf48e6..79c229184873 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -119,7 +119,7 @@ static int intel_dp_mst_compute_config(struct
> > > intel_encoder *encoder,
> > > limits.min_lane_count =
> > > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> > >
> > > - limits.min_bpp = 6 * 3;
> > > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > > limits.max_bpp = pipe_config->pipe_bpp;
> > >
> > > intel_dp_adjust_compliance_config(intel_dp, pipe_config, );
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e79954c6271c..13f1b0367287 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1919,6 +1919,7 @@ void intel_dp_adjust_compliance_config(struct
> > > intel_dp
> > > *intel_dp,
> > > struct link_config_limits *limits);
> > > bool intel_dp_limited_color_range(const struct intel_crtc_state
> > > *crtc_state,
> > > const struct drm_connector_state *conn_state);
> > > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> > > bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
> > > i915_reg_t dp_reg, enum port port,
> > > enum pipe *pipe);
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> the minimum is 8bpc. Set our lower limit accordingly.
Patch doesn't apply anymore, got a conflict in intel_drv.h.
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2aee526ed632..149fdfbcb343 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2002,6 +2002,14 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> +{
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + return 6 * 3;
> + else
> + return 8 * 3;
Code matches spec, however I think there is a possibility of min_bpp becoming
greater than max_bpp. The max_bpc property allows user space to set a value of 6
and limits.min_bpp can become 24 because of the code above. Add a check for that
in compute_link_config()? Probably would mess up the compute_config() loop too.
> +}
> +
> static int
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
> @@ -2025,7 +2033,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> limits.min_lane_count = 1;
> limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>
> - limits.min_bpp = 6 * 3;
> + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 6d2af7cf48e6..79c229184873 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -119,7 +119,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> limits.min_lane_count =
> limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>
> - limits.min_bpp = 6 * 3;
> + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> limits.max_bpp = pipe_config->pipe_bpp;
>
> intel_dp_adjust_compliance_config(intel_dp, pipe_config, );
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e79954c6271c..13f1b0367287 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1919,6 +1919,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
> struct link_config_limits *limits);
> bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
> i915_reg_t dp_reg, enum port port,
> enum pipe *pipe);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Make PSR registers relative to transcoders
On Wed, 2019-04-03 at 16:35 -0700, José Roberto de Souza wrote:
> PSR registers are a mess, some have the full address while others just
> have the additional offset from psr_mmio_base.
>
> psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET + 0x800 and
> using it makes more difficult for people with an PSR register address
> from BSpec to search the register name in i915 as also the BSpec name
> don't match with the name in i915.
>
> The other option would be use the whole hard-coded address but this is
> not future proof, so here going in the middle ground by making every
> PSR register relative to transcoder(that is EDP transcoder), the only
> exception is PSR_IMR/IIR that is not relative to nothing.
> For the _TRANS2() macros to work it needs the address of the register
> from the TRANSCODER_A, so adding it to every register together with
> the register address from the EDP transcoder so it will make easy for
> people searching with BSpec address also adding those with the BSpec
> name.
>
> For Haswell all the PSR register are relative to 0x64000, so
> mmio_base_adjust was added and used to take care of that.
>
> Also removing BDW_EDP_PSR_BASE from GVT because it is not used as
> the only PSR register that GVT have is this one(SRD/PSR_CTL).
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 1 -
> drivers/gpu/drm/i915/i915_drv.h | 5 ++-
> drivers/gpu/drm/i915/i915_reg.h | 59 -
> drivers/gpu/drm/i915/intel_psr.c| 11 --
> 4 files changed, 52 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 86761b1def1e..d09b798e93cb 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2739,7 +2739,6 @@ static int init_broadwell_mmio_info(struct intel_gvt
> *gvt)
> MMIO_D(CHICKEN_PIPESL_1(PIPE_C), D_BDW_PLUS);
>
> MMIO_D(WM_MISC, D_BDW);
> - MMIO_D(_MMIO(BDW_EDP_PSR_BASE), D_BDW);
>
> MMIO_D(_MMIO(0x6671c), D_BDW_PLUS);
> MMIO_D(_MMIO(0x66c00), D_BDW_PLUS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8f38d03b1c4e..9ce46a7dabfd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -501,6 +501,8 @@ struct i915_drrs {
> };
>
> struct i915_psr {
> + /* different than zero only on HSW see _TRANS2_PSR() for more info */
> + u32 mmio_base_adjust;
> struct mutex lock;
>
> #define I915_PSR_DEBUG_MODE_MASK 0x0f
> @@ -515,6 +517,7 @@ struct i915_psr {
> bool enabled;
> struct intel_dp *dp;
> enum pipe pipe;
> + enum transcoder transcoder;
> bool active;
> struct work_struct work;
> unsigned busy_frontbuffer_bits;
> @@ -1541,8 +1544,6 @@ struct drm_i915_private {
> /* MMIO base address for MIPI regs */
> u32 mipi_mmio_base;
>
> - u32 psr_mmio_base;
> -
> u32 pps_mmio_base;
>
> wait_queue_head_t gmbus_wait_queue;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 18e2991b376d..4df56c118cd2 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_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))
> @@ -4210,9 +4211,15 @@
Re: [Intel-gfx] [PATCH 3/7] drm/i915/psr: Initialize PSR mutex even when sink is not reliable
On Thu, 2019-04-04 at 17:32 -0700, Souza, Jose wrote:
> On Thu, 2019-04-04 at 17:22 -0700, Dhinakaran Pandiyan wrote:
> > On Wed, 2019-04-03 at 16:35 -0700, José Roberto de Souza wrote:
> > > Even when driver is reloaded and hits this scenario the PSR mutex
> > > should be initialized, otherwise reading PSR debugfs status will
> > > execute mutex_lock() over a mutex that was not initialized.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_psr.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index c80bb3003a7d..a84da931c3be 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -1227,7 +1227,6 @@ void intel_psr_init(struct drm_i915_private
> > > *dev_priv)
> > > if (val) {
> > > DRM_DEBUG_KMS("PSR interruption error set\n");
> > > dev_priv->psr.sink_not_reliable = true;
> >
> > Should we just sink_support = false and keep the return? IOW is there
> > any use
> > for sink_not_reliable?
>
> I guess it could cause confusion as user had PSR support before the
> module reload and after the load PSR debugfs will say that sink do not
> support PSR.
I don't think it is any more confusing than saying sink supports PSR and not
enabling it. Might as well make it clear that we are blaming the sink for not
enabling PSR.
>
> >
> > > - return;
> > > }
> > >
> > > /* Set link_standby x link_off defaults */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/bdw+: Move misc display IRQ handling to it own function
On Wed, 2019-04-03 at 16:35 -0700, José Roberto de Souza wrote:
> Just moving it to reduce the tabs and avoid break code lines.
> No behavior changes intended here.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_irq.c | 63 +++--
> 1 file changed, 36 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index aa107a78cb36..527d5cb21baa 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2702,41 +2702,50 @@ static u32 gen8_de_port_aux_mask(struct
> drm_i915_private *dev_priv)
> return mask;
> }
>
> -static irqreturn_t
> -gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> +static enum irqreturn
> +gen8_de_misc_irq_handler(struct drm_i915_private *dev_priv)
> {
> - irqreturn_t ret = IRQ_NONE;
> - u32 iir;
> - enum pipe pipe;
> + u32 iir = I915_READ(GEN8_DE_MISC_IIR);
> + enum irqreturn ret = IRQ_NONE;
> + bool found = false;
>
> - if (master_ctl & GEN8_DE_MISC_IRQ) {
> - iir = I915_READ(GEN8_DE_MISC_IIR);
> - if (iir) {
> - bool found = false;
> -
> - I915_WRITE(GEN8_DE_MISC_IIR, iir);
> - ret = IRQ_HANDLED;
> + if (!iir) {
> + DRM_ERROR("The master control interrupt lied (DE MISC)!\n");
> + return ret;
> + }
Move the above to the caller and pass the IIR value as a parameter? That would
make it consistent with other handlers in this file. The benefit I see is that I
don't have to look beyond gen8_de_irq_handler() to know what the return value is
going to be.
> - found = true;
> - }
> + I915_WRITE(GEN8_DE_MISC_IIR, iir);
> + ret = IRQ_HANDLED;
>
> - if (iir & GEN8_DE_EDP_PSR) {
> - u32 psr_iir = I915_READ(EDP_PSR_IIR);
> + if (iir & GEN8_DE_MISC_GSE) {
> + intel_opregion_asle_intr(dev_priv);
> + found = true;
> + }
>
> - intel_psr_irq_handler(dev_priv, psr_iir);
> - I915_WRITE(EDP_PSR_IIR, psr_iir);
> - found = true;
> - }
> + if (iir & GEN8_DE_EDP_PSR) {
> + u32 psr_iir = I915_READ(EDP_PSR_IIR);
>
> - if (!found)
> - DRM_ERROR("Unexpected DE Misc interrupt\n");
> - }
> - else
> - DRM_ERROR("The master control interrupt lied (DE
> MISC)!\n");
> + intel_psr_irq_handler(dev_priv, psr_iir);
> + I915_WRITE(EDP_PSR_IIR, psr_iir);
> + found = true;
> }
>
> + if (!found)
> + DRM_ERROR("Unexpected DE Misc interrupt\n");
> +
> + return ret;
> +}
> +
> +static irqreturn_t
> +gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> +{
> + irqreturn_t ret = IRQ_NONE;
> + u32 iir;
> + enum pipe pipe;
> +
> + if (master_ctl & GEN8_DE_MISC_IRQ)
> + ret = gen8_de_misc_irq_handler(dev_priv);
> +
> if (INTEL_GEN(dev_priv) >= 11 && (master_ctl & GEN11_DE_HPD_IRQ)) {
> iir = I915_READ(GEN11_DE_HPD_IIR);
> if (iir) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/psr: Initialize PSR mutex even when sink is not reliable
On Wed, 2019-04-03 at 16:35 -0700, José Roberto de Souza wrote:
> Even when driver is reloaded and hits this scenario the PSR mutex
> should be initialized, otherwise reading PSR debugfs status will
> execute mutex_lock() over a mutex that was not initialized.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index c80bb3003a7d..a84da931c3be 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1227,7 +1227,6 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> if (val) {
> DRM_DEBUG_KMS("PSR interruption error set\n");
> dev_priv->psr.sink_not_reliable = true;
Should we just sink_support = false and keep the return? IOW is there any use
for sink_not_reliable?
> - return;
> }
>
> /* Set link_standby x link_off defaults */
___
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
On Thu, 2019-04-04 at 14:41 -0700, Dhinakaran Pandiyan wrote:
> 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_SHIFT 0
> > > > >
> > > > > -#define _PSR_EVENT_TRANS_A 0x60848
> > > > > -#define _PSR_EVENT_TRANS_B 0x61848
> > > > > -#define _PSR_EVENT_TRANS_C 0x62848
> > > > > -#define _PSR_EVENT_TRANS_D
Re: [Intel-gfx] [PATCH 4/7] drm/i915/psr: Do not enable PSR in interlaced mode for all GENs
On Wed, 2019-04-03 at 17:29 -0700, Rodrigo Vivi wrote:
> On Wed, Apr 03, 2019 at 04:35:36PM -0700, José Roberto de Souza wrote:
> > This interlaced restriction applies to all gens, not only to Haswell.
>
> I believe this came from VLV times and I doubt we would be
> impacted by it ever, but better to protect just in case:
>
>
> Reviewed-by: Rodrigo Vivi
>
>
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index a84da931c3be..bb97c1657493 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -627,8 +627,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
> > return;
> > }
> >
> > - if (IS_HASWELL(dev_priv) &&
> > - adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
> > + if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
> > DRM_DEBUG_KMS("PSR condition failed: Interlaced is Enabled\n");
It'd be nice to change this to "interlaced mode"
Noticed that the spec says PSR does not work with Stereo 3d mode as well. But,
that should be okay since we don't set stereo_allowed for DP.
Reviewed-by: Dhinakaran Pandiyan
> > return;
> > }
> > --
> > 2.21.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/psr: Make all PSR register relative to mmio base
On Fri, 2019-03-22 at 11:15 +0200, Jani Nikula wrote:
> On Thu, 21 Mar 2019, José Roberto de Souza wrote:
> > Right now it have a mix of PSR registers that are relative to PSR
> > mmio base and other register with a hardcoded address, lets keep it
> > consistented and have it all relative to mmio base.
>
> This is not strictly limited to this patch, but an overall trend. The
> thing that really bugs me with this is losing more of the actual
> absolute mmio addresses from the file. When you're seeking to add a new
> register, you can't trivially grep for it in the file anymore. Not all
> of our register names match the spec (and the spec occasionally also
> changes register names) so being able to find the offset is important.
Fully agreed.
I think we can do something along the lines of
#define _HSW_PSR_OFFSET BDW_EDP_PSR_BASE - HSW_PSR_PSR_BASE
#define _BDW_PSR_CTL 0x6f800
_MMIO_HSW_ADJUST(pipe, reg) IS_HASWELL(dev_priv) ?
MMIO_TRANS2((pipe), reg - _HSW_PSR_OFFSET) :
MMIO_TRANS2((pipe), reg)
#define EDP_PSR_CTL(pipe) _MMIO_HSW_ADJUST((pipe), _BDW_PSR_CTL)
I'd like at least BDW+ addresses to be in the code.
-DK
>
> When we added the macros that use ->pipe_offsets and ->trans_offsets, we
> took care to have at least one of the offsets in the file. I'm wondering
> if we could do something like that here as well.
>
> BR,
> Jani.
>
>
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 11 ---
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 28728399e607..e1ed2ba1c315 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4326,7 +4326,7 @@ enum {
> > #define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1 << 16) /* Reserved in
> > ICL+ */
> > #define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1 << 15) /* SKL+ */
> >
> > -#define EDP_PSR2_CTL _MMIO(0x6f900)
> > +#define EDP_PSR2_CTL _MMIO(dev_priv->psr.mmio_base +
> > 0x100)
> > #define EDP_PSR2_ENABLE (1 << 31)
> > #define EDP_SU_TRACK_ENABLE (1 << 30)
> > #define EDP_Y_COORDINATE_VALID (1 << 26) /* GLK and CNL+ */
> > @@ -4344,7 +4344,7 @@ enum {
> > #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> > #define EDP_PSR2_IDLE_FRAME_SHIFT0
> >
> > -#define PSR_EVENT _MMIO(0x6F848)
> > +#define PSR_EVENT _MMIO(dev_priv->psr.mmio_base +
> > 0x48)
> > #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)
> > @@ -4362,14 +4362,11 @@ enum {
> > #define PSR_EVENT_LPSP_MODE_EXIT (1 << 1)
> > #define PSR_EVENT_PSR_DISABLE (1 << 0)
> >
> > -#define EDP_PSR2_STATUS_MMIO(0x6f940)
> > +#define EDP_PSR2_STATUS_MMIO(dev_priv->psr.mmio_base +
> > 0x140)
> > #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> > #define EDP_PSR2_STATUS_STATE_SHIFT28
> >
> > -#define _PSR2_SU_STATUS_0 0x6F914
> > -#define _PSR2_SU_STATUS_1 0x6F918
> > -#define _PSR2_SU_STATUS_2 0x6F91C
> > -#define _PSR2_SU_STATUS(index) _MMIO(_PICK_EVEN((index),
> > _PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
> > +#define _PSR2_SU_STATUS(index) _MMIO(dev_priv->psr.mmio_base +
> > 0x114 + (index) * 4)
> > #define PSR2_SU_STATUS(frame) (_PSR2_SU_STATUS((frame) / 3))
> > #define PSR2_SU_STATUS_SHIFT(frame)(((frame) % 3) * 10)
> > #define PSR2_SU_STATUS_MASK(frame) (0x3ff << PSR2_SU_STATUS_SHIFT(frame))
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix PSR2 selective update corruption after PSR1 setup (rev5)
On Tue, 2019-03-19 at 19:55 +, Souza, Jose wrote: > On Tue, 2019-03-19 at 14:06 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Fix PSR2 selective update corruption after PSR1 > > setup (rev5) > > URL : https://patchwork.freedesktop.org/series/57900/ > > State : success > > Pushed to drm-intel-next-queued, thanks for the reviews Rodrigo and > Dhinakaran. > btw, is this something an IGT Selective Update test can detect? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix PSR2 selective update corruption after PSR1 setup
On Thu, 2019-03-14 at 16:01 -0700, José Roberto de Souza wrote: > There is probably a issue in DMC firmwares(icl_dmc_ver1_07.bin and > kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to fail nit: instead of "fail", it is better to document what you see visually - freeze, flicker, corruption etc. > after > exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so for now > lets workaround the issue by cleaning PSR_CTL before enable PSR2. > > v2: > - Updated commit description and comment to state that it may be > a DMC firmware issue (Rodrigo) > - No need to RMW, let's write 0 to PSR_CTL(Dhinakaran) Based on the discussion with José offline, this work around sounds reasonable to have until we have answers to whether this is a DMC issue. Reviewed-by: Dhinakaran Pandiyan > > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/intel_psr.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 7d570a45fc17..10bf70e521b6 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -531,6 +531,14 @@ static void hsw_activate_psr2(struct intel_dp > *intel_dp) > else > val |= EDP_PSR2_TP2_TIME_2500us; > > + /* > + * FIXME: There is probably a issue in DMC > firmwares(icl_dmc_ver1_07.bin > + * and kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to nit: Expand SU to selective update, I am not sure how familiar others with these acronyms. > fail after > + * exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so > for now > + * lets workaround the issue by cleaning PSR_CTL before enable clearing* > PSR2. > + */ > + I915_WRITE(EDP_PSR_CTL, 0); > + > I915_WRITE(EDP_PSR2_CTL, val); > } > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix PSR2 selective update corruption after PSR1 setup
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?
> > 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.
> >
> > /* 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 v3 2/3] drm/i915/psr: Move logic to get TPS registers values to another function
On Mon, 2019-03-11 at 16:28 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 03:47:33PM -0800, José Roberto de Souza
> wrote:
> > This will make hsw_activate_psr1() more easy to read and will make
> > future modification to TPS registers more easy to review and read.
> >
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 56 +++-
> >
> > 1 file changed, 33 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 831f345b4ad8..2fa2f4c9c935 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -437,32 +437,13 @@ static void intel_psr_enable_sink(struct
> > intel_dp *intel_dp)
> > drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0);
> > }
> >
> > -static void hsw_activate_psr1(struct intel_dp *intel_dp)
> > +static u32 psr1_tps_regs_val_get(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - u32 max_sleep_time = 0x1f;
> > - u32 val = EDP_PSR_ENABLE;
> > -
> > - /* 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);
> > -
> > - /* sink_sync_latency of 8 means source has to wait for more
> > than 8
> > -* frames, we'll go with 9 frames for now
> > -*/
> > - idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > - val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> > -
> > - val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > - if (IS_HASWELL(dev_priv))
> > - val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> > -
> > - if (dev_priv->psr.link_standby)
> > - val |= EDP_PSR_LINK_STANDBY;
> > + u32 val = 0;
> >
> > if (dev_priv->vbt.psr.tp1_wakeup_time_us == 0)
> > - val |= EDP_PSR_TP1_TIME_0us;
> > + val |= EDP_PSR_TP1_TIME_0us;
> > else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 100)
> > val |= EDP_PSR_TP1_TIME_100us;
> > else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 500)
> > @@ -471,7 +452,7 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > val |= EDP_PSR_TP1_TIME_2500us;
> >
> > if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us == 0)
> > - val |= EDP_PSR_TP2_TP3_TIME_0us;
> > + val |= EDP_PSR_TP2_TP3_TIME_0us;
> > else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
> > val |= EDP_PSR_TP2_TP3_TIME_100us;
> > else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
> > @@ -485,6 +466,35 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > else
> > val |= EDP_PSR_TP1_TP2_SEL;
> >
> > + return val;
> > +}
> > +
> > +static void hsw_activate_psr1(struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > + u32 max_sleep_time = 0x1f;
> > + u32 val = EDP_PSR_ENABLE;
> > +
> > + /* 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);
> > +
> > + /* sink_sync_latency of 8 means source has to wait for more
> > than 8
> > +* frames, we'll go with 9 frames for now
> > +*/
> > + idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > + val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> > +
> > + val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > + if (IS_HASWELL(dev_priv))
> > + val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> > +
> > + if (dev_priv->psr.link_standby)
> > + val |= EDP_PSR_LINK_STANDBY;
> > +
> > + val |= psr1_tps_regs_val_get(intel_dp);
>
> I'd prefer intel_psr1_tps...
>
intel_psr1_get_tp_time(intel_dp)?
> Reviewed-by: Rodrigo Vivi
>
> > +
> > if (INTEL_GEN(dev_priv) >= 8)
> > val |= EDP_PSR_CRC_ENABLE;
> >
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 8/9] drm/i915: Force PSR exit when getting pipe CRC
On Thu, 2019-03-07 at 13:57 -0800, Souza, Jose wrote:
> On Thu, 2019-03-07 at 13:25 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > > If PSR is active when pipe CRC is enabled the CRC calculations
> > > will
> > > be inhibit by the transition to low power states that PSR brings.
> >
> > The MMIO write to enable CRCs should bring the hardware out from
> > PSR,
> > but I can imagine some initial CRCs are going to be corrupt or
> > unavailable.
>
> That do not happen, if PSR is active and CRC is configured PSR will
> remain active and no CRC will be calculated.
Odd, MMIO writes should trigger DC6 exit, which always results in PSR
exit. If the hardware isnt't in DC6, then I can imagine CRC enabling
not causing a PSR exit.
>
> >
> > > So lets for a PSR exit and as soon as pipe CRC is enabled it will
> >
> > There is a missing word.
>
> Thanks
>
> "So lets force a PSR exit and as soon as pipe CRC is enabled it will
> block PSR activation and avoid CRC timeouts when running IGT tests."
>
>
> >
> > > block PSR activation avoid CRC timeouts when running IGT tests.
> >
> > This surely has fdo bugs, please include them in the commit
> > message.
>
> I did this patch because of the regressions that I got from CI in my
> testings,
Can you include the test name and platform in the commit message?
> the only bug that I found related is
> https://bugs.freedesktop.org/show_bug.cgi?id=107814 but we don't have
> PSR enabled by default on HSW.
Jani S had reported the issue, Cc'ing him.
>
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_psr.c | 36
> > >
> > >
> > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index d3e3996551c6..5d66e7313c75 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -452,6 +452,7 @@ static void hsw_activate_psr1(struct intel_dp
> > > *intel_dp)
> > >* frames, we'll go with 9 frames for now
> > >*/
> > > idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > > + 1);
> > > +
> > > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> > >
> > > val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > > @@ -851,6 +852,20 @@ void intel_psr_disable(struct intel_dp
> > > *intel_dp,
> > > cancel_work_sync(_priv->psr.work);
> > > }
> > >
> > > +static void psr_force_hw_tracking_exit(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + /*
> > > + * 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_SURFLIVE_A,
> > > + * but it makes more sense write to the current active
> > > + * pipe.
> > > + */
> > > + I915_WRITE(CURSURFLIVE(dev_priv->psr.pipe), 0);
> > > +}
> > > +
> > > /**
> > > * intel_psr_update - Update PSR state
> > > * @intel_dp: Intel DP
> > > @@ -875,8 +890,13 @@ void intel_psr_update(struct intel_dp
> > > *intel_dp,
> > > enable = crtc_state->has_psr && psr_global_enabled(psr->debug);
> > > psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
> > >
> > > - if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> > > + if (enable == psr->enabled && psr2_enable == psr-
> > > > psr2_enabled)
> > >
> > > {
> >
> > PSR2 is enabled, then user requests CRCs, the mode_changed commit
> > switches to PSR1. The above condition isn't true in that case.
>
> Not sure if I understood the question but if PSR2 is enabled and user
> request CRC it will switch to PSR1 already forcing a PSR exit so we
> don't need to call psr_force_hw_tracking_exit() in this case.
The PSR2->PSR1 switching gives us the same window before CRC enabling
as force_hw_tracking_exit(). My question was about if that window is
sufficient.
>
> >
> > Also, since the CRC workaround is done before enabling pipe CRC,
>
Re: [Intel-gfx] [PATCH v5 9/9] drm/i915: Enable PSR2 by default
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote: > The support for PSR2 was polished, IGT tests for PSR2 was added and > it was tested performing regular user workloads like browsing, > editing documents and compiling Linux, so it is time to enable it by > default and enjoy even more power-savings. Great job :) Reviewed-by: Dhinakaran Pandiyan Is there a reason to include the PSR1 CRC fix in this series, that is an orthogonal issue IMO. And I think we should merge the PSR2 patches independently. > > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan > Reviewed-by: Rodrigo Vivi > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/intel_psr.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 5d66e7313c75..bae266869c20 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -80,9 +80,6 @@ static bool intel_psr2_enabled(struct > drm_i915_private *dev_priv, > case I915_PSR_DEBUG_DISABLE: > case I915_PSR_DEBUG_FORCE_PSR1: > return false; > - case I915_PSR_DEBUG_DEFAULT: > - if (i915_modparams.enable_psr <= 0) > - return false; > default: > return crtc_state->has_psr2; > } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 8/9] drm/i915: Force PSR exit when getting pipe CRC
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> If PSR is active when pipe CRC is enabled the CRC calculations will
> be inhibit by the transition to low power states that PSR brings.
The MMIO write to enable CRCs should bring the hardware out from PSR,
but I can imagine some initial CRCs are going to be corrupt or
unavailable.
> So lets for a PSR exit and as soon as pipe CRC is enabled it will
There is a missing word.
> block PSR activation avoid CRC timeouts when running IGT tests.
This surely has fdo bugs, please include them in the commit message.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 36
>
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d3e3996551c6..5d66e7313c75 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -452,6 +452,7 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
>* frames, we'll go with 9 frames for now
>*/
> idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> + 1);
> +
> val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>
> val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> @@ -851,6 +852,20 @@ void intel_psr_disable(struct intel_dp
> *intel_dp,
> cancel_work_sync(_priv->psr.work);
> }
>
> +static void psr_force_hw_tracking_exit(struct drm_i915_private
> *dev_priv)
> +{
> + /*
> + * 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_SURFLIVE_A,
> + * but it makes more sense write to the current active
> + * pipe.
> + */
> + I915_WRITE(CURSURFLIVE(dev_priv->psr.pipe), 0);
> +}
> +
> /**
> * intel_psr_update - Update PSR state
> * @intel_dp: Intel DP
> @@ -875,8 +890,13 @@ void intel_psr_update(struct intel_dp *intel_dp,
> enable = crtc_state->has_psr && psr_global_enabled(psr->debug);
> psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
>
> - if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> + if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> {
PSR2 is enabled, then user requests CRCs, the mode_changed commit
switches to PSR1. The above condition isn't true in that case.
Also, since the CRC workaround is done before enabling pipe CRC, isn't
there a possibility that the idle frame counter times out and activates
PSR1 before CRC is enabled?
> + /* Force a PSR exit when enabling CRC to avoid CRC
> timeouts */
> + if (crtc_state->crc_enabled && psr->enabled)
> + psr_force_hw_tracking_exit(dev_priv);
The patch fixes a PSR1 issue, why isn't there any reference to PSR1
anywhere?
> +
> goto unlock;
> + }
>
> if (psr->enabled)
> intel_psr_disable_locked(intel_dp);
> @@ -1146,18 +1166,8 @@ 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) {
> - /*
> - * 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_SURFLIVE_A,
> - * but it makes more sense write to the current active
> - * pipe.
> - */
> - I915_WRITE(CURSURFLIVE(dev_priv->psr.pipe), 0);
> - }
> + if (frontbuffer_bits)
> + psr_force_hw_tracking_exit(dev_priv);
>
> if (!dev_priv->psr.active && !dev_priv-
> >psr.busy_frontbuffer_bits)
> schedule_work(_priv->psr.work);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 7/9] drm/i915: Drop redundant checks to update PSR state
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> All of this checks are redudant and can be removed as the if bellow
below*
> already takes care when there is no changes in the state.
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 73453d89a841..d3e3996551c6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -878,15 +878,11 @@ void intel_psr_update(struct intel_dp
> *intel_dp,
> if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> goto unlock;
>
> - if (psr->enabled) {
> - if (!enable || psr2_enable != psr->psr2_enabled)
> - intel_psr_disable_locked(intel_dp);
> - }
> + if (psr->enabled)
> + intel_psr_disable_locked(intel_dp);
>
> - if (enable) {
> - if (!psr->enabled || psr2_enable != psr->psr2_enabled)
> - intel_psr_enable_locked(dev_priv, crtc_state);
> - }
> + if (enable)
> + intel_psr_enable_locked(dev_priv, crtc_state);
>
Looks like all cases are handled
PSR1 -> PSR2, disable, PSR1
PSR2 -> PSR1, disable, PSR2
disable -> PSR1, disable, PSR2
Reviewed-by: Dhinakaran Pandiyan
> unlock:
> mutex_unlock(_priv->psr.lock);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 6/9] drm/i915: Disable PSR2 while getting pipe CRC
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
s/interruptions/interrupts
I suppose there are no bugzilla references, since we do not check CRCs
in kms_psr and PSR2 is not enabled in kms_frontbuffer_tracking
>
> This same behavior don't happen with PSR1, as soon as pipe CRC is
> enabled it blocks PSR1 activation
The hardware also deactivates PSR1, not just block future PSR1
activation. Right?
> so CRC calculation continues to
> happens normaly.
>
> This patch also set mode_changed as true when PSR is available to
> force atomic check functions to compute new PSR state, otherwise PSR2
> would not be disabled.
>
> v4: Only setting mode_changed if has_psr is set(Dhinakaran)
>
> v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting
> mode_changed if it can do PSR.
>
> v2: Changed commit description to describe that PSR2 inhibit CRC
> calculations.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index af64597c5c6e..c17f02b88453 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -307,6 +307,7 @@ intel_crtc_crc_setup_workarounds(struct
> intel_crtc *crtc, bool enable)
> goto put_state;
> }
>
> + pipe_config->base.mode_changed = pipe_config->has_psr;
> pipe_config->crc_enabled = enable;
>
> if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d9f64c362e2..73453d89a841 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> + if (crtc_state->crc_enabled)
> + return false;
No DRM_DEBUG_KMS()?
with that added
Reviewed-by: Dhinakaran Pandiyan
> +
> return true;
> }
>
___
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
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?
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 v5 5/9] drm/i915/crc: Make IPS workaround generic
On Tue, 2019-03-05 at 22:47 -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.
>
> v2: Renaming and parameter changes to the functions that prepares the
> commit (Ville)
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Reviewed-by: Rodrigo Vivi
> 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 | 47 +++
>
> 3 files changed, 29 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9312b3f35eb0..b3a5d8462251 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;
>
> /* IPS should be fine as long as at least one plane is enabled.
> */
> @@ -11687,7 +11693,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..af64597c5c6e 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -280,15 +280,15 @@ 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_setup_workarounds(struct intel_crtc *crtc, bool
> enable)
> {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct drm_device *dev = _priv->drm;
We could eliminate this local.
> - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> PIPE_A);
> struct intel_crtc_state *pipe_config;
> struct drm_atomic_state *state;
> struct drm_modeset_acquire_ctx ctx;
> - int ret = 0;
> + int ret;
>
> drm_modeset_acquire_init(, 0);
>
> @@ -307,17 +307,9 @@ static void hsw_pipe_A_crc_wa(struct
> drm_i915_private *dev_priv,
> goto put_state;
> }
>
> - if (HAS_IPS(dev_priv)) {
> - /*
> - * 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.
> - */
> - pipe_config->ips_force_disable = enable;
> - }
> + pipe_config->crc_enabled = enable;
>
> - if (IS_HASWELL(dev_priv)) {
> + if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
> pipe_config->pch_pfit.force_thru = enable;
> if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
> pipe_config->pch_pfit.en
Re: [Intel-gfx] [PATCH 2/2] drm/i915/cml: Introduce Comet Lake PCH
On Wed, 2019-03-06 at 10:07 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> > From: Anusha Srivatsa
> >
> > Comet Lake PCH is based off of Cannon Point(CNP).
> > Add PCI ID for Comet Lake PCH.
> >
> > v2: Code cleanup (DK)
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 4
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1b2f5a6f8c25..e787c999b2c6 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -188,6 +188,10 @@ intel_pch_type(const struct drm_i915_private
> > *dev_priv, unsigned short id)
> > DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
> > return PCH_CNP;
> > + case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > + DRM_DEBUG_KMS("Found Comet Lake LP PCH (CMP)\n");
> > + WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
>
> Please remove CNL from this list...
>
> also please add a comment here before the return
>
> /* CM has same south display engine from CNP */
>
> > + return PCH_CNP;
> > case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> > WARN_ON(!IS_ICELAKE(dev_priv));
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 453af7438e67..55298e19e740 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -530,7 +530,7 @@ enum intel_pch {
> > PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
> > PCH_SPT,/* Sunrisepoint PCH */
> > PCH_KBP,/* Kaby Lake PCH */
> > - PCH_CNP,/* Cannon Lake PCH */
> > + PCH_CNP,/* Cannon/Comet Lake PCH */
> > PCH_ICP,/* Ice Lake PCH */
> > PCH_NOP,/* PCH without south display */
> > };
> > @@ -2552,6 +2552,7 @@ static inline unsigned int
> > i915_sg_segment_size(void)
> > #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > +#define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
The debug message calls the device "LP" but the device id macro
doesn't. This is not the case with CNP as both are consistent. So, the
question is this an LP PCH?
> > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> > #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> > --
> > 2.21.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/cml: Introduce Comet Lake PCH
On Mon, 2019-03-04 at 15:50 -0800, Rodrigo Vivi wrote:
> On Mon, Mar 04, 2019 at 03:06:05PM -0800, Anusha wrote:
> > From: Anusha Srivatsa
> >
> > Comet Lake PCH is based off of Cannon Point(CNP).
> > Add PCI ID for Comet Lake PCH.
> >
> > Cc: Rodrigo Vivi
> > Cc: Lucas De Marchi
> > Signed-off-by: Anusha Srivatsa
>
> Reviewed-by: Rodrigo Vivi
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 2 ++
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1b2f5a6f8c25..7934f19ed250 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -186,6 +186,8 @@ intel_pch_type(const struct drm_i915_private
> > *dev_priv, unsigned short id)
> > return PCH_CNP;
> > case INTEL_PCH_CNP_LP_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> > + case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > + DRM_DEBUG_KMS("Found Comet Lake LP PCH (CMP)\n");
This will end up printing both debug messages for CNP-LP devices.
> > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
> > return PCH_CNP;
> > case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 453af7438e67..55298e19e740 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -530,7 +530,7 @@ enum intel_pch {
> > PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
> > PCH_SPT,/* Sunrisepoint PCH */
> > PCH_KBP,/* Kaby Lake PCH */
> > - PCH_CNP,/* Cannon Lake PCH */
> > + PCH_CNP,/* Cannon/Comet Lake PCH */
> > PCH_ICP,/* Ice Lake PCH */
> > PCH_NOP,/* PCH without south display */
> > };
> > @@ -2552,6 +2552,7 @@ static inline unsigned int
> > i915_sg_segment_size(void)
> > #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > +#define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> > #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> > --
> > 2.21.0
> >
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/psr: Set idle frames to maximum while getting pipe CRC
On Mon, 2019-03-04 at 10:40 -0800, Souza, Jose wrote:
> On Mon, 2019-03-04 at 10:31 -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> > > Increase the idle frames to activate PSR1 to avoid CRC timeouts,
> > > as
> > > soon as pipe CRC is enabled it will avoid PSR1 to activate but if
> > > PSR1 is activate before that, hardware goes to lower power states
> > > that inhibits CRC calculations causing CRC timeout errors in IGT
> > > tests.
Okay, so you are solving the case where PSR is already active when we
want CRCs. How does modifying the idle frame count help if PSR is
already active?
The commit also says PSR does not become active if CRCs were already
enabled (idle count should not matter here). In that case, just
disabling and re-enabling should be good, isn't it? Or perhaps, just
doing a psr_flush() would do the same job?
> > >
> > > 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_psr.c | 17 +++--
> > > 2 files changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 453af7438e67..e336f758e481 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -521,6 +521,7 @@ struct i915_psr {
> > > bool sink_not_reliable;
> > > bool irq_aux_error;
> > > u16 su_x_granularity;
> > > + bool crc_enabled;
> > > };
> > >
> > > enum intel_pch {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index d3e3996551c6..b237d96db277 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct
> > > intel_dp
> > > *intel_dp)
> > >* frames, we'll go with 9 frames for now
> > >*/
> > > idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > > + 1);
> > > +
> > > + /*
> > > + * Increase the idle frames to active PSR1 to avoid CRC
> > > timeouts, as
> > > + * soon as pipe CRC is enabled it will avoid PSR1 to activate
> > > but if
> > > + * PSR1 is activate before that, hardware goes to lower power
> > > states
> > > + * that inhibits CRC calculations.
> > > + */
> > > + if (dev_priv->psr.crc_enabled)
> > > + idle_frames = 0xf;
> >
> > My understanding was only the enable bit can be changed when PSR is
> > enabled. Does this work?
>
> That is true, the additional changes in intel_psr_update() will
> disable
> and then enable PSR with this new idle_frames.
>
> >
> > > +
> > > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 7/9] drm/i915: Drop redundant checks to update PSR state
On Mon, 2019-03-04 at 10:42 -0800, Rodrigo Vivi wrote:
> On Fri, Mar 01, 2019 at 05:34:54PM -0800, José Roberto de Souza
> wrote:
> > All of this checks are redudant and can be removed as the if bellow
> > already takes care when there is no changes in the state.
>
> is it just redundant or does it really change the behaviour for PSR2
> as needed?
I have the same question now that I read José's response to patch 8/9.
At first, I ignored reading this patch because it included the word
"redundant" in the commit message :)
>
> code seems right, explanation here not so sure...
> but if this is really right and I am missing something feel
> free to use:
>
>
> Reviewed-by: Rodrigo Vivi
>
> otherwise please change the msg.
>
> Thanks,
> Rodrigo.
>
> >
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 12
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 73453d89a841..d3e3996551c6 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -878,15 +878,11 @@ void intel_psr_update(struct intel_dp
> > *intel_dp,
> > if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> > goto unlock;
> >
> > - if (psr->enabled) {
> > - if (!enable || psr2_enable != psr->psr2_enabled)
> > - intel_psr_disable_locked(intel_dp);
> > - }
> > + if (psr->enabled)
> > + intel_psr_disable_locked(intel_dp);
> >
> > - if (enable) {
> > - if (!psr->enabled || psr2_enable != psr->psr2_enabled)
> > - intel_psr_enable_locked(dev_priv, crtc_state);
> > - }
> > + if (enable)
> > + intel_psr_enable_locked(dev_priv, crtc_state);
> >
> > unlock:
> > mutex_unlock(_priv->psr.lock);
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/psr: Set idle frames to maximum while getting pipe CRC
On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> Increase the idle frames to activate PSR1 to avoid CRC timeouts, as
> soon as pipe CRC is enabled it will avoid PSR1 to activate but if
> PSR1 is activate before that, hardware goes to lower power states
> that inhibits CRC calculations causing CRC timeout errors in IGT
> tests.
>
> 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_psr.c | 17 +++--
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 453af7438e67..e336f758e481 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -521,6 +521,7 @@ struct i915_psr {
> bool sink_not_reliable;
> bool irq_aux_error;
> u16 su_x_granularity;
> + bool crc_enabled;
> };
>
> enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d3e3996551c6..b237d96db277 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
>* frames, we'll go with 9 frames for now
>*/
> idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> + 1);
> +
> + /*
> + * Increase the idle frames to active PSR1 to avoid CRC
> timeouts, as
> + * soon as pipe CRC is enabled it will avoid PSR1 to activate
> but if
> + * PSR1 is activate before that, hardware goes to lower power
> states
> + * that inhibits CRC calculations.
> + */
> + if (dev_priv->psr.crc_enabled)
> + idle_frames = 0xf;
My understanding was only the enable bit can be changed when PSR is
enabled. Does this work?
> +
> val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Wed, 2019-02-27 at 17:32 -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
Just to make sure we are documenting the issue correctly in the commit
message - is it the SU state when CRC generation stops or deep sleep?
-DK
>
> Oddly that don't happen when PSR1 active, so here it switches from
> PSR2 to PSR1 while user is requesting pipe CRC.
>
> Force setting mode_changed as true is necessary to atomic checks
> functions compute new PSR state, that is why it was added to
> intel_crtc_crc_prepare().
>
> v3: Reusing intel_crtc_crc_prepare() and crc_enabled
>
> v2: Changed commit description to describe that PSR2 inhibit CRC
> calculations.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index f6d0b2aaffe2..e7ac24c33650 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct drm_i915_private
> *dev_priv, struct drm_crtc *crtc,
> goto put_state;
> }
>
> + pipe_config->base.mode_changed = pipe_config->crc_enabled !=
> enable;
> pipe_config->crc_enabled = enable;
>
> if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6175b1d2e0c8..f7730b8b2ec0 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> + if (crtc_state->crc_enabled)
> + return false;
> +
> return true;
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Thu, 2019-02-28 at 15:07 -0800, Souza, Jose wrote:
> On Thu, 2019-02-28 at 18:58 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza
> > wrote:
> > > When PSR2 is active aka after the number of frames programmed in
> > > PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> > > interruptions causing IGT tests to fail due timeout.
> > >
> > > Oddly that don't happen when PSR1 active, so here it switches
> > > from
> > > PSR2 to PSR1 while user is requesting pipe CRC.
> > >
> > > Force setting mode_changed as true is necessary to atomic checks
> > > functions compute new PSR state, that is why it was added to
> > > intel_crtc_crc_prepare().
> > >
> > > v3: Reusing intel_crtc_crc_prepare() and crc_enabled
> > >
> > > v2: Changed commit description to describe that PSR2 inhibit CRC
> > > calculations.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> > > drivers/gpu/drm/i915/intel_psr.c | 3 +++
> > > 2 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index f6d0b2aaffe2..e7ac24c33650 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct
> > > drm_i915_private
> > > *dev_priv, struct drm_crtc *crtc,
> > > goto put_state;
> > > }
> > >
> > > + pipe_config->base.mode_changed = pipe_config->crc_enabled !=
> > > enable;
> >
> > Do we really want to set that unconditionally?
>
> Without it atomic helpers will return ealier as there is no state
> changes, I was wondering if the IPS was being applied in the bellow
> connectors_changed is not set.
> Anyways to triggers the code paths to disable PSR2 it is needed, and
> with fastboot enable by default in gen9+ it will do a fastset so not
> much drawbacks.
What about pre gen9 platforms that do not have PSR? Running through
state checks and acquiring several locks on platforms that will never
need it is wasteful.
Why not make it conditional upon?
if (HAS_PSR()) or even CAN_PSR() for that matter.
>
> >
> > > pipe_config->crc_enabled = enable;
> > >
> > > if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 6175b1d2e0c8..f7730b8b2ec0 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> > > intel_dp *intel_dp,
> > > return false;
> > > }
> > >
> > > + if (crtc_state->crc_enabled)
> > > + return false;
> > > +
> > > return true;
> > > }
> > >
> > > --
> > > 2.21.0
___
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
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_crt
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC
On Sat, 2019-02-23 at 02:48 +, Souza, Jose wrote:
> On Fri, 2019-02-22 at 18:13 -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.
> > >
> > > 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 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -577,6 +577,9 @@ static bool intel_psr2_config_valid(struct
> > > inte
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC
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.
>
> 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 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -577,6 +577,9 @@ static bool intel_psr2_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> + if (dev_priv->psr.pipe_crc_enabled)
> + return false;
> +
Disabling PSR instead of switching to PSR1 is safer considering the
past bug reports with PSR1.
> return true;
> }
>
> @@ -1291,3 +1294,23 @@ bool intel_psr_enabled(struct intel_dp
> *intel_dp)
>
> return ret;
> }
> +
> +void intel_psr_crc_prepare_or_finish(struct drm_i915_private
> *dev_priv, enum pipe pipe, bool prepare)
> +{
> + bool fastset = false;
> +
> + if (!CAN_PSR(dev_priv))
> + return;
> +
> + mutex_lock(_priv->psr.lock);
> +
> + if (dev_priv->psr.pipe == pipe) {
> + dev_priv->psr.pipe_crc_enabled = prepare;
.crc_enabled seems like it belongs in crtc_state rather than in the
global atomic state.
Looks like we could rename and re-purpose crtc_state.ips_force_disable
for this. I don't see that flag being used for anything other working
around CRC issues.
> + fastset = !prepare || dev_priv->psr.psr2_enabled;
> + }
> +
> + mutex_unlock(_priv->psr.lock);
> +
> + if (fastset)
> + intel_psr_fastset_force(dev_priv);
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset
On Fri, 2019-02-22 at 16:33 -0800, Souza, Jose wrote:
> On Fri, 2019-02-22 at 16:27 -0800, Pandiyan, Dhinakaran wrote:
> > 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.
>
> When PSR2 is enabled by default tests like
> kms_pipe_crc_basic@read-crc-pipe-b are failling even with the patch
> that disable PSR2 when getting CRC.
Thanks!
>
> >
> > > 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) {
if (crtc_state->enable && intel_crtc_state->has_psr)
should cover all the cases, no?
And also add a WARN() in case we somehow end up with more than once
crtc with the above condition being true.
> > > /* 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
On Mon, 2019-02-18 at 19:57 +0200, Ville Syrjälä wrote: > On Fri, Feb 15, 2019 at 09:43:37PM +, Pandiyan, Dhinakaran wrote: > > 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. > > Could just be an omission in the spec. I don't think I actually > tested to see what happens when you try to use the pipe CRC with the > TV e
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x
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.
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;
> > > - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
> > > - need_stable_symbols = true;
> > > - break;
> > > - case INTEL_PIPE_CRC_SOURCE_DP_D:
> > > - if (!IS_G4X(dev_priv))
> > > - return -EINVAL;
> > > - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
> > > - need_stable_symbols = true;
> > > - break;
> > > case INTEL_PIPE_CRC_SOURCE_NONE:
> > > *val = 0;
> > > break;
> > > default:
> > > + /*
> &
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend skl+ crc sources with more planes
On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On skl the crc registers were extended to provide plane crcs
> for up to 7 planes. Add the new crc sources.
>
> The current code uses the ivb+ register definitions for skl+
> which does happen to work as the plane1, plane2, and dmux/pf
> bits happen the match what ivb+ had. So no bug in the current
> code.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 ++
> drivers/gpu/drm/i915/i915_reg.h | 9
> drivers/gpu/drm/i915/intel_pipe_crc.c | 76
> ++-
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 4e11d970cbcf..8607c1e9ed02 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1196,6 +1196,11 @@ enum intel_pipe_crc_source {
> INTEL_PIPE_CRC_SOURCE_NONE,
> INTEL_PIPE_CRC_SOURCE_PLANE1,
> INTEL_PIPE_CRC_SOURCE_PLANE2,
> + INTEL_PIPE_CRC_SOURCE_PLANE3,
> + INTEL_PIPE_CRC_SOURCE_PLANE4,
> + INTEL_PIPE_CRC_SOURCE_PLANE5,
> + INTEL_PIPE_CRC_SOURCE_PLANE6,
> + INTEL_PIPE_CRC_SOURCE_PLANE7,
> INTEL_PIPE_CRC_SOURCE_PIPE,
> /* TV/DP on pre-gen5/vlv can't use the pipe source. */
> INTEL_PIPE_CRC_SOURCE_TV,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 0df8c6e76da7..5286536e9cb8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4017,6 +4017,15 @@ enum {
> /* Pipe A CRC regs */
> #define _PIPE_CRC_CTL_A 0x60050
> #define PIPE_CRC_ENABLE(1 << 31)
> +/* skl+ source selection */
> +#define PIPE_CRC_SOURCE_PLANE_1_SKL(0 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_2_SKL(2 << 28)
> +#define PIPE_CRC_SOURCE_DMUX_SKL (4 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_3_SKL(6 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_4_SKL(7 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_5_SKL(5 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_6_SKL(3 << 28)
> +#define PIPE_CRC_SOURCE_PLANE_7_SKL(1 << 28)
> /* ivb+ source selection */
> #define PIPE_CRC_SOURCE_PRIMARY_IVB(0 << 29)
> #define PIPE_CRC_SOURCE_SPRITE_IVB (1 << 29)
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 66bb7b031537..e521f82ba5d9 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -34,6 +34,11 @@ static const char * const pipe_crc_sources[] = {
> [INTEL_PIPE_CRC_SOURCE_NONE] = "none",
> [INTEL_PIPE_CRC_SOURCE_PLANE1] = "plane1",
> [INTEL_PIPE_CRC_SOURCE_PLANE2] = "plane2",
> + [INTEL_PIPE_CRC_SOURCE_PLANE3] = "plane3",
> + [INTEL_PIPE_CRC_SOURCE_PLANE4] = "plane4",
> + [INTEL_PIPE_CRC_SOURCE_PLANE5] = "plane5",
> + [INTEL_PIPE_CRC_SOURCE_PLANE6] = "plane6",
> + [INTEL_PIPE_CRC_SOURCE_PLANE7] = "plane7",
> [INTEL_PIPE_CRC_SOURCE_PIPE] = "pipe",
> [INTEL_PIPE_CRC_SOURCE_TV] = "TV",
> [INTEL_PIPE_CRC_SOURCE_DP_B] = "DP-B",
> @@ -368,6 +373,50 @@ static int ivb_pipe_crc_ctl_reg(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +static int skl_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> + enum pipe pipe,
> + enum intel_pipe_crc_source *source,
> + uint32_t *val,
> + bool set_wa)
set_wa is unused.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove the "pf" crc source
On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The "pipe" and "pf" crc sources are in fact the same thing.
> Remove the "pf" one.
And BDW+ seem to call it DMUX output.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_pipe_crc.c | 6 ++
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 17fe942eaafa..4e11d970cbcf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1196,7 +1196,6 @@ enum intel_pipe_crc_source {
> INTEL_PIPE_CRC_SOURCE_NONE,
> INTEL_PIPE_CRC_SOURCE_PLANE1,
> INTEL_PIPE_CRC_SOURCE_PLANE2,
> - INTEL_PIPE_CRC_SOURCE_PF,
> INTEL_PIPE_CRC_SOURCE_PIPE,
> /* TV/DP on pre-gen5/vlv can't use the pipe source. */
> INTEL_PIPE_CRC_SOURCE_TV,
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index a8554dc4f196..a3a3ad760158 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -34,7 +34,6 @@ static const char * const pipe_crc_sources[] = {
> "none",
> "plane1",
> "plane2",
> - "pf",
> "pipe",
> "TV",
> "DP-B",
> @@ -396,7 +395,7 @@ static int ivb_pipe_crc_ctl_reg(struct
> drm_i915_private *dev_priv,
> bool set_wa)
> {
> if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> - *source = INTEL_PIPE_CRC_SOURCE_PF;
> + *source = INTEL_PIPE_CRC_SOURCE_PIPE;
>
> switch (*source) {
> case INTEL_PIPE_CRC_SOURCE_PLANE1:
> @@ -405,7 +404,7 @@ static int ivb_pipe_crc_ctl_reg(struct
> drm_i915_private *dev_priv,
> case INTEL_PIPE_CRC_SOURCE_PLANE2:
> *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_IVB;
> break;
> - case INTEL_PIPE_CRC_SOURCE_PF:
> + case INTEL_PIPE_CRC_SOURCE_PIPE:
Ah, source == "pipe" would have returned a failure here
although ivb_crc_source_valid() considers it a valid source. This
patch fixes that too.
Reviewed-by: Dhinakaran Pandiyan
> if (set_wa && (IS_HASWELL(dev_priv) ||
>IS_BROADWELL(dev_priv)) && pipe == PIPE_A)
> hsw_pipe_A_crc_wa(dev_priv, true);
> @@ -532,7 +531,6 @@ static int ivb_crc_source_valid(struct
> drm_i915_private *dev_priv,
> case INTEL_PIPE_CRC_SOURCE_PIPE:
> case INTEL_PIPE_CRC_SOURCE_PLANE1:
> case INTEL_PIPE_CRC_SOURCE_PLANE2:
> - case INTEL_PIPE_CRC_SOURCE_PF:
> case INTEL_PIPE_CRC_SOURCE_NONE:
> return 0;
> default:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove the "pf" crc source
On Thu, 2019-02-14 at 17:32 -0800, Dhinakaran Pandiyan wrote: > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The "pipe" and "pf" crc sources are in fact the same thing. > > Remove the "pf" one. > > And BDW+ seem to call it DMUX output. Oh, we need to remove this in IGT too. > > > > Signed-off-by: Ville Syrjälä > > --- ___ 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
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.
>
> 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;
> - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
> - need_stable_symbols = true;
> - break;
> - case INTEL_PIPE_CRC_SOURCE_DP_D:
> - if (!IS_G4X(dev_priv))
> - return -EINVAL;
> - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
> - need_stable_symbols = true;
> - break;
> case INTEL_PIPE_CRC_SOURCE_NONE:
> *val = 0;
> break;
> default:
> + /*
> + * The DP CRC source doesn't work on g4x.
> + * It can be made to work to some degree by selecting
> + * the correct CRC source before the port is enabled,
> + * and not touching the CRC source bits again until
> + * the port is disabled. But even then the bits
> + * eventually get stuck and a reboot is needed to get
> + * working CRCs on the pipe again. Let's simply
> + * refuse to use DP CRCs on g4x.
> + */z
> return -EINVAL;
> }
>
> - /*
> - * When the pipe CRC tap point is after the transcoders we need
> - * to tweak symbol-level features to produce a deterministic
> series of
> - * symbols for a given frame. We need to reset those features
> only once
> - * a frame (instead of every nth symbol):
> - * - DC-balance: used to ensure a better clock recovery from
> the data
> - * link (SDVO)
> - * - DisplayPort scrambling: used for EMI reduction
> - */
> - if (need_stable_symbols) {
> - u32 tmp = I915_READ(PORT_DFT2_G4X);
> -
> - WARN_ON(!IS_G4X(dev_priv));
> -
> - I915_WRITE(PORT_DFT_I9XX,
> -I915_READ(PORT_DFT_I9XX) |
> DC_BALANCE_RESET);
> -
> - if (pipe == PIPE_A)
> - tmp |= PIPE_A_SCRAMBLE_RESET;
> - else
> - tmp |= PIPE_B_SCRAMBLE_RESET;
> -
> - I915_WRITE(PORT_DFT2_G4X, tmp);
> - }
> -
> return 0;
> }
>
> @@ -282,24 +247,6 @@ static void vlv_undo_pipe_scramble_reset(struct
> drm_i915_private *dev_priv,
> if (!(tmp & PIPE_SCRAMBLE_RESET_MASK))
> tmp &= ~DC_BALANCE_RESET_VLV;
> I915_WRITE(PORT_DFT2_G4X, tmp);
> -
> -}
> -
> -static void g4x_undo_pipe_scramble_reset(struct drm_i915_private
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC
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?
> 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 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -577,6 +577,9 @@ static bool intel_psr2_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> + if (dev_priv->psr.pipe_crc_enabled)
> + return false;
> +
> return true;
> }
>
> @@ -1291,3 +1294,23 @@ bool intel_psr_enabled(struct intel_dp
> *intel_dp)
>
> return ret;
> }
> +
> +void intel_psr_crc_prepare_or_finish(struct drm_i915_private
> *dev_priv, enum pipe pipe, bool prepare)
> +{
> + bool fastset = false;
> +
> + if (!CAN_PSR(dev_priv))
> + return;
> +
> + mutex_lock(_priv->psr.lock);
> +
> + if (dev_priv-&
Re: [Intel-gfx] [PATCH 4/6] drm/i915/psr: Remove PSR2 FIXME
On Thu, 2019-02-07 at 14:24 -0800, José Roberto de Souza wrote: > Now we are checking sink capabilities when probing PSR DPCD register > and then dynamically checking in if new state is compatible with PSR > in, so this FIXME can be dropped. Right, this was fixed a while ago. Reviewed-by: Dhinakaran Pandiyan > > Cc: Dhinakaran Pandiyan > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/intel_psr.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 75c1a5deebf5..8bed73914876 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -532,11 +532,6 @@ static bool intel_psr2_config_valid(struct > intel_dp *intel_dp, > int crtc_vdisplay = crtc_state- > >base.adjusted_mode.crtc_vdisplay; > int psr_max_h = 0, psr_max_v = 0; > > - /* > - * FIXME psr2_support is messed up. It's both computed > - * dynamically during PSR enable, and extracted from sink > - * caps during eDP detection. > - */ > if (!dev_priv->psr.sink_psr2_support) > return false; > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/psr: Execute the default PSR code path when setting i915_edp_psr_debug
On Wed, 2019-02-06 at 13:18 -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)
>
> v4: Adding back the missing call to intel_psr_irq_control(Dhinakaran)
Reviewed-by: Dhinakaran Pandiyan
>
> 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| 182
>
> 5 files changed, 113 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 0bd890c04fe4..20a49cc4a9a1 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_debug_set(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 a2293152cb6a..989d1ac72ec8 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 9ec3d00fbd19..3eba33a2f951 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2077,9 +2077,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_debug_set(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
> index 84a0fb981561..75c1a5deebf5 100644
> --
Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Execute the default PSR code path when setting i915_edp_psr_debug
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
> index 84a0fb981561..e970ffd7dd0d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -51,6 +51,8 @@
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Execute the default PSR code path when setting i915_edp_psr_debug
On Wed, 2019-01-30 at 16:58 -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
>
> 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
> ---
>
> Should I add IGT tests to test every state switch combination?
Yes, please. At the minimum we need, PSR1->PSR2->PSR1 to make sure the
driver warnings aren't triggered.
>
> 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| 187 +-
> --
> 5 files changed, 118 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 22da9df1f0a7..f75b4ce4df5f 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
> index 84a0fb981
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vbt: Parse and use the new field with PSR2 TP2/3/4 wakeup time
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
These values are for PSR1, aren't they? Like you write in Patch 4/4,
the PSR2 control register does not have a bit to set anything other
than Tp2.
-DK
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_bios.c | 10 ++
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index d9893d35f0e2..e739ed9ce60c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -967,6 +967,13 @@ enum psr_tp_wakeup_time {
> PSR_TP_WAKEUP_TIME_LAST
> };
>
> +enum psr2_tp_wakeup_time {
> + PSR2_TP_WAKEUP_TIME_500USEC = 0,
> + PSR2_TP_WAKEUP_TIME_100USEC,
> + PSR2_TP_WAKEUP_TIME_2500USEC,
> + PSR2_TP_WAKEUP_TIME_50USEC
> +};
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1005,6 +1012,7 @@ struct intel_vbt_data {
> enum psr_lines_to_wait lines_to_wait;
> enum psr_tp_wakeup_time tp1_wakeup_time;
> enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> + enum psr2_tp_wakeup_time psr2_tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 6de6f6f1deec..23130e0d5e6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -757,6 +757,16 @@ parse_psr(struct drm_i915_private *dev_priv,
> const struct bdb_header *bdb)
>
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time =
> wakeup_time;
> }
> +
> + if (bdb->version >= 226) {
> + u32 wakeup_time = psr_table-
> >psr2_tp2_tp3_tp4_wakeup_time;
> +
> + wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> wakeup_time;
> + } else {
> + /* Reusing PSR1 wakeup time for PSR2 in older VBTs */
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time;
> + }
> }
>
> static void parse_dsi_backlight_ports(struct drm_i915_private
> *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 5daf0b9e2b42..2fc537fb6e78 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -494,7 +494,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency
> + 1);
>
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
> + val |= dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
>
> I915_WRITE(EDP_PSR2_CTL, val);
> }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 4ed66efde49f..dc0a14977953 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -772,6 +772,9 @@ struct psr_table {
> /* TP wake up time in multiple of 100 */
> u16 tp1_wakeup_time;
> u16 tp2_tp3_tp4_wakeup_time;
> +
> + /* PSR2 TP2/TP3/TP4 wakeup time for 16 panels */
This needs to fixed as well.
> + u32 psr2_tp2_tp3_tp4_wakeup_time;
> } __packed;
>
> struct bdb_psr {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Add HBR3 support
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> If the sink and source supports HBR3, TP4 should be used as link
> training pattern.
> For PSR2 there is no register to set and enable TP4 but according to
> eDP spec TP3 is still a training pattern acceptable for HBR3 panels.
>
Sounds like TP3 and TP4 are used only with PSR1, please document that
in the commit message.
> Cc: Manasi Navare
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
>
> Still trying to understand how PSR1 was working on ICL while sending
> TP4 to a panel that only supports HBR2.
That's a good point, along with that please find out what Bit 11: "TPS4
Control" does. I'd like us get these questions answered, if possible,
before merging this series.
>
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 24 ++---
> --
> 4 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 5faca634ee70..1e792309a79e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4162,6 +4162,7 @@ enum {
> #define EDP_PSR_TP1_TP3_SEL(1 << 11)
> #define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
> #define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
> +#define EDP_PSR_TP4_TIME_SHIFT (6) /* ICL+ */
> #define EDP_PSR_TP1_TIME_SHIFT (4)
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 30be0e39bd5f..3e9798a5498c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -238,7 +238,7 @@ intel_dp_link_training_clock_recovery(struct
> intel_dp *intel_dp)
> * or for 1.4 devices that support it, training Pattern 3 for HBR2
> * or 1.2 devices that support it, Training Pattern 2 otherwise.
> */
> -static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
> +u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
> {
> bool source_tps3, sink_tps3, source_tps4, sink_tps4;
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e5a436c33307..fc3e6ae92276 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1807,6 +1807,7 @@ int
> intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int link_rate, uint8_t
> lane_count);
> void intel_dp_start_link_train(struct intel_dp *intel_dp);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> +u32 intel_dp_training_pattern(struct intel_dp *intel_dp);
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2fc537fb6e78..b0525940e5e9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -440,6 +440,7 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u32 max_sleep_time = 0x1f;
> u32 val = EDP_PSR_ENABLE;
> + u32 tp;
>
> /* Let's use 6 as the minimum to cover all known cases
> including the
>* off-by-one issue that HW has in some cases.
> @@ -460,13 +461,24 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> val |= EDP_PSR_LINK_STANDBY;
>
> val |= dev_priv->vbt.psr.tp1_wakeup_time <<
> EDP_PSR_TP1_TIME_SHIFT;
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR_TP2_TP3_TIME_SHIFT;
>
> - if (intel_dp_source_supports_hbr2(intel_dp) &&
Now that you are removing a caller, make this function static and move
to intel_dp_link_tranining.c instead ? Or just inline the code there.
> - drm_dp_tps3_supported(intel_dp->dpcd))
> - val |= EDP_PSR_TP1_TP3_SEL;
> - else
> - val |= EDP_PSR_TP1_TP2_SEL;
> + tp = intel_dp_training_pattern(intel_dp);
> + if (tp == DP_TRAINING_PATTERN_4) {
> + /*
> + * TP4 is selected by setting EDP_PSR_TP4_TIME with
> other value
> + * than PSR_TP_WAKEUP_TIME_NONE
> + */
IMHO I think we should skip t
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/icl: Work around broken VBTs for port F detection
On Thu, 2018-12-20 at 17:52 +0200, Imre Deak wrote: > VBT may include incorrect information about the presence of port F. > Work > around this on SKUs where we know the port is not present. If we cannot trust the data in VBT, can we not test for the absence of port-F by enabling the powerwell and checking for a timeout? Or at least mark up a non-existent port after the first timeout so that we don't keep probing it. This patch is an improvement over checking the VBT for all ports, so Reviewed-by: Dhinakaran Pandiyan > > v2: > - Fix IS_ICL_WITH_PORT_F, so it's useable from any context. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108915 > Cc: Mika Kahola > Cc: Jani Nikula > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_display.c | 4 +++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > b/drivers/gpu/drm/i915/i915_drv.h > index 815db160b966..e45cda9d9555 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2317,6 +2317,8 @@ intel_info(const struct drm_i915_private > *dev_priv) >(dev_priv)->info.gt == 3) > #define IS_CNL_WITH_PORT_F(dev_priv) (IS_CANNONLAKE(dev_priv) && \ > (INTEL_DEVID(dev_priv) & > 0x0004) == 0x0004) > +#define IS_ICL_WITH_PORT_F(dev_priv) (IS_ICELAKE(dev_priv) && \ > + INTEL_DEVID(dev_priv) != > 0x8A51) > > #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)- > >is_alpha_support) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 2b81da068010..bd7fdaf7e093 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14276,8 +14276,10 @@ static void intel_setup_outputs(struct > drm_i915_private *dev_priv) > /* >* On some ICL SKUs port F is not present. No strap > bits for >* this, so rely on VBT. > + * Work around broken VBTs on SKUs known to have no > port F. >*/ > - if (intel_bios_is_port_present(dev_priv, PORT_F)) > + if (IS_ICL_WITH_PORT_F(dev_priv) && > + intel_bios_is_port_present(dev_priv, PORT_F)) > intel_ddi_init(dev_priv, PORT_F); > > icl_dsi_init(dev_priv); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/debugfs: Print PSR selective update status register values
On Fri, 2019-01-11 at 12:44 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> v2:
> - Using new macros
> - Changed the string output
>
> v3:
> - reading PSR2_SU_STATUS registers together(Dhinakaran)
> - printing SU blocks of frames with 0 updates(Dhinakaran)
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index f8668cb05d64..5817ae0fb5f8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2600,6 +2600,29 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> }
>
> + if (psr->psr2_enabled) {
> + u32 su_frames_val[3];
> + u8 frame;
'int' seems like a more appropriate choice here. With that changed,
Reviewed-by: Dhinakaran Pandiyan
Also, patch 2/4 needs rebase.
-DK
> +
> + /*
> + * Reading all 3 registers before hand to minimize
> crossing a
> + * frame boundary between register reads
> + */
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame +=
> 3)
> + su_frames_val[frame / 3] =
> I915_READ(PSR2_SU_STATUS(frame));
> +
> + seq_puts(m, "Frame:\tPSR2 SU blocks:\n");
> +
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame++)
> {
> + u32 su_blocks;
> +
> + su_blocks = su_frames_val[frame / 3] &
> + PSR2_SU_STATUS_MASK(frame);
> + su_blocks = su_blocks >>
> PSR2_SU_STATUS_SHIFT(frame);
> + seq_printf(m, "%d\t%d\n", frame, su_blocks);
> + }
> + }
> +
> unlock:
> mutex_unlock(>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 v2 5/6] drm/i915: Add PSR2 selective update status registers and bits definitions
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
I suppose you mean 'polling'.
> flip
> can show that the expected values are set for the current frame and
> the
> previous ones too.
The values correspond to the last 8 frames actually.
>
> v2: Improved macros(Dhinakaran)
Reviewed-by: Dhinakaran Pandiyan
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 44958d994bfa..f9712d05314b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4272,6 +4272,15 @@ enum {
> #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
>
> +#define _PSR2_SU_STATUS_00x6F914
> +#define _PSR2_SU_STATUS_10x6F918
> +#define _PSR2_SU_STATUS_20x6F91C
> +#define _PSR2_SU_STATUS(index) _MMIO(_PICK_EVEN((index
> ), _PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
> +#define PSR2_SU_STATUS(frame)(_PSR2_SU_STATUS((frame
> ) / 3))
> +#define PSR2_SU_STATUS_SHIFT(frame) (((frame) % 3) * 10)
> +#define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> PSR2_SU_STATUS_SHIFT(frame))
> +#define PSR2_SU_STATUS_FRAMES8
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/debugfs: Print PSR selective update status register values
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> v2:
> - Using new macros
> - Changed the string output
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 32 +
>
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5ebf0e647ac7..4e92078bc65d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2621,10 +2621,34 @@ static int i915_edp_psr_status(struct
> seq_file *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> - seq_printf(m, "Last attempted entry at: %lld\n",
> -psr->last_entry_attempt);
> - seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> + if (!psr->psr2_enabled) {
> + if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + seq_printf(m, "Last attempted entry at:
> %lld\n",
> +psr->last_entry_attempt);
> + seq_printf(m, "Last exit at: %lld\n", psr-
> >last_exit);
> + }
> + } else {
> + u8 frame;
> +
> + seq_puts(m, "Frame:\tPSR2 SU blocks:\n");
> +
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame++)
> {
> + u32 su_blocks;
> +
> + /*
> + * Avoid register reads as each register
> contains more
> + * than one frame value
> + */
I don't think the comment is needed, but if you want to retain it I
suggest explicitly saying each register contains data for three frames?
Not sure if it matters, how about completing all the three register
reads before printing so that we reduce the chances of crossing a frame
boundary between register reads?
> + if ((frame % 3) == 0)
> + val = I915_READ(PSR2_SU_STATUS(frame));
> +
> + su_blocks = val & PSR2_SU_STATUS_MASK(frame);
> + su_blocks = su_blocks >>
> PSR2_SU_STATUS_SHIFT(frame);
> + /* Only printing frames with SU blocks */
> + if (!su_blocks)
> + continue;
Why not print zero if that's the number of blocks updated in a frame?
> + seq_printf(m, "%d\t%d\n", frame, su_blocks);
> + }
> }
>
> unlock:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/psr: Do not print last attempted entry or exit in PSR debugfs while in PSR2
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugfs.
> Also adding a comment to intel_psr_irq_handler() about that.
>
Is it worth keeping this stuff for PSR1 if PSR2 is not supported, did
not work well enough for PSR1 IGTs either. In any case, are these
interrupts present on ICL?
> v2: Warning and not letting user set PSR_DEBUG_IRQ when PSR2 is
> enabled(Dhinakaran)
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
> drivers/gpu/drm/i915/intel_psr.c| 1 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 77b097b50fd5..5ebf0e647ac7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2621,7 +2621,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
Is there a case where PSR2 and IRQ debug are enabled now that you
disallow setting of this value?
> seq_printf(m, "Last attempted entry at: %lld\n",
> psr->last_entry_attempt);
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> @@ -2676,6 +2676,10 @@ i915_edp_psr_debug_set(void *data, u64 val)
> skip_mode:
> if (!ret) {
> mutex_lock(_priv->psr.lock);
> + if (dev_priv->psr.psr2_enabled && (val &
> I915_PSR_DEBUG_IRQ)) {
> + val &= ~I915_PSR_DEBUG_IRQ;
> + DRM_WARN("PSR debug IRQ cannot be enabled with
> PSR2");
WARN is inconsistent with DEBUG level logging that this function
already uses.
> + }
> dev_priv->psr.debug = val;
> intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
We are accessing hardware outside of rpm_get()/rpm_put() here.
> mutex_unlock(_priv->psr.lock);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index bba4f7da68b3..a875546880fa 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -201,6 +201,7 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir)
> mask |= EDP_PSR_ERROR(shift);
> }
>
> + /* PSR2 don't trigger PRE_ENTRY and POST_EXIT
> interruptions */
> if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
> dev_priv->psr.last_entry_attempt = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR entry
> attempt in 2 vblanks\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Refactor PSR status debugfs
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy frontbuffer bits: 0x000
> Main link in standby mode: no
> HW Enabled & Active bit: yes
> Source PSR status: 0x24050006 [SRDONACK]
>
> To:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x03]
> PSR mode: PSR1 enabled
> Source PSR ctl: enabled [0x81f00e26]
> Source PSR status: IDLE [0x04010006]
> Busy frontbuffer bits: 0x
>
> The 'Main link in standby mode' was removed as it is not useful but
> if needed by someone the information is still in the register value
> of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was
> squashed into PSR mode, some renames and reorders and we have this
> cleaner version. This will also make easy to parse debugfs for IGT
> tests.
>
> v2: Printing sink PSR version with only 2 hex digits as it is a byte
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 95 ++-
> --
> 1 file changed, 47 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 193823048f96..1a31921598e7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2529,7 +2529,8 @@ DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> static void
> psr_source_status(struct drm_i915_private *dev_priv, struct seq_file
> *m)
> {
> - u32 val, psr_status;
> + u32 val, status_val;
> + const char *status = "unknown";
>
> if (dev_priv->psr.psr2_enabled) {
> static const char * const live_status[] = {
> @@ -2545,14 +2546,11 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "BUF_ON",
> "TG_ON"
> };
> - psr_status = I915_READ(EDP_PSR2_STATUS);
> - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> - EDP_PSR2_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR2_STATUS);
> + status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> } else {
> static const char * const live_status[] = {
> "IDLE",
> @@ -2564,74 +2562,75 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "SRDOFFACK",
> "SRDENT_ON",
> };
> - psr_status = I915_READ(EDP_PSR_STATUS);
> - val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> - EDP_PSR_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR_STATUS);
> + status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> + EDP_PSR_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> }
>
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n", psr_status,
> "unknown");
> + seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
> }
>
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - u32 psrperf = 0;
> - bool enabled = false;
> - bool sink_support;
> + struct i915_psr *psr = _priv->psr;
> + const char *status;
> + bool enabled;
> + u32 val;
>
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>
> - sink_support =
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/psr: Allow PSR2 to be enabled when debugfs asks
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be enabled needs to take in consideration
> the debug field.
>
> v2: Using the switch/case that intel_psr2_enabled() already had to
> handle this(DK)
Reviewed-by: Dhinakaran Pandiyan
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index dce39f06b682..0ef6c5f8c298 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,17 +71,17 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state
> *crtc_state)
> {
> - /* Disable PSR2 by default for all platforms */
> - if (i915_modparams.enable_psr == -1)
> - return false;
> -
> /* Cannot enable DSC and PSR2 simultaneously */
> WARN_ON(crtc_state->dsc_params.compression_enable &&
> crtc_state->has_psr2);
>
> switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
> + case I915_PSR_DEBUG_DISABLE:
> case I915_PSR_DEBUG_FORCE_PSR1:
> return false;
> + case I915_PSR_DEBUG_DEFAULT:
> + if (i915_modparams.enable_psr <= 0)
> + return false;
> default:
> return crtc_state->has_psr2;
> }
___
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: Refactor PSR status debugfs
On Wed, 2019-01-02 at 09:09 -0800, Souza, Jose wrote:
> On Tue, 2018-12-11 at 18:54 +, Souza, Jose wrote:
> > On Tue, 2018-12-11 at 10:32 -0800, Dhinakaran Pandiyan wrote:
> > > On Tue, 2018-12-11 at 04:44 -0800, Souza, Jose wrote:
> > > > On Mon, 2018-12-10 at 22:51 -0800, Dhinakaran Pandiyan wrote:
> > > > > On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza
> > > > > wrote:
> > > > > > The old debugfs fields was not following a naming partern
> > > > > > and
> > > > > > it
> > > > > > was
> > > > > > a bit confusing.
> > > > > >
> > > > > > So it went from:
> > > > > > ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> > > > > > Sink_Support: yes
> > > > > > PSR mode: PSR1
> > > > > > Enabled: yes
> > > > > > Busy frontbuffer bits: 0x000
> > > > > > Main link in standby mode: no
> > > > > > HW Enabled & Active bit: yes
> > > > > > Source PSR status: 0x24050006 [SRDONACK]
> > > > > >
> > > > > > To:
> > > > > > ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> > > > > > Sink support: yes [0x0003]
> > > > > > Status: PSR1 enabled
> > > > > > Source PSR ctl: enabled [0x81f00e26]
> > > > > > Source PSR status: SRDENT [0x40040006]
> > > > > > Busy frontbuffer bits: 0x
> > > > > >
> > > > > > The 'Main link in standby mode' was removed as it is not
> > > > > > useful
> > > > > > but
> > > > > > if needed by someone the information is still in the
> > > > > > register
> > > > > > value
> > > > > > of 'Source PSR ctl' inside of the brackets, PSR mode and
> > > > > > Enabled
> > > > > > was
> > > > > > squashed into Status, some renames and reorders and we have
> > > > > > this
> > > > > > cleaner version. This will also make easy to parse debugfs
> > > > > > for
> > > > > > IGT
> > > > > > tests.
> > > > > >
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Dhinakaran Pandiyan
> > > > > > Suggested-by: Dhinakaran Pandiyan <
> > > > > > dhinakaran.pandi...@intel.com>
> > > > > > Signed-off-by: José Roberto de Souza
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_debugfs.c | 96 +++--
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1 file changed, 49 insertions(+), 47 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > > > index 38dcee1ca062..86303ba02666 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > > > @@ -2665,7 +2665,8 @@
> > > > > > DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> > > > > > static void
> > > > > > psr_source_status(struct drm_i915_private *dev_priv,
> > > > > > struct
> > > > > > seq_file
> > > > > > *m)
> > > > > > {
> > > > > > - u32 val, psr_status;
> > > > > > + u32 val, status_val;
> > > > > > + const char *status = "unknown";
> > > > > >
> > > > > > if (dev_priv->psr.psr2_enabled) {
> > > > > > static const char * const live_status[] = {
> > > > > > @@ -2681,14 +2682,11 @@ psr_source_status(struct
> > > > > > drm_i915_private
> > > > > > *dev_priv, struct seq_file *m)
> > > > > > "BUF_ON",
> > > > > > "TG_ON"
> > > > > > };
> > > > > > - psr_status = I915_READ(EDP_PSR2_STATUS);
> > > > > > - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK)
> > > > > > - EDP_PSR2_STATUS_STATE_SHIFT;
> > > > >
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: DDI: call intel_psr_ and _edp_drrs_enable() on pipe updates (v2)
On Thu, 2018-12-20 at 15:13 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-12-20 at 09:10 -0800, Rodrigo Vivi wrote:
> > On Thu, Dec 20, 2018 at 02:21:20PM +0100, Hans de Goede wrote:
> > > Call intel_psr_enable() and intel_edp_drrs_enable() on pipe
> > > updates
> > > to make
> > > sure that we enable PSR / DRRS (when applicable) on fastsets.
>
> I am probably missing something, doesn't intel_pipe_config_compare()
> need to check for pipe_config->has_psr? And also read the hardware
> PSR
> state at boot?
Answering my own question here, pipe_config_compare() returns true
lacking a comparison for ->has_psr. And we assume the bios does not
enable PSR, so no need to read the hardware state.
> > >
> > > Note calling these functions when PSR / DRRS has already been
> > > enabled is a
> > > no-op, so it is safe to do this on every encoder->update_pipe
> > > callback.
> > >
> > > Changes in v2:
> > > -Merge the patches adding the intel_psr_enable() and
> > > intel_edp_drrs_enable()
> > > calls into a single patch
> > >
> > > Reviewed-by: Maarten Lankhorst > > >
> > > Signed-off-by: Hans de Goede
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: José Roberto de Souza
> >
> > Acked-by: Rodrigo Vivi
> >
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 19 +++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index e3cc19e19199..fdf57f451b72 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3537,6 +3537,24 @@ static void intel_disable_ddi(struct
> > > intel_encoder *encoder,
> > > intel_disable_ddi_dp(encoder, old_crtc_state,
> > > old_conn_state);
> > > }
> > >
> > > +static void intel_ddi_update_pipe_dp(struct intel_encoder
> > > *encoder,
> > > + const struct intel_crtc_state
> > > *crtc_state,
> > > + const struct drm_connector_state
> > > *conn_state)
> > > +{
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > > +
> > > + intel_psr_enable(intel_dp, crtc_state);
> > > + intel_edp_drrs_enable(intel_dp, crtc_state);
> > > +}
> > > +
> > > +static void intel_ddi_update_pipe(struct intel_encoder *encoder,
> > > + const struct intel_crtc_state
> > > *crtc_state,
> > > + const struct drm_connector_state
> > > *conn_state)
> > > +{
> > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>
> We could restrict this to eDP outputs as both PSR and DRRS are eDP
> features.
>
> > > + intel_ddi_update_pipe_dp(encoder, crtc_state,
> > > conn_state);
> > > +}
> > > +
> > > static void intel_ddi_set_fia_lane_count(struct intel_encoder
> > > *encoder,
> > >const struct intel_crtc_state
> > > *pipe_config,
> > >enum port port)
> > > @@ -4169,6 +4187,7 @@ void intel_ddi_init(struct drm_i915_private
> > > *dev_priv, enum port port)
> > > intel_encoder->pre_enable = intel_ddi_pre_enable;
> > > intel_encoder->disable = intel_disable_ddi;
> > > intel_encoder->post_disable = intel_ddi_post_disable;
> > > + intel_encoder->update_pipe = intel_ddi_update_pipe;
> > > intel_encoder->get_hw_state = intel_ddi_get_hw_state;
> > > intel_encoder->get_config = intel_ddi_get_config;
> > > intel_encoder->suspend = intel_ddi_encoder_suspend;
> > > --
> > > 2.20.1
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: simplify enable_psr handling
On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> The following commit:
>
> commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> enabled.")
>
> added some code with no usable functionality. Regardless of how the
> psr
> default is set up in the BDB_DRIVER_FEATURES section, if the
> enable_psr
> module parameter isn't specified it defaults to 0.
Right, that was intentional and the commit message even makes a note of
it
" Note: The feature currently remains disabled by default for all
platforms irrespective of what VBT says."
Anyway, we've enabled the feature by default now and the current code
should take into account the VBT flag if the module parameter is left
to a default value. Please check git://anongit.freedesktop.org/drm-tip
drm-tip.
-DK
>
> Remove this dead code, simplify the way that enable_psr is handled
> and
> update the module parameter string to match the actual functionality.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: Ross Zwisler
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 -
> drivers/gpu/drm/i915/i915_params.c | 4 +---
> drivers/gpu/drm/i915/i915_params.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 1 -
> drivers/gpu/drm/i915/intel_psr.c | 7 ---
> 5 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 872a2e159a5f9..b4c50ba0b22a6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1115,7 +1115,6 @@ struct intel_vbt_data {
> } edp;
>
> struct {
> - bool enable;
> bool full_link;
> bool require_aux_wakeup;
> int idle_frames;
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 295e981e4a398..80ce8758c3c69 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -87,9 +87,7 @@ i915_param_named_unsafe(enable_ppgtt, int, 0400,
> "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full
> with extended address space)");
>
> i915_param_named_unsafe(enable_psr, int, 0600,
> - "Enable PSR "
> - "(0=disabled, 1=enabled) "
> - "Default: -1 (use per-chip default)");
> + "Enable PSR (default: false)");
>
> i915_param_named_unsafe(alpha_support, bool, 0400,
> "Enable alpha quality driver support for latest hardware. "
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 6c4d4a21474b5..144572f17a83d 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -42,7 +42,7 @@ struct drm_printer;
> param(int, enable_dc, -1) \
> param(int, enable_fbc, -1) \
> param(int, enable_ppgtt, -1) \
> - param(int, enable_psr, -1) \
> + param(int, enable_psr, 0) \
> param(int, disable_power_well, -1) \
> param(int, enable_ips, 1) \
> param(int, invert_brightness, 0) \
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 1faa494e2bc91..d676d483d5cf1 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -551,7 +551,6 @@ parse_driver_features(struct drm_i915_private
> *dev_priv,
>*/
> if (!driver->drrs_enabled)
> dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> - dev_priv->vbt.psr.enable = driver->psr_enabled;
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index b6838b525502e..26e7eb318cf07 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1065,13 +1065,6 @@ void intel_psr_init(struct drm_i915_private
> *dev_priv)
> if (!dev_priv->psr.sink_support)
> return;
>
> - if (i915_modparams.enable_psr == -1) {
> - i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
> -
> - /* Per platform default: all disabled. */
> - i915_modparams.enable_psr = 0;
> - }
> -
> /* Set link_standby x link_off defaults */
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> /* HSW and BDW require workarounds that we don't
> implement. */
___
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: DDI: call intel_psr_ and _edp_drrs_enable() on pipe updates (v2)
On Thu, 2018-12-20 at 09:10 -0800, Rodrigo Vivi wrote:
> On Thu, Dec 20, 2018 at 02:21:20PM +0100, Hans de Goede wrote:
> > Call intel_psr_enable() and intel_edp_drrs_enable() on pipe updates
> > to make
> > sure that we enable PSR / DRRS (when applicable) on fastsets.
I am probably missing something, doesn't intel_pipe_config_compare()
need to check for pipe_config->has_psr? And also read the hardware PSR
state at boot?
> >
> > Note calling these functions when PSR / DRRS has already been
> > enabled is a
> > no-op, so it is safe to do this on every encoder->update_pipe
> > callback.
> >
> > Changes in v2:
> > -Merge the patches adding the intel_psr_enable() and
> > intel_edp_drrs_enable()
> > calls into a single patch
> >
> > Reviewed-by: Maarten Lankhorst
> > Signed-off-by: Hans de Goede
>
> Cc: Dhinakaran Pandiyan
> Cc: José Roberto de Souza
>
> Acked-by: Rodrigo Vivi
>
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index e3cc19e19199..fdf57f451b72 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3537,6 +3537,24 @@ static void intel_disable_ddi(struct
> > intel_encoder *encoder,
> > intel_disable_ddi_dp(encoder, old_crtc_state,
> > old_conn_state);
> > }
> >
> > +static void intel_ddi_update_pipe_dp(struct intel_encoder
> > *encoder,
> > +const struct intel_crtc_state
> > *crtc_state,
> > +const struct drm_connector_state
> > *conn_state)
> > +{
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +
> > + intel_psr_enable(intel_dp, crtc_state);
> > + intel_edp_drrs_enable(intel_dp, crtc_state);
> > +}
> > +
> > +static void intel_ddi_update_pipe(struct intel_encoder *encoder,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + const struct drm_connector_state
> > *conn_state)
> > +{
> > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
We could restrict this to eDP outputs as both PSR and DRRS are eDP
features.
> > + intel_ddi_update_pipe_dp(encoder, crtc_state,
> > conn_state);
> > +}
> > +
> > static void intel_ddi_set_fia_lane_count(struct intel_encoder
> > *encoder,
> > const struct intel_crtc_state
> > *pipe_config,
> > enum port port)
> > @@ -4169,6 +4187,7 @@ void intel_ddi_init(struct drm_i915_private
> > *dev_priv, enum port port)
> > intel_encoder->pre_enable = intel_ddi_pre_enable;
> > intel_encoder->disable = intel_disable_ddi;
> > intel_encoder->post_disable = intel_ddi_post_disable;
> > + intel_encoder->update_pipe = intel_ddi_update_pipe;
> > intel_encoder->get_hw_state = intel_ddi_get_hw_state;
> > intel_encoder->get_config = intel_ddi_get_config;
> > intel_encoder->suspend = intel_ddi_encoder_suspend;
> > --
> > 2.20.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Thu, 2018-12-13 at 15:09 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> > On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan
> > wrote:
> > > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Fill out the AVI infoframe quantization range bits using
> > > > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as
> > > > well.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> > > > 1 file changed, 10 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > > index 1277d31adb54..9c16e273fb8d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > > @@ -984,6 +984,8 @@ static bool
> > > > intel_sdvo_set_avi_infoframe(struct
> > > > intel_sdvo *intel_sdvo,
> > > > const struct
> > > > intel_crtc_state
> > > > *pipe_config,
> > > > const struct
> > > > drm_connector_state *conn_state)
> > > > {
> > > > + const struct drm_display_mode *adjusted_mode =
> > > > + _config->base.adjusted_mode;
> > > > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > > > union hdmi_infoframe frame;
> > > > int ret;
> > > > @@ -991,20 +993,19 @@ static bool
> > > > intel_sdvo_set_avi_infoframe(struct
> > > > intel_sdvo *intel_sdvo,
> > > >
> > > > ret =
> > > > drm_hdmi_avi_infoframe_from_display_mode(,
> > > >conn_sta
> > > > te-
> > > > > connector,
> > > >
> > > > - _co
> > > > nfig-
> > > > > base.adjusted_mode);
> > > >
> > > > + adjusted
> > > > _mode);
> > > > if (ret < 0) {
> > > > DRM_ERROR("couldn't fill AVI infoframe\n");
> > > > return false;
> > > > }
> > > >
> > > > - if (intel_sdvo->rgb_quant_range_selectable) {
> > > > - if (pipe_config->limited_color_range)
> > > > - frame.avi.quantization_range =
> > > > - HDMI_QUANTIZATION_RANGE_LIMITED
> > > > ;
> > > > - else
> > > > - frame.avi.quantization_range =
> > > > - HDMI_QUANTIZATION_RANGE_FULL;
> > > > - }
> > > > + drm_hdmi_avi_infoframe_quant_range(,
> > > > + conn_state-
> > > > >connector,
> > > > + adjusted_mode,
> > > > + pipe_config-
> > > > > limited_color_range ?
> > > >
> > > > + rgb_quant_range_sele
> > > > ctableTE
> > > > D :
> > > > + HDMI_QUANTIZATION_RA
> > > > NGE_FULL
> > > > ,
> > > > + intel_sdvo-
> > > > > rgb_quant_range_selectable);
> > >
> > > Seems like avi.quantization_range can now get set to _LIMITED or
> > > _FULL
> > > even when ->rgb_quant_range_selectable == false, i.e., it is not
> > > _DEFAULT anymore. Is that change in behavior intended?
> >
> > ->quant_range_selectable will be passed to
> > drm_hdmi_avi_infoframe_quant_range() which will do the right thing
> > with
> > it.
> >
> > That said, there is a slight behavioural change in that it will set
>
> Okay, I was indeed referring to this case.
>
> > the Q bit even with QS==1 iff the quantization range matches the
> > default quantization range for the mode. I noted this in the radeon
> > patch but forgot to mention it here.
>
> I'll let someone else with knowledge of HDMI to review this
> behavioral
> change. I'm trying to get hold of the HDMI spec now and will review
> if
> this hasn't been looked at by then.
>
Looks alright now that I went through the specs. With commit message
updated to make note of the Q value changes
Reviewed-by: Dhinakaran Pandiyan
>
> >
> > >
> > >
> > > >
> > > > len = hdmi_infoframe_pack(, sdvo_data,
> > > > sizeof(sdvo_data));
> > > > if (len < 0)
> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Fill out the AVI infoframe quantization range bits using
> > > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as
> > > well.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> > > 1 file changed, 10 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > index 1277d31adb54..9c16e273fb8d 100644
> > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > @@ -984,6 +984,8 @@ static bool
> > > intel_sdvo_set_avi_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > >const struct intel_crtc_state
> > > *pipe_config,
> > >const struct
> > > drm_connector_state *conn_state)
> > > {
> > > + const struct drm_display_mode *adjusted_mode =
> > > + _config->base.adjusted_mode;
> > > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > > union hdmi_infoframe frame;
> > > int ret;
> > > @@ -991,20 +993,19 @@ static bool
> > > intel_sdvo_set_avi_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > >
> > > ret = drm_hdmi_avi_infoframe_from_display_mode(,
> > > conn_state-
> > > > connector,
> > >
> > > -_config-
> > > > base.adjusted_mode);
> > >
> > > +adjusted_mode);
> > > if (ret < 0) {
> > > DRM_ERROR("couldn't fill AVI infoframe\n");
> > > return false;
> > > }
> > >
> > > - if (intel_sdvo->rgb_quant_range_selectable) {
> > > - if (pipe_config->limited_color_range)
> > > - frame.avi.quantization_range =
> > > - HDMI_QUANTIZATION_RANGE_LIMITED;
> > > - else
> > > - frame.avi.quantization_range =
> > > - HDMI_QUANTIZATION_RANGE_FULL;
> > > - }
> > > + drm_hdmi_avi_infoframe_quant_range(,
> > > +conn_state->connector,
> > > +adjusted_mode,
> > > +pipe_config-
> > > > limited_color_range ?
> > >
> > > +rgb_quant_range_selectableTE
> > > D :
> > > +HDMI_QUANTIZATION_RANGE_FULL
> > > ,
> > > +intel_sdvo-
> > > > rgb_quant_range_selectable);
> >
> > Seems like avi.quantization_range can now get set to _LIMITED or
> > _FULL
> > even when ->rgb_quant_range_selectable == false, i.e., it is not
> > _DEFAULT anymore. Is that change in behavior intended?
>
> ->quant_range_selectable will be passed to
> drm_hdmi_avi_infoframe_quant_range() which will do the right thing
> with
> it.
>
> That said, there is a slight behavioural change in that it will set
Okay, I was indeed referring to this case.
> the Q bit even with QS==1 iff the quantization range matches the
> default quantization range for the mode. I noted this in the radeon
> patch but forgot to mention it here.
I'll let someone else with knowledge of HDMI to review this behavioral
change. I'm trying to get hold of the HDMI spec now and will review if
this hasn't been looked at by then.
>
> >
> >
> > >
> > > len = hdmi_infoframe_pack(, sdvo_data,
> > > sizeof(sdvo_data));
> > > if (len < 0)
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/psr: Disable DRRS if enabled when enabling PSR from debugfs
On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote:
> On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > > Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > > > If panel supports DRRS and PSR and if driver is loaded without
> > > > PSR
> > > > enabled, driver will enable DRRS as expected but if PSR is
> > > > enabled
> > > > by
> > > > debugfs latter it will keep PSR and DRRS enabled causing
> > > > possible
> > > > problems as DRRS will lower the refresh rate while PSR enabled.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
> > > > Cc: Maarten Lankhorst
> > > > Cc: Dhinakaran Pandiyan
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_psr.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 853e3f1370a0..bfc6a08b5cf4 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -904,8 +904,11 @@ int intel_psr_set_debugfs_mode(struct
> > > > drm_i915_private *dev_priv,
> > > >
> > > > intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
> > > >
> > > > - if (dev_priv->psr.prepared && enable)
> > > > + if (dev_priv->psr.prepared && enable) {
> > > > + if (crtc_state)
> > > > + intel_edp_drrs_disable(dp, crtc_state);
> > > > intel_psr_enable_locked(dev_priv, crtc_state);
> > > > + }
> > > >
> > > > mutex_unlock(_priv->psr.lock);
> > > > return ret;
> > >
> > > I've considered this, but I thought it was a feature, not a bug.
> > > It's
> > > a pain to track
> > > how we handle this as intended.
> > >
> > > kms_frontbuffer_tracking is also controlling DRRS during the
> > > test,
> > > so
> > > perhaps simply
> > > fix the test?
> > >
> > > It seems the no_drrs test simply checks that if PSR is enabled,
> > > we
> > > don't have drrs
> > > enabled. We probably care about the default configuration, so I
> > > would
> > > simply disable
> > > the pipe, update the PSR flag, and then start running the tests.
> > > Else
> > > the only thing
> > > we test is that debugfs disables DRRS. Not that the default
> > > modeset
> > > path prevents
> > > PSR and DRRS simultaneously.
> > >
> > > ~Maarten
> > >
> > > Maybe something like below?
> > >
> > > Perhaps move the drrs manipulation functions from
> > > kms_frontbuffer_tracking to lib/kms_psr.c
> > >
> > > 8<---
> > > diff --git a/tests/kms_psr.c b/tests/kms_psr.c
> > > index 9767f475bf23..ffc356df06ce 100644
> > > --- a/tests/kms_psr.c
> > > +++ b/tests/kms_psr.c
> > > @@ -414,9 +414,6 @@ int main(int argc, char *argv[])
> > > kmstest_set_vt_graphics_mode();
> > > data.devid = intel_get_drm_devid(data.drm_fd);
> > >
> > > - if (!data.with_psr_disabled)
> > > - psr_enable(data.debugfs_fd);
> > > -
> > > igt_require_f(sink_support(),
> > > "Sink does not support PSR\n");
> > >
> > > @@ -428,18 +425,25 @@ int main(int argc, char *argv[])
> > > }
> > >
> > > igt_subtest("basic") {
> > > - setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> > > - igt_assert(psr_wait_entry_if_enabled());
> > > - test_cleanup();
> > > - }
> > > + /* Disable display to get a default setup. */
> > > + igt_display_commit2(,
> > > data.display.is_atomic ? COMMIT_ATOMIC : COMMIT_LEGACY);
> > > +
> > > + if (!data.with_psr_disabled)
> > > + psr_enable(data.debugfs_fd);
> > >
> > > - igt_subtest("no_drrs") {
> > > setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> > > igt_assert(psr_wait_entry_if_e
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fill out the AVI infoframe quantization range bits using
> drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 1277d31adb54..9c16e273fb8d 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -984,6 +984,8 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>const struct intel_crtc_state
> *pipe_config,
>const struct
> drm_connector_state *conn_state)
> {
> + const struct drm_display_mode *adjusted_mode =
> + _config->base.adjusted_mode;
> uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> union hdmi_infoframe frame;
> int ret;
> @@ -991,20 +993,19 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>
> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> conn_state-
> >connector,
> -_config-
> >base.adjusted_mode);
> +adjusted_mode);
> if (ret < 0) {
> DRM_ERROR("couldn't fill AVI infoframe\n");
> return false;
> }
>
> - if (intel_sdvo->rgb_quant_range_selectable) {
> - if (pipe_config->limited_color_range)
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_LIMITED;
> - else
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_FULL;
> - }
> + drm_hdmi_avi_infoframe_quant_range(,
> +conn_state->connector,
> +adjusted_mode,
> +pipe_config-
> >limited_color_range ?
> +rgb_quant_range_selectableTE
> D :
> +HDMI_QUANTIZATION_RANGE_FULL
> ,
> +intel_sdvo-
> >rgb_quant_range_selectable);
Seems like avi.quantization_range can now get set to _LIMITED or _FULL
even when ->rgb_quant_range_selectable == false, i.e., it is not
_DEFAULT anymore. Is that change in behavior intended?
>
> len = hdmi_infoframe_pack(, sdvo_data,
> sizeof(sdvo_data));
> if (len < 0)
___
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/debugfs: Print PSR selective update status register values
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 42 ++-
> --
> 1 file changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 505d93b31eb6..754b33194e09 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2760,10 +2760,44 @@ static int i915_edp_psr_status(struct
> seq_file *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> - seq_printf(m, "Last attempted entry at: %lld\n",
> -psr->last_entry_attempt);
> - seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> + if (!psr->psr2_enabled) {
> + if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + seq_printf(m, "Last attempted entry at:
> %lld\n",
> +psr->last_entry_attempt);
> + seq_printf(m, "Last exit at: %lld\n", psr-
> >last_exit);
> + }
> + } else {
> + u8 i;
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS);
> + seq_printf(m, "PSR2 SU status: 0x%08x\n", val);
> + for (i = 0; val && i < 3; i++) {
> + u32 num;
> +
> + num = val &
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> + num = num >>
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> + seq_printf(m, "\tSU num blocks in frame N-%u:
> %u\n", i, num);
> + }
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS2);
> + seq_printf(m, "PSR2 SU status2: 0x%08x\n", val);
> + for (i = 0; val && i < 3; i++) {
> + u32 num;
> +
> + num = val &
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> + num = num >>
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> + seq_printf(m, "\tSU num blocks in frame N-%u:
> %u\n", i + 3, num);
> + }
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS3);
> + seq_printf(m, "PSR2 SU status3: 0x%08x\n", val);
> + for (i = 0; val && i < 2; i++) {
> + u32 num;
> +
> + num = val &
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> + num = num >>
> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> + seq_printf(m, "\tSU num blocks in frame N-%u:
> %u\n", i + 6, num);
nitpick: Have you considered reducing the text that's getting printed
here? I guess we might not need to increase the read buffer size in IGT
if we do some thing like this.
Frame SU blocks
0 f
1 o
2 o
I'll leave it to you if you want to change, but I do prefer making this
less verbose.
> + }
> }
>
> unlock:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/psr: Disable DRRS if enabled when enabling PSR from debugfs
On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > If panel supports DRRS and PSR and if driver is loaded without PSR
> > enabled, driver will enable DRRS as expected but if PSR is enabled
> > by
> > debugfs latter it will keep PSR and DRRS enabled causing possible
> > problems as DRRS will lower the refresh rate while PSR enabled.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
> > Cc: Maarten Lankhorst
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 853e3f1370a0..bfc6a08b5cf4 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -904,8 +904,11 @@ int intel_psr_set_debugfs_mode(struct
> > drm_i915_private *dev_priv,
> >
> > intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
> >
> > - if (dev_priv->psr.prepared && enable)
> > + if (dev_priv->psr.prepared && enable) {
> > + if (crtc_state)
> > + intel_edp_drrs_disable(dp, crtc_state);
> > intel_psr_enable_locked(dev_priv, crtc_state);
> > + }
> >
> > mutex_unlock(_priv->psr.lock);
> > return ret;
>
> I've considered this, but I thought it was a feature, not a bug. It's
> a pain to track
> how we handle this as intended.
>
> kms_frontbuffer_tracking is also controlling DRRS during the test, so
> perhaps simply
> fix the test?
>
> It seems the no_drrs test simply checks that if PSR is enabled, we
> don't have drrs
> enabled. We probably care about the default configuration, so I would
> simply disable
> the pipe, update the PSR flag, and then start running the tests. Else
> the only thing
> we test is that debugfs disables DRRS. Not that the default modeset
> path prevents
> PSR and DRRS simultaneously.
>
> ~Maarten
>
> Maybe something like below?
>
> Perhaps move the drrs manipulation functions from
> kms_frontbuffer_tracking to lib/kms_psr.c
>
> 8<---
> diff --git a/tests/kms_psr.c b/tests/kms_psr.c
> index 9767f475bf23..ffc356df06ce 100644
> --- a/tests/kms_psr.c
> +++ b/tests/kms_psr.c
> @@ -414,9 +414,6 @@ int main(int argc, char *argv[])
> kmstest_set_vt_graphics_mode();
> data.devid = intel_get_drm_devid(data.drm_fd);
>
> - if (!data.with_psr_disabled)
> - psr_enable(data.debugfs_fd);
> -
> igt_require_f(sink_support(),
> "Sink does not support PSR\n");
>
> @@ -428,18 +425,25 @@ int main(int argc, char *argv[])
> }
>
> igt_subtest("basic") {
> - setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> - igt_assert(psr_wait_entry_if_enabled());
> - test_cleanup();
> - }
> + /* Disable display to get a default setup. */
> + igt_display_commit2(,
> data.display.is_atomic ? COMMIT_ATOMIC : COMMIT_LEGACY);
> +
> + if (!data.with_psr_disabled)
> + psr_enable(data.debugfs_fd);
>
> - igt_subtest("no_drrs") {
> setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> igt_assert(psr_wait_entry_if_enabled());
> igt_assert(drrs_disabled());
> test_cleanup();
This makes a lot more sense to me, ensuring that DRRS does not get
enabled in the default code path was the goal of the no-drrs test.
-DK
> }
>
> + igt_fixture {
> + drrs_disable();
> +
> + if (!data.with_psr_disabled)
> + psr_enable(data.debugfs_fd);
> + }
> +
> for (op = PAGE_FLIP; op <= RENDER; op++) {
> igt_subtest_f("primary_%s", op_str(op)) {
> data.op = op;
>
___
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: Refactor PSR status debugfs
On Tue, 2018-12-11 at 04:44 -0800, Souza, Jose wrote:
> On Mon, 2018-12-10 at 22:51 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> > > The old debugfs fields was not following a naming partern and it
> > > was
> > > a bit confusing.
> > >
> > > So it went from:
> > > ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> > > Sink_Support: yes
> > > PSR mode: PSR1
> > > Enabled: yes
> > > Busy frontbuffer bits: 0x000
> > > Main link in standby mode: no
> > > HW Enabled & Active bit: yes
> > > Source PSR status: 0x24050006 [SRDONACK]
> > >
> > > To:
> > > ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> > > Sink support: yes [0x0003]
> > > Status: PSR1 enabled
> > > Source PSR ctl: enabled [0x81f00e26]
> > > Source PSR status: SRDENT [0x40040006]
> > > Busy frontbuffer bits: 0x
> > >
> > > The 'Main link in standby mode' was removed as it is not useful
> > > but
> > > if needed by someone the information is still in the register
> > > value
> > > of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled
> > > was
> > > squashed into Status, some renames and reorders and we have this
> > > cleaner version. This will also make easy to parse debugfs for
> > > IGT
> > > tests.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Dhinakaran Pandiyan
> > > Suggested-by: Dhinakaran Pandiyan
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 96 +++--
> > >
> > >
> > > 1 file changed, 49 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 38dcee1ca062..86303ba02666 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2665,7 +2665,8 @@
> > > DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> > > static void
> > > psr_source_status(struct drm_i915_private *dev_priv, struct
> > > seq_file
> > > *m)
> > > {
> > > - u32 val, psr_status;
> > > + u32 val, status_val;
> > > + const char *status = "unknown";
> > >
> > > if (dev_priv->psr.psr2_enabled) {
> > > static const char * const live_status[] = {
> > > @@ -2681,14 +2682,11 @@ psr_source_status(struct drm_i915_private
> > > *dev_priv, struct seq_file *m)
> > > "BUF_ON",
> > > "TG_ON"
> > > };
> > > - psr_status = I915_READ(EDP_PSR2_STATUS);
> > > - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> > > - EDP_PSR2_STATUS_STATE_SHIFT;
> > > - if (val < ARRAY_SIZE(live_status)) {
> > > - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> > > -psr_status, live_status[val]);
> > > - return;
> > > - }
> > > + val = I915_READ(EDP_PSR2_STATUS);
> > > + status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> > > + EDP_PSR2_STATUS_STATE_SHIFT;
> > > + if (status_val < ARRAY_SIZE(live_status))
> > > + status = live_status[status_val];
> > > } else {
> > > static const char * const live_status[] = {
> > > "IDLE",
> > > @@ -2700,74 +2698,78 @@ psr_source_status(struct drm_i915_private
> > > *dev_priv, struct seq_file *m)
> > > "SRDOFFACK",
> > > "SRDENT_ON",
> > > };
> > > - psr_status = I915_READ(EDP_PSR_STATUS);
> > > - val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> > > - EDP_PSR_STATUS_STATE_SHIFT;
> > > - if (val < ARRAY_SIZE(live_status)) {
> > > - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> > > -psr_status, live_status[val]);
> > > - return;
> > > - }
> > > + val = I915_READ(EDP_PSR_STATUS);
> > > + status_val = (val & EDP_PSR_STATUS_
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Add PSR2 selective update status registers and bits definitions
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
> flip
> can show that the expected values are set for the current frame and
> the
> previous ones too.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 0a7d60509ca7..7d634f34ca7d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4248,6 +4248,12 @@ enum {
> #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
>
> +#define EDP_PSR2_SU_STATUS _MMIO(0
> x6f914)
> +#define EDP_PSR2_SU_STATUS2 _MMIO(0
> x6F918)
> +#define EDP_PSR2_SU_STATUS3 _MMIO(0
> x6F91C)
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i) ((i) *
> 10)
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i) (0x3FF
> << ((i) * 10))
How about moving the MMIO selection logic to the macros?
#define PSR2_SU_HISTORY 8
#define _PSR2_SU_STATUS_0 0x6f914
#define _PSR2_SU_STATUS_1 0x6f918
#define _PSR2_SU_STATUS(dword) _MMIO(_PICK_EVEN((dword),\
_PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
#define PSR2_SU_SHIFT(frame) ((frame) % 3) * 10
#define PSR2_SU_MASK(frame) (0x3ff << PSR2_SU_SHIFT(frame))
#define PSR2_SU_BLOCKS(frame) _PSR2_SU_STATUS((frame) / 3)
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
___
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/psr: Do not print last attempted entry or exit in PSR debugfs while in PSR2
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugsfs.
> Also adding a comment to intel_psr_irq_handler() about that.
The code still allows the enabling of interrupt debugging for PSR2. Fix
that to reject debugfs writes?
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/intel_psr.c| 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 86303ba02666..505d93b31eb6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2760,7 +2760,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> seq_printf(m, "Last attempted entry at: %lld\n",
> psr->last_entry_attempt);
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 15a2121aa64f..85349a57689c 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -203,6 +203,7 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir)
> mask |= EDP_PSR_ERROR(shift);
> }
>
> + /* PSR2 don't trigger PRE_ENTRY and POST_EXIT
> interruptions */
> if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
> dev_priv->psr.last_entry_attempt = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR entry
> attempt in 2 vblanks\n",
___
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: Refactor PSR status debugfs
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy frontbuffer bits: 0x000
> Main link in standby mode: no
> HW Enabled & Active bit: yes
> Source PSR status: 0x24050006 [SRDONACK]
>
> To:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x0003]
> Status: PSR1 enabled
> Source PSR ctl: enabled [0x81f00e26]
> Source PSR status: SRDENT [0x40040006]
> Busy frontbuffer bits: 0x
>
> The 'Main link in standby mode' was removed as it is not useful but
> if needed by someone the information is still in the register value
> of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was
> squashed into Status, some renames and reorders and we have this
> cleaner version. This will also make easy to parse debugfs for IGT
> tests.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 96 +++--
>
> 1 file changed, 49 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 38dcee1ca062..86303ba02666 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2665,7 +2665,8 @@ DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> static void
> psr_source_status(struct drm_i915_private *dev_priv, struct seq_file
> *m)
> {
> - u32 val, psr_status;
> + u32 val, status_val;
> + const char *status = "unknown";
>
> if (dev_priv->psr.psr2_enabled) {
> static const char * const live_status[] = {
> @@ -2681,14 +2682,11 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "BUF_ON",
> "TG_ON"
> };
> - psr_status = I915_READ(EDP_PSR2_STATUS);
> - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> - EDP_PSR2_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR2_STATUS);
> + status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> } else {
> static const char * const live_status[] = {
> "IDLE",
> @@ -2700,74 +2698,78 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "SRDOFFACK",
> "SRDENT_ON",
> };
> - psr_status = I915_READ(EDP_PSR_STATUS);
> - val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> - EDP_PSR_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR_STATUS);
> + status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> + EDP_PSR_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> }
>
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n", psr_status,
> "unknown");
> + seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
> }
>
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - u32 psrperf = 0;
> - bool enabled = false;
> - bool sink_support;
> + struct i915_psr *psr = _priv->psr;
> + const char *status;
> + bool enabled;
> + u32 val;
>
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>
> - sink_support = dev_priv->psr.sink_support;
> - seq_printf(m, "Sink_Support: %s\n"
Re: [Intel-gfx] [PATCH 1/5] drm/i915/psr: Allow PSR2 to be enabled when debugfs asks
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be enabled needs to take in consideration
> the debug field.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 4c4dd1c310ce..15a2121aa64f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,8 +71,11 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state
> *crtc_state)
> {
> + const u32 debug_mode = dev_priv->psr.debug &
> I915_PSR_DEBUG_MODE_MASK;
> +
> /* Disable PSR2 by default for all platforms */
> - if (i915_modparams.enable_psr == -1)
> + if (i915_modparams.enable_psr == -1 &&
> + debug_mode != I915_PSR_DEBUG_ENABLE)
> return false;
@@ -71,17 +71,17 @@ static bool psr_global_enabled(u32 debug)
static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
const struct intel_crtc_state
*crtc_state)
{
- /* Disable PSR2 by default for all platforms */
- if (i915_modparams.enable_psr == -1)
- return false;
-
/* Cannot enable DSC and PSR2 simultaneously */
WARN_ON(crtc_state->dsc_params.compression_enable &&
crtc_state->has_psr2);
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
+ case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
+ case I915_PSR_DEBUG_DEFAULT:
+ if (i915_modparams.enable_psr <= 0)
+ return false;
default:
return crtc_state->has_psr2;
}
Does this read any better? Keeping the condition checks together and
also having a consistent priority between debugfs and module parameter
options is easier to follow IMHO.
>
> /* Cannot enable DSC and PSR2 simultaneously */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux
On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> or
> not. Makes it possible to send multiple messages in one go with
> stop+start generated between the messages (as opposed nothing or
> repstart depending on whether thr address/rw changed).
>
> Not sure anyone has actual use for this but figured I'd handle it
> since I started to look at that flag for MST remote i2c xfers.
>
Don't see the I2C_M_STOP flag anywhere in drm_edid.c, but the change
introduced here does make sense.
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 37c01b6076ec..e85cea299d2a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -884,7 +884,8 @@ static void drm_dp_i2c_msg_set_request(struct
> drm_dp_aux_msg *msg,
> {
> msg->request = (i2c_msg->flags & I2C_M_RD) ?
> DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> - msg->request |= DP_AUX_I2C_MOT;
> + if (!(i2c_msg->flags & I2C_M_STOP))
> + msg->request |= DP_AUX_I2C_MOT;
> }
>
> /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, 2018-12-10 at 23:29 +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT
> > bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a type. We're just preserving MOT. What makes you think it
> should always be set?
>
The table defining request commands (2-148) has the MOT bit set for
Write_Status_Update_Request, doesn't make it look like an option when
querying the status. Checking the callers again, I see that we could
get a defer when ending an i2c transaction and that will require a
Write_Status_Update_Request with MOT unset. Sorry for the noise.
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain
> > partial I2C_WRITE requests")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..d98805b517f0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -677,7 +677,7 @@ static void
> > drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
> > * rest of the message
> > */
> > if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> > - msg->request &= DP_AUX_I2C_MOT;
> > + msg->request |= DP_AUX_I2C_MOT;
> > msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> > }
> > }
> > --
> > 2.17.1
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
The Write_Status_Update_Request I2C transaction requires the MOT bit to
be set, Change the logical AND to OR to fix what looks like a typo.
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
I2C_WRITE requests")
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2d6c491a0542..d98805b517f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
drm_dp_aux_msg *msg)
* rest of the message
*/
if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
- msg->request &= DP_AUX_I2C_MOT;
+ msg->request |= DP_AUX_I2C_MOT;
msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
}
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
