- 23 May, 2024 1 commit
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-6.10-2024-05-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-6.10-2024-05-22: amdgpu: - Handle vbios table integrated info v2.3 amdkfd: - Handle duplicate BOs in reserve_bo_and_cond_vms - Handle memory limitations on small APUs Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240522185346.16716-1-alexander.deucher@amd.com
-
- 22 May, 2024 2 commits
-
-
Li Ma authored
[Why] The vram width value is 0. Because the integratedsysteminfo table in VBIOS has updated to 2.3. [How] Driver needs a new intergrated info v2.3 table too. Then the vram width value will be correct. Signed-off-by:
Li Ma <li.ma@amd.com> Reviewed-by:
Yifan Zhang <yifan1.zhang@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2024-05-16' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.10-rc1: - VM_BIND fix for nouveau. - Lots of panthor fixes: * Fixes for panthor's heap logical block. * Reset on unrecoverable fault * Fix VM references. * Reset fix. - xlnx compile and doc fixes. Signed-off-by:
-
- 20 May, 2024 2 commits
-
-
Lang Yu authored
Small APUs(i.e., consumer, embedded products) usually have a small carveout device memory which can't satisfy most compute workloads memory allocation requirements. We can't even run a Basic MNIST Example with a default 512MB carveout. https://github.com/pytorch/examples/tree/main/mnist. Error Log: "torch.cuda.OutOfMemoryError: HIP out of memory. Tried to allocate 84.00 MiB. GPU 0 has a total capacity of 512.00 MiB of which 0 bytes is free. Of the allocated memory 103.83 MiB is allocated by PyTorch, and 22.17 MiB is reserved by PyTorch but unallocated" Though we can change BIOS settings to enlarge carveout size, which is inflexible and may bring complaint. On the other hand, the memory resource can't be effectively used between host and device. The solution is MI300A approach, i.e., let VRAM allocations go to GTT. Then device and host can flexibly and effectively share memory resource. v2: Report local_mem_size_private as 0. (Felix) Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
-
Lang Yu authored
Observed on gfx8 ASIC where KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM is used. Two attachments use the same VM, root PD would be locked twice. [ 57.910418] Call Trace: [ 57.793726] ? reserve_bo_and_cond_vms+0x111/0x1c0 [amdgpu] [ 57.793820] amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu+0x6c/0x1c0 [amdgpu] [ 57.793923] ? idr_get_next_ul+0xbe/0x100 [ 57.793933] kfd_process_device_free_bos+0x7e/0xf0 [amdgpu] [ 57.794041] kfd_process_wq_release+0x2ae/0x3c0 [amdgpu] [ 57.794141] ? process_scheduled_works+0x29c/0x580 [ 57.794147] process_scheduled_works+0x303/0x580 [ 57.794157] ? __pfx_worker_thread+0x10/0x10 [ 57.794160] worker_thread+0x1a2/0x370 [ 57.794165] ? __pfx_worker_thread+0x10/0x10 [ 57.794167] kthread+0x11b/0x150 [ 57.794172] ? __pfx_kthread+0x10/0x10 [ 57.794177] ret_from_fork+0x3d/0x60 [ 57.794181] ? __pfx_kthread+0x10/0x10 [ 57.794184] ret_from_fork_asm+0x1b/0x30 Signed-off-by:
-
- 19 May, 2024 1 commit
-
-
Arunpravin Paneer Selvam authored
Move the fallback and block incompatible checks above, so that we dont unnecessarily split the blocks and leaving the unmerged. This resolves the unnecessary warn on's thrown during force_merge call. v2:(Matthew) - Move the fallback and block incompatible checks above the contains check. Signed-off-by:Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Fixes: 96950929 ("drm/buddy: Implement tracking clear page feature") Link: https://patchwork.kernel.org/project/dri-devel/patch/20240517135015.17565-1-Arunpravin.PaneerSelvam@amd.com/Signed-off-by:
-
- 16 May, 2024 2 commits
-
-
Arunpravin Paneer Selvam authored
Allocate cleared blocks in the bias range when the DRM buddy's clear avail is zero. This will validate the bias range allocation in scenarios like system boot when no cleared blocks are available and exercise the fallback path too. The resulting blocks should always be dirty. v1:(Matthew) - move the size to the variable declaration section. - move the mm.clear_avail init to allocator init. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Problem statement: During the system boot time, an application request for the bulk volume of cleared range bias memory when the clear_avail is zero, we dont fallback into normal allocation method as we had an unnecessary clear_avail check which prevents the fallback method leads to fb allocation failure following system goes into unresponsive state. Solution: Remove the unnecessary clear_avail check in the range bias allocation function. v2: add a kunit for this corner case (Daniel Vetter) Signed-off-by:
-
- 13 May, 2024 10 commits
-
-
Mohamed Ahmed authored
Allow PTE kind and tile mode on BO create with VM_BIND, and add a GETPARAM to indicate this change. This is needed to support modifiers in NVK and ensure correctness when dealing with the nouveau GL driver. The userspace modifiers implementation this is for can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795 Fixes: b88baab8 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by:
Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by:
Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240509204352.7597-1-mohamedahmedegypt2001@gmail.com
-
Boris Brezillon authored
We need to undo what was done in panthor_sched_pre_reset() even if the reset failed. We just flag all previously running groups as terminated when that happens to unblock things. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502183813.1612017-5-boris.brezillon@collabora.com
-
Boris Brezillon authored
This way get NULL derefs instead of use-after-free if the FW VM is referenced after the device has been unplugged. Signed-off-by:
-
Boris Brezillon authored
Avoids use-after-free situations when panthor_fw_unplug() is called and the kernel BO was mapped to the FW VM. Signed-off-by:
-
Boris Brezillon authored
If the FW reports an unrecoverable fault, we need to reset the GPU before we can start re-using it again. Signed-off-by:
-
Boris Brezillon authored
Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle must be a handle previously returned by DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE. v4: - Add Steve's R-b v3: - New patch Signed-off-by:
-
Boris Brezillon authored
The heap ID is used to index the heap context pool, and allocating in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was originally to avoid returning a zero heap handle, but given the handle is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't end up with a valid heap handle that's zero. v4: - s/XA_FLAGS_ALLOC1/XA_FLAGS_ALLOC/ v3: - Allocate in the [0:MAX_HEAPS_PER_POOL-1] range v2: - New patch Fixes: 9cca48fa ("drm/panthor: Add the heap logical block") Reported-by:
Eric Smith <eric.smith@collabora.com> Signed-off-by:
-
Boris Brezillon authored
The field used to store the chunk size if 12 bits wide, and the encoding is chunk_size = chunk_header.chunk_size << 12, which gives us a theoretical [4k:8M] range. This range is further limited by implementation constraints, and all known implementations seem to impose a [128k:8M] range, so do the same here. We also relax the power-of-two constraint, which doesn't seem to exist on v10. This will allow userspace to fine-tune initial/max tiler memory on memory-constrained devices. v4: - Actually fix the range in the kerneldoc v3: - Add R-bs - Fix valid range in the kerneldoc v2: - Turn the power-of-two constraint into a page-aligned constraint to allow fine-tune of the initial/max heap memory size - Fix the panthor_heap_create() kerneldoc Fixes: 9cca48fa ("drm/panthor: Add the heap logical block") Signed-off-by:
-
Boris Brezillon authored
It doesn't make sense to have a maximum number of chunks smaller than the initial number of chunks attached to the context. Fix the uAPI header to reflect the new constraint, and mention the undocumented "initial_chunk_count > 0" constraint while at it. v3: - Add R-b v2: - Fix the check Fixes: 9cca48fa ("drm/panthor: Add the heap logical block") Signed-off-by:
-
Antonino Maniscalco authored
If the kernel couldn't allocate memory because we reached the maximum number of chunks but no render passes are in flight (panthor_heap_grow() returning -ENOMEM), we should defer the OOM handling to the FW by returning a NULL chunk. The FW will then call the tiler OOM exception handler, which is supposed to implement incremental rendering (execute an intermediate fragment job to flush the pending primitives, release the tiler memory that was used to store those primitives, and start over from where it stopped). Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow() return ENOMEM no matter the reason of this allocation failure, the FW doesn't care anyway. v3: - Add R-bs v2: - Make panthor_heap_grow() return -ENOMEM for all kind of allocation failures - Document the panthor_heap_grow() semantics Fixes: de854881 ("drm/panthor: Add the scheduler logical block") Signed-off-by:
Antonino Maniscalco <antonino.maniscalco@collabora.com> Signed-off-by:
-
- 10 May, 2024 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2024-05-09-1' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Use ordered WQ for G2H handler. (Matthew Brost) - Use flexible-array rather than zero-sized (Lucas De Marchi) Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2024-05-08' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.10-rc1: - panthor fixes. - Reverting Kconfig changes, and moving drm options to submenu. - Hide physical fb address in fb helper. - zynqmp bridge fix. - Revert broken ti-sn65dsi83 fix. Signed-off-by:
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
Updates for v6.10 Core: - Switched to generating register header files during build process instead of shipping pre-generated headers - Merged DPU and MDP4 format databases. DP: - Stop using compat string to distinguish DP and eDP cases - Added support for X Elite platform (X1E80100) - Reworked DP aux/audio support - Added SM6350 DP to the bindings (no driver changes, using SM8350 as a fallback compat) GPU: - a7xx perfcntr reg fixes - MAINTAINERS updates - a750 devcoredump support Signed-off-by:
-
- 09 May, 2024 2 commits
-
-
Lucas De Marchi authored
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arraysReported-by:
kernel test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506141917.205714-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit ee728423) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Matthew Brost authored
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506034758.3697397-1-matthew.brost@intel.com (cherry picked from commit 50aec966) Signed-off-by:
-
- 08 May, 2024 2 commits
-
-
Anatoliy Klymenko authored
Fix W=1 clang 19 compilation error in zynqmp_disp_layer_drm_formats(). Reported-by:
Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: b0f0469a ("drm: xlnx: zynqmp_dpsub: Anounce supported input formats") Link: https://patchwork.freedesktop.org/patch/msgid/20240426-dp-live-fmt-fix-v3-2-e904b5ae51d7@amd.com (cherry picked from commit c7221175) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de>
-
Anatoliy Klymenko authored
Fix arguments description for zynqmp_disp_layer_find_live_format() and zynqmp_disp_layer_set_live_format(). Reported-by:
-
- 07 May, 2024 2 commits
-
-
Dmitry Baryshkov authored
We don't need to run the validation of the XML files if we are just compiling the kernel. Skip the validation unless the user enables corresponding Kconfig option. This removes a warning from gen_header.py about lxml being not installed. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20240409120108.2303d0bd@canb.auug.org.au/Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/592558/Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
These tables were made non-const in commit 3cba4a2c ("drm/msm/a6xx: Update ROQ size in coredump") in order to avoid powering up the GPU when reading back a devcoredump. Instead let's just stash the count that is potentially read from hw in struct a6xx_gpu_state_obj, and make the tables const again. Signed-off-by:
-
- 05 May, 2024 2 commits
-
-
Connor Abbott authored
Add an a750 case to the various places where we choose a list of registers. Patchwork: https://patchwork.freedesktop.org/patch/592519/Signed-off-by:
Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/592519Signed-off-by:
-
Connor Abbott authored
Use the kgsl-style list of indices, because this is about to change for a750 and we want to reuse the downstream header directly. Patchwork: https://patchwork.freedesktop.org/patch/592520/Signed-off-by:
-
- 04 May, 2024 8 commits
-
-
Connor Abbott authored
Update to Mesa commit e82d70d472cc ("freedreno/a7xx: Add A7XX_HLSQ_DP_STR location from kgsl"). Signed-off-by: -
Connor Abbott authored
Add A7XX prefixes necessary because we use the same code for dumping a6xx and a7xx, fix register name prefixes for upstream, and use the upstream header. Patchwork: https://patchwork.freedesktop.org/patch/592517/Signed-off-by:
-
Connor Abbott authored
Import from kgsl commit 809ee24fe560. Signed-off-by:
-
Konrad Dybcio authored
Add myself as a reviewer for Adreno driver changes. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/590705/Signed-off-by:
-
Konrad Dybcio authored
The msm driver is.. gigantic and covers display hardware (incl. things concerning (e)DP, DSI, HDMI), as well as the entire lineup of Adreno GPUs (with hw bringup, memory mappings, userspace interaction etc.). Because of that, people listed as M:/R: receive patches concerning drivers for any part of the display block OR the GPU. Separate the latter, as it's both a functionally separate block and is of interest to different folks. Signed-off-by:
-
Konrad Dybcio authored
Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Fixes: 76efc245 ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: -
Zan Dobersek authored
a7xx_submit() should use the a7xx variant of the RBBM_PERFCTR_CP register for retrieving the CP cycles value before and after the submitted command stream execution. Signed-off-by:
Zan Dobersek <zdobersek@igalia.com> Fixes: af66706a ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/588445/Signed-off-by:
-
Zan Dobersek authored
In addition to the CP_PERFCTR_CP_SEL register range, allow writes to the CP_BV_PERFCTR_CP_SEL registers in the 0x8e0-0x8e6 range for profiling purposes of tools like fdperf and perfetto. Signed-off-by:
-
- 03 May, 2024 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2024-05-02' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Fix for a backmerge going slightly wrong. - An UAF fix - Avoid a WA error on LNL. Signed-off-by:
-
- 02 May, 2024 2 commits
-
-
Sean Anderson authored
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- Fixes: eb2d64bf ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Signed-off-by:
Sean Anderson <sean.anderson@linux.dev> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Luca Ceresoli authored
This reverts commit 8a91b29f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com (cherry picked from commit 2940ee03) Signed-off-by:
-
