All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Imre Deak <imre.deak@intel.com>,
	Dibin Moolakadan Subrahmanian
	<dibin.moolakadan.subrahmanian@intel.com>,
	<intel-gfx@lists.freedesktop.org>,
	 <intel-xe@lists.freedesktop.org>, <ankit.k.nautiyal@intel.com>,
	<uma.shankar@intel.com>
Subject: Re: [PATCH v2] drm/xe/display: Block hpd during suspend
Date: Tue, 29 Jul 2025 10:35:48 -0400	[thread overview]
Message-ID: <aIjcRFU90s6Ml9Vt@intel.com> (raw)
In-Reply-To: <1c1510bdb0b9ade97da615f81d91e8f7cde20275@intel.com>

On Tue, Jul 29, 2025 at 12:44:47PM +0300, Jani Nikula wrote:
> On Thu, 24 Jul 2025, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> > Hey,
> >
> > Den 2025-07-23 kl. 15:19, skrev Rodrigo Vivi:
> >> On Wed, Jul 23, 2025 at 12:38:08PM +0300, Imre Deak wrote:
> >>> On Wed, Jul 23, 2025 at 02:59:46PM +0530, Dibin Moolakadan Subrahmanian wrote:
> >>>> It has been observed that during `xe_display_pm_suspend()` execution,
> >>>> an HPD interrupt can still be triggered, resulting in `dig_port_work`
> >>>> being scheduled. The issue arises when this work executes after
> >>>> `xe_display_pm_suspend_late()`, by which time the display is fully
> >>>> suspended.
> >>>>
> >>>> This can lead to errors such as "DC state mismatch", as the dig_port
> >>>> work accesses display resources that are no longer available or
> >>>> powered.
> >>>>
> >>>> To address this, introduce  'intel_encoder_block_all_hpds' and
> >>>> 'intel_encoder_unblock_all_hpds' functions, which iterate over all
> >>>> encoders and block/unblock HPD respectively.
> >>>>
> >>>> These are used to:
> >>>> - Block HPD IRQs before calling 'intel_hpd_cancel_work' in suspend
> >>>>   and shutdown
> >>>> - Unblock HPD IRQs after 'intel_hpd_init' in resume
> >>>>
> >>>> This will prevent 'dig_port_work' being scheduled during display
> >>>> suspend.
> >>>>
> >>>> Continuation of previous patch discussion:
> >>>> https://patchwork.freedesktop.org/patch/663964/
> >>>>
> >>>> Changes in v2:
> >>>>  - Add 'intel_encoder_block_all_hpds' to 'xe_display_pm_shutdown'
> >>>>  - Add 'intel_hpd_cancel_work' to 'xe_display_fini_early' to cancel
> >>>>    any HPD pending work at late driver removal
> >>>>
> >>>> Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
> >>>> ---
> >>>>  drivers/gpu/drm/i915/display/intel_encoder.c | 23 ++++++++++++++++++++
> >>>>  drivers/gpu/drm/i915/display/intel_encoder.h |  3 +++
> >>>>  drivers/gpu/drm/i915/display/intel_hotplug.c |  2 --
> >>>>  drivers/gpu/drm/xe/display/xe_display.c      |  6 +++++
> >>>>  4 files changed, 32 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_encoder.c b/drivers/gpu/drm/i915/display/intel_encoder.c
> >>>> index 0b7bd26f4339..4e2b77b87678 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_encoder.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_encoder.c
> >>>> @@ -8,6 +8,7 @@
> >>>>  #include "intel_display_core.h"
> >>>>  #include "intel_display_types.h"
> >>>>  #include "intel_encoder.h"
> >>>> +#include "intel_hotplug.h"
> >>>>  
> >>>>  static void intel_encoder_link_check_work_fn(struct work_struct *work)
> >>>>  {
> >>>> @@ -37,6 +38,28 @@ void intel_encoder_link_check_queue_work(struct intel_encoder *encoder, int dela
> >>>>  			 &encoder->link_check_work, msecs_to_jiffies(delay_ms));
> >>>>  }
> >>>>  
> >>>> +void intel_encoder_unblock_all_hpds(struct intel_display *display)
> >>>> +{
> >>>> +	struct intel_encoder *encoder;
> >>>> +
> >>>> +	if (!HAS_DISPLAY(display))
> >>>> +		return;
> >>>> +
> >>>> +	for_each_intel_encoder(display->drm, encoder)
> >>>> +		intel_hpd_unblock(encoder);
> >>>> +}
> >>>> +
> >>>> +void intel_encoder_block_all_hpds(struct intel_display *display)
> >>>> +{
> >>>> +	struct intel_encoder *encoder;
> >>>> +
> >>>> +	if (!HAS_DISPLAY(display))
> >>>> +		return;
> >>>> +
> >>>> +	for_each_intel_encoder(display->drm, encoder)
> >>>> +		intel_hpd_block(encoder);
> >>>> +}
> >>>> +
> >>>>  void intel_encoder_suspend_all(struct intel_display *display)
> >>>>  {
> >>>>  	struct intel_encoder *encoder;
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_encoder.h b/drivers/gpu/drm/i915/display/intel_encoder.h
> >>>> index 3fa5589f0b1c..e1d3aeab7c00 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_encoder.h
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_encoder.h
> >>>> @@ -17,4 +17,7 @@ void intel_encoder_link_check_flush_work(struct intel_encoder *encoder);
> >>>>  void intel_encoder_suspend_all(struct intel_display *display);
> >>>>  void intel_encoder_shutdown_all(struct intel_display *display);
> >>>>  
> >>>> +void intel_encoder_block_all_hpds(struct intel_display *display);
> >>>> +void intel_encoder_unblock_all_hpds(struct intel_display *display);
> >>>> +
> >>>>  #endif /* __INTEL_ENCODER_H__ */
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c
> >>>> index 265aa97fcc75..c69b535497bf 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> >>>> @@ -971,8 +971,6 @@ void intel_hpd_cancel_work(struct intel_display *display)
> >>>>  
> >>>>  	spin_lock_irq(&display->irq.lock);
> >>>>  
> >>>> -	drm_WARN_ON(display->drm, get_blocked_hpd_pin_mask(display));
> >>>> -
> >>>>  	display->hotplug.long_hpd_pin_mask = 0;
> >>>>  	display->hotplug.short_hpd_pin_mask = 0;
> >>>>  	display->hotplug.event_bits = 0;
> >>>> diff --git a/drivers/gpu/drm/xe/display/xe_display.c b/drivers/gpu/drm/xe/display/xe_display.c
> >>>> index e2e0771cf274..9e984a045059 100644
> >>>> --- a/drivers/gpu/drm/xe/display/xe_display.c
> >>>> +++ b/drivers/gpu/drm/xe/display/xe_display.c
> >>>> @@ -96,6 +96,7 @@ static void xe_display_fini_early(void *arg)
> >>>>  	if (!xe->info.probe_display)
> >>>>  		return;
> >>>>  
> >>>> +	intel_hpd_cancel_work(display);
> >>>>  	intel_display_driver_remove_nogem(display);
> >>>>  	intel_display_driver_remove_noirq(display);
> >>>>  	intel_opregion_cleanup(display);
> >>>> @@ -340,6 +341,8 @@ void xe_display_pm_suspend(struct xe_device *xe)
> >>>>  
> >>>>  	xe_display_flush_cleanup_work(xe);
> >>>>  
> >>>> +	intel_encoder_block_all_hpds(display);
> >>>> +
> >>>>  	intel_hpd_cancel_work(display);
> >>>>  
> >>>>  	if (has_display(xe)) {
> >>>> @@ -369,6 +372,7 @@ void xe_display_pm_shutdown(struct xe_device *xe)
> >>>>  	}
> >>>>  
> >>>>  	xe_display_flush_cleanup_work(xe);
> >>>> +	intel_encoder_block_all_hpds(display);
> >>>
> >>> MST still needs HPD IRQs for side-band messaging, so the HPD IRQs must
> >>> be blocked only after intel_dp_mst_suspend().
> >>>
> >>> Otherwise the patch looks ok to me, so with the above fixed and provided
> >>> that Maarten is ok to disable all display IRQs only later:
> >> 
> >> Also probably good to identify the patch as both xe and i915 in the subject
> >> drm/{i915,xe}/display:
> >> 
> >> and Maarten or Imre, any preference on which branch to go? any chance of
> >> conflicting with any of work you might be doing in any side?
> >> 
> >> From my side I believe that any conflict might be easy to handle, so
> >> 
> >> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >> 
> >> from either side...
> >> 
> >>>
> >>> Reviewed-by: Imre Deak <imre.deak@intel.com>
> > We had a discussion on this approach, and it seems that completely disabling interrupts here like in i915 would fail too.
> >
> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >
> > I don't mind either branch. As long as it applies. :-)
> 
> Please do not merge through *any* tree.
> 
> How come you all think it's okay to add this xe specific thing, and make
> unification harder?

I lost any moral or rights to complain here since I couldn't move with my
tasks of unification of the pm flow :(

double sorry!

> 
> intel_encoder_block_all_hpds() is *way* too specific for a high level
> function. Neither xe nor i915 should never call something like that
> directly.

that's a valid point indeed. But I cannot see another way to fix the
current issue right now without trying to move with the full unification
faster. Do you?

> 
> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel

  reply	other threads:[~2025-07-29 14:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23  9:29 [PATCH v2] drm/xe/display: Block hpd during suspend Dibin Moolakadan Subrahmanian
2025-07-23  9:35 ` ✓ CI.KUnit: success for drm/xe/display: Block hpd during suspend (rev3) Patchwork
2025-07-23  9:38 ` [PATCH v2] drm/xe/display: Block hpd during suspend Imre Deak
2025-07-23 13:19   ` Rodrigo Vivi
2025-07-23 16:54     ` Imre Deak
2025-07-24 11:15     ` Maarten Lankhorst
2025-07-29  9:44       ` Jani Nikula
2025-07-29 14:35         ` Rodrigo Vivi [this message]
2025-07-29 15:03           ` Imre Deak
2025-07-29 16:36             ` Jani Nikula
2025-07-31 12:01               ` Imre Deak
2025-07-31 12:32                 ` Jani Nikula
2025-08-01 15:25                   ` Rodrigo Vivi
2025-07-30  7:21             ` Maarten Lankhorst
2025-07-30 10:24               ` Imre Deak
2025-07-23 10:30 ` ✓ i915.CI.BAT: success for drm/xe/display: Block hpd during suspend (rev2) Patchwork
2025-07-23 10:36 ` ✓ Xe.CI.BAT: success for drm/xe/display: Block hpd during suspend (rev3) Patchwork
2025-07-23 12:29 ` ✗ Xe.CI.Full: failure " Patchwork
2025-07-23 13:59 ` ✗ i915.CI.Full: failure for drm/xe/display: Block hpd during suspend (rev2) Patchwork
2025-07-24  8:58 ` ✓ i915.CI.BAT: success for drm/xe/display: Block hpd during suspend (rev3) Patchwork
2025-07-29  9:39 ` [PATCH v2] drm/xe/display: Block hpd during suspend Jani Nikula

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=aIjcRFU90s6Ml9Vt@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=ankit.k.nautiyal@intel.com \
    --cc=dibin.moolakadan.subrahmanian@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=uma.shankar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.