All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
To: <sashiko-reviews@lists.linux.dev>, <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] drm/xe: Access MMIO after pcode init
Date: Thu, 15 Oct 2026 16:52:38 -0700	[thread overview]
Message-ID: <7d145ffb-4614-417b-97d8-b6bdde6197b3@intel.com> (raw)
In-Reply-To: <sashiko-outbox-173473@kernel.org>


On 10/15/2026 4:43 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] drm/xe: incomplete mmio deferral fix misses xe_wa_apply_tile_workarounds
> --
>
> commit a929401ac9f4b4d8f49c85fe7a5336571b384903
> Author: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
>
> drm/xe: Access MMIO after pcode init
>
> This commit delays MMIO space accesses during resume until after pcode
> initialization is complete. It achieves this by moving xe_gt_idle_disable_c6()
> after the call to xe_pcode_ready().
>
>> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
>> index daa7ba2df317a..1f5097875bcdf 100644
>> --- a/drivers/gpu/drm/xe/xe_pm.c
>> +++ b/drivers/gpu/drm/xe/xe_pm.c
>> @@ -241,9 +241,6 @@ int xe_pm_resume(struct xe_device *xe)
>>   	drm_dbg(&xe->drm, "Resuming device\n");
>>   	trace_xe_pm_resume(xe, __builtin_return_address(0));
>>   
>> -	for_each_gt(gt, xe, id)
>> -		xe_gt_idle_disable_c6(gt);
>> -
>>   	for_each_tile(tile, xe, id)
>>   		xe_wa_apply_tile_workarounds(tile);
> [Severity: High]
> Does this code still access MMIO before pcode initialization completes?
>
> The commit message indicates we shouldn't poke around the MMIO space during
> resume before pcode init completes, but xe_wa_apply_tile_workarounds()
> performs MMIO accesses via xe_mmio_rmw32() when applying workarounds:
>
> drivers/gpu/drm/xe/xe_wa.c:xe_wa_apply_tile_workarounds() {
> 	...
> 	if (XE_DEVICE_WA(tile->xe, 22010954014))
> 		xe_mmio_rmw32(mmio, XEHP_CLOCK_GATE_DIS, 0, SGSI_SIDECLK_DIS);
> }
>
> Should the xe_wa_apply_tile_workarounds() call also be moved after
> xe_pcode_ready() to fully prevent MMIO access before the synchronization
> barrier?

XEHP_CLOCK_GATE_DIS is an soc register outside the GT domain as 
documented in the function. It should be fine to access those regs. The 
issue this patch is fixing is related to accessing GT registers before 
pcode is ready. I will clarify this in the commit message.

Thanks,

Vinay.

>
>>   
>> @@ -251,6 +248,9 @@ int xe_pm_resume(struct xe_device *xe)
>>   	if (err)
>>   		return err;
>>   
>> +	for_each_gt(gt, xe, id)
>> +		xe_gt_idle_disable_c6(gt);
>> +
>>   	xe_display_pm_resume_early(xe);

  reply	other threads:[~2026-10-15 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 16:54 [PATCH 0/3] drm/xe: Some d3cold related fixes Vinay Belgaumkar
2026-10-15 16:54 ` [PATCH 1/3] drm/xe: Toggle the D3Cold enable flag at runtime resume Vinay Belgaumkar
2026-10-15 16:54 ` [PATCH 2/3] drm/xe: Access MMIO after pcode init Vinay Belgaumkar
2026-10-15 23:43   ` sashiko-bot
2026-10-15 23:52     ` Belgaumkar, Vinay [this message]
2026-10-15 16:54 ` [PATCH 3/3] drm/xe: Memset g2g buffer on resume Vinay Belgaumkar
2026-10-16  0:03 ` ✓ CI.KUnit: success for drm/xe: Some d3cold related fixes Patchwork
2026-10-16  0:41 ` ✓ Xe.CI.BAT: " 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=7d145ffb-4614-417b-97d8-b6bdde6197b3@intel.com \
    --to=vinay.belgaumkar@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.