[Intel-xe] [PATCH 10/11] drm/xe: Clear SOC CORRECTABLE error registers.

Ghimiray, Himal Prasad himal.prasad.ghimiray at intel.com
Thu Oct 12 04:01:53 UTC 2023



> -----Original Message-----
> From: Aravind Iddamsetty <aravind.iddamsetty at linux.intel.com>
> Sent: 12 October 2023 08:30
> To: Ghimiray, Himal Prasad <himal.prasad.ghimiray at intel.com>; intel-
> xe at lists.freedesktop.org
> Subject: Re: [Intel-xe] [PATCH 10/11] drm/xe: Clear SOC CORRECTABLE error
> registers.
> 
> 
> On 11/10/23 12:22, Ghimiray, Himal Prasad wrote:
> >
> > On 11-10-2023 12:18, Aravind Iddamsetty wrote:
> >> On 27/09/23 17:16, Himal Prasad Ghimiray wrote:
> >>> PVC doesn't support correctable SOC errors, if we receive MSI due to
> >> statement looks incomplete/inappropriate,
> >>
> >> better rephrase to "PVC doesn't support correctable SOC error reporting"
> > ok.
> >>
> >> Thanks,
> >> Aravind.
> >>> correctable error, classify them as Undefined and clear the registers.
> >>>
> >>> Signed-off-by: Himal Prasad Ghimiray
> >>> <himal.prasad.ghimiray at intel.com>
> >>> ---
> >>>   drivers/gpu/drm/xe/xe_hw_error.c | 24 +++++++++++++++++++++++-
> >>>   1 file changed, 23 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/xe/xe_hw_error.c
> >>> b/drivers/gpu/drm/xe/xe_hw_error.c
> >>> index dcf395bd985f..0bcb1bea7ffb 100644
> >>> --- a/drivers/gpu/drm/xe/xe_hw_error.c
> >>> +++ b/drivers/gpu/drm/xe/xe_hw_error.c
> >>> @@ -616,9 +616,30 @@ xe_soc_hw_error_handler(struct xe_tile *tile,
> >>> const enum hardware_error hw_err)
> >>>         lockdep_assert_held(&tile_to_xe(tile)->irq.lock);
> >>>   -    if ((tile_to_xe(tile)->info.platform != XE_PVC) && hw_err ==
> >>> HARDWARE_ERROR_CORRECTABLE)
> >>> +    if ((tile_to_xe(tile)->info.platform != XE_PVC))
> >>>           return;
> >>>   +    if (hw_err == HARDWARE_ERROR_CORRECTABLE) {
> >>> +        for (i = 0; i < PVC_NUM_IEH; i++)
> >>> +            xe_mmio_write32(gt, SOC_GSYSEVTCTL_REG(base,
> >>> +slave_base, i),
> >>> +                    ~REG_BIT(hw_err));
> >>> +
> >>> +        xe_mmio_write32(gt, SOC_GLOBAL_ERR_STAT_MASTER_REG(base,
> >>> +hw_err),
> >>> +                REG_GENMASK(31, 0));
> >>> +        xe_mmio_write32(gt, SOC_LOCAL_ERR_STAT_MASTER_REG(base,
> >>> +hw_err),
> >>> +                REG_GENMASK(31, 0));
> >>> +        xe_mmio_write32(gt,
> >>> +SOC_GLOBAL_ERR_STAT_SLAVE_REG(slave_base, hw_err),
> >>> +                REG_GENMASK(31, 0));
> >>> +        xe_mmio_write32(gt,
> >>> +SOC_LOCAL_ERR_STAT_SLAVE_REG(slave_base, hw_err),
> >>> +                REG_GENMASK(31, 0));
> >>> +
> >>> +        drm_info(&tile_to_xe(tile)->drm, HW_ERR
> >>> +              "Tile%d Undefine SOC %s error.",
> >>> +              tile->id, hwerr_to_str);
> >> I still feel in this scenarios at least we shall flag this as
> >> drm_err, since even though it is correctable and corrected by HW,
> >> aren't they spurious as we don't expect to receive them and a HW
> misbehaviour. Thoughts?
> >
> > Agreed. IMO this change should be part of low driver error reporting.
> > Not only SOC, we need to report other gt and tile errors
> 
> the category will be added as part of low level driver error, but the since you
> are adding the print, suggesting to change to drm_err

Ok

> 
> Thanks,
> 
> Aravind.
> 
> >
> > too as spurious interrupt errors when they are undefined irrespective of
> error classes(correctable/uncorrectable).
> >
> >>
> >>
> >> Thanks,
> >> Aravind.
> >>> +
> >>> +        goto unmask_gsysevtctl;
> >>> +    }
> >>> +
> >>>       if (hw_err == HARDWARE_ERROR_FATAL) {
> >>>           soc_mstr_glbl_err_reg = soc_mstr_glbl_err_reg_fatal;
> >>>           soc_mstr_lcl_err_reg = soc_mstr_lcl_err_reg_fatal; @@
> >>> -709,6 +730,7 @@ xe_soc_hw_error_handler(struct xe_tile *tile, const
> >>> enum hardware_error hw_err)
> >>>       xe_mmio_write32(gt, SOC_GLOBAL_ERR_STAT_MASTER_REG(base,
> >>> hw_err),
> >>>               mst_glb_errstat);
> >>>   +unmask_gsysevtctl:
> >>>       for (i = 0; i < PVC_NUM_IEH; i++)
> >>>           xe_mmio_write32(gt, SOC_GSYSEVTCTL_REG(base, slave_base,
> >>> i),
> >>>                   (HARDWARE_ERROR_MAX << 1) + 1);


More information about the Intel-xe mailing list