linux/drivers/gpu/drm/drm_debugfs.c, branch v6.12

drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes

2024-09-24T14:10:12Z

The largest infoframe we create is the DRM (Dynamic Range Mastering) infoframe which is 26 bytes + a 4 byte header, for a total of 30 bytes. With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we allocate too little space to pack a DRM infoframe in write_device_infoframe(), leading to an ENOSPC return from hdmi_infoframe_pack(), and never calling the connector's write_infoframe() vfunc. Instead of having HDMI_MAX_INFOFRAME_SIZE defined in two places, replace HDMI_MAX_INFOFRAME_SIZE with HDMI_INFOFRAME_SIZE(MAX) and make MAX 27 bytes - which is defined by the HDMI specification to be the largest infoframe payload. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Fixes: c602e4959a0c ("drm/connector: hdmi: Create Infoframe DebugFS entries") Signed-off-by: Derek Foreman Acked-by: Maxime Ripard Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240827163918.48160-1-derek.foreman@collabora.com Signed-off-by: Maxime Ripard

drm/bridge-connector: implement glue code for HDMI connector

2024-06-12T07:56:57Z

In order to let bridge chains implement HDMI connector infrastructure, add necessary glue code to the drm_bridge_connector. In case there is a bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs implementation. Note, to simplify implementation, there can be only one bridge in a chain that sets DRM_BRIDGE_OP_HDMI. Setting more than one is considered an error. This limitation can be lifted later, if the need arises. Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240607-bridge-hdmi-connector-v5-3-ab384e6021af@linaro.org Signed-off-by: Dmitry Baryshkov

drm/connector: hdmi: Create Infoframe DebugFS entries

2024-05-28T08:24:41Z

There has been some discussions recently about the infoframes sent by drivers and if they were properly generated. In parallel, there's been some interest in creating an infoframe-decode tool similar to edid-decode. Both would be much easier if we were to expose the infoframes programmed in the hardware. It won't be perfect since we have no guarantee that it's actually what goes through the wire, but it's the best we can do. Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-24-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard

drm/debugfs: Drop conditionals around of_node pointers

2024-05-01T16:06:46Z

Having conditional around the of_node pointer of the drm_bridge structure is not necessary anymore, since drm_bridge structure always has the of_node member since the commit d8dfccde2709 ("drm/bridge: Drop conditionals around of_node pointers"). So drop the conditional, please also note that this patch is following the convention used by driver core, see commit c9e358dfc4a8 ("driver-core: remove conditionals around devicetree pointers"). Reviewed-by: Dmitry Baryshkov Signed-off-by: Sui Jingfeng Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20240501051323.805076-1-sui.jingfeng@linux.dev

drm/debugfs: drop unneeded DEBUG_FS guard

2024-01-02T13:50:13Z

The Makefile enables/disables the file compilation depending on CONFIG_DEBUG_FS. Signed-off-by: Dario Binacchi Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20231223183301.78332-1-dario.binacchi@amarulasolutions.com

drm/debugfs: fix potential NULL pointer dereference

2023-12-07T10:29:17Z

encoder->funcs entry might be NULL, so check it first before calling its methods. This fixes NULL pointer dereference observed on Rasberry Pi 3b/4b boards. Fixes: caf525ed45b4 ("drm/encoder: register per-encoder debugfs dir") Signed-off-by: Marek Szyprowski Tested-by: Nishanth Menon Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20231205130631.3456986-1-m.szyprowski@samsung.com

drm/bridge: migrate bridge_chains to per-encoder file

2023-12-04T14:07:29Z

Instead of having a single file with all bridge chains, list bridges under a corresponding per-encoder debugfs directory. While we are at it, also slightly improve the formatting of the bridge data: split a single line entry into multiple lines, include the symbol name of the bridge funcs and add the textual representation of the bridge ops. Example of the listing: $ cat /sys/kernel/debug/dri/0/encoder-0/bridges bridge[0]: dsi_mgr_bridge_funcs type: [0] Unknown ops: [0] bridge[1]: lt9611uxc_bridge_funcs type: [11] HDMI-A OF: /soc@0/geniqup@9c0000/i2c@994000/hdmi-bridge@2b:lontium,lt9611uxc ops: [7] detect edid hpd Reviewed-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20231203115315.1306124-3-dmitry.baryshkov@linaro.org

drm/encoder: register per-encoder debugfs dir

2023-12-04T14:07:29Z

Each of connectors and CRTCs used by the DRM device provides debugfs directory, which is used by several standard debugfs files and can further be extended by the driver. Add such generic debugfs directories for encoder. Reviewed-by: Neil Armstrong Acked-by: Maxime Ripard Signed-off-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20231203115315.1306124-2-dmitry.baryshkov@linaro.org

drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm

2023-09-25T23:51:28Z

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:44Z

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