All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>
Cc: Dibin Moolakadan Subrahmanian
	<dibin.moolakadan.subrahmanian@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Shankar, Uma" <uma.shankar@intel.com>,
	"Sharma, Swati2" <swati2.sharma@intel.com>,
	"Nikula, Jani" <jani.nikula@intel.com>
Subject: Re: [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR interrupt
Date: Fri, 13 Mar 2026 13:25:46 +0200	[thread overview]
Message-ID: <abP0OsNCqxhoaBCV@intel.com> (raw)
In-Reply-To: <DM3PPF208195D8D00F123DBDB50B578B8F0E345A@DM3PPF208195D8D.namprd11.prod.outlook.com>

On Fri, Mar 13, 2026 at 10:08:47AM +0000, Kandpal, Suraj wrote:
> > Subject: Re: [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR interrupt
> > 
> > On Fri, Mar 13, 2026 at 05:04:46AM +0000, Kandpal, Suraj wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dibin Moolakadan Subrahmanian
> > > > <dibin.moolakadan.subrahmanian@intel.com>
> > > > Sent: Friday, March 13, 2026 9:55 AM
> > > > To: Kandpal, Suraj <suraj.kandpal@intel.com>;
> > > > intel-gfx@lists.freedesktop.org; intel-xe@lists.freedesktop.org
> > > > Cc: ville.syrjala@linux.intel.com; Shankar, Uma
> > > > <uma.shankar@intel.com>; Sharma, Swati2 <swati2.sharma@intel.com>
> > > > Subject: Re: [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR
> > > > interrupt
> > > >
> > > >
> > > > On 13-03-2026 08:56, Kandpal, Suraj wrote:
> > > > >> On 12-03-2026 08:48, Kandpal, Suraj wrote:
> > > > >>>> Subject: [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR
> > > > >>>> interrupt
> > > > >>>>
> > > > >>>> Enable PIPEDMC_ERROR interrupt bit for display version 35+.
> > > > >>>>
> > > > >>> Add same Bspec link here too
> > > > >>>
> > > > >>>> Signed-off-by: Dibin Moolakadan Subrahmanian
> > > > >>>> <dibin.moolakadan.subrahmanian@intel.com>
> > > > >>>> ---
> > > > >>>>    drivers/gpu/drm/i915/display/intel_dmc.c | 3 ++-
> > > > >>>>    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >>>>
> > > > >>>> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > >>>> b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > >>>> index 38b284a0db82..e60f1f977070 100644
> > > > >>>> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > >>>> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > > > >>>> @@ -510,7 +510,8 @@ static void pipedmc_clock_gating_wa(struct
> > > > >>>> intel_display *display, bool enable)  static u32
> > > > >>>> pipedmc_interrupt_mask(struct intel_display *display)  {
> > > > >>>>    	if (DISPLAY_VER(display) >= 35)
> > > > >>>> -		return PIPEDMC_FLIPQ_PROG_DONE;
> > > > >>>> +		return PIPEDMC_FLIPQ_PROG_DONE |
> > > > >>>> +			PIPEDMC_ERROR;
> > > > >>>>
> > > > >>> Mostly looks okay but here's my question:
> > > > >>> I know LNL pipe B had an issue with PIPEDMC_ERROR being
> > > > >>> triggered on LNL pipe B, As I can see from Ville's commit
> > > > >>> message, but is it still the case for
> > > > >> PTL ?
> > > > >>> Can we have that tested ?
> > > > >>> If that works we can add the PIPEDMC_ERROR from PTL onwards.
> > > > >>> Then here we can change code to create a mask and then return it
> > > > >>> finally like
> > > > >> :
> > > > >>> mask = PIPEDMC_FLIPQ_PROG_DONE
> > > > >>>
> > > > >>> if display ver >= 30
> > > > >>> mask |= PIPEDMC_ERROR
> > > > >>>
> > > > >>> if display ver < 35
> > > > >>> mask |= PIPEDMC_GTT_FAULT |
> > > > >>>                   PIPEDMC_ATS_FAULT;
> > > > >>>
> > > > >>> Return mask;
> > > > >>>
> > > > >>> Obviously that is if PIPEDMC_ERROR works on PTL properly.
> > > > >> Thank you for spotting this, I think its better to add above
> > > > >> logic in new series rather than combing with 35+ bit mask update.
> > > > >>
> > > > >> Regards,
> > > > >> Dibin
> > > > > If that is the case then I think its better to drop this patch altogether.
> > > > > We have a justification of why we remove bits in first patch, that
> > > > > was a change
> > > > in NVL H/w.
> > > > > But this change was introduced in LNL.
> > > > > Without a strong reasoning of why you are enabling this is in NVL
> > > > > and not in PTL (which I don’t see in this patch series) I suggest
> > > > > you add this patch with as a part of the series where you have a
> > > > > use case for it. And if
> > > > there too you only add it for NVL You will need to add a comments as
> > > > to why this is not enabled for PTL.
> > > >
> > > > This patch intent to fix the interrupt mask for 35+.
> > > > I dont see any reason to disable this bit as
> > > > 1) error bit warning is already present in interrupt handler.
> > > > 2) bit is defined in bsepc.
> > > > 3) LNL it was mentioned disabled because pipeB triggering it during
> > > > first DC state transition which did not see in this case.
> > >
> > > In that case the interrupt handler is made to report errors if this bit is
> > unmasked for  >= LNL.
> > > Now this bit is introduced in LNL timeframe for which the reason to not add it
> > is mentioned in comment and documented.
> > > Similarly if you want to skip PTL you will need this to be documented
> > > with the reason. Which means the FIXME comment needs to be modified In
> > the least. If this patch is to go through.
> > > Also Ville can you shed some light, on what the H/w folks had to say
> > > regarding this and if they had mentioned any WA for LNL, and if this is fixed In
> > LNL+.
> > 
> > I suspect it might be some kind of issue in the DMC firmware where it's
> > accessing unpowered registers. But it was never investigated properly.
> > 
> > It would be good if someone could take that up and actually figure out what's
> > going on. The problem is figuring out what exactly is the register that causes
> > this. I don't think LNL has any kind of RM_CAPTURE register/etc available for
> > the DMC that would directly tell us that :(
> > 
> > IIRC the Windows driver did seem to enable the error interrupt on LNL, but
> > either they just ignore all the reported errors, or somehow the way they use
> > the hardware/firmware doesn't trigger them.
> 
> Hmm would it be okay if we can move with enabling the bit for NVL+ since Dibin says we don’t see this issue
> Anymore, while we add or TODO or FIXME in the comment to investigate this further for PTL and LNL

Yeah, I think the sooner we enable this on NVL the better. We want to
catch the issues early. For PTL someone should just send a patch to
enable it (separately from the NVL changes) and hopefully CI will tell
us whether it's still a problem there or not.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-03-13 11:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11  6:32 [PATCH 0/2] drm/i915/dmc: Update PIPEDMC interrupt mask Dibin Moolakadan Subrahmanian
2026-03-11  6:32 ` [PATCH 1/2] drm/i915/dmc: Remove invalid PIPEDMC interrupt bits Dibin Moolakadan Subrahmanian
2026-03-12  3:10   ` Kandpal, Suraj
2026-03-12 12:24     ` Dibin Moolakadan Subrahmanian
2026-03-11  6:32 ` [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR interrupt Dibin Moolakadan Subrahmanian
2026-03-12  3:18   ` Kandpal, Suraj
2026-03-12 12:28     ` Dibin Moolakadan Subrahmanian
2026-03-13  3:26       ` Kandpal, Suraj
2026-03-13  4:25         ` Dibin Moolakadan Subrahmanian
2026-03-13  5:04           ` Kandpal, Suraj
2026-03-13 10:03             ` Ville Syrjälä
2026-03-13 10:08               ` Kandpal, Suraj
2026-03-13 11:25                 ` Ville Syrjälä [this message]
2026-03-16  2:49                   ` Kandpal, Suraj
2026-03-16 12:13                     ` Dibin Moolakadan Subrahmanian
2026-03-11  6:37 ` ✓ CI.KUnit: success for drm/i915/dmc: Update PIPEDMC interrupt mask (rev2) Patchwork
2026-03-11  7:19 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-11  7:58 ` ✓ i915.CI.BAT: " Patchwork
2026-03-11 18:42 ` ✓ i915.CI.Full: " Patchwork
2026-03-11 21:52 ` ✗ 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=abP0OsNCqxhoaBCV@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dibin.moolakadan.subrahmanian@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=suraj.kandpal@intel.com \
    --cc=swati2.sharma@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.