[PATCH] drm/debugfs: add client-id to the debugfs entry

Khatri, Sunil sukhatri at amd.com
Wed May 28 13:24:54 UTC 2025


Sure Pierre

Go ahead and get them merged. I am also planning to use that information 
in debugfs implementation of some parameters of our driver so I do need 
those. I will drop my debugfs patch.

Regards
Sunil Khatri

On 5/28/2025 6:32 PM, Christian König wrote:
> On 5/28/25 14:33, Pierre-Eric Pelloux-Prayer wrote:
>> Hi,
>>
>> This patch looks similar to:
>> https://lists.freedesktop.org/archives/dri-devel/2025-May/507653.html
> Mhm, I thought that I have seen that before.
>
> Why haven't we pushed that yet? Is there still some ongoing reviews on the scheduler side?
>
> Regards,
> Christian.
>
>> Thanks,
>> Pierre-Eric
>>
>> Le 28/05/2025 à 13:00, Christian König a écrit :
>>> Adding some people who worked on the client name and client id fields.
>>>
>>> On 5/28/25 09:22, Sunil Khatri wrote:
>>>> pid is not always the right choice for fd to track
>>>> the caller and hence adding drm client-id to the
>>>> print which is unique for a drm client and can be
>>>> used by driver in debugging
>>>>
>>>> One of the use is to further enhance debugging for
>>>> amdgpu driver based on client-id.
>>>>
>>>> Signed-off-by: Sunil Khatri<sunil.khatri at amd.com>
>>>> ---
>>>>    drivers/gpu/drm/drm_debugfs.c | 9 +++++----
>>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
>>>> index 6b2178864c7e..2d43bda82887 100644
>>>> --- a/drivers/gpu/drm/drm_debugfs.c
>>>> +++ b/drivers/gpu/drm/drm_debugfs.c
>>>> @@ -77,14 +77,15 @@ static int drm_clients_info(struct seq_file *m, void *data)
>>>>        kuid_t uid;
>>>>          seq_printf(m,
>>>> -           "%20s %5s %3s master a %5s %10s %*s\n",
>>>> +           "%20s %5s %3s master a %5s %10s %*s %5s\n",
>>>>               "command",
>>>>               "tgid",
>>>>               "dev",
>>>>               "uid",
>>>>               "magic",
>>>>               DRM_CLIENT_NAME_MAX_LEN,
>>>> -           "name");
>>>> +           "name",
>>>> +           "client-id");
>>> It might make sense to print the client id first and then the name.
>>>
>>> Apart from that looks sane to me.
>>>
>>> Regards,
>>> Christian.
>>>
>>>>          /* dev->filelist is sorted youngest first, but we want to present
>>>>         * oldest first (i.e. kernel, servers, clients), so walk backwardss.
>>>> @@ -100,7 +101,7 @@ static int drm_clients_info(struct seq_file *m, void *data)
>>>>            pid = rcu_dereference(priv->pid);
>>>>            task = pid_task(pid, PIDTYPE_TGID);
>>>>            uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
>>>> -        seq_printf(m, "%20s %5d %3d   %c    %c %5d %10u %*s\n",
>>>> +        seq_printf(m, "%20s %5d %3d   %c    %c %5d %10u %*s %5llu\n",
>>>>                   task ? task->comm : "<unknown>",
>>>>                   pid_vnr(pid),
>>>>                   priv->minor->index,
>>>> @@ -109,7 +110,7 @@ static int drm_clients_info(struct seq_file *m, void *data)
>>>>                   from_kuid_munged(seq_user_ns(m), uid),
>>>>                   priv->magic,
>>>>                   DRM_CLIENT_NAME_MAX_LEN,
>>>> -               priv->client_name ? priv->client_name : "<unset>");
>>>> +               priv->client_name ? priv->client_name : "<unset>", priv->client_id);
>>>>            rcu_read_unlock();
>>>>            mutex_unlock(&priv->client_name_lock);
>>>>        }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250528/07828169/attachment-0001.htm>


More information about the dri-devel mailing list