Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <anshuman.gupta@intel.com>,
	<raag.jadav@intel.com>, <riana.tauro@intel.com>,
	<mallesh.koujalagi@intel.com>, <aravind.iddamsetty@intel.com>,
	<heikki.krogerus@linux.intel.com>,
	<himal.prasad.ghimiray@intel.com>
Subject: Re: [PATCH 1/2] drm/xe/i2c: Expose AMC Alert reason sysfs
Date: Wed, 9 Sep 2026 21:02:45 +0530	[thread overview]
Message-ID: <9c8c6067-5dff-4648-b23d-437161a0c043@intel.com> (raw)
In-Reply-To: <570c3776-1157-4d3f-985b-330caa7ca769@intel.com>


On 09-09-2026 19:57, Nilawar, Badal wrote:
>
> On 09-09-2026 00:22, Rodrigo Vivi wrote:
>> On Fri, Sep 04, 2026 at 09:36:10PM +0530, Badal Nilawar wrote:
>>> AMC raises an SMBUS alert before performing a power removal or
>>> power-cycle operation. The xe driver then places the device into
>>> vendor-specific wedge mode until the recovery is performed.
>>>
>>> Expose a read-only xe_amc_alert_reason sysfs attribute to help users
>>> identify the required recovery action.
>>>
>>> Assisted-by: Claude:claude-opus-4.8
>>> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
>>> ---
>>> v2:
>>>   - Created sysfs during i2c probe time
>>>   - Fix Documentation (Rodrigo)
>>> ---
>>>   .../ABI/testing/sysfs-driver-intel-xe-amc     | 21 +++++++
>>>   drivers/gpu/drm/xe/xe_amc.c                   | 61 
>>> ++++++++++++++++++-
>>>   2 files changed, 79 insertions(+), 3 deletions(-)
>>>   create mode 100644 
>>> Documentation/ABI/testing/sysfs-driver-intel-xe-amc
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-amc 
>>> b/Documentation/ABI/testing/sysfs-driver-intel-xe-amc
>>> new file mode 100644
>>> index 000000000000..4e5389163dbb
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-amc
>>> @@ -0,0 +1,21 @@
>>> +What:        /sys/bus/pci/drivers/xe/.../xe_amc_alert_reason
>>> +Date:        September 2026
>>> +KernelVersion:    7.4
>>> +Contact:    intel-xe@lists.freedesktop.org
>>> +Description:
>>> +        This file exposes the reason for the most recent Add-In
>>> +        Management Controller (AMC) alert on Intel Xe platforms.
>>> +
>>> +        An AMC alert is delivered via an SMBUS interrupt and causes 
>>> the
>>> +        device to be wedged, requiring vendor-specific recovery. This
>>> +        attribute is created when such an alert is handled and is
>>> +        available to all users as read-only.
>>> +
>>> +        Read returns a single line containing one of the following
>>> +        alert reasons:
>>> +
>>> +            Firmware Download
>>> +            Thermal Trip
>>> +            OOB Request
>>> +            OOB Reset
>>> +            Catastrophic
>> please make this non capital letters and no space
>>
>> firmware_download
>> thermal_trip
>> oob_request
>> oob_reset
>> catastrophic
>>
>>> diff --git a/drivers/gpu/drm/xe/xe_amc.c b/drivers/gpu/drm/xe/xe_amc.c
>>> index 8ecadee6eea3..c2d516c76502 100644
>>> --- a/drivers/gpu/drm/xe/xe_amc.c
>>> +++ b/drivers/gpu/drm/xe/xe_amc.c
>>> @@ -18,6 +18,7 @@
>>>   #include "xe_device.h"
>>>   #include "xe_i2c.h"
>>>   #include "xe_mmio.h"
>>> +#include "xe_printk.h"
>>>     /**
>>>    * DOC: Add-In Management Controller (AMC)
>>> @@ -46,6 +47,7 @@ enum xe_amc_alert {
>>>   };
>>>     static const char * const amc_alert[] = {
>>> +    [AMC_ALERT_UNKNOWN]        = "None",
>> shouldn't be unknown?
> It can be unknown.
>> shouldn't be in the list above?
>
> Not required, as only valid alert reasons result in the device being 
> wedged and subsequently exposed to userspace.

I will add both states "none" and "unknown".  "None" will indicate that 
no SMBUS alert has been received so far, while "Unknown" will indicate 
that an AMC alert was received but the alert reason is unrecognized.

Thanks,
Badal

>
>
> Thanks,
> Badal
>
>>
>>>       [AMC_ALERT_FW_DOWNLOAD]        = "Firmware Download",
>>>       [AMC_ALERT_THERMAL_TRIP]    = "Thermal Trip",
>>>       [AMC_ALERT_OOB_REQUEST]        = "OOB Request",
>>> @@ -56,6 +58,8 @@ static const char * const amc_alert[] = {
>>>   struct xe_amc {
>>>       struct xe_i2c *i2c;
>>>       struct work_struct work;
>>> +    u8 alert_reason;
>>> +    bool sysfs_created;
>>>   };
>>>     struct amc_header {
>>> @@ -104,6 +108,45 @@ static const struct amc_request 
>>> amc_get_alert_reason = {
>>>       },
>>>   };
>>>   +/**
>>> + * DOC: AMC Alert Reason
>>> + *
>>> + * On Intel Xe platforms, AMC sends an alert notification via an 
>>> SMBUS interrupt
>>> + * to notify events such as firmware download, thermal trip or a
>>> + * catastrophic error. See enum xe_amc_alert for the full list of 
>>> reasons.
>>> + * Upon an AMC alert the device is wedged and requires 
>>> vendor-specific recovery.
>>> + *
>>> + * The alert reason is exposed through
>>> + * /sys/bus/pci/devices/<BDF>/xe_amc_alert_reason
>>> + *
>>> + * See Documentation/ABI/testing/sysfs-driver-intel-xe-amc for the ABI
>>> + * specification.
>>> + */
>>> +
>>> +static ssize_t xe_amc_alert_reason_show(struct device *dev,
>>> +                    struct device_attribute *attr, char *buff)
>>> +{
>>> +    struct xe_device *xe = pdev_to_xe_device(to_pci_dev(dev));
>>> +    struct xe_amc *amc = xe->i2c->amc;
>>> +
>>> +    return sysfs_emit(buff, "%s\n", amc_alert[amc->alert_reason]);
>>> +}
>>> +static DEVICE_ATTR_RO(xe_amc_alert_reason);
>>> +
>>> +static void xe_amc_remove_alert_sysfs(struct xe_i2c *i2c)
>>> +{
>>> +    struct device *dev = i2c->drm_dev;
>>> +
>>> +    device_remove_file(dev, &dev_attr_xe_amc_alert_reason);
>>> +}
>>> +
>>> +static int xe_amc_create_alert_sysfs(struct xe_i2c *i2c)
>>> +{
>>> +    struct device *dev = i2c->drm_dev;
>>> +
>>> +    return device_create_file(dev, &dev_attr_xe_amc_alert_reason);
>>> +}
>>> +
>>>   static void xe_amc_work(struct work_struct *work)
>>>   {
>>>       const struct amc_request *request = &amc_get_alert_reason;
>>> @@ -158,10 +201,15 @@ static void xe_amc_work(struct work_struct *work)
>>>       case AMC_ALERT_THERMAL_TRIP:
>>>       case AMC_ALERT_OOB_REQUEST:
>>>       case AMC_ALERT_OOB_RESET:
>>> -    case AMC_ALERT_CATERR:
>>> +    case AMC_ALERT_CATERR: {
>>> +        struct xe_device *xe = i2c_client_to_xe_device(client);
>>> +
>>>           dev_warn(amc->i2c->drm_dev, "AMC Alert: %s\n", 
>>> amc_alert[alert_reason]);
>>> - xe_device_declare_wedged(i2c_client_to_xe_device(client));
>>> +        amc->alert_reason = alert_reason;
>>> +        xe_device_set_wedged_method(xe, DRM_WEDGE_RECOVERY_VENDOR);
>>> +        xe_device_declare_wedged(xe);
>>>           break;
>>> +    }
>>>       default:
>>>           dev_warn(amc->i2c->drm_dev, "unknown AMC alert: %d\n", 
>>> alert_reason);
>>>           break;
>>> @@ -176,6 +224,7 @@ void xe_amc_handle_alert(struct xe_i2c *i2c)
>>>   int xe_amc_init(struct xe_i2c *i2c)
>>>   {
>>>       struct xe_amc *amc;
>>> +    int ret;
>>>         amc = kzalloc(sizeof(*amc), GFP_KERNEL);
>>>       if (!amc)
>>> @@ -185,11 +234,17 @@ int xe_amc_init(struct xe_i2c *i2c)
>>>       i2c->amc = amc;
>>>       amc->i2c = i2c;
>>>   -    return 0;
>>> +    ret =  xe_amc_create_alert_sysfs(i2c);
>>> +    if (ret)
>>> +        kfree(i2c->amc);
>>> +
>>> +    return ret;
>>>   }
>>>     void xe_amc_exit(struct xe_i2c *i2c)
>>>   {
>>> +    xe_amc_remove_alert_sysfs(i2c);
>>> +
>>>       if (i2c->amc) {
>>>           cancel_work_sync(&i2c->amc->work);
>>>           kfree(i2c->amc);
>>> -- 
>>> 2.54.0
>>>

  reply	other threads:[~2026-09-09 15:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 16:06 [PATCH 0/2] Expose device sysfs for AMC and GPU UUID Badal Nilawar
2026-09-04 15:56 ` ✗ CI.checkpatch: warning for " Patchwork
2026-09-04 15:58 ` ✓ CI.KUnit: success " Patchwork
2026-09-04 16:06 ` [PATCH 1/2] drm/xe/i2c: Expose AMC Alert reason sysfs Badal Nilawar
2026-09-08 18:52   ` Rodrigo Vivi
2026-09-09 14:27     ` Nilawar, Badal
2026-09-09 15:32       ` Nilawar, Badal [this message]
2026-09-04 16:06 ` [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs Badal Nilawar
2026-09-04 15:57   ` sashiko-bot
2026-09-04 16:02   ` Gupta, Anshuman
2026-09-04 16:37   ` Michal Wajdeczko
2026-09-07  9:13     ` Nilawar, Badal
2026-09-07 11:55       ` Michal Wajdeczko
2026-09-07 12:04         ` Gupta, Anshuman
2026-09-07 15:48           ` Michal Wajdeczko
2026-09-08 18:55             ` Rodrigo Vivi
2026-09-10  6:31         ` Nilawar, Badal
2026-09-07  5:02   ` Joonas Lahtinen
2026-09-07  8:16     ` Nilawar, Badal
2026-09-04 16:48 ` ✓ Xe.CI.BAT: success for Expose device sysfs for AMC and GPU UUID Patchwork
2026-09-05  0:54 ` ✓ Xe.CI.FULL: " 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=9c8c6067-5dff-4648-b23d-437161a0c043@intel.com \
    --to=badal.nilawar@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=aravind.iddamsetty@intel.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=mallesh.koujalagi@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox