aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/lima/lima_sched.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/sched: Rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESETMaíra Canal2025-07-151-3/+3
| | | | | | | | | | | | | | | | | | | Among the scheduler's statuses, the only one that indicates an error is DRM_GPU_SCHED_STAT_ENODEV. Any status other than DRM_GPU_SCHED_STAT_ENODEV signifies that the operation succeeded and the GPU is in a nominal state. However, to provide more information about the GPU's status, it is needed to convey more information than just "OK". Therefore, rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET, which better communicates the meaning of this status. The status DRM_GPU_SCHED_STAT_RESET indicates that the GPU has hung, but it has been successfully reset and is now in a nominal state again. Reviewed-by: Philipp Stanner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maíra Canal <[email protected]>
* drm/sched: Store the drm client_id in drm_sched_fencePierre-Eric Pelloux-Prayer2025-05-281-2/+4
| | | | | | | | | | | | | | | | | | | | | This will be used in a later commit to trace the drm client_id in some of the gpu_scheduler trace events. This requires changing all the users of drm_sched_job_init to add an extra parameter. The newly added drm_client_id field in the drm_sched_fence is a bit of a duplicate of the owner one. One suggestion I received was to merge those 2 fields - this can't be done right now as amdgpu uses some special values (AMDGPU_FENCE_OWNER_*) that can't really be translated into a client id. Christian is working on getting rid of those; when it's done we should be able to squash owner/drm_client_id together. Reviewed-by: Christian König <[email protected]> Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]> Signed-off-by: Philipp Stanner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
* drm/gem: Change locked/unlocked postfix of drm_gem_v/unmap() function namesDmitry Osipenko2025-03-261-2/+2
| | | | | | | | | | | | | | | Make drm/gem API function names consistent by having locked function use the _locked postfix in the name, while the unlocked variants don't use the _unlocked postfix. Rename drm_gem_v/unmap() function names to make them consistent with the rest of the API functions. Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Suggested-by: Boris Brezillon <[email protected]> Reviewed-by: Christian König <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: Use struct for drm_sched_init() paramsPhilipp Stanner2025-02-121-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | drm_sched_init() has a great many parameters and upcoming new functionality for the scheduler might add even more. Generally, the great number of parameters reduces readability and has already caused one missnaming, addressed in: commit 6f1cacf4eba7 ("drm/nouveau: Improve variable name in nouveau_sched_init()"). Introduce a new struct for the scheduler init parameters and port all users. Reviewed-by: Liviu Dudau <[email protected]> Acked-by: Matthew Brost <[email protected]> # for Xe Reviewed-by: Boris Brezillon <[email protected]> # for Panfrost and Panthor Reviewed-by: Christian Gmeiner <[email protected]> # for Etnaviv Reviewed-by: Frank Binns <[email protected]> # for Imagination Reviewed-by: Tvrtko Ursulin <[email protected]> # for Sched Reviewed-by: Maíra Canal <[email protected]> # for v3d Reviewed-by: Danilo Krummrich <[email protected]> Reviewed-by: Lizhi Hou <[email protected]> # for amdxdna Signed-off-by: Philipp Stanner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: add optional errno to drm_sched_start()Christian König2024-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of drm_sched_start uses a hardcoded -ECANCELED to dispose of a job when the parent/hw fence is NULL. This results in drm_sched_job_done being called with -ECANCELED for each job with a NULL parent in the pending list, making it difficult to distinguish between recovery methods, whether a queue reset or a full GPU reset was used. To improve this, we first try a soft recovery for timeout jobs and use the error code -ENODATA. If soft recovery fails, we proceed with a queue reset, where the error code remains -ENODATA for the job. Finally, for a full GPU reset, we use error codes -ECANCELED or -ETIME. This patch adds an error code parameter to drm_sched_start, allowing us to differentiate between queue reset and GPU reset failures. This enables user mode and test applications to validate the expected correctness of the requested operation. After a successful queue reset, the only way to continue normal operation is to call drm_sched_job_done with the specific error code -ENODATA. v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain and amdgpu_device_unlock_reset_domain to allow user mode to track the queue reset status and distinguish between queue reset and GPU reset. v2: Christian suggested using the error codes -ENODATA for queue reset and -ECANCELED or -ETIME for GPU reset, returned to amdgpu_cs_wait_ioctl. v3: To meet the requirements, we introduce a new function drm_sched_start_ex with an additional parameter to set dma_fence_set_error, allowing us to handle the specific error codes appropriately and dispose of bad jobs with the selected error code depending on whether it was a queue reset or GPU reset. v4: Alex suggested using a new name, drm_sched_start_with_recovery_error, which more accurately describes the function's purpose. Additionally, it was recommended to add documentation details about the new method. v5: Fixed declaration of new function drm_sched_start_with_recovery_error.(Alex) v6 (chk): rebase on upstream changes, cleanup the commit message, drop the new function again and update all callers, apply the errno also to scheduler fences with hw fences v7 (chk): rebased Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Vitaly Prosyak <[email protected]> Signed-off-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/scheduler: remove full_recover from drm_sched_startChristian König2024-07-251-1/+1
| | | | | | | | | | | | | | | This was basically just another one of amdgpus hacks. The parameter allowed to restart the scheduler without turning fence signaling on again. That this is absolutely not a good idea should be obvious by now since the fences will then just sit there and never signal. While at it cleanup the code a bit. Signed-off-by: Christian König <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: mask irqs in timeout path before hard resetErico Nunes2024-04-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. Signed-off-by: Erico Nunes <[email protected]> Reviewed-by: Qiang Yu <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: include pp bcast irq in timeout handler checkErico Nunes2024-04-151-0/+2
| | | | | | | | | | | | | In commit 53cb55b20208 ("drm/lima: handle spurious timeouts due to high irq latency") a check was added to detect an unexpectedly high interrupt latency timeout. With further investigation it was noted that on Mali-450 the pp bcast irq may also be a trigger of race conditions against the timeout handler, so add it to this check too. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: increase default job timeout to 10sErico Nunes2024-02-121-1/+1
| | | | | | | | | | | | | The previous 500ms default timeout was fairly optimistic and could be hit by real world applications. Many distributions targeting devices with a Mali-4xx already bumped this timeout to a higher limit. We can be generous here with a high value as 10s since this should mostly catch buggy jobs like infinite loop shaders, and these don't seem to happen very often in real applications. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: remove guilty drm_sched context handlingErico Nunes2024-02-121-3/+2
| | | | | | | | | | | | | | | | | | | | | | | Marking the context as guilty currently only makes the application which hits a single timeout problem to stop its rendering context entirely. All jobs submitted later are dropped from the guilty context. Lima runs on fairly underpowered hardware for modern standards and it is not entirely unreasonable that a rendering job may time out occasionally due to high system load or too demanding application stack. In this case it would be generally preferred to report the error but try to keep the application going. Other similar embedded GPU drivers don't make use of the guilty context flag. Now that there are reliability improvements to the lima timeout recovery handling, drop the guilty contexts to let the application keep running in this case. Signed-off-by: Erico Nunes <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: handle spurious timeouts due to high irq latencyErico Nunes2024-02-121-3/+28
| | | | | | | | | | | | | | | | There are several unexplained and unreproduced cases of rendering timeouts with lima, for which one theory is high IRQ latency coming from somewhere else in the system. This kind of occurrence may cause applications to trigger unnecessary resets of the GPU or even applications to hang if it hits an issue in the recovery path. Panfrost already does some special handling to account for such "spurious timeouts", it makes sense to have this in lima too to reduce the chance that it hit users. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: implement dynamic job-flow controlDanilo Krummrich2023-11-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Currently, job flow control is implemented simply by limiting the number of jobs in flight. Therefore, a scheduler is initialized with a credit limit that corresponds to the number of jobs which can be sent to the hardware. This implies that for each job, drivers need to account for the maximum job size possible in order to not overflow the ring buffer. However, there are drivers, such as Nouveau, where the job size has a rather large range. For such drivers it can easily happen that job submissions not even filling the ring by 1% can block subsequent submissions, which, in the worst case, can lead to the ring run dry. In order to overcome this issue, allow for tracking the actual job size instead of the number of jobs. Therefore, add a field to track a job's credit count, which represents the number of credits a job contributes to the scheduler's credit limit. Signed-off-by: Danilo Krummrich <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: Convert drm scheduler to use a work queue rather than kthreadMatthew Brost2023-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1 mapping between a drm_gpu_scheduler and drm_sched_entity. At first this seems a bit odd but let us explain the reasoning below. 1. In Xe the submission order from multiple drm_sched_entity is not guaranteed to be the same completion even if targeting the same hardware engine. This is because in Xe we have a firmware scheduler, the GuC, which allowed to reorder, timeslice, and preempt submissions. If a using shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls apart as the TDR expects submission order == completion order. Using a dedicated drm_gpu_scheduler per drm_sched_entity solve this problem. 2. In Xe submissions are done via programming a ring buffer (circular buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow control on the ring for free. A problem with this design is currently a drm_gpu_scheduler uses a kthread for submission / job cleanup. This doesn't scale if a large number of drm_gpu_scheduler are used. To work around the scaling issue, use a worker rather than kthread for submission / job cleanup. v2: - (Rob Clark) Fix msm build - Pass in run work queue v3: - (Boris) don't have loop in worker v4: - (Tvrtko) break out submit ready, stop, start helpers into own patch v5: - (Boris) default to ordered work queue v6: - (Luben / checkpatch) fix alignment in msm_ringbuffer.c - (Luben) s/drm_sched_submit_queue/drm_sched_wqueue_enqueue - (Luben) Update comment for drm_sched_wqueue_enqueue - (Luben) Positive check for submit_wq in drm_sched_init - (Luben) s/alloc_submit_wq/own_submit_wq v7: - (Luben) s/drm_sched_wqueue_enqueue/drm_sched_run_job_queue v8: - (Luben) Adjust var names / comments Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Luben Tuikov <[email protected]>
* drm/sched: Convert the GPU scheduler to variable number of run-queuesLuben Tuikov2023-10-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPU scheduler has now a variable number of run-queues, which are set up at drm_sched_init() time. This way, each driver announces how many run-queues it requires (supports) per each GPU scheduler it creates. Note, that run-queues correspond to scheduler "priorities", thus if the number of run-queues is set to 1 at drm_sched_init(), then that scheduler supports a single run-queue, i.e. single "priority". If a driver further sets a single entity per run-queue, then this creates a 1-to-1 correspondence between a scheduler and a scheduled entity. Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Rob Clark <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Emma Anholt <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Luben Tuikov <[email protected]> Acked-by: Christian König <[email protected]> Link: https://lore.kernel.org/r/[email protected]
* drm/lima: fix sched context destroyErico Nunes2023-06-071-1/+1
| | | | | | | | | | | | | | | | | The drm sched entity must be flushed before finishing, to account for jobs potentially still in flight at that time. Lima did not do this flush until now, so switch the destroy call to the drm_sched_entity_destroy() wrapper which will take care of that. This fixes a regression on lima which started since the rework in commit 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini") where some specific types of applications may hang indefinitely. Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini") Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/gem: Take reservation lock for vmap/vunmap operationsDmitry Osipenko2022-10-171-2/+2
| | | | | | | | | | | | | The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM core to take the lock around the vmapping operations and update DRM drivers to use the locked functions for the case where DRM core now holds the lock. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by: Christian König <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* Merge tag 'drm-misc-next-2022-02-23' of ↵Dave Airlie2022-02-241-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.18: UAPI Changes: Cross-subsystem Changes: - Split out panel-lvds and lvds dt bindings . - Put yes/no on/off disabled/enabled strings in linux/string_helpers.h and use it in drivers and tomoyo. - Clarify dma_fence_chain and dma_fence_array should never include eachother. - Flatten chains in syncobj's. - Don't double add in fbdev/defio when page is already enlisted. - Don't sort deferred-I/O pages by default in fbdev. Core Changes: - Fix missing pm_runtime_put_sync in bridge. - Set modifier support to only linear fb modifier if drivers don't advertise support. - As a result, we remove allow_fb_modifiers. - Add missing clear for EDID Deep Color Modes in drm_reset_display_info. - Assorted documentation updates. - Warn once in drm_clflush if there is no arch support. - Add missing select for dp helper in drm_panel_edp. - Assorted small fixes. - Improve fb-helper's clipping handling. - Don't dump shmem mmaps in a core dump. - Add accounting to ttm resource manager, and use it in amdgpu. - Allow querying the detected eDP panel through debugfs. - Add helpers for xrgb8888 to 8 and 1 bits gray. - Improve drm's buddy allocator. - Add selftests for the buddy allocator. Driver Changes: - Add support for nomodeset to a lot of drm drivers. - Use drm_module_*_driver in a lot of drm drivers. - Assorted small fixes to bridge/lt9611, v3d, vc4, vmwgfx, mxsfb, nouveau, bridge/dw-hdmi, panfrost, lima, ingenic, sprd, bridge/anx7625, ti-sn65dsi86. - Add bridge/it6505. - Create DP and DVI-I connectors in ast. - Assorted nouveau backlight fixes. - Rework amdgpu reset handling. - Add dt bindings for ingenic,jz4780-dw-hdmi. - Support reading edid through aux channel in ingenic. - Add a drm driver for Solomon SSD130x OLED displays. - Add simple support for sharp LQ140M1JW46. - Add more panels to nt35560. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
| * drm/sched: Add device pointer to drm_gpu_schedulerJiawei Gu2022-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add device pointer so scheduler's printing can use DRM_DEV_ERROR() instead, which makes life easier under multiple GPU scenario. v2: amend all calls of drm_sched_init() v3: fill dev pointer for all drm_sched_init() calls Signed-off-by: Jiawei Gu <[email protected]> Reviewed-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
| * drm/lima: avoid error task dump attempt when not enabledErico Nunes2022-02-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when users try to run an application with lima and that hits an issue such as a timeout, a message saying "fail to save task state" and "error task list is full" is shown in dmesg. The error task dump is a debug feature disabled by default, so the error task list is usually not going to be available at all. The message can be misleading and creates confusion in bug reports. We can avoid that code path and that particular message when the user has not explicitly set the max_error_tasks parameter to enable the feature. Signed-off-by: Erico Nunes <[email protected]> Reviewed-by: Qiang Yu <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* | dma-buf-map: Rename to iosys-mapLucas De Marchi2022-02-081-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers. The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory. The conversion was mostly done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include <linux/dma-buf-map.h> + #include <linux/iosys-map.h> Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map. Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section. v2: - Squash patches v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst v4: - Change documentation title and level Signed-off-by: Lucas De Marchi <[email protected]> Acked-by: Christian König <[email protected]> Acked-by: Sumit Semwal <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/shmem-helper: Pass GEM shmem object in public interfacesThomas Zimmermann2021-11-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Change all GEM SHMEM object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_shmem_object instead. This change reduces the number of upcasts from struct drm_gem_object by moving them into callers. The C compiler can now verify that the GEM SHMEM functions are called with the correct type. For consistency, the patch also renames drm_gem_shmem_free_object to drm_gem_shmem_free. It further updates documentation for a number of functions. v3: * fix docs for drm_gem_shmem_object_free() v2: * mention _object_ callbacks in docs (Daniel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: use scheduler dependency trackingDaniel Vetter2021-08-301-21/+0
| | | | | | | | | | | | | | | | | | | | | Nothing special going on here. Aside reviewing the code, it seems like drm_sched_job_arm() should be moved into lima_sched_context_queue_task and put under some mutex together with drm_sched_push_job(). See the kerneldoc for drm_sched_push_job(). v2: Rebase over renamed functions to add dependencies. Reviewed-by: Qiang Yu <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: drop entity parameter from drm_sched_push_jobDaniel Vetter2021-08-301-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally a job was only bound to the queue when we pushed this, but now that's done in drm_sched_job_init, making that parameter entirely redundant. Remove it. The same applies to the context parameter in lima_sched_context_queue_task, simplify that too. v2: Rebase on top of msm adopting drm/sched Reviewed-by: Christian König <[email protected]> Acked-by: Emma Anholt <[email protected]> Acked-by: Melissa Wen <[email protected]> Reviewed-by: Steven Price <[email protected]> (v1) Reviewed-by: Boris Brezillon <[email protected]> (v1) Signed-off-by: Daniel Vetter <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Rob Herring <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Steven Price <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Emma Anholt <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Chen Li <[email protected]> Cc: Lee Jones <[email protected]> Cc: Deepak R Varma <[email protected]> Cc: Kevin Wang <[email protected]> Cc: Luben Tuikov <[email protected]> Cc: "Marek Olšák" <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Andrey Grodzovsky <[email protected]> Cc: Dennis Li <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Rob Clark <[email protected]> Cc: Sean Paul <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: Split drm_sched_job_initDaniel Vetter2021-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpers into the scheduler code, and that means drm_sched_job_init must be called a lot earlier, without arming the job. v2: - don't change .gitignore (Steven) - don't forget v3d (Emma) v3: Emma noticed that I leak the memory allocated in drm_sched_job_init if we bail out before the point of no return in subsequent driver patches. To be able to fix this change drm_sched_job_cleanup() so it can handle being called both before and after drm_sched_job_arm(). Also improve the kerneldoc for this. v4: - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as usual (Melissa) - Christian pointed out that drm_sched_entity_select_rq() also needs to be moved into drm_sched_job_arm, which made me realize that the job->id definitely needs to be moved too. Shuffle things to fit between job_init and job_arm. v5: Reshuffle the split between init/arm once more, amdgpu abuses drm_sched.ready to signal gpu reset failures. Also document this somewhat. (Christian) v6: Rebase on top of the msm drm/sched support. Note that the drm_sched_job_init() call is completely misplaced, and hence also the split-out drm_sched_entity_push_job(). I've put in a FIXME which the next patch will address. v7: Drop the FIXME in msm, after discussions with Rob I agree it shouldn't be a problem where it is now. Acked-by: Christian König <[email protected]> Acked-by: Melissa Wen <[email protected]> Cc: Melissa Wen <[email protected]> Acked-by: Emma Anholt <[email protected]> Acked-by: Steven Price <[email protected]> (v2) Reviewed-by: Boris Brezillon <[email protected]> (v5) Signed-off-by: Daniel Vetter <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Rob Herring <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Steven Price <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Kees Cook <[email protected]> Cc: Adam Borowski <[email protected]> Cc: Nick Terrell <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Paul Menzel <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Viresh Kumar <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Deepak R Varma <[email protected]> Cc: Lee Jones <[email protected]> Cc: Kevin Wang <[email protected]> Cc: Chen Li <[email protected]> Cc: Luben Tuikov <[email protected]> Cc: "Marek Olšák" <[email protected]> Cc: Dennis Li <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Andrey Grodzovsky <[email protected]> Cc: Sonny Jiang <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: Tian Tao <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Emma Anholt <[email protected]> Cc: Rob Clark <[email protected]> Cc: Sean Paul <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/sched: Allow using a dedicated workqueue for the timeout/fault tdrBoris Brezillon2021-07-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU reset. This leads to extra complexity when we need to synchronize timeout works with the reset work. One solution to address that is to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. Thanks to the serialization provided by the ordered workqueue we are guaranteed that timeout handlers are executed sequentially, and can thus easily reset the GPU from the timeout handler without extra synchronization. v5: * Add a new paragraph to the timedout_job() method v3: * New patch v4: * Actually use the timeout_wq to queue the timeout work Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Christian König <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Emma Anholt <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/scheduler: provide scheduler score externallyChristian König2021-02-051-1/+1
| | | | | | | | | | Allow multiple schedulers to share the load balancing score. This is useful when one engine has different hw rings. Signed-off-by: Christian König <[email protected]> Reviewed-and-Tested-by: Leo Liu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: fix reference leak in lima_pm_busyQinglang Miao2021-01-301-1/+1
| | | | | | | | | | | | | | | | | | pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. A new function pm_runtime_resume_and_get is introduced in [0] to keep usage counter balanced. So We fix the reference leak by replacing it with new function. [0] commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Fixes: 50de2e9ebbc0 ("drm/lima: enable runtime pm") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Qinglang Miao <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/scheduler: Job timeout handler returns status (v3)Luben Tuikov2021-01-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does not change current behaviour. The driver's job timeout handler now returns status indicating back to the DRM layer whether the device (GPU) is no longer available, such as after it's been unplugged, or whether all is normal, i.e. current behaviour. All drivers which make use of the drm_sched_backend_ops' .timedout_job() callback have been accordingly renamed and return the would've-been default value of DRM_GPU_SCHED_STAT_NOMINAL to restart the task's timeout timer--this is the old behaviour, and is preserved by this patch. v2: Use enum as the status of a driver's job timeout callback method. v3: Return scheduler/device information, rather than task information. Cc: Alexander Deucher <[email protected]> Cc: Andrey Grodzovsky <[email protected]> Cc: Christian König <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: Qiang Yu <[email protected]> Cc: Rob Herring <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Steven Price <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Eric Anholt <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Luben Tuikov <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Acked-by: Christian König <[email protected]> Acked-by: Steven Price <[email protected]> Signed-off-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/415095/
* drm/lima/lima_sched: Remove unused and unnecessary variable 'ret'Lee Jones2020-11-161-2/+1
| | | | | | | | | | | | | | | | | | | | Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/lima/lima_sched.c: In function ‘lima_sched_run_job’: drivers/gpu/drm/lima/lima_sched.c:227:20: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Qiang Yu <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backendsThomas Zimmermann2020-11-091-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Christian König <[email protected]> Tested-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: Expose job_hang_limit module parameterAndrey Lebedev2020-07-131-2/+3
| | | | | | | | | | Some pp or gp jobs can be successfully repeated even after they time outs. Introduce lima module parameter to specify number of times a job can hang before being dropped. Signed-off-by: Andrey Lebedev <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: remove _unlocked suffix in drm_gem_object_put_unlockedEmil Velikov2020-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not know (or need to) about the horror stories involving struct_mutex. Just drop the suffix. It makes the API cleaner. Done via the following script: __from=drm_gem_object_put_unlocked __to=drm_gem_object_put for __file in $(git grep --name-only $__from); do sed -i "s/$__from/$__to/g" $__file; done Cc: Qiang Yu <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: enable runtime pmQiang Yu2020-04-241-5/+36
| | | | | | | | | | | | | | Enable runtime pm by default so GPU suspend when idle for 200ms. This value can be changed by autosuspend_delay_ms in device's power sysfs dir. On Allwinner H3 lima_device_resume takes ~40us and lima_device_suspend takes ~20us. Tested-by: Bhushan Shah <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: always set page directory when switch vmQiang Yu2020-04-241-10/+4
| | | | | | | | | | | We need to flush TLB anyway before every task start, and the page directory will be set to empty vm after suspend/resume, so always set it to the task vm even no ctx switch happens. Tested-by: Bhushan Shah <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: check vm != NULL in lima_vm_putQiang Yu2020-04-241-5/+2
| | | | | | | | | No need to handle this check before calling lima_vm_put. Tested-by: Bhushan Shah <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: print process name and pid when task errorQiang Yu2020-04-241-1/+2
| | | | | | | | | | When error task list is full, print the process info where the error task come from for debug usage. Tested-by: Bhushan Shah <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: Add optional devfreq and cooling device supportMartin Blumenstingl2020-03-281-0/+7
| | | | | | | | | | | | | | | | | | | | Most platforms with a Mali-400 or Mali-450 GPU also have support for changing the GPU clock frequency. Add devfreq support so the GPU clock rate is updated based on the actual GPU usage when the "operating-points-v2" property is present in the board.dts. The actual devfreq code is taken from panfrost_devfreq.c and modified so it matches what the lima hardware needs: - a call to dev_pm_opp_set_clkname() during initialization because there are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks the GPU so we need to control it using devfreq. - locking when reading or writing the devfreq statistics because (unlike than panfrost) we have multiple PP and GP IRQs which may finish jobs concurrently. Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: add trace point for tasksQiang Yu2020-03-221-1/+4
| | | | | | | | | | | | | | | | track lima task start which can be combined with dma_fence_signal to identify task execution time. example command to record: trace-cmd record -i \ -e "lima:lima_task_submit" -e "lima:lima_task_run" \ -e "*fence:*fence_signaled" -e "drm:drm_vblank_event" \ -e "drm:drm_vblank_event_queued" sleep 4 Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: save task info dump when task failQiang Yu2020-03-221-0/+130
| | | | | | | | | | | | | Save all information to start a task which can be exported to user for debug usage. Dump file data format is specified in lima_dump.h v2: Add include header to address build robot complain. Tested-by: Andreas Baierl <[email protected]> Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* Merge v5.6-rc2 into drm-misc-nextMaxime Ripard2020-02-171-2/+3
|\ | | | | | | | | | | | | Lyude needs some patches in 5.6-rc2 and we didn't bring drm-misc-next forward yet, so it looks like a good occasion. Signed-off-by: Maxime Ripard <[email protected]>
| * Merge tag 'amd-drm-next-5.6-2020-01-09' of ↵Dave Airlie2020-01-131-2/+3
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~agd5f/linux into drm-next amd-drm-next-5.6-2020-01-09: amdgpu: - Enable DCN support on POWER - Enable GFXOFF for Raven1 refresh - Clean up MM engine idle handlers - HDMI 2.0 audio fixes - Fixes for some 10 bpc EDP panels - Watermark fixes for renoir - SR-IOV fixes - Runtime pm robustness fixes - Arcturus VCN fixes - RAS fixes - BACO fixes for Arcturus - Stable pstate fixes for swSMU - HDCP fixes - PSP cleanup - HDMI fixes - Misc cleanups amdkfd: - Spread interrupt work across cores to reduce latency - Topology fixes for APUs - GPU reset improvements UAPI: - Enable DRIVER_SYNCOBJ_TIMELINE for vulkan - Return better error values for kfd process ioctl Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
| | * drm/scheduler: rework entity creationNirmoy Das2019-12-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Entity currently keeps a copy of run_queue list and modify it in drm_sched_entity_set_priority(). Entities shouldn't modify run_queue list. Use drm_gpu_scheduler list instead of drm_sched_rq list in drm_sched_entity struct. In this way we can select a runqueue based on entity/ctx's priority for a drm scheduler. Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
* | | drm/lima: recover task by enlarging heap bufferQiang Yu2020-01-271-4/+29
|/ / | | | | | | | | | | | | | | | | | | Increase heap buffer backup memory when GP receive PLBU out of memory interrupt, then resume the task. Reviewed-by: Vasily Khoruzhick <[email protected]> Tested-by: Andreas Baierl <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* / drm/lima: use drm_sched_fault for error task handlingQiang Yu2020-01-091-26/+9
|/ | | | | | | | | | | | | drm_sched_job_timedout works with drm_sched_stop as a pair, so we'd better use the drm_sched_fault helper to make the error and timeout handling go the same path. This also fixes application hang when task error. Reviewed-by: Vasily Khoruzhick <[email protected]> Tested-by: Andreas Baierl <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: use drm_gem_shmem_helpersQiang Yu2019-10-171-3/+3
| | | | | | | | | | | | Do not need to maintain our own shmem memory management code as drm_gem_shmem_helpers provides it. And we can also benifit from the work of others with shared code. This is also a preparation for implementing buffer madv. Reviewed-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: add timeout to drm scheduler initErico Nunes2019-05-211-7/+4
| | | | | | | | | | | | | | | | | | | | | | | After "5918045c4ed4 drm/scheduler: rework job destruction", lima started to leak memory due to buffers not being destroyed after job execution in the drm scheduler. This started happening because the drm scheduler only destroyed buffers after cancelling the job timeout handler, and for lima this handler was never started as lima specified a MAX_SCHEDULE_TIMEOUT timeout. Lima seems to run well in its current state with a real timeout, so to make it more aligned with the other drivers from now on, let's use a real default timeout. This also fixes the observed memory leaks. The 500ms value was chosen as it is the current value for all other embedded gpu drivers using drm sched. Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/scheduler: rework job destructionChristian König2019-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | We now destroy finished jobs from the worker thread to make sure that we never destroy a job currently in timeout processing. By this we avoid holding lock around ring mirror list in drm_sched_stop which should solve a deadlock reported by a user. v2: Remove unused variable. v4: Move guilty job free into sched code. v5: Move sched->hw_rq_count to drm_sched_start to account for counter decrement in drm_sched_stop even when we don't call resubmit jobs if guily job did signal. v6: remove unused variable Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692 Acked-by: Chunming Zhou <[email protected]> Signed-off-by: Christian König <[email protected]> Signed-off-by: Andrey Grodzovsky <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: Make lima_sched_ops staticYueHaibing2019-04-171-1/+1
| | | | | | | | | | | | | Fix sparse warning: drivers/gpu/drm/lima/lima_sched.c:356:36: warning: symbol 'lima_sched_ops' was not declared. Should it be static? Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* drm/lima: Use the drm_gem_fence_array_add helpers for our deps.Eric Anholt2019-04-161-54/+12
| | | | | | | | It's a pretty direct port of what I did for v3d. Signed-off-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-and-tested-by: Qiang Yu <[email protected]>
* drm/lima: driver for ARM Mali4xx GPUsQiang Yu2019-04-011-0/+404
- Mali 4xx GPUs have two kinds of processors GP and PP. GP is for OpenGL vertex shader processing and PP is for fragment shader processing. Each processor has its own MMU so prcessors work in virtual address space. - There's only one GP but multiple PP (max 4 for mali 400 and 8 for mali 450) in the same mali 4xx GPU. All PPs are grouped togather to handle a single fragment shader task divided by FB output tiled pixels. Mali 400 user space driver is responsible for assign target tiled pixels to each PP, but mali 450 has a HW module called DLBU to dynamically balance each PP's load. - User space driver allocate buffer object and map into GPU virtual address space, upload command stream and draw data with CPU mmap of the buffer object, then submit task to GP/PP with a register frame indicating where is the command stream and misc settings. - There's no command stream validation/relocation due to each user process has its own GPU virtual address space. GP/PP's MMU switch virtual address space before running two tasks from different user process. Error or evil user space code just get MMU fault or GP/PP error IRQ, then the HW/SW will be recovered. - Use GEM+shmem for MM. Currently just alloc and pin memory when gem object creation. GPU vm map of the buffer is also done in the alloc stage in kernel space. We may delay the memory allocation and real GPU vm map to command submission stage in the furture as improvement. - Use drm_sched for GPU task schedule. Each OpenGL context should have a lima context object in the kernel to distinguish tasks from different user. drm_sched gets task from each lima context in a fair way. mesa driver can be found here before upstreamed: https://gitlab.freedesktop.org/lima/mesa v8: - add comments for in_sync - fix ctx free miss mutex unlock v7: - remove lima_fence_ops with default value - move fence slab create to device probe - check pad ioctl args to be zero - add comments for user/kernel interface v6: - fix comments by checkpatch.pl v5: - export gp/pp version to userspace - rebase on drm-misc-next v4: - use get param interface to get info - separate context create/free ioctl - remove unused max sched task param - update copyright time - use xarray instead of idr - stop using drmP.h v3: - fix comments from kbuild robot - restrict supported arch to tested ones v2: - fix syscall argument check - fix job finish fence leak since kernel 5.0 - use drm syncobj to replace native fence - move buffer object GPU va map into kernel - reserve syscall argument space for future info - remove kernel gem modifier - switch TTM back to GEM+shmem MM - use time based io poll - use whole register name - adopt gem reservation obj integration - use drm_timeout_abs_to_jiffies Cc: Eric Anholt <[email protected]> Cc: Rob Herring <[email protected]> Cc: Christian König <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Rob Clark <[email protected]> Cc: Dave Airlie <[email protected]> Signed-off-by: Andreas Baierl <[email protected]> Signed-off-by: Erico Nunes <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Simon Shields <[email protected]> Signed-off-by: Vasily Khoruzhick <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/291200/
generated by cgit (git 2.51.2) at 2025-11-30 17:06:02 +0000