From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Hamza Mahfooz <hamza.mahfooz@amd.com>
Cc: dri-devel@lists.freedesktop.org,
"Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <rodrigo.siqueira@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Alex Hung" <alex.hung@amd.com>, "Wayne Lin" <wayne.lin@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()
Date: Tue, 9 Jul 2024 12:09:12 +0200 [thread overview]
Message-ID: <Zo0MSB7eSp1H0iPI@phenom.ffwll.local> (raw)
In-Reply-To: <Zo0Dm_XeF3dMqK1C@phenom.ffwll.local>
On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> > enable PSR more quickly for displays that support it.
> >
> > Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++++++++++++++-----
> > 1 file changed, 22 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index fdbc9b57a23d..ee6c31e9d3c4 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
> >
> > static void manage_dm_interrupts(struct amdgpu_device *adev,
> > struct amdgpu_crtc *acrtc,
> > - bool enable)
> > + struct dm_crtc_state *acrtc_state)
> > {
> > /*
> > * We have no guarantee that the frontend index maps to the same
> > @@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct amdgpu_device *adev,
> > *
> > * TODO: Use a different interrupt or check DC itself for the mapping.
> > */
> > - int irq_type =
> > - amdgpu_display_crtc_idx_to_irq_type(
> > - adev,
> > - acrtc->crtc_id);
> > + int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
> > + acrtc->crtc_id);
> > + struct dc_crtc_timing *timing;
> > + int offdelay;
> > +
> > + if (acrtc_state) {
> > + timing = &acrtc_state->stream->timing;
> > +
> > + /* at least 2 frames */
> > + offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
> > + (uint64_t)100),
> > + timing->v_total),
> > + timing->h_total) + 1;
>
> Yeah, _especially_ when you have a this short timeout your really have to
> instead fix the vblank driver code properly so you can enable
> vblank_disable_immediate. This is just cheating :-)
Michel mentioned on irc that DC had immediate vblank disabling, but this
was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
vblank_disable_immediate for DC"").
I haven't looked at the details of the bug report, but stuttering is
exactly what happens when the driver's vblank code has these races. Going
for a very low timeout instead of zero just means it's a bit harder to hit
the issue, and much, much harder to debug properly.
So yeah even more reasons to look at the underlying root-cause here I
think.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-07-09 10:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 20:29 [PATCH 1/2] drm/vblank: allow dynamic per-crtc vblank off delay Hamza Mahfooz
2024-07-08 20:29 ` [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay() Hamza Mahfooz
2024-07-09 9:32 ` Daniel Vetter
2024-07-09 10:09 ` Daniel Vetter [this message]
2024-07-09 14:02 ` Hamza Mahfooz
2024-07-10 8:43 ` Daniel Vetter
2024-07-10 21:13 ` Hamza Mahfooz
2024-07-15 8:40 ` Daniel Vetter
2024-07-09 9:30 ` [PATCH 1/2] drm/vblank: allow dynamic per-crtc vblank off delay Daniel Vetter
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=Zo0MSB7eSp1H0iPI@phenom.ffwll.local \
--to=daniel.vetter@ffwll.ch \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamza.mahfooz@amd.com \
--cc=harry.wentland@amd.com \
--cc=mario.limonciello@amd.com \
--cc=mripard@kernel.org \
--cc=rodrigo.siqueira@amd.com \
--cc=sunpeng.li@amd.com \
--cc=tzimmermann@suse.de \
--cc=wayne.lin@amd.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