From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: Drew Davenport <ddavenport@chromium.org>,
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/psr: Define more PSR mask bits
Date: Mon, 20 Mar 2023 14:23:51 +0200 [thread overview]
Message-ID: <ZBhQV4jUAD1UbvMn@intel.com> (raw)
In-Reply-To: <ZBhJyClkzHgf2xjJ@ideak-desk.fi.intel.com>
On Mon, Mar 20, 2023 at 02:05:46PM +0200, Imre Deak wrote:
> On Mon, Mar 20, 2023 at 11:54:38AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Define more of the PSR mask bits. Even if we don't set them
> > from the driver they can be very useful during PSR debugging.
> > Having to trawl through bspec every time to find them is
> > not fun.
> >
> > The particularly interesting bits are:
> >
> > - PIPE_MISC[21]/PIPE_MISC_PSR_MASK_PIPE_REG_WRITE
> >
> > Normally most, if not all, pipe/plane registers (even the
> > noarm ones) trigger a PSR exit. This stops that, leaving
> > only PLANE_SURF (or so it seems) to do the triggering
> >
> > - CHICKEN_TRANS[30]/NO_VBLANK_MASK_IN_DEEP_PSR
> >
> > Stops PSR exit from generating an extra vblank before the
> > first frame is transmitted.
> >
> > Looks like with DC states enabled the extra vblank happens
> > after link traning, with DC states disabled it seems to happen
> > immediately. No idea as of now why there is a difference.
> >
> > Unfortunately CHICKEN_TRANS itself seems to be double buffered
> > and thus won't latch until the first vblank. So with DC states
> > enabled the register effctively uses the reset value during DC5
> > exit+PSR exit sequence, and thus the bit does nothing until
> > latched by the vblank that it was trying to prevent from being
> > generated in the first place. So we should probably call this one
> > a chicken/egg bit instead.
> >
> > TODO: should confirm what this does when using PSR standby
> > mode instead of deep/link-off mode...
> >
> > Cc: Manasi Navare <navaremanasi@google.com>
> > Cc: Drew Davenport <ddavenport@chromium.org>
> > Cc: Imre Deak <imre.deak@intel.com>
> > Cc: Jouni Högander <jouni.hogander@intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index d22ffd7a32dc..383c532320f9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2205,6 +2205,7 @@
> > #define EDP_PSR_DEBUG_MASK_LPSP (1 << 27)
> > #define EDP_PSR_DEBUG_MASK_MEMUP (1 << 26)
> > #define EDP_PSR_DEBUG_MASK_HPD (1 << 25)
> > +#define EDP_PSR_DEBUG_MASK_FBC_MODIFY (1 << 24)
> > #define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE (1 << 16) /* Reserved in ICL+ */
> > #define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1 << 15) /* SKL+ */
> >
> > @@ -3500,8 +3501,13 @@
> > #define PIPE_MISC_YUV420_ENABLE REG_BIT(27) /* glk+ */
> > #define PIPE_MISC_YUV420_MODE_FULL_BLEND REG_BIT(26) /* glk+ */
> > #define PIPE_MISC_HDR_MODE_PRECISION REG_BIT(23) /* icl+ */
>
> 'Allow Double Buffer Update Disable' BIT(24) on tgl+ looks also related
> to these flags.
Not directly. It controls whether DOUBLE_BUFFER_CTL will disable
the double buffer latching at vblank for a given hw unit (PSR or
no PSR). Most hw units have their own 'Allow Double Buffer Update
Disable' bit in one of their registers. If and then we start to
use DOUBLE_BUFFER_CTL we have to track down all those bits and
set them.
>
> The patchset looks ok to me:
> Reviewed-by: Imre Deak <imre.deak@intel.com>
Thanks.
>
> > +#define PIPE_MISC_PSR_MASK_PRIMARY_FLIP REG_BIT(23) /* bdw only */
> > +#define PIPE_MISC_PSR_MASK_SPRITE_ENABLE REG_BIT(22) /* bdw only */
> > +#define PIPE_MISC_PSR_MASK_PIPE_REG_WRITE REG_BIT(21) /* skl+ */
> > +#define PIPE_MISC_PSR_MASK_CURSOR_MOVE REG_BIT(21) /* bdw only */
> > +#define PIPE_MISC_PSR_MASK_VBLANK_VSYNC_INT REG_BIT(20)
> > #define PIPE_MISC_OUTPUT_COLORSPACE_YUV REG_BIT(11)
> > -#define PIPE_MISC_PIXEL_ROUNDING_TRUNC REG_BIT(8) /* tgl+ */
> > +#define PIPE_MISC_PIXEL_ROUNDING_TRUNC REG_BIT(8) /* tgl+ */
> > /*
> > * For Display < 13, Bits 5-7 of PIPE MISC represent DITHER BPC with
> > * valid values of: 6, 8, 10 BPC.
> > @@ -5550,7 +5556,7 @@
> > #define MTL_CHICKEN_TRANS(trans) _MMIO_TRANS((trans), \
> > _MTL_CHICKEN_TRANS_A, \
> > _MTL_CHICKEN_TRANS_B)
> > -
> > +#define NO_VBLANK_MASK_IN_DEEP_PSR REG_BIT(30) /* skl+ */
> > #define HSW_FRAME_START_DELAY_MASK REG_GENMASK(28, 27)
> > #define HSW_FRAME_START_DELAY(x) REG_FIELD_PREP(HSW_FRAME_START_DELAY_MASK, x)
> > #define VSC_DATA_SEL_SOFTWARE_CONTROL REG_BIT(25) /* GLK */
> > --
> > 2.39.2
> >
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-03-20 12:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 9:54 [Intel-gfx] [PATCH 0/6] drm/i915: Fix various issues with noarm register writes Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 1/6] drm/i915: Split icl_color_commit_noarm() from skl_color_commit_noarm() Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 2/6] drm/i915: Move CSC load back into .color_commit_arm() when PSR is enabled on skl/glk Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 3/6] drm/i915: Add a .color_post_update() hook Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 4/6] drm/i915: Workaround ICL CSC_MODE sticky arming Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 5/6] drm/i915: Disable DC states for all commits Ville Syrjala
2023-03-20 11:51 ` Imre Deak
2023-03-20 18:24 ` Ville Syrjälä
2023-03-20 18:35 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2023-03-20 9:54 ` [Intel-gfx] [PATCH 6/6] drm/i915/psr: Define more PSR mask bits Ville Syrjala
2023-03-20 12:05 ` Imre Deak
2023-03-20 12:23 ` Ville Syrjälä [this message]
2023-03-21 20:45 ` Ville Syrjälä
2023-03-20 18:01 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Fix various issues with noarm register writes Patchwork
2023-03-20 18:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: " Patchwork
2023-03-20 18:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-20 18:02 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2023-03-20 18:23 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-03-21 6:07 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Fix various issues with noarm register writes (rev2) Patchwork
2023-03-21 6:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: " Patchwork
2023-03-21 6:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-21 6:33 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-21 9:59 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZBhQV4jUAD1UbvMn@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ddavenport@chromium.org \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).