dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Tomer Tayar <ttayar@habana.ai>
To: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"alexander.deucher@amd.com" <alexander.deucher@amd.com>,
	"airlied@gmail.com" <airlied@gmail.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"joonas.lahtinen@linux.intel.com"
	<joonas.lahtinen@linux.intel.com>,
	"ogabbay@kernel.org" <ogabbay@kernel.org>,
	"Hawking.Zhang@amd.com" <Hawking.Zhang@amd.com>,
	"Harish.Kasiviswanathan@amd.com" <Harish.Kasiviswanathan@amd.com>,
	"Felix.Kuehling@amd.com" <Felix.Kuehling@amd.com>,
	"Luben.Tuikov@amd.com" <Luben.Tuikov@amd.com>,
	"Ruhl, Michael J" <michael.j.ruhl@intel.com>
Subject: Re: [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an error
Date: Sun, 12 Nov 2023 15:28:46 +0000	[thread overview]
Message-ID: <e58e5753-d501-4a5a-86be-4cdebc31a287@habana.ai> (raw)
In-Reply-To: <825661de-922f-459e-b667-b95aa0df7f46@habana.ai>

On 10/11/2023 14:27, Tomer Tayar wrote:
> On 20/10/2023 18:58, Aravind Iddamsetty wrote:
>> Whenever a correctable or an uncorrectable error happens an event is sent
>> to the corresponding listeners of these groups.
>>
>> v2: Rebase
>>
>> Signed-off-by: Aravind Iddamsetty<aravind.iddamsetty@linux.intel.com>
>> ---
>>    drivers/gpu/drm/xe/xe_hw_error.c | 33 ++++++++++++++++++++++++++++++++
>>    1 file changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_hw_error.c b/drivers/gpu/drm/xe/xe_hw_error.c
>> index bab6d4cf0b69..b0befb5e01cb 100644
>> --- a/drivers/gpu/drm/xe/xe_hw_error.c
>> +++ b/drivers/gpu/drm/xe/xe_hw_error.c
>> @@ -786,6 +786,37 @@ xe_soc_hw_error_handler(struct xe_tile *tile, const enum hardware_error hw_err)
>>    				(HARDWARE_ERROR_MAX << 1) + 1);
>>    }
>>    
>> +static void
>> +generate_netlink_event(struct xe_device *xe, const enum hardware_error hw_err)
>> +{
>> +	struct sk_buff *msg;
>> +	void *hdr;
>> +
>> +	if (!xe->drm.drm_genl_family.module)
>> +		return;
>> +
>> +	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
>> +	if (!msg) {
>> +		drm_dbg_driver(&xe->drm, "couldn't allocate memory for error multicast event\n");
>> +		return;
>> +	}
>> +
>> +	hdr = genlmsg_put(msg, 0, 0, &xe->drm.drm_genl_family, 0, DRM_RAS_CMD_ERROR_EVENT);
>> +	if (!hdr) {
>> +		drm_dbg_driver(&xe->drm, "mutlicast msg buffer is small\n");
>> +		nlmsg_free(msg);
>> +		return;
>> +	}
>> +
>> +	genlmsg_end(msg, hdr);
>> +
>> +	genlmsg_multicast(&xe->drm.drm_genl_family, msg, 0,
>> +			  hw_err ?
>> +			  DRM_GENL_MCAST_UNCORR_ERR
>> +			  : DRM_GENL_MCAST_CORR_ERR,
>> +			  GFP_ATOMIC);
> I agree that hiding/wrapping any netlink/genetlink API/macro with a DRM
> helper would be sometimes redundant,
> and that in some cases the specific DRM driver would have to "dirt its
> hands" and deal with netlink (e.g. fill_error_details() in patch #3).
> However maybe here a DRM helper would have been useful, so we won't see
> a copy of this sequence in other DRM drivers?
>
> Thanks,
> Tomer

After rethinking, it is possible that different DRM drivers will need 
some flexibility when it comes to calling genlmsg_put(), as they might 
want to have more of this call in order to attach some data related to 
the error indication.
In that case, adding a DRM function that wraps it may me redundant.
What do you think?

>> +}
>> +
>>    static void
>>    xe_hw_error_source_handler(struct xe_tile *tile, const enum hardware_error hw_err)
>>    {
>> @@ -849,6 +880,8 @@ xe_hw_error_source_handler(struct xe_tile *tile, const enum hardware_error hw_er
>>    	}
>>    
>>    	xe_mmio_write32(gt, DEV_ERR_STAT_REG(hw_err), errsrc);
>> +
>> +	generate_netlink_event(tile_to_xe(tile), hw_err);
>>    unlock:
>>    	spin_unlock_irqrestore(&tile_to_xe(tile)->irq.lock, flags);
>>    }
>


  reply	other threads:[~2023-11-12 15:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 15:58 [RFC v4 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem Aravind Iddamsetty
2023-10-20 15:58 ` [RFC v4 1/5] drm/netlink: Add netlink infrastructure Aravind Iddamsetty
2023-10-20 20:36   ` Ruhl, Michael J
2023-10-21  1:10     ` Aravind Iddamsetty
2023-11-10 12:24   ` Tomer Tayar
2023-11-22 14:32     ` Aravind Iddamsetty
2023-11-23  7:26       ` Tomer Tayar
2023-10-20 15:58 ` [RFC v2 2/5] drm/xe/RAS: Register netlink capability Aravind Iddamsetty
2023-10-20 20:37   ` Ruhl, Michael J
2023-10-20 15:58 ` [RFC v3 3/5] drm/xe/RAS: Expose the error counters Aravind Iddamsetty
2023-10-20 20:39   ` Ruhl, Michael J
2023-11-10 12:27   ` Tomer Tayar
2023-11-22 14:33     ` Aravind Iddamsetty
2023-10-20 15:58 ` [RFC 4/5] drm/netlink: Define multicast groups Aravind Iddamsetty
2023-10-20 20:39   ` Ruhl, Michael J
2023-10-20 15:58 ` [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an error Aravind Iddamsetty
2023-10-20 20:40   ` Ruhl, Michael J
2023-11-10 12:27   ` Tomer Tayar
2023-11-12 15:28     ` Tomer Tayar [this message]
2023-11-22 14:34       ` Aravind Iddamsetty
2023-10-23 15:29 ` [RFC v4 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem Alex Deucher
2023-10-24  8:59   ` Zhang, Hawking
2023-10-26  9:27     ` Aravind Iddamsetty
2023-10-26 10:04   ` Lazar, Lijo
2023-10-30  6:19     ` Aravind Iddamsetty
2023-10-30 15:11       ` Lazar, Lijo
2023-11-01  8:06         ` Aravind Iddamsetty
2023-11-07  5:30           ` Lazar, Lijo
2023-11-08  9:24             ` Aravind Iddamsetty
2023-11-10 12:23 ` Tomer Tayar
2023-11-22 14:28   ` Aravind Iddamsetty
  -- strict thread matches above, loose matches on Subject: below --
2023-10-08  9:26 [RFC v3 " Aravind Iddamsetty
2023-10-08  9:26 ` [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an error Aravind Iddamsetty
2023-08-25 11:55 [RFC v2 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem Aravind Iddamsetty
2023-08-25 11:55 ` [RFC v2 5/5] drm/xe/RAS: send multicast event on occurrence of an error Aravind Iddamsetty

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=e58e5753-d501-4a5a-86be-4cdebc31a287@habana.ai \
    --to=ttayar@habana.ai \
    --cc=Felix.Kuehling@amd.com \
    --cc=Harish.Kasiviswanathan@amd.com \
    --cc=Hawking.Zhang@amd.com \
    --cc=Luben.Tuikov@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=ogabbay@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).