linux-toradex.git/drivers/gpu/drm/drm_debugfs.c, branch v6.7-rc1

drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm

2023-09-25T23:51:28+00:00

Rename struct drm_gpuva_manager to struct drm_gpuvm including
corresponding functions. This way the GPUVA manager's structures align
very well with the documentation of VM_BIND [1] and VM_BIND locking [2].

It also provides a better foundation for the naming of data structures
and functions introduced for implementing a common dma-resv per GPU-VM
including tracking of external and evicted objects in subsequent
patches.

[1] Documentation/gpu/drm-vm-bind-async.rst
[2] Documentation/gpu/drm-vm-bind-locking.rst

Cc: Thomas Hellström 
Cc: Matthew Brost 
Acked-by: Dave Airlie 
Acked-by: Christian König 
Signed-off-by: Danilo Krummrich 
Link: https://patchwork.freedesktop.org/patch/msgid/20230920144343.64830-2-dakr@redhat.com

drm: Update file owner during use

2023-09-20T13:27:44+00:00

With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.

Fix it by updating the drm_file->pid on ioctl access from a different
process.

The field is also made RCU protected to allow for lockless readers. Update
side is protected with dev->filelist_mutex.

Before:

$ cat /sys/kernel/debug/dri/0/clients
             command   pid dev master a   uid      magic
                Xorg  2344   0   y    y     0          0
                Xorg  2344   0   n    y     0          2
                Xorg  2344   0   n    y     0          3
                Xorg  2344   0   n    y     0          4

After:

$ cat /sys/kernel/debug/dri/0/clients
             command  tgid dev master a   uid      magic
                Xorg   830   0   y    y     0          0
       xfce4-session   880   0   n    y     0          1
               xfwm4   943   0   n    y     0          2
           neverball  1095   0   n    y     0          3

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
The traditional model, the server was the orchestrator managing the
primary device node. From the fd, to the master status and
authentication. But looking at the fd alone, this has varied across
the years.

IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
fd(s) and reuse those whenever needed, DRI2 the client was responsible
for open() themselves and with DRI3 the fd was passed to the client.

Around the inception of DRI3 and systemd-logind, the latter became
another possible orchestrator. Whereby Xorg and Wayland compositors
could ask it for the fd. For various reasons (hysterical and genuine
ones) Xorg has a fallback path going the open(), whereas Wayland
compositors are moving to solely relying on logind... some never had
fallback even.

Over the past few years, more projects have emerged which provide
functionality similar (be that on API level, Dbus, or otherwise) to
systemd-logind.
"""

v2:
 * Fixed typo in commit text and added a fine historical explanation
   from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 
Reviewed-by: Rob Clark 
Tested-by: Rob Clark 
Link: https://patchwork.freedesktop.org/patch/msgid/20230621094824.2348732-1-tvrtko.ursulin@linux.intel.com
Signed-off-by: Christian König

drm/debugfs: rework drm_debugfs_create_files implementation v2

2023-09-01T06:54:12+00:00

Use managed memory allocation for this. That allows us to not keep
track of all the files any more.

v2: keep drm_debugfs_cleanup(), but rename to drm_debugfs_unregister(),
    we still need to cleanup the symlink

Signed-off-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-6-christian.koenig@amd.com
Reviewed-by: Andi Shyti

drm/debugfs: remove dev->debugfs_list and debugfs_mutex v2

2023-09-01T06:53:05+00:00

The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.

Completely drop that approach and just create the files directly but
return -ENODEV while opening the file when the minors are not
registered yet.

v2: rebase on debugfs directory rework, limit access before minors are
    registered.

Signed-off-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-5-christian.koenig@amd.com
Reviewed-by: Andi Shyti

drm/debugfs: rework debugfs directory creation v5

2023-09-01T06:51:18+00:00

Instead of the per minor directories only create a single debugfs
directory for the whole device directly when the device is initialized.

For DRM devices each minor gets a symlink to the per device directory
for now until we can be sure that this isn't useful any more in any way.

Accel devices create only the per device directory and also drops the mid
layer callback to create driver specific files.

v2: cleanup accel component as well
v3: fix typo when debugfs is disabled
v4: call drm_debugfs_dev_fini() during release as well,
    some kerneldoc typos fixed
v5: rebased and one more kerneldoc fix

Signed-off-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-4-christian.koenig@amd.com
Reviewed-by: Andi Shyti

drm/debugfs: disallow debugfs access when device isn't registered

2023-08-31T15:00:37+00:00

During device bringup it might be that we can't access the debugfs files.
Return -ENODEV until the registration is completed on access.

Signed-off-by: Christian König 
Reviewed-by: Andi Shyti 
Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-3-christian.koenig@amd.com

drm/debugfs: drop debugfs_init() for the render and accel node v2

2023-08-31T15:00:10+00:00

We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those in the mid layer callback.

v2: drop it for the accel node as well

Signed-off-by: Christian König 
Tested-by: Stanislaw Gruszka 
Reviewed-by: Andi Shyti 
Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-2-christian.koenig@amd.com

drm/bridge: Add debugfs print for bridge chains

2023-08-02T08:05:01+00:00

DRM bridges are not visible to the userspace and it may not be
immediately clear if the chain is somehow constructed incorrectly. I
have had two separate instances of a bridge driver failing to do a
drm_bridge_attach() call, resulting in the bridge connector not being
part of the chain. In some situations this doesn't seem to cause issues,
but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used.

Add a debugfs file to print the bridge chains. For me, on this TI AM62
based platform, I get the following output:

encoder[39]
	bridge[0] type: 0, ops: 0x0
	bridge[1] type: 0, ops: 0x0, OF: /bus@f0000/i2c@20000000/dsi@e:toshiba,tc358778
	bridge[2] type: 0, ops: 0x3, OF: /bus@f0000/i2c@20010000/hdmi@48:lontium,lt8912b
	bridge[3] type: 11, ops: 0x7, OF: /hdmi-connector:hdmi-connector

Tested-by: Alexander Stein 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
Acked-by: Neil Armstrong 
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20230802-drm-bridge-chain-debugfs-v4-1-7e3ae3d137c0@ideasonboard.com

drm: debugfs: Silence warning from cast

2023-07-20T21:43:14+00:00

Casting a pointer to an integer of a different size generates a warning
from the compiler. First cast the pointer to a pointer-sized type to
keep the compiler happy.

Fixes: 4f66feeab173 ("drm: debugfs: provide infrastructure to dump a DRM GPU VA space")
Reviewed-by: Danilo Krummrich 
Signed-off-by: Steven Price 
Signed-off-by: Danilo Krummrich 
Link: https://patchwork.freedesktop.org/patch/msgid/010b58cd-1225-02f7-33f0-c678e5cd349d@arm.com

drm: debugfs: provide infrastructure to dump a DRM GPU VA space

2023-07-20T03:16:21+00:00

This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.

Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spaces and a DRM core infrastructure, hence we need the
indirection via the driver iterating it's maintained DRM GPU VA spaces.

Reviewed-by: Boris Brezillon 
Signed-off-by: Danilo Krummrich 
Link: https://patchwork.freedesktop.org/patch/msgid/20230720001443.2380-3-dakr@redhat.com