kernel/linux.git/drivers/gpu/drm/msm/msm_debugfs.c, branch v6.19.11

drm/msm: Fix dereference of pointer minor before null check

2025-08-07T16:22:27+00:00

Currently the pointer minor is being dereferenced before it is null checked, leading to a potential null pointer dereference issue. Fix this by dereferencing the pointer only after it has been null checked. Also Replace minor->dev with dev. Fixes: 4f89cf40d01e ("drm/msm: bail out late_init_minor() if it is not a GPU device") Signed-off-by: Colin Ian King Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/666259/ Signed-off-by: Rob Clark

drm/msm: bail out late_init_minor() if it is not a GPU device

2025-07-05T14:13:35+00:00

Both perf and hangrd make sense only for GPU devices. Bail out if we are registering a KMS-only device. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662583/ Signed-off-by: Rob Clark

drm/msm: make it possible to disable KMS-related code.

2025-07-05T14:13:35+00:00

If the Adreno device is used in a headless mode, there is no need to build all KMS components. Build corresponding parts conditionally, only selecting them if modeset support is actually required. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662581/ Signed-off-by: Rob Clark

drm/msm: Temporarily disable stall-on-fault after a page fault

2025-06-09T18:37:34+00:00

When things go wrong, the GPU is capable of quickly generating millions of faulting translation requests per second. When that happens, in the stall-on-fault model each access will stall until it wins the race to signal the fault and then the RESUME register is written. This slows processing page faults to a crawl as the GPU can generate faults much faster than the CPU can acknowledge them. It also means that all available resources in the SMMU are saturated waiting for the stalled transactions, so that other transactions such as transactions generated by the GMU, which shares translation resources with the GPU, cannot proceed. This causes a GMU watchdog timeout, which leads to a failed reset because GX cannot collapse when there is a transaction pending and a permanently hung GPU. On older platforms with qcom,smmu-v2, it seems that when one transaction is stalled subsequent faulting transactions are terminated, which avoids this problem, but the MMU-500 follows the spec here. To work around these problems, disable stall-on-fault as soon as we get a page fault until a cooldown period after pagefaults stop. This allows the GMU some guaranteed time to continue working. We only use stall-on-fault to halt the GPU while we collect a devcoredump and we always terminate the transaction afterward, so it's fine to miss some subsequent page faults. We also keep it disabled so long as the current devcoredump hasn't been deleted, because in that case we likely won't capture another one if there's a fault. After this commit HFI messages still occasionally time out, because the crashdump handler doesn't run fast enough to let the GMU resume, but the driver seems to recover from it. This will probably go away after the HFI timeout is increased. Signed-off-by: Connor Abbott Reviewed-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/654891/ Signed-off-by: Rob Clark

drm/msm: clean up fault injection usage

2024-09-02T03:43:33+00:00

With the proper stubs in place in linux/fault-inject.h, we can remove a bunch of conditional compilation for CONFIG_FAULT_INJECTION=n. Link: https://lkml.kernel.org/r/20240813121237.2382534-2-jani.nikula@intel.com Signed-off-by: Jani Nikula Reviewed-by: Thomas Hellström Reviewed-by: Himal Prasad Ghimiray Reviewed-by: Abhinav Kumar Cc: Akinobu Mita Cc: Rob Clark Cc: Dmitry Baryshkov Cc: Lucas De Marchi Cc: Rodrigo Vivi Signed-off-by: Andrew Morton

drm/msm: don't create GPU-related debugfs files with no GPU present

2023-11-21T02:31:42+00:00

If there is no GPU present, skip creation of the GPU-related debugfs files, making the MSM's debugfs more usable. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/561742/ Signed-off-by: Rob Clark

drm/msm: make fb debugfs file available only in KMS case

2023-10-09T18:42:36+00:00

Don't register the 'fb' debugfs file, if there is no KMS (and so no framebuffers). Reviewed-by: Rob Clark Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/561650/ Signed-off-by: Rob Clark

drm/msm: only register 'kms' debug file if KMS is used

2023-10-09T18:42:36+00:00

There is little point in having the empty debugfs file which always returns -ENODEV. Change this file to be created only if KMS is actually used. Reviewed-by: Rob Clark Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/561656/ Signed-off-by: Rob Clark

drm/msm: Remove unnecessary (void*) conversions

2023-06-04T02:23:39+00:00

Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/540599/ Link: https://lore.kernel.org/r/20230522013213.25876-1-suhui@nfschina.com Signed-off-by: Dmitry Baryshkov

drm/msm: Implement fbdev emulation as in-kernel client

2023-04-06T17:29:40+00:00

Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to msm_fbdev_setup() after msm has registered its DRM device. As in most drivers, msm's fbdev emulation now acts like a regular DRM client. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_dev_unregister() releases the client automatically. No further action is required within msm. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. v2: * handle fbdev module parameter correctly (kernel test robot) Signed-off-by: Thomas Zimmermann Reviewed-by: Dmitry Baryshkov Tested-by: Dmitry Baryshkov # RB5 Patchwork: https://patchwork.freedesktop.org/patch/530560/ Link: https://lore.kernel.org/r/20230403124538.8497-9-tzimmermann@suse.de Signed-off-by: Dmitry Baryshkov