kernel/linux.git/drivers/gpu/drm/panfrost, branch v5.10.46

drm/panfrost: Don't try to map pages that are already mapped

2021-05-14T07:50:01+00:00

commit f45da8204ff1707c529a8769f5467ff16f504b26 upstream. We allocate 2MB chunks at a time, so it might appear that a page fault has already been handled by a previous page fault when we reach panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the same area twice. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-3-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Clear MMU irqs before handling the fault

2021-05-14T07:50:00+00:00

commit 3aa0a80fc692c9959c261f4c5bfe9c23ddd90562 upstream. When a fault is handled it will unblock the GPU which will continue executing its shader and might fault almost immediately on a different page. If we clear interrupts after handling the fault we might miss new faults, so clear them before. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Support cache-coherent integrations

2021-02-07T14:37:12+00:00

commit 268af50f38b1f2199a2e85e38073d7a25c20190c upstream. When the GPU's ACE-Lite interface is fully wired up and capable of snooping CPU caches, it may be described as "dma-coherent" in devicetree, which will already inform the DMA layer not to perform unnecessary cache maintenance. However, we still need to ensure that the GPU uses the appropriate cacheable outer-shareable attributes in order to generate the requisite snoop signals, and that CPU mappings don't create a mismatch by using a non-cacheable type either. Signed-off-by: Robin Murphy Tested-by: Neil Armstrong Reviewed-by: Steven Price Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/7024ce18c1cb1a226e918037d49175571db0b436.1600780574.git.robin.murphy@arm.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Remove unused variables in panfrost_job_close()

2021-01-17T13:17:06+00:00

commit 7d6763ab77b3c047cf7d31ca7c4b799808a684a6 upstream. Commit a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on open/close") left unused variables behind, thus generating a warning at compilation time. Remove those variables. Fixes: a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on open/close") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20201101173817.831769-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Don't corrupt the queue mutex on open/close

2021-01-17T13:16:53+00:00

[ Upstream commit a17d609e3e216c406f7c0cec2a94086a4401ac06 ] The mutex within the panfrost_queue_state should have the lifetime of the queue, however it was erroneously initialised/destroyed during panfrost_job_{open,close} which is called every time a client opens/closes the drm node. Move the initialisation/destruction to panfrost_job_{init,fini} where it belongs. Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling") Signed-off-by: Steven Price Reviewed-by: Boris Brezillon Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20201029170047.30564-1-steven.price@arm.com Signed-off-by: Sasha Levin

drm/panfrost: Move the GPU reset bits outside the timeout handler

2020-12-30T10:54:19+00:00

commit 5bc5cc2819c2c0adb644919e3e790b504ea47e0a upstream. We've fixed many races in panfrost_job_timedout() but some remain. Instead of trying to fix it again, let's simplify the logic and move the reset bits to a separate work scheduled when one of the queue reports a timeout. v5: - Simplify panfrost_scheduler_stop() (Steven Price) - Always restart the queue in panfrost_scheduler_start() even if the status is corrupted (Steven Price) v4: - Rework the logic to prevent a race between drm_sched_start() (reset work) and drm_sched_job_timedout() (timeout work) - Drop Steven's R-b - Add dma_fence annotation to the panfrost_reset() function (Daniel Vetter) v3: - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy) - Add Steven's R-b v2: - Use atomic_cmpxchg() to conditionally schedule the reset work (Steven Price) Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20201105151704.2010667-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Fix job timeout handling

2020-12-30T10:54:18+00:00

commit 1a11a88cfd9a97e13be8bc880c4795f9844fbbec upstream. If more than two jobs end up timeout-ing concurrently, only one of them (the one attached to the scheduler acquiring the lock) is fully handled. The other one remains in a dangling state where it's no longer part of the scheduling queue, but still blocks something in scheduler, leading to repetitive timeouts when new jobs are queued. Let's make sure all bad jobs are properly handled by the thread acquiring the lock. v3: - Add Steven's R-b - Don't take the sched_lock when stopping the schedulers v2: - Fix the subject prefix - Stop the scheduler before returning from panfrost_job_timedout() - Call cancel_delayed_work_sync() after drm_sched_stop() to make sure no timeout handlers are in flight when we reset the GPU (Steven Price) - Make sure we release the reset lock before restarting the schedulers (Steven Price) Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20201002122506.1374183-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Fix module unload

2020-11-03T08:43:57+00:00

When unloading the call to pm_runtime_put_sync_suspend() will attempt to turn the GPU cores off, however panfrost_device_fini() will have turned the clocks off. This leads to the hardware locking up. Instead don't call pm_runtime_put_sync_suspend() and instead simply mark the device as suspended using pm_runtime_set_suspended(). And also include this on the error path in panfrost_probe(). Fixes: aebe8c22a912 ("drm/panfrost: Fix possible suspend in panfrost_remove") Signed-off-by: Steven Price Reviewed-by: Tomeu Vizoso Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20201030145833.29006-1-steven.price@arm.com

drm/panfrost: Fix a deadlock between the shrinker and madvise path

2020-11-03T08:21:52+00:00

panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings and shmem locks in different orders, thus leading to a potential the mappings lock first. Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept") Cc: Cc: Christian Hewitt Reported-by: Christian Hewitt Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20201101174016.839110-1-boris.brezillon@collabora.com

Merge tag 'drm-misc-next-fixes-2020-10-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2020-10-13T21:31:53+00:00

One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a timeout at power up. Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201013065709.lwjw3fthoxwsbqsl@gilmour.lan