From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C66E4105F79D for ; Fri, 13 Mar 2026 11:25:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 580EC10EBA8; Fri, 13 Mar 2026 11:25:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="jXMvLjIC"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id 753CF10EBA5; Fri, 13 Mar 2026 11:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773401151; x=1804937151; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=vVYY05MWceJfoLgMiLiuHYgFUj+vPKgA+UlheqqJMxA=; b=jXMvLjIClsUU4zDszkooeQorhaX53BFIDgHU6AhBvIdD3xl7FYxM7HcN FySmKi6AI8yrZGJ6UgQmqsj8ytDvGMDcp5jU5zxCLOPP75Y2mAVJgx4WB Npzvd1VoHKeJp0/G/Q1tJDRL5vMZRWh+2oBXvXnQ1xZhmhToOHDjbvdQY l2cjkJNe0Q2cCOQ6Fe/4lMa5iTDLtdNPNMZKL2kAyGKzzEd9AG2MMIGOB KWlgmYVftd9+G1Z9ifXA3MHQ5i2gliZ+8+X+riPn45tQDOdkcFO2BeNNc tkRLL7PfvqIu3CPSkdYM7Aqb74O0R8Z5+y0IcNZnxZbBgviCCxkNpdifZ Q==; X-CSE-ConnectionGUID: mXS2Be61T7ynFJHRepFgzA== X-CSE-MsgGUID: 9jNPkNReR3iPz2eWM73upw== X-IronPort-AV: E=McAfee;i="6800,10657,11727"; a="74474613" X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="74474613" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2026 04:25:51 -0700 X-CSE-ConnectionGUID: cSXs33fqSISUzSwEImUBlQ== X-CSE-MsgGUID: OGFgb2zvQ2ytQYaoGhQU/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="225591733" Received: from smoticic-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.21]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2026 04:25:48 -0700 Date: Fri, 13 Mar 2026 13:25:46 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Kandpal, Suraj" Cc: Dibin Moolakadan Subrahmanian , "intel-gfx@lists.freedesktop.org" , "intel-xe@lists.freedesktop.org" , "Shankar, Uma" , "Sharma, Swati2" , "Nikula, Jani" Subject: Re: [PATCH 2/2] drm/i915/dmc: Enable PIPEDMC_ERROR interrupt Message-ID: References: <20260311063259.2608206-1-dibin.moolakadan.subrahmanian@intel.com> <20260311063259.2608206-3-dibin.moolakadan.subrahmanian@intel.com> <7b072000-0b8d-4910-ae05-0eaac6d9e94a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 > > > > > > > > Sent: Friday, March 13, 2026 9:55 AM > > > > To: Kandpal, Suraj ; > > > > intel-gfx@lists.freedesktop.org; intel-xe@lists.freedesktop.org > > > > Cc: ville.syrjala@linux.intel.com; Shankar, Uma > > > > ; Sharma, Swati2 > > > > 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 > > > > >>>> > > > > >>>> --- > > > > >>>> 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