From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Jouni Högander" <jouni.hogander@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v3 10/10] drm/i915/psr: Allow DSB usage when PSR is enabled
Date: Fri, 17 Jan 2025 22:20:17 +0200 [thread overview]
Message-ID: <Z4q7ge2MMHAmDvNJ@intel.com> (raw)
In-Reply-To: <20250109073137.1977494-11-jouni.hogander@intel.com>
On Thu, Jan 09, 2025 at 09:31:37AM +0200, Jouni Högander wrote:
> Now as we have correct PSR2_MAN_TRK_CTL handling in place we can allow DSB
> usage also when PSR is enabled for LunarLake onwards.
We seem to still lack an answer as to when the PSR wakes, when it
latches the update, and how does all that guarantee that the DSB
interrupt fires after the update has been latched?
Some thoughts as to how to figure this out:
1. make sure we're in PSR
2. sample TIMESTAMP_CTR
3. start DSB in which
write PLANE_SURF with a new value
send push
wait for vblank
poll PLANE_SURFLIVE == new value
fire interrupt
in the interrupt handler:
sample TIMESTAMP_CTR again
And then compare flip timestmap vs. frame timestamp vs. the
manually sampled timestamps. And then repeat without the SURFLIVE
poll to make sure nothing has changed. You'll need to be careful
to make sure it will actually poll for long enough to make a real
difference (if the poll actuall is needed), but tweaking the poll
interval+count suitably. I don't remeber what the max poll
count was, but IIRC it wasn't too high so the duration will have
to get bumped for long polls.
I guess one could also try to poll for the actual PSR status,
but dunno how well that'll work.
And we could also try to come up with different ideas on where
to sample timestamps. Unfortunately we only have the single
pipe flip timestamp register so we can only sample one timestamp
from the DSB itself per frame. If we had more we could much more
easily figure things out :/
I pushed my latest DSB selftest stuff to
https://github.com/vsyrjala/linux.git dsb_selftests_7
which has a bunch of stuff for this kind of experimentation.
It's in a somewhat sorry state at the moment since I last used
to hunt for various DSB bugs, but at least it still builds :)
The way I use that is that I run igt 'testdisplay -o ...'
to make sure nothing else is actively poking the hardware
and then I trigger the DSB tests via debugfs.
>
> Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index e448ff64660a..58575800fad2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7631,6 +7631,7 @@ static void intel_atomic_dsb_finish(struct intel_atomic_state *state,
> intel_atomic_get_old_crtc_state(state, crtc);
> struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> + struct intel_display *display = to_intel_display(crtc);
>
> if (!new_crtc_state->hw.active)
> return;
> @@ -7643,7 +7644,7 @@ static void intel_atomic_dsb_finish(struct intel_atomic_state *state,
> new_crtc_state->update_planes &&
> !new_crtc_state->vrr.enable &&
> !new_crtc_state->do_async_flip &&
> - !new_crtc_state->has_psr &&
> + (DISPLAY_VER(display) >= 20 || !new_crtc_state->has_psr) &&
> !new_crtc_state->scaler_state.scaler_users &&
> !old_crtc_state->scaler_state.scaler_users &&
> !intel_crtc_needs_modeset(new_crtc_state) &&
> --
> 2.43.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-01-17 20:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 7:31 [PATCH v3 00/10] PSR DSB support Jouni Högander
2025-01-09 7:31 ` [PATCH v3 01/10] drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update Jouni Högander
2025-01-15 7:43 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 02/10] drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_update Jouni Högander
2025-01-15 7:46 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 03/10] drm/i915/psr: Split setting sff and cff bits away from intel_psr_force_update Jouni Högander
2025-01-15 7:58 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 04/10] drm/i915/psr: Add register definitions for SFF_CTL and CFF_CTL registers Jouni Högander
2025-01-15 8:32 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 05/10] drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwards Jouni Högander
2025-01-15 8:18 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 06/10] drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSB Jouni Högander
2025-01-16 6:03 ` Manna, Animesh
2025-01-17 19:22 ` Ville Syrjälä
2025-01-20 6:47 ` Hogander, Jouni
2025-01-09 7:31 ` [PATCH v3 07/10] drm/i915/psr: Changes for PSR2_MAN_TRK_CTL handling when DSB is in use Jouni Högander
2025-01-16 6:10 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 08/10] drm/i915/psr: Add intel_psr_is_psr_mode_changing Jouni Högander
2025-01-16 7:15 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 09/10] drm/i915/display: Don't use DSB if psr mode changing Jouni Högander
2025-01-16 7:19 ` Manna, Animesh
2025-01-09 7:31 ` [PATCH v3 10/10] drm/i915/psr: Allow DSB usage when PSR is enabled Jouni Högander
2025-01-16 7:27 ` Manna, Animesh
2025-01-17 20:20 ` Ville Syrjälä [this message]
2025-01-17 23:07 ` Ville Syrjälä
2025-01-20 7:28 ` Hogander, Jouni
2025-01-20 14:39 ` Ville Syrjälä
2025-01-20 15:27 ` Ville Syrjälä
2025-01-21 10:29 ` Hogander, Jouni
2025-01-21 13:57 ` Ville Syrjälä
2025-01-21 15:11 ` Ville Syrjälä
2025-01-22 5:53 ` Hogander, Jouni
2025-01-09 7:46 ` ✓ CI.Patch_applied: success for PSR DSB support (rev3) Patchwork
2025-01-09 7:46 ` ✓ CI.checkpatch: " Patchwork
2025-01-09 7:47 ` ✓ CI.KUnit: " Patchwork
2025-01-09 8:05 ` ✓ CI.Build: " Patchwork
2025-01-09 8:07 ` ✓ CI.Hooks: " Patchwork
2025-01-09 8:09 ` ✗ CI.checksparse: warning " Patchwork
2025-01-09 8:38 ` ✓ Xe.CI.BAT: success " Patchwork
2025-01-11 11:27 ` ✗ Xe.CI.Full: failure " 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=Z4q7ge2MMHAmDvNJ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jouni.hogander@intel.com \
/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