Commit 941aae32 authored by Maíra Canal's avatar Maíra Canal Committed by Maíra Canal

drm/todo: update the debugfs clean up task

The structs drm_debugfs_info and drm_debugfs_entry introduced a new
debugfs structure to DRM, centered on drm_device instead of drm_minor.
Therefore, remove the tasks related to create a new device-centered
debugfs structure and add a new task to replace the use of
drm_debugfs_create_files() for the use of drm_debugfs_add_file() and
drm_debugfs_add_files().
Signed-off-by: default avatarMaíra Canal <mcanal@igalia.com>
Reviewed-by: default avatarMelissa Wen <mwen@igalia.com>
Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarMaíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20221219120621.15086-8-mcanal@igalia.com
parent 03d2673b
...@@ -508,17 +508,18 @@ Clean up the debugfs support ...@@ -508,17 +508,18 @@ Clean up the debugfs support
There's a bunch of issues with it: There's a bunch of issues with it:
- The drm_info_list ->show() function doesn't even bother to cast to the drm - Convert drivers to support the drm_debugfs_add_files() function instead of
structure for you. This is lazy. the drm_debugfs_create_files() function.
- Improve late-register debugfs by rolling out the same debugfs pre-register
infrastructure for connector and crtc too. That way, the drivers won't need to
split their setup code into init and register anymore.
- We probably want to have some support for debugfs files on crtc/connectors and - We probably want to have some support for debugfs files on crtc/connectors and
maybe other kms objects directly in core. There's even drm_print support in maybe other kms objects directly in core. There's even drm_print support in
the funcs for these objects to dump kms state, so it's all there. And then the the funcs for these objects to dump kms state, so it's all there. And then the
->show() functions should obviously give you a pointer to the right object. ->show() functions should obviously give you a pointer to the right object.
- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
anything we want to print drm_device (or maybe drm_file) is the right thing.
- The drm_driver->debugfs_init hooks we have is just an artifact of the old - The drm_driver->debugfs_init hooks we have is just an artifact of the old
midlayered load sequence. DRM debugfs should work more like sysfs, where you midlayered load sequence. DRM debugfs should work more like sysfs, where you
can create properties/files for an object anytime you want, and the core can create properties/files for an object anytime you want, and the core
...@@ -527,8 +528,6 @@ There's a bunch of issues with it: ...@@ -527,8 +528,6 @@ There's a bunch of issues with it:
this (together with the drm_minor->drm_device move) would allow us to remove this (together with the drm_minor->drm_device move) would allow us to remove
debugfs_init. debugfs_init.
Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/
Contact: Daniel Vetter Contact: Daniel Vetter
Level: Intermediate Level: Intermediate
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment