<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div dir="auto">Yeah, that should work as well.
<div dir="auto"><br>
</div>
<div dir="auto">The extra text is a bit questionable, but I think we can live with that as well.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Christian.</div>
</div>
<div class="x_gmail_extra"><br>
<div class="x_gmail_quote">Am 08.08.2019 17:48 schrieb "Zhang, Hawking" <Hawking.Zhang@amd.com>:<br type="attribution">
</div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">Not exactly, there will be only one line left<br>
feature mask: 0x3ffb<br>
<br>
Regards,<br>
Hawking<br>
-----Original Message-----<br>
From: Freehill, Chris <Chris.Freehill@amd.com> <br>
Sent: 2019年8月8日 23:28<br>
To: Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; Russell, Kent <Kent.Russell@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; amd-gfx@lists.freedesktop.org; Pan, Xinhui <Xinhui.Pan@amd.com><br>
Subject: RE: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
<br>
Hi Hawking,<br>
<br>
I don't want to divert from this important discussion, but would like clarification...<br>
<br>
In the rocm-smi library, I previously had this interpretation of the values (I think someone had confirmed this):<br>
none,   //!< No current errors<br>
disabled   //!< ECC is disabled<br>
parity     //!< ECC errors present, but type unknown<br>
 single_correctable,     //!< Single correctable error<br>
multi_correctable    //!< Multiple uncorrectable errors<br>
poison     //!< Firmware detected error and isolated<br>
                                 //!< page. Treat as uncorrectable.<br>
<br>
It seems now we are just saying it's enabled/disabled, but no indication of whether there are errors or not. Is that right, or am I misunderstanding something?<br>
<br>
Chris<br>
<br>
-----Original Message-----<br>
From: Koenig, Christian <Christian.Koenig@amd.com><br>
Sent: Thursday, August 8, 2019 10:24 AM<br>
To: Zhang, Hawking <Hawking.Zhang@amd.com>; Russell, Kent <Kent.Russell@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; amd-gfx@lists.freedesktop.org; Pan, Xinhui <Xinhui.Pan@amd.com>; Freehill, Chris <Chris.Freehill@amd.com><br>
Subject: Re: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
<br>
Hi Hawking,<br>
<br>
yeah, but this isn't sufficient to comply to the upstream rules.<br>
<br>
See what we need to do is to remove the extra text and the per IP information. In other words something like this:<br>
<br>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
index 1a4412e47810..c8c7f9655ffc 100644<br>
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
@@ -819,22 +819,7 @@ static ssize_t<br>
amdgpu_ras_sysfs_features_read(struct device *dev,<br>
         ssize_t s;<br>
         struct ras_manager *obj;<br>
<br>
-       s = scnprintf(buf, PAGE_SIZE, "feature mask: 0x%x\n", <br>
con->features);<br>
-<br>
-       for (i = 0; i < ras_block_count; i++) {<br>
-               head.block = i;<br>
-<br>
-               if (amdgpu_ras_is_feature_enabled(adev, &head)) {<br>
-                       obj = amdgpu_ras_find_obj(adev, &head);<br>
-                       s += scnprintf(&buf[s], PAGE_SIZE - s,<br>
-                                       "%s: %s\n",<br>
-                                       ras_block_str(i),<br>
- ras_err_str(obj->head.type));<br>
-               } else<br>
-                       s += scnprintf(&buf[s], PAGE_SIZE - s,<br>
-                                       "%s: disabled\n",<br>
-                                       ras_block_str(i));<br>
-       }<br>
+       s = scnprintf(buf, PAGE_SIZE, "0x%x\n", con->features);<br>
<br>
         return s;<br>
  }<br>
<br>
And I'm not talking about some rule we could bend. This is an absolutely<br>
*MUST* have for upstreaming.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 08.08.19 um 17:17 schrieb Zhang, Hawking:<br>
> Hi Chris,<br>
><br>
> I thought I've stated as "The feature mask is already good enough for this node". It is just a uint32 value. We don't expect ROCm SMI to read any other information from feature node except for the feature mask.<br>
><br>
> Regards,<br>
> Hawking<br>
><br>
> -----Original Message-----<br>
> From: Koenig, Christian <Christian.Koenig@amd.com><br>
> Sent: 2019年8月8日 23:11<br>
> To: Zhang, Hawking <Hawking.Zhang@amd.com>; Russell, Kent <br>
> <Kent.Russell@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; <br>
> amd-gfx@lists.freedesktop.org; Pan, Xinhui <Xinhui.Pan@amd.com>; <br>
> Freehill, Chris <Chris.Freehill@amd.com><br>
> Subject: Re: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
><br>
> Hi Hawking,<br>
><br>
> a multi line value is not the problem, but here you have multiple values.<br>
><br>
> E.g. in the case of the pp tables that is one big array of power profiles and we actually had a discussion if exposing them like this is ok or not.<br>
><br>
> But in the case of the ras features you got multiple different things in the same file. And that in turn is a clear violation of the sysfs rules.<br>
><br>
> I don't think we can't upstream the interface like this. See here for <br>
> a good summary of the rules as well: <a href="https://lwn.net/Articles/378884/">
https://lwn.net/Articles/378884/</a><br>
><br>
> Regards,<br>
> Christian.<br>
><br>
> Am 08.08.19 um 17:00 schrieb Zhang, Hawking:<br>
>> Hi Chris,<br>
>><br>
>> I'm not aware of how ROCM SMI using feature nodes. but not all the sysfs are intended to be used by upper level apps/libs.<br>
>><br>
>> There are bunches of sysfs entries that have multiple line value. The most complicate one would be pp_power_profile_mode, which looks like.<br>
>><br>
>> 0 BOOTUP_DEFAULT*:<br>
>>                       0(       GFXCLK)       0       0       1       0       4     800 4587520  -65536       0<br>
>>                       1(       SOCCLK)       0       0       1       0       4     800  327680   -6553       0<br>
>>                       2(         UCLK)       0       0       1       0       4     800  327680  -65536       0<br>
>> .......<br>
>> 1 3D_FULL_SCREEN :<br>
>>                       0(       GFXCLK)       0       1       1       0       4     800 4587520  -65536       0<br>
>>                       1(       SOCCLK)       0       1       4     850       4     800  327680  -65536       0<br>
>><br>
>> Regards,<br>
>> Hawking<br>
>> -----Original Message-----<br>
>> From: Christian König <ckoenig.leichtzumerken@gmail.com><br>
>> Sent: 2019年8月8日 22:25<br>
>> To: Zhang, Hawking <Hawking.Zhang@amd.com>; Russell, Kent <br>
>> <Kent.Russell@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; <br>
>> amd-gfx@lists.freedesktop.org; Pan, Xinhui <Xinhui.Pan@amd.com>; <br>
>> Freehill, Chris <Chris.Freehill@amd.com><br>
>> Subject: Re: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
>><br>
>> Hi Hawking,<br>
>><br>
>> looks like you skipped my response.<br>
>><br>
>> Even the current way how sysfs is used in the ras code is a clear NO-GO and should be fixed before this is pushed upstream.<br>
>><br>
>> A sysfs entry should seriously NOT return a multi line value which needs to be extensively parsed by the application.<br>
>><br>
>> Regards,<br>
>> Christian.<br>
>><br>
>> Am 08.08.19 um 15:50 schrieb Zhang, Hawking:<br>
>>> Understood and agree we should keep stable interfaces.<br>
>>><br>
>>> But the information in feature node is not correct and makes people confusing. Basically, each IP blocks can support all the four error types, not just multi-uncorrectable. As a result, any upper level apps/libs that read from this file will just get confusing
 information as well. The feature mask is already good enough for this node.<br>
>>><br>
>>> Regards,<br>
>>> Hawking<br>
>>> -----Original Message-----<br>
>>> From: Russell, Kent <Kent.Russell@amd.com><br>
>>> Sent: 2019年8月8日 20:51<br>
>>> To: Zhang, Hawking <Hawking.Zhang@amd.com>; Zhou1, Tao <br>
>>> <Tao.Zhou1@amd.com>; amd-gfx@lists.freedesktop.org; Pan, Xinhui <br>
>>> <Xinhui.Pan@amd.com>; Freehill, Chris <Chris.Freehill@amd.com><br>
>>> Cc: Zhou1, Tao <Tao.Zhou1@amd.com><br>
>>> Subject: RE: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
>>><br>
>>> +Chris Freehill<br>
>>><br>
>>> While I can understand this change, this broke our SMI interface, which was expecting a specific string format for the ras/features file. This has happened a few times now, where changes to the RAS sysfs files has broke the SMI CLI and/or SMI LIB. Can we
 please get a stable interface and sysfs format set up before publishing patches? This is creating a lot of extra work for developers with the SMI to constantly keep up with the changes being made to sysfs files. Thank you.<br>
>>><br>
>>>     Kent<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of <br>
>>> Zhang, Hawking<br>
>>> Sent: Monday, August 5, 2019 4:15 AM<br>
>>> To: Zhou1, Tao <Tao.Zhou1@amd.com>; amd-gfx@lists.freedesktop.org; <br>
>>> Pan, Xinhui <Xinhui.Pan@amd.com><br>
>>> Cc: Zhou1, Tao <Tao.Zhou1@amd.com><br>
>>> Subject: RE: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
>>><br>
>>> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com><br>
>>><br>
>>> Regards,<br>
>>> Hawking<br>
>>> -----Original Message-----<br>
>>> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of <br>
>>> Tao Zhou<br>
>>> Sent: 2019年8月5日 16:04<br>
>>> To: amd-gfx@lists.freedesktop.org; Pan, Xinhui <Xinhui.Pan@amd.com>; <br>
>>> Zhang, Hawking <Hawking.Zhang@amd.com><br>
>>> Cc: Zhou1, Tao <Tao.Zhou1@amd.com><br>
>>> Subject: [PATCH] drm/amdgpu: update ras sysfs feature info<br>
>>><br>
>>> remove confused ras error type info<br>
>>><br>
>>> Signed-off-by: Tao Zhou <tao.zhou1@amd.com><br>
>>> ---<br>
>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 17 +++++------------<br>
>>>     1 file changed, 5 insertions(+), 12 deletions(-)<br>
>>><br>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
>>> index d2e8a85f6e38..369651247b23 100644<br>
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c<br>
>>> @@ -787,25 +787,18 @@ static ssize_t amdgpu_ras_sysfs_features_read(struct device *dev,<br>
>>>      struct amdgpu_device *adev = ddev->dev_private;<br>
>>>      struct ras_common_if head;<br>
>>>      int ras_block_count = AMDGPU_RAS_BLOCK_COUNT;<br>
>>> -   int i;<br>
>>> +   int i, enabled;<br>
>>>      ssize_t s;<br>
>>> -   struct ras_manager *obj;<br>
>>>     <br>
>>>      s = scnprintf(buf, PAGE_SIZE, "feature mask: 0x%x\n",<br>
>>> con->features);<br>
>>>     <br>
>>>      for (i = 0; i < ras_block_count; i++) {<br>
>>>              head.block = i;<br>
>>> +           enabled = amdgpu_ras_is_feature_enabled(adev, &head);<br>
>>>     <br>
>>> -           if (amdgpu_ras_is_feature_enabled(adev, &head)) {<br>
>>> -                   obj = amdgpu_ras_find_obj(adev, &head);<br>
>>> -                   s += scnprintf(&buf[s], PAGE_SIZE - s,<br>
>>> -                                   "%s: %s\n",<br>
>>> -                                   ras_block_str(i),<br>
>>> -                                   ras_err_str(obj->head.type));<br>
>>> -           } else<br>
>>> -                   s += scnprintf(&buf[s], PAGE_SIZE - s,<br>
>>> -                                   "%s: disabled\n",<br>
>>> -                                   ras_block_str(i));<br>
>>> +           s += scnprintf(&buf[s], PAGE_SIZE - s,<br>
>>> +                           "%s ras feature mask: %s\n",<br>
>>> +                           ras_block_str(i), enabled?"on":"off");<br>
>>>      }<br>
>>>     <br>
>>>      return s;<br>
<br>
</div>
</span></font>
</body>
</html>