From: Jani Nikula <jani.nikula@linux.intel.com>
To: Animesh Manna <animesh.manna@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: jouni.hogander@intel.com, Animesh Manna <animesh.manna@intel.com>
Subject: Re: [PATCH] drm/i915/alpm: Introduce has_alpm to simplify alpm check in enable/disable
Date: Mon, 28 Apr 2025 14:38:29 +0300 [thread overview]
Message-ID: <877c34y0qy.fsf@intel.com> (raw)
In-Reply-To: <20250428095838.3154962-1-animesh.manna@intel.com>
On Mon, 28 Apr 2025, Animesh Manna <animesh.manna@intel.com> wrote:
> Simplify alpm check in enable/disable with has_alpm.
> Add a check for alpm during lobf disable which can be enabled
> with panel replay/psr2.
>
> Suggested-by: Jouni Högander <jouni.hogander@intel.com>
> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_alpm.c | 23 +++++++++++++------
> .../drm/i915/display/intel_display_types.h | 3 +++
> drivers/gpu/drm/i915/display/intel_psr.c | 2 ++
> 3 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
> index 1bf08b80c23f..aa3f442bf8bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -322,6 +322,8 @@ void intel_alpm_lobf_compute_config(struct intel_dp *intel_dp,
>
> crtc_state->has_lobf = (context_latency + guardband) >
> (first_sdp_position + waketime_in_lines);
> +
> + crtc_state->has_alpm |= crtc_state->has_lobf;
I'm averse to using bitwise operators on logical booleans.
> }
>
> static void lnl_alpm_configure(struct intel_dp *intel_dp,
> @@ -332,8 +334,7 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp,
> enum port port = dp_to_dig_port(intel_dp)->base.port;
> u32 alpm_ctl;
>
> - if (DISPLAY_VER(display) < 20 || (!intel_psr_needs_alpm(intel_dp, crtc_state) &&
> - !crtc_state->has_lobf))
> + if (DISPLAY_VER(display) < 20 || !crtc_state->has_alpm)
> return;
>
> mutex_lock(&intel_dp->alpm_parameters.lock);
> @@ -417,12 +418,20 @@ void intel_alpm_pre_plane_update(struct intel_atomic_state *state,
> if (!intel_dp_is_edp(intel_dp))
> continue;
>
> - if (old_crtc_state->has_lobf) {
> - mutex_lock(&intel_dp->alpm_parameters.lock);
> + mutex_lock(&intel_dp->alpm_parameters.lock);
> + if (crtc_state->has_alpm) {
> + u32 alpm_ctl = intel_de_read(display, ALPM_CTL(display, cpu_transcoder));
> + if (alpm_ctl & ALPM_CTL_LOBF_ENABLE) {
> + alpm_ctl &= ~ALPM_CTL_LOBF_ENABLE;
> + intel_de_write(display, ALPM_CTL(display, cpu_transcoder), alpm_ctl);
> + drm_dbg_kms(display->drm, "Link off between frames (LOBF) disabled\n");
> + }
> + } else {
> intel_de_write(display, ALPM_CTL(display, cpu_transcoder), 0);
> - drm_dbg_kms(display->drm, "Link off between frames (LOBF) disabled\n");
> - mutex_unlock(&intel_dp->alpm_parameters.lock);
> + drm_dbg_kms(display->drm,
> + "Link off between frames (LOBF) with ALPM disabled\n");
> }
> + mutex_unlock(&intel_dp->alpm_parameters.lock);
> }
> }
>
> @@ -431,7 +440,7 @@ static void intel_alpm_enable_sink(struct intel_dp *intel_dp,
> {
> u8 val;
>
> - if (!intel_psr_needs_alpm(intel_dp, crtc_state) && !crtc_state->has_lobf)
> + if (!crtc_state->has_alpm)
> return;
>
> val = DP_ALPM_ENABLE | DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 7415564d058a..6edcfa5d9c41 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1328,6 +1328,9 @@ struct intel_crtc_state {
>
> /* LOBF flag */
> bool has_lobf;
> +
> + /* ALPM flag */
What benefit does this or the above "LOBF flag" comment give?
If you don't know what "has_lobf" or "has_alpm" mean, how on earth would
adding the word "flag" help here?
> + bool has_alpm;
> };
>
> enum intel_pipe_crc_source {
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
> index ccd66bbc72f7..e643f36057f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1707,6 +1707,8 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>
> crtc_state->has_sel_update = intel_sel_update_config_valid(intel_dp, crtc_state);
>
> + crtc_state->has_alpm = intel_psr_needs_alpm(intel_dp, crtc_state);
Looks like the below thing can disable PSR usage, but you'll still leave
has_sel_update and (with this patch) has_alpm enabled. Are you taking
all those combos into account? Including in readout?
BR,
Jani.
> +
> /* Wa_18037818876 */
> if (intel_psr_needs_wa_18037818876(intel_dp, crtc_state)) {
> crtc_state->has_psr = false;
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-04-28 11:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 9:58 [PATCH] drm/i915/alpm: Introduce has_alpm to simplify alpm check in enable/disable Animesh Manna
2025-04-28 10:50 ` Hogander, Jouni
2025-04-28 11:29 ` ✓ CI.Patch_applied: success for " Patchwork
2025-04-28 11:29 ` ✗ CI.checkpatch: warning " Patchwork
2025-04-28 11:30 ` ✓ CI.KUnit: success " Patchwork
2025-04-28 11:38 ` Jani Nikula [this message]
2025-04-28 11:38 ` ✓ CI.Build: " Patchwork
2025-04-28 11:41 ` ✓ CI.Hooks: " Patchwork
2025-04-28 11:42 ` ✓ CI.checksparse: " Patchwork
2025-04-28 12:05 ` ✓ Xe.CI.BAT: " Patchwork
2025-04-28 13: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=877c34y0qy.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=animesh.manna@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