Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Riana Tauro <riana.tauro@intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>,
	<aravind.iddamsetty@linux.intel.com>, <anshuman.gupta@intel.com>,
	<rodrigo.vivi@intel.com>, <joonas.lahtinen@linux.intel.com>,
	<simona.vetter@ffwll.ch>, <airlied@gmail.com>,
	<pratik.bari@intel.com>, <joshua.santosh.ranjan@intel.com>,
	<ashwin.kumar.kulkarni@intel.com>, <shubham.kumar@intel.com>
Subject: Re: [PATCH v3 2/4] drm/xe/xe_drm_ras: Add support for drm ras
Date: Fri, 9 Jan 2026 13:38:44 +0530	[thread overview]
Message-ID: <ac78c819-51ce-4a6b-a5c8-1f327d1d8a7e@intel.com> (raw)
In-Reply-To: <aTfcV5nb_vBOOBvP@black.igk.intel.com>

Hi Raag

Thank you for the review

On 12/9/2025 1:52 PM, Raag Jadav wrote:
> On Fri, Dec 05, 2025 at 02:09:34PM +0530, Riana Tauro wrote:
>> Allocate correctable, nonfatal and fatal nodes per xe device.
>> Each node contains error classes, counters and respective
>> query counter functions.
>>
>> Add basic functionality to create and register drm nodes.
>> Below operations can be performed using Generic netlink DRM RAS interface
>>
>> List Nodes:
>>
>> $ sudo ynl --family drm_ras  --dump list-nodes
>> [{'device-name': '0000:03:00.0',
>>    'node-id': 0,
>>    'node-name': 'correctable-errors',
>>    'node-type': 'error-counter'},
>>   {'device-name': '0000:03:00.0',
>>    'node-id': 1,
>>    'node-name': 'nonfatal-errors',
>>    'node-type': 'error-counter'},
>>   {'device-name': '0000:03:00.0',
>>    'node-id': 2,
>>    'node-name': 'fatal-errors',
>>    'node-type': 'error-counter'}]
>>
>> Get Error counters:
>>
>> $ sudo ynl --family drm_ras  --dump get-error-counters --json '{"node-id":1}'
>> [{'error-id': 1, 'error-name': 'Core Compute Error', 'error-value': 0},
>>   {'error-id': 2, 'error-name': 'SOC Internal Error', 'error-value': 0}]
> 
> Minor bikeshedding: Is there anything like 'SOC External'? If not, perhaps
> simply 'SOC' would be sufficient.

Agree. SoC should be sufficient

> 
>> Query Error counter:
>>
>> $ sudo ynl --family drm_ras --do query-error-counter  --json '{"node-id":1, "error-id":1}'
>> {'error-id': 1, 'error-name': 'Core Compute Error', 'error-value': 0}
> 
> One more (sorry): So this means graphics will be a different id? Or do they
> overlap? How does it work?
> 

Did not get this question.

> 
> Also,
> 
> [*] I'm not much informed about the history here but the 'error' term
> seems slapped onto almost everything. We already know it's RAS so perhaps
> we add it only where make sense and try to simplify some of the naming?

Let's keep the errors in the node-names. Removing it from error-name 
should be okay. Wil fix ths


> 
> ...
> 
>> diff --git a/drivers/gpu/drm/xe/xe_drm_ras.c b/drivers/gpu/drm/xe/xe_drm_ras.c
>> new file mode 100644
>> index 000000000000..764b14b1edf8
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_drm_ras.c
>> @@ -0,0 +1,199 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2025 Intel Corporation
>> + */
>> +
>> +#include <drm/drm_managed.h>
>> +#include <drm/drm_ras.h>
>> +#include <linux/bitmap.h>
>> +
>> +#include "xe_device.h"
> 
> This inherits some of the debt that should not be there, so let's try to
> get away with xe_device_types.h where possible. But please double check.
> 
>> +#include "xe_drm_ras.h"
> 
> ...
> 
>> +static struct xe_drm_ras_counter *allocate_and_copy_counters(struct xe_device *xe,
>> +							     int count)
>> +{
>> +	struct xe_drm_ras_counter *counter;
>> +	int i;
>> +
>> +	counter = drmm_kzalloc(&xe->drm, count * sizeof(struct xe_drm_ras_counter), GFP_KERNEL);
> 
> Why not drmm_kcalloc()? We get a bonus overflow protection.

Will check

> 
>> +	if (!counter)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	for (i = 0; i < count; i++) {
>> +		if (!errors[i])
>> +			continue;
>> +
>> +		counter[i].name = errors[i];
>> +		atomic64_set(&counter[i].counter, 0);
>> +	}
>> +
>> +	return counter;
>> +}
>> +
>> +static int assign_node_params(struct xe_device *xe, struct drm_ras_node *node,
>> +			      const enum drm_xe_ras_error_severity severity)
>> +{
>> +	struct xe_drm_ras *ras = &xe->ras;
>> +	int count = 0, ret = 0;
> 
> Redundant initializations, also why do we need them?

redundant code from previous rev. Will remove

> 
>> +	count = DRM_XE_RAS_ERROR_CLASS_MAX;
>> +	node->error_counter_range.first = DRM_XE_RAS_ERROR_CORE_COMPUTE;
>> +	node->error_counter_range.last = DRM_XE_RAS_ERROR_CLASS_MAX - 1;
>> +
>> +	ras->info[severity] = allocate_and_copy_counters(xe, count);
> 
> This looks like count should be derived from first and last, or did I
> miss something?

assigned it directly. Can be done

> 
>> +	if (IS_ERR(ras->info[severity]))
>> +		return PTR_ERR(ras->info[severity]);
>> +
>> +	switch (severity) {
>> +	case DRM_XE_RAS_ERROR_CORRECTABLE:
>> +		node->query_error_counter = query_correctable_error_counters;
>> +		break;
>> +	case DRM_XE_RAS_ERROR_NONFATAL:
>> +		node->query_error_counter = query_non_fatal_error_counters;
>> +		break;
>> +	case DRM_XE_RAS_ERROR_FATAL:
>> +		node->query_error_counter = query_fatal_error_counters;
>> +		break;
>> +	default:
> 
> Do we need this?

yes.

> 
>> +		break;
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>> +static int register_nodes(struct xe_device *xe)
>> +{
>> +	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
>> +	struct xe_drm_ras *ras = &xe->ras;
>> +	const char *device_name;
>> +	int i = 0, ret;
> 
> Redundant initialization. Also, ret belongs to the loop below.
> 
>> +	device_name = kasprintf(GFP_KERNEL, "%04x:%02x:%02x.%d",
>> +				pci_domain_nr(pdev->bus), pdev->bus->number,
>> +				PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
>> +
>> +	for (i = 0; i < DRM_XE_RAS_ERROR_SEVERITY_MAX; i++) {
> 
> We could potentially have a nice for_each_error_severity() now ;)

Sure. Will check. If its used in multiple places then its worth having a 
helper

> 
>> +		struct drm_ras_node *node = &ras->node[i];
>> +
>> +		node->device_name = device_name;
>> +		node->node_name = error_severity[i];
>> +		node->type = DRM_RAS_NODE_TYPE_ERROR_COUNTER;
>> +		node->priv = xe;
>> +
>> +		ret = assign_node_params(xe, node, i);
>> +		if (ret)
>> +			return ret;
>> +
>> +		ret = drm_ras_node_register(node);
>> +		if (ret) {
>> +			drm_err(&xe->drm, "Failed to register drm ras tile node\n");
>> +			return ret;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
> 
> ...
> 
>> +int xe_drm_ras_allocate_nodes(struct xe_device *xe)
>> +{
>> +	struct xe_drm_ras *ras = &xe->ras;
>> +	struct drm_ras_node *node;
>> +	int err;
>> +
>> +	node = drmm_kzalloc(&xe->drm, DRM_XE_RAS_ERROR_SEVERITY_MAX * sizeof(struct drm_ras_node),
>> +			    GFP_KERNEL);
> 
> Ditto for drmm_kcalloc().
> 
>> +	if (!node)
>> +		return -ENOMEM;
>> +
>> +	ras->node = node;
>> +
>> +	err = register_nodes(xe);
>> +	if (err) {
>> +		drm_err(&xe->drm, "Failed to register drm ras node\n");
> 
> You wanted to call drm_err_probe(), didn't you ...?
> 
> Ah, not upstream yet :(
> But perhaps an opportunity worth considering.
> 
>> +		return err;
>> +	}
>> +
>> +	err = devm_add_action_or_reset(xe->drm.dev, xe_drm_ras_unregister_nodes, xe);
>> +	if (err) {
>> +		drm_err(&xe->drm, "Failed to add action for xe drm_ras\n");
> 
> Ditto.
> 
>> +		return err;
>> +	}
>> +
>> +	return 0;
> 
> ...
> 
>> +/**
>> + * struct xe_drm_ras_counter - xe ras counter
>> + *
>> + * This structure contains error class and counter information
>> + */
>> +struct xe_drm_ras_counter {
>> +	/** @name: error class name */
>> +	const char *name;
>> +	/** @counter: count of error */
>> +	atomic64_t counter;
>> +};
>> +
>> +/**
>> + * struct xe_drm_ras - xe drm ras structure
>> + *
>> + * This structure has details of error counters
>> + */
>> +struct xe_drm_ras {
>> +	/** @node: DRM RAS node */
>> +	struct drm_ras_node *node;
>> +
>> +	/** @info: info array for all types of errors */
>> +	struct xe_drm_ras_counter *info[DRM_XE_RAS_ERROR_SEVERITY_MAX];
>> +
>> +};
> 
> Either separate the members with blank lines or don't, but let's be
> consistent.

Will fix

> 
> ...
> 
>>   void xe_hw_error_irq_handler(struct xe_tile *tile, const u32 master_ctl)
>>   {
>> -	enum hardware_error hw_err;
>> +	u32 hw_err;
>>   
>>   	if (fault_inject_csc_hw_error())
>>   		schedule_work(&tile->csc_hw_error_work);
>>   
>> -	for (hw_err = 0; hw_err < HARDWARE_ERROR_MAX; hw_err++)
>> +	for (hw_err = 0; hw_err < DRM_XE_RAS_ERROR_SEVERITY_MAX; hw_err++)
> 
> for_each_error_severity()
> 
>>   		if (master_ctl & ERROR_IRQ(hw_err))
>>   			hw_error_source_handler(tile, hw_err);
>>   }
> 
> ...
> 
>> +/**
>> + * enum drm_xe_ras_error_severity - Supported drm ras error severity.
>> + */
>> +enum drm_xe_ras_error_severity {
>> +	/** @DRM_XE_RAS_ERROR_CORRECTABLE: Correctable Error */
>> +	DRM_XE_RAS_ERROR_CORRECTABLE = 0,
>> +	/** @DRM_XE_RAS_ERROR_NONFATAL: Non fatal Error */
>> +	DRM_XE_RAS_ERROR_NONFATAL,
>> +	/** @DRM_XE_RAS_ERROR_FATAL: Fatal error */
>> +	DRM_XE_RAS_ERROR_FATAL,
>> +	/** @DRM_XE_RAS_ERROR_SEVERITY_MAX: Max severity */
>> +	DRM_XE_RAS_ERROR_SEVERITY_MAX, /* non-ABI */
> 
> This is guaranteed last member, so redundant comma.

ok

> 
>> +};
>> +
>> +/**
>> + * enum drm_xe_ras_error_class - Supported drm ras error classes.
>> + */
>> +enum drm_xe_ras_error_class {
>> +	/** @DRM_XE_RAS_ERROR_CORE_COMPUTE: GT and Media Error */
>> +	DRM_XE_RAS_ERROR_CORE_COMPUTE = 1,
>> +	/** @DRM_XE_RAS_ERROR_SOC_INTERNAL: SOC Error */
>> +	DRM_XE_RAS_ERROR_SOC_INTERNAL,
>> +	/** @DRM_XE_RAS_ERROR_CLASS_MAX: Max Error */
>> +	DRM_XE_RAS_ERROR_CLASS_MAX,	/* non-ABI */
> 
> Ditto.
> 
>> +};
> 
> Also, all of the enums share the same DRM_XE_RAS_ERROR_* prefix, so let's try
> to have distinguishable naming. Perhaps [*] would be useful here as well ;)

DRM_XE_RAS_ERROR_SEVERITY_* will cause longer names. Any suggestions?

Thanks
Riana

> 
> Raag


  reply	other threads:[~2026-01-09  8:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-05  8:39 [PATCH v3 0/4] Introduce DRM_RAS using generic netlink for RAS Riana Tauro
2025-12-05  8:39 ` [PATCH v3 1/4] drm/ras: Introduce the DRM RAS infrastructure over generic netlink Riana Tauro
2025-12-09 21:35   ` Rodrigo Vivi
2026-01-08 22:36     ` Zack McKevitt
2026-01-09 20:57       ` Rodrigo Vivi
2026-01-13  8:20         ` Riana Tauro
2026-01-15 23:39           ` Zack McKevitt
2026-01-16  5:56             ` Riana Tauro
2026-01-16 20:26               ` Rodrigo Vivi
2025-12-05  8:39 ` [PATCH v3 2/4] drm/xe/xe_drm_ras: Add support for drm ras Riana Tauro
2025-12-09  8:22   ` Raag Jadav
2026-01-09  8:08     ` Riana Tauro [this message]
2026-01-09 14:13       ` Rodrigo Vivi
2026-01-09 15:58         ` Raag Jadav
2026-01-12  6:13           ` Riana Tauro
2026-01-12 10:27             ` Raag Jadav
2025-12-09 21:57   ` Rodrigo Vivi
2026-01-07  9:48     ` Aravind Iddamsetty
2025-12-05  8:39 ` [PATCH v3 3/4] drm/xe/xe_hw_error: Add support for GT hardware errors Riana Tauro
2025-12-10 18:18   ` Raag Jadav
2026-01-12  3:41     ` Riana Tauro
2026-01-12 10:02       ` Raag Jadav
2025-12-05  8:39 ` [PATCH v3 4/4] drm/xe/xe_hw_error: Add support for PVC SOC errors Riana Tauro
2025-12-15 10:52   ` Raag Jadav
2026-01-12  4:45     ` Riana Tauro
2026-01-12 10:06       ` Raag Jadav
2025-12-05  9:40 ` ✗ CI.checkpatch: warning for Introduce DRM_RAS using generic netlink for RAS (rev3) Patchwork
2025-12-05  9:41 ` ✓ CI.KUnit: success " Patchwork
2025-12-05  9:56 ` ✗ CI.checksparse: warning " Patchwork
2025-12-05 11:27 ` ✗ Xe.CI.Full: failure " Patchwork
2025-12-09 21:56 ` [PATCH v3 0/4] Introduce DRM_RAS using generic netlink for RAS Alex Deucher

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=ac78c819-51ce-4a6b-a5c8-1f327d1d8a7e@intel.com \
    --to=riana.tauro@intel.com \
    --cc=airlied@gmail.com \
    --cc=anshuman.gupta@intel.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=ashwin.kumar.kulkarni@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=joshua.santosh.ranjan@intel.com \
    --cc=pratik.bari@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=shubham.kumar@intel.com \
    --cc=simona.vetter@ffwll.ch \
    /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