Re: [PATCH 1/2] drm/xe/xe_pci_error: Wait for pcode init post SBR

[Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>]

On 28-08-2026 19:36, Gupta, Anshuman wrote:
>
>> -----Original Message-----
>> From: Tauro, Riana <riana.tauro@intel.com>
>> Sent: Friday, August 28, 2026 5:01 PM
>> To: intel-xe@lists.freedesktop.org
>> Cc: Tauro, Riana <riana.tauro@intel.com>; Gupta, Anshuman
>> <anshuman.gupta@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>;
>> aravind.iddamsetty@linux.intel.com; Jadav, Raag <raag.jadav@intel.com>;
>> Koppuravuri, Ravi Kishore <ravi.kishore.koppuravuri@intel.com>; Roper,
>> Matthew D <matthew.d.roper@intel.com>
>> Subject: [PATCH 1/2] drm/xe/xe_pci_error: Wait for pcode init post SBR
>>
>> Pcode init complete indicates the device is ready, with device memory
>> initialization complete. Wait for Pcode init before accessing the device post
>> Secondary Bus Reset (SBR).
>>
>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>> ---
>>  drivers/gpu/drm/xe/xe_pci_error.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_pci_error.c
>> b/drivers/gpu/drm/xe/xe_pci_error.c
>> index 79ce0c671549..3e9c77f8483d 100644
>> --- a/drivers/gpu/drm/xe/xe_pci_error.c
>> +++ b/drivers/gpu/drm/xe/xe_pci_error.c
>> @@ -9,6 +9,7 @@
>>  #include "xe_gt.h"
>>  #include "xe_log.h"
>>  #include "xe_pci.h"
>> +#include "xe_pcode.h"
>>  #include "xe_pm.h"
>>  #include "xe_printk.h"
>>  #include "xe_ras.h"
>> @@ -109,6 +110,10 @@ static pci_ers_result_t
>> xe_pci_error_slot_reset(struct pci_dev *pdev)
>>  		return PCI_ERS_RESULT_DISCONNECT;
>>  	}
>>
>> +	err = xe_pcode_probe_early(xe);
> This can be a 3-minute wait in worst case, after PCIe core pci_bridge_wait_for_secondary_bus() is already waited for 1 second*[1].
> What will be the impact on already running workload and any worker thread tries to access the mmio or PCIe bar here? 

The existing workloads are expected to crash or terminate for an error
that needs SBR to recover, before we reach to this state driver declares
the device as wedged anyways.

Thanks,
Aravind.
>
> [1]
> /*
>  * Devices may extend the 1 sec period through Request Retry Status
>  * completions (PCIe r6.0 sec 2.3.1).  The spec does not provide an upper
>  * limit, but 60 sec ought to be enough for any device to become
>  * responsive.
>  */
> #define PCIE_RESET_READY_POLL_MS 60000 /* msec */
>
> Thanks,
> Anshuman
>> +	if (err)
>> +		return PCI_ERS_RESULT_DISCONNECT;
>> +
>>  	/*
>>  	 * Secondary Bus Reset causes all VRAM state to be lost along with
>>  	 * hardware state. As an initial step, re-probe the device to
>> --
>> 2.47.1