linux-stable.git/drivers/gpu/drm/msm/msm_debugfs.c, branch linux-6.16.y Linux kernel stable tree drm/msm: Temporarily disable stall-on-fault after a page fault 2025-06-09T18:37:34+00:00 Connor Abbott cwabbott0@gmail.com 2025-05-20T19:08:59+00:00 b13044092c1e30453d2f7e9be596d3a2616582a0 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 <cwabbott0@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/654891/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> 
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 <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654891/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
drm/msm: clean up fault injection usage 2024-09-02T03:43:33+00:00 Jani Nikula jani.nikula@intel.com 2024-08-13T12:12:36+00:00 f161cdd91b2a68ed846ecaac43b2f01af0ea61c8 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 <jani.nikula@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
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 <jani.nikula@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drm/msm: don't create GPU-related debugfs files with no GPU present 2023-11-21T02:31:42+00:00 Dmitry Baryshkov dmitry.baryshkov@linaro.org 2023-10-10T05:54:25+00:00 f6afe4f09f6605b725b39670b3568ab2927c9b43 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 <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/561742/ Signed-off-by: Rob Clark <robdclark@chromium.org> 
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 <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/561742/
Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm: make fb debugfs file available only in KMS case 2023-10-09T18:42:36+00:00 Dmitry Baryshkov dmitry.baryshkov@linaro.org 2023-10-09T18:10:39+00:00 7d4d6ef70846a33b65a7e9753e4d052e2464b2be Don't register the 'fb' debugfs file, if there is no KMS (and so no framebuffers). Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/561650/ Signed-off-by: Rob Clark <robdclark@chromium.org> 
Don't register the 'fb' debugfs file, if there is no KMS (and so no
framebuffers).

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/561650/
Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm: only register 'kms' debug file if KMS is used 2023-10-09T18:42:36+00:00 Dmitry Baryshkov dmitry.baryshkov@linaro.org 2023-10-09T18:10:38+00:00 ae13219e47d314b3bf7496b97983c22485e3627a 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 <robdclark@gmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/561656/ Signed-off-by: Rob Clark <robdclark@chromium.org> 
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 <robdclark@gmail.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/561656/
Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm: Remove unnecessary (void*) conversions 2023-06-04T02:23:39+00:00 Su Hui suhui@nfschina.com 2023-05-22T01:32:13+00:00 eea9cf72b718b1d2c935f2be2610d05e7527f2d8 Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/540599/ Link: https://lore.kernel.org/r/20230522013213.25876-1-suhui@nfschina.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> 
Pointer variables of (void*) type do not require type cast.

Signed-off-by: Su Hui <suhui@nfschina.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/540599/
Link: https://lore.kernel.org/r/20230522013213.25876-1-suhui@nfschina.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/msm: Implement fbdev emulation as in-kernel client 2023-04-06T17:29:40+00:00 Thomas Zimmermann tzimmermann@suse.de 2023-04-03T12:45:38+00:00 940b869c2f2fb75696d7a3104b23caac9d5da841 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 <tzimmermann@suse.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # 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 <dmitry.baryshkov@linaro.org> 
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 <tzimmermann@suse.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # 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 <dmitry.baryshkov@linaro.org>
drm/msm: Remove fbdev from struct msm_drm_private 2023-04-06T17:29:40+00:00 Thomas Zimmermann tzimmermann@suse.de 2023-04-03T12:45:35+00:00 e13446341f9750198592a337bf87e8f0519ecd87 The DRM device stores a pointer to the fbdev helper. Remove struct msm_drm_private.fbdev, which contains the same value. No functional changes. v2: * test for fb_helper->fb in debugfs code Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/530559/ Link: https://lore.kernel.org/r/20230403124538.8497-6-tzimmermann@suse.de Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> 
The DRM device stores a pointer to the fbdev helper. Remove struct
msm_drm_private.fbdev, which contains the same value. No functional
changes.

v2:
	* test for fb_helper->fb in debugfs code

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/530559/
Link: https://lore.kernel.org/r/20230403124538.8497-6-tzimmermann@suse.de
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/msm/gpu: Add devfreq tuning debugfs 2023-01-16T18:40:18+00:00 Rob Clark robdclark@chromium.org 2023-01-10T23:14:42+00:00 6563f60f14cbb3dcbdc4e1d8469fc0fbaaa80544 Make the handful of tuning knobs available visible via debugfs. v2: select DEVFREQ_GOV_SIMPLE_ONDEMAND because for some reason struct devfreq_simple_ondemand_data depends on this Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/517784/ Link: https://lore.kernel.org/r/20230110231447.1939101-2-robdclark@gmail.com Reviewed-by: Chia-I Wu <olvaffe@gmail.com> 
Make the handful of tuning knobs available visible via debugfs.

v2: select DEVFREQ_GOV_SIMPLE_ONDEMAND because for some reason
    struct devfreq_simple_ondemand_data depends on this

Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/517784/
Link: https://lore.kernel.org/r/20230110231447.1939101-2-robdclark@gmail.com
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
drm/msm: Add fault-injection support 2022-08-28T15:32:11+00:00 Rob Clark robdclark@chromium.org 2022-08-07T17:28:48+00:00 6d29709de8028cfd5a827d02f93a5076ba632563 Intended as a way to trigger error paths in mesa. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/496710/ Link: https://lore.kernel.org/r/20220807172848.2432845-1-robdclark@gmail.com 
Intended as a way to trigger error paths in mesa.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/496710/
Link: https://lore.kernel.org/r/20220807172848.2432845-1-robdclark@gmail.com