From: "Kazlauskas, Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org>
To: "Li, Sun peng (Leo)" <Sunpeng.Li-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Wentland, Harry" <Harry.Wentland-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 1/2] drm/amd/display: Send vblank and user events at vsartup for DCN
Date: Tue, 5 Nov 2019 16:15:02 +0000 [thread overview]
Message-ID: <c93c503d-48dc-1ea5-19f7-42ff9392e162@amd.com> (raw)
In-Reply-To: <20191105153416.32049-1-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
On 2019-11-05 10:34 a.m., sunpeng.li@amd.com wrote:
> From: Leo Li <sunpeng.li@amd.com>
>
> [Why]
>
> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
> interrupt. This is different from DCE, which has it assigned to vblank
> start.
>
> We'd like to send vblank and user events at vstartup because:
>
> * It happens close enough to vupdate - the point of no return for HW.
>
> * It is programmed as lines relative to vblank end - i.e. it is not in
> the variable portion when VRR is enabled. We should signal user
> events here.
>
> * The pflip interrupt responsible for sending user events today only
> fires if the DCH HUBP component is not clock gated. In situations
> where planes are disabled - but the CRTC is enabled - user events won't
> be sent out, leading to flip done timeouts.
>
> Consequently, this makes vupdate on DCN hardware redundant. It will be
> removed in the next change.
>
> [How]
>
> Add a DCN-specific crtc_high_irq handler, and hook it to the VStartup
> signal. Inside the DCN handler, we send off user events if the pflip
> handler hasn't already done so.
>
> Signed-off-by: Leo Li <sunpeng.li@amd.com>
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++++++++++++++++++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> 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 00017b91c91a..256a23a0ec28 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -485,6 +485,69 @@ static void dm_crtc_high_irq(void *interrupt_params)
> }
> }
>
> +
> +/**
> + * dm_dcn_crtc_high_irq() - Handles VStartup interrupt for DCN generation ASICs
> + * @interrupt params - interrupt parameters
> + *
> + * Notify DRM's vblank event handler at VSTARTUP
> + *
> + * Unlike DCE hardware, we trigger the handler at VSTARTUP. at which:
> + * * We are close enough to VUPDATE - the point of no return for hw
> + * * We are in the fixed portion of variable front porch when vrr is enabled
> + * * We are before VUPDATE, where double-buffered vrr registers are swapped
> + *
> + * It is therefore the correct place to signal vblank, send user flip events,
> + * and update VRR.
> + */
> +static void dm_dcn_crtc_high_irq(void *interrupt_params)
> +{
> + struct common_irq_params *irq_params = interrupt_params;
> + struct amdgpu_device *adev = irq_params->adev;
> + struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
> +
> + acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - IRQ_TYPE_VBLANK);
> +
> + if (!acrtc)
> + return;
> +
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
> +
> + amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
> + drm_crtc_handle_vblank(&acrtc->base);
Shouldn't this be the other way around? Don't we want the CRC sent back
to userspace to have the updated vblank counter?
This is how it worked before at least.
Other than that, this patch looks fine to me.
Nicholas Kazlauskas
> +
> + spin_lock_irqsave(&adev->ddev->event_lock, flags);
> +
> + if (acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE) {
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params.adjust);
> + }
> +
> + if (acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED) {
> + if (acrtc->event) {
> + drm_crtc_send_vblank_event(&acrtc->base, acrtc->event);
> + acrtc->event = NULL;
> + drm_crtc_vblank_put(&acrtc->base);
> + }
> + acrtc->pflip_status = AMDGPU_FLIP_NONE;
> + }
> +
> + spin_unlock_irqrestore(&adev->ddev->event_lock, flags);
> +}
> +
> static int dm_set_clockgating_state(void *handle,
> enum amd_clockgating_state state)
> {
> @@ -2175,7 +2238,7 @@ static int dcn10_register_irq_handlers(struct amdgpu_device *adev)
> c_irq_params->irq_src = int_params.irq_source;
>
> amdgpu_dm_irq_register_interrupt(adev, &int_params,
> - dm_crtc_high_irq, c_irq_params);
> + dm_dcn_crtc_high_irq, c_irq_params);
> }
>
> /* Use VUPDATE_NO_LOCK interrupt on DCN, which seems to correspond to
> --
> 2.23.0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>
To: "Li, Sun peng (Leo)" <Sunpeng.Li@amd.com>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "mario.kleiner.de@gmail.com" <mario.kleiner.de@gmail.com>,
"Wentland, Harry" <Harry.Wentland@amd.com>
Subject: Re: [PATCH 1/2] drm/amd/display: Send vblank and user events at vsartup for DCN
Date: Tue, 5 Nov 2019 16:15:02 +0000 [thread overview]
Message-ID: <c93c503d-48dc-1ea5-19f7-42ff9392e162@amd.com> (raw)
Message-ID: <20191105161502.bYQfvabvRDXKmu0IdCZ1AMoP6863RUNd3b5Jsqn0bcU@z> (raw)
In-Reply-To: <20191105153416.32049-1-sunpeng.li@amd.com>
On 2019-11-05 10:34 a.m., sunpeng.li@amd.com wrote:
> From: Leo Li <sunpeng.li@amd.com>
>
> [Why]
>
> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
> interrupt. This is different from DCE, which has it assigned to vblank
> start.
>
> We'd like to send vblank and user events at vstartup because:
>
> * It happens close enough to vupdate - the point of no return for HW.
>
> * It is programmed as lines relative to vblank end - i.e. it is not in
> the variable portion when VRR is enabled. We should signal user
> events here.
>
> * The pflip interrupt responsible for sending user events today only
> fires if the DCH HUBP component is not clock gated. In situations
> where planes are disabled - but the CRTC is enabled - user events won't
> be sent out, leading to flip done timeouts.
>
> Consequently, this makes vupdate on DCN hardware redundant. It will be
> removed in the next change.
>
> [How]
>
> Add a DCN-specific crtc_high_irq handler, and hook it to the VStartup
> signal. Inside the DCN handler, we send off user events if the pflip
> handler hasn't already done so.
>
> Signed-off-by: Leo Li <sunpeng.li@amd.com>
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++++++++++++++++++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> 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 00017b91c91a..256a23a0ec28 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -485,6 +485,69 @@ static void dm_crtc_high_irq(void *interrupt_params)
> }
> }
>
> +
> +/**
> + * dm_dcn_crtc_high_irq() - Handles VStartup interrupt for DCN generation ASICs
> + * @interrupt params - interrupt parameters
> + *
> + * Notify DRM's vblank event handler at VSTARTUP
> + *
> + * Unlike DCE hardware, we trigger the handler at VSTARTUP. at which:
> + * * We are close enough to VUPDATE - the point of no return for hw
> + * * We are in the fixed portion of variable front porch when vrr is enabled
> + * * We are before VUPDATE, where double-buffered vrr registers are swapped
> + *
> + * It is therefore the correct place to signal vblank, send user flip events,
> + * and update VRR.
> + */
> +static void dm_dcn_crtc_high_irq(void *interrupt_params)
> +{
> + struct common_irq_params *irq_params = interrupt_params;
> + struct amdgpu_device *adev = irq_params->adev;
> + struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
> +
> + acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - IRQ_TYPE_VBLANK);
> +
> + if (!acrtc)
> + return;
> +
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
> +
> + amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
> + drm_crtc_handle_vblank(&acrtc->base);
Shouldn't this be the other way around? Don't we want the CRC sent back
to userspace to have the updated vblank counter?
This is how it worked before at least.
Other than that, this patch looks fine to me.
Nicholas Kazlauskas
> +
> + spin_lock_irqsave(&adev->ddev->event_lock, flags);
> +
> + if (acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE) {
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params.adjust);
> + }
> +
> + if (acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED) {
> + if (acrtc->event) {
> + drm_crtc_send_vblank_event(&acrtc->base, acrtc->event);
> + acrtc->event = NULL;
> + drm_crtc_vblank_put(&acrtc->base);
> + }
> + acrtc->pflip_status = AMDGPU_FLIP_NONE;
> + }
> +
> + spin_unlock_irqrestore(&adev->ddev->event_lock, flags);
> +}
> +
> static int dm_set_clockgating_state(void *handle,
> enum amd_clockgating_state state)
> {
> @@ -2175,7 +2238,7 @@ static int dcn10_register_irq_handlers(struct amdgpu_device *adev)
> c_irq_params->irq_src = int_params.irq_source;
>
> amdgpu_dm_irq_register_interrupt(adev, &int_params,
> - dm_crtc_high_irq, c_irq_params);
> + dm_dcn_crtc_high_irq, c_irq_params);
> }
>
> /* Use VUPDATE_NO_LOCK interrupt on DCN, which seems to correspond to
> --
> 2.23.0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-11-05 16:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 15:34 [PATCH 1/2] drm/amd/display: Send vblank and user events at vsartup for DCN sunpeng.li-5C7GfCeVMHo
2019-11-05 15:34 ` sunpeng.li
[not found] ` <20191105153416.32049-1-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2019-11-05 15:34 ` [PATCH 2/2] drm/amd/display: Disable VUpdate interrupt for DCN hardware sunpeng.li-5C7GfCeVMHo
2019-11-05 15:34 ` sunpeng.li
[not found] ` <20191105153416.32049-2-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2019-11-05 15:58 ` [PATCH 2/2 v2] " sunpeng.li-5C7GfCeVMHo
2019-11-05 15:58 ` sunpeng.li
[not found] ` <20191105155802.1302-1-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2019-11-05 16:16 ` Kazlauskas, Nicholas
2019-11-05 16:16 ` Kazlauskas, Nicholas
[not found] ` <47f9dd1b-66c1-a521-d6c8-b9422616cf2e-5C7GfCeVMHo@public.gmane.org>
2019-11-05 18:54 ` Li, Sun peng (Leo)
2019-11-05 18:54 ` Li, Sun peng (Leo)
2019-11-05 19:01 ` [PATCH v3] " sunpeng.li-5C7GfCeVMHo
2019-11-05 19:01 ` sunpeng.li
[not found] ` <20191105190147.7283-1-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2019-11-05 19:04 ` Li, Sun peng (Leo)
2019-11-05 19:04 ` Li, Sun peng (Leo)
2019-11-05 19:07 ` [PATCH v4] " sunpeng.li-5C7GfCeVMHo
2019-11-05 19:07 ` sunpeng.li
[not found] ` <20191105190709.7816-1-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2019-11-05 20:21 ` Kazlauskas, Nicholas
2019-11-05 20:21 ` Kazlauskas, Nicholas
2019-11-05 16:15 ` Kazlauskas, Nicholas [this message]
2019-11-05 16:15 ` [PATCH 1/2] drm/amd/display: Send vblank and user events at vsartup for DCN Kazlauskas, Nicholas
[not found] ` <c93c503d-48dc-1ea5-19f7-42ff9392e162-5C7GfCeVMHo@public.gmane.org>
2019-11-05 18:32 ` Li, Sun peng (Leo)
2019-11-05 18:32 ` Li, Sun peng (Leo)
[not found] ` <ed7b7f5e-4a53-f3e1-912f-e0ae5181288c-5C7GfCeVMHo@public.gmane.org>
2019-11-05 20:21 ` Kazlauskas, Nicholas
2019-11-05 20:21 ` Kazlauskas, Nicholas
2019-11-29 19:20 ` Mario Kleiner
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=c93c503d-48dc-1ea5-19f7-42ff9392e162@amd.com \
--to=nicholas.kazlauskas-5c7gfcevmho@public.gmane.org \
--cc=Harry.Wentland-5C7GfCeVMHo@public.gmane.org \
--cc=Sunpeng.Li-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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