kernel/drivers/gpu/drm/panfrost, branch linux-6.9.y

drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()

2024-04-04T15:11:01Z

Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called. Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Cc: Reviewed-by: Steven Price Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Boris Brezillon Co-developed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20240105184624.508603-18-dmitry.osipenko@collabora.com

drm/panfrost: fix power transition timeout warnings

2024-03-28T16:23:10Z

Increase the timeout value to prevent system logs on Amlogic boards flooding with power transition warnings: [ 13.047638] panfrost ffe40000.gpu: shader power transition timeout [ 13.048674] panfrost ffe40000.gpu: l2 power transition timeout [ 13.937324] panfrost ffe40000.gpu: shader power transition timeout [ 13.938351] panfrost ffe40000.gpu: l2 power transition timeout ... [39829.506904] panfrost ffe40000.gpu: shader power transition timeout [39829.507938] panfrost ffe40000.gpu: l2 power transition timeout [39949.508369] panfrost ffe40000.gpu: shader power transition timeout [39949.509405] panfrost ffe40000.gpu: l2 power transition timeout The 2000 value has been found through trial and error testing with devices using G52 and G31 GPUs. Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()") Signed-off-by: Christian Hewitt Reviewed-by: Steven Price Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20240322164525.2617508-1-christianshewitt@gmail.com

Backmerge tag 'v6.7-rc5' into drm-next

2023-12-12T01:32:33Z

Linux 6.7-rc5 Alex requested this for some amdkfd work relying on the symbols exports. Signed-off-by: Dave Airlie

drm/panfrost: Synchronize and disable interrupts before powering off

2023-12-05T10:39:59Z

To make sure that we don't unintentionally perform any unclocked and/or unpowered R/W operation on GPU registers, before turning off clocks and regulators we must make sure that no GPU, JOB or MMU ISR execution is pending: doing that requires to add a mechanism to synchronize the interrupts on suspend. Add functions panfrost_{gpu,job,mmu}_suspend_irq() which will perform interrupts masking and ISR execution synchronization, and then call those in the panfrost_device_runtime_suspend() handler in the exact sequence of job (may require mmu!) -> mmu -> gpu. As a side note, JOB and MMU suspend_irq functions needed some special treatment: as their interrupt handlers will unmask interrupts, it was necessary to add an `is_suspended` bitmap which is used to address the possible corner case of unintentional IRQ unmasking because of ISR execution after a call to synchronize_irq(). At resume, clear each is_suspended bit in the reset path of JOB/MMU to allow unmasking the interrupts. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Boris Brezillon Tested-by: Marek Szyprowski Reviewed-by: Steven Price Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20231204114215.54575-4-angelogioacchino.delregno@collabora.com

drm/panfrost: Add gpu_irq, mmu_irq to struct panfrost_device

2023-12-05T10:39:57Z

In preparation for adding a IRQ synchronization mechanism for PM suspend, add gpu_irq and mmu_irq variables to struct panfrost_device and change functions panfrost_gpu_init() and panfrost_mmu_init() to use those. Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: AngeloGioacchino Del Regno Tested-by: Marek Szyprowski Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20231204114215.54575-3-angelogioacchino.delregno@collabora.com

drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq

2023-12-05T10:39:57Z

Some SoCs may be equipped with a GPU containing two core groups and this is exactly the case of Samsung's Exynos 5422 featuring an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost is partial, as this driver currently supports using only one core group and that's reflected on all parts of it, including the power on (and power off, previously to this patch) function. The issue with this is that even though executing the soft reset operation should power off all cores unconditionally, on at least one platform we're seeing a crash that seems to be happening due to an interrupt firing which may be because we are calling power transition only on the first core group, leaving the second one unchanged, or because ISR execution was pending before entering the panfrost_gpu_power_off() function and executed after powering off the GPU cores, or all of the above. Finally, solve this by: - Avoid to enable the power transition interrupt on reset; and - Ignoring the core_mask and ask the GPU to poweroff both core groups Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()") Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: AngeloGioacchino Del Regno Tested-by: Marek Szyprowski Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20231204114215.54575-2-angelogioacchino.delregno@collabora.com

drm/panfrost: Fix incorrect updating of current device frequency

2023-11-30T10:53:42Z

It was noticed when setting the Panfrost's DVFS device to the performant governor, GPU frequency as reported by fdinfo had dropped to 0 permamently. There are two separate issues causing this behaviour: - Not initialising the device's current_frequency variable to its original value during device probe(). - Updating said variable in Panfrost devfreq's get_dev_status() rather than after the new OPP's frequency had been retrieved in target(), which meant the old frequency would be assigned instead. Signed-off-by: Adrián Larumbe Fixes: f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics") Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20231125205438.375407-3-adrian.larumbe@collabora.com

drm/panfrost: Consider dma-buf imported objects as resident

2023-11-30T10:53:07Z

A GEM object constructed from a dma-buf imported sgtable should be regarded as being memory resident, because the dma-buf API mandates backing storage to be allocated when attachment succeeds. Signed-off-by: Adrián Larumbe Fixes: 9ccdac7aa822 ("drm/panfrost: Add fdinfo support for memory stats") Reported-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20231125205438.375407-2-adrian.larumbe@collabora.com

Merge drm/drm-next into drm-misc-next

2023-11-15T09:56:44Z

Let's kickstart the v6.8 release cycle. Signed-off-by: Maxime Ripard

drm/panfrost: Set regulators on/off during system sleep on MediaTek SoCs

2023-11-10T14:12:23Z

All of the MediaTek SoCs supported by Panfrost can completely cut power to the GPU during full system sleep without any user-noticeable delay in the resume operation, as shown by measurements taken on multiple MediaTek SoCs (MT8183/86/92/95). As an example, for MT8195 - a "before" with only runtime PM operations (so, without turning on/off regulators), and an "after" executing both the system sleep .resume() handler and .runtime_resume() (so the time refers to T_Resume + T_Runtime_Resume): Average Panfrost-only system sleep resume time, before: ~33500ns Average Panfrost-only system sleep resume time, after: ~336200ns Keep in mind that this additional ~308200 nanoseconds delay happens only in resume from a full system suspend, and not in runtime PM operations, hence it is acceptable. Measurements were also taken on MT8186, showing a delay of ~312000 ns. Testing of this happened on all of the aforementioned MediaTek SoCs, but: MT8183 got tested only by KernelCI with <=10 suspend/resume cycles MT8186, MT8192, MT8195 were tested manually with over 100 suspend/resume cycles with GNOME DE (Mutter + Wayland). Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20231109102543.42971-7-angelogioacchino.delregno@collabora.com