aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/v3d/v3d_perfmon.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-07drm/v3d: Stop the active perfmon before being destroyedMaíra Canal1-1/+8
When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: [email protected] # v5.15+ Closes: https://github.com/raspberrypi/linux/issues/6389 Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace") Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-13drm/v3d: Move perfmon init completely into own unitTvrtko Ursulin1-17/+23
Now that the build time dependencies on various array sizes have been removed, we can move the perfmon init completely into its own compilation unit and remove the hardcoded defines. This improves on the temporary fix quickly delivered in commit 9c3951ec27b9 ("drm/v3d: Fix perfmon build error/warning"). Signed-off-by: Tvrtko Ursulin <[email protected]> References: 9c3951ec27b9 ("drm/v3d: Fix perfmon build error/warning") Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-05drm/v3d: Fix perfmon build error/warningTvrtko Ursulin1-6/+198
Move static const array into the source file to fix the "defined but not used" errors. The fix is perhaps not the prettiest due hand crafting the array sizes in v3d_performance_counters.h, but I did add some build time asserts to validate the counts look sensible, so hopefully it is good enough for a quick fix. Signed-off-by: Tvrtko Ursulin <[email protected]> Fixes: 3cbcbe016c31 ("drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/Cc: Maíra Canal <[email protected]> Cc: Iago Toral Quiroga <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Ashutosh Dixit <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-20drm/v3d: Create new IOCTL to expose performance counters informationMaíra Canal1-0/+33
Userspace usually needs some information about the performance counters available. Although we could replicate this information in the kernel and user-space, let's use the kernel as the "single source of truth" to avoid issues in the future (e.g. list of performance counters is updated in user-space, but not in the kernel, generating invalid requests). Therefore, create a new IOCTL to expose the performance counters information, that is name, category, and description. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-20drm/v3d: Different V3D versions can have different number of perfcntMaíra Canal1-1/+2
Currently, even though V3D 7.1 has 93 performance counters, it is not possible to create counters bigger than 87, as `v3d_perfmon_create_ioctl()` understands that counters bigger than 87 are invalid. Therefore, create a device variable to expose the maximum number of counters for a given V3D version and make `v3d_perfmon_create_ioctl()` check this variable. This commit fixes CTS failures in the performance queries tests `dEQP-VK.query_pool.performance_query.*` [1] Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/ea1f09a5f21839f4f3b93610b58507c4bd9b9b81 [1] Fixes: 6fd9487147c4 ("drm/v3d: add brcm,2712-v3d as a compatible V3D device") Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-10drm/v3d: add missing mutex_destroyMaíra Canal1-1/+5
v3d_perfmon_open_file() instantiates a mutex for a particular file instance, but it never destroys it by calling mutex_destroy() in v3d_perfmon_close_file(). Similarly, v3d_perfmon_create_ioctl() instantiates a mutex for a particular perfmon, but it never destroys it by calling mutex_destroy() in v3d_perfmon_destroy_ioctl(). So, add the missing mutex_destroy on both cases. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-07-28drm/v3d: use idr_init_base() to initialize v3d_priv->perfmon.idrDanilo Krummrich1-1/+1
idr_init_base(), implemented by commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient"), let us set an arbitrary base other than idr_init(), which uses base 0. Since, for this IDR, no ID < 1 is ever requested/allocated, using idr_init_base(&idr, 1) avoids unnecessary tree walks. Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-04-26drm/v3d: Fix null pointer dereference of pointer perfmonColin Ian King1-1/+2
In the unlikely event that pointer perfmon is null the WARN_ON return path occurs after the pointer has already been deferenced. Fix this by only dereferencing perfmon after it has been null checked. Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace") Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-21drm/v3d: Expose performance counters to userspaceJuan A. Suarez Romero1-0/+213
The V3D engine has several hardware performance counters that can of interest for userspace performance analysis tools. This exposes new ioctls to create and destroy performance monitor objects, as well as to query the counter values. Each created performance monitor object has an ID that can be attached to CL/CSD submissions, so the driver enables the requested counters when the job is submitted, and updates the performance monitor values when the job is done. It is up to the user to ensure all the jobs have been finished before getting the performance monitor values. It is also up to the user to properly synchronize BCL jobs when submitting jobs with different performance monitors attached. Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: Emma Anholt <[email protected]> To: [email protected] Signed-off-by: Juan A. Suarez Romero <[email protected]> Acked-by: Melissa Wen <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]