On Tue, 25 Aug 2026 10:01:21 +0200
Boris Brezillon <[email protected]> wrote:

> Right now, panthor is one of the rare drivers to signal fences
> from work items (not even from the threaded IRQ handler). We
> tried moving the job_completion check to hardirq handlers like
> other drivers do, but the duration of this handler gets
> slightly over the few usec (20+ usecs) we usually expect from
> hardird handlers, and we're not sure we want to hold off the
> processing of other interrupts for that long. So this series
> just gets rid of the threaded-handler -> work_item indirection
> and checks for job completion (and thus, fence signalling)
> directly in the threaded handler.
> 
> Signed-off-by: Boris Brezillon <[email protected]>

Queued to drm-misc-next.

> ---
> Changes in v7:
> - Adjust scg_slots comment to reflect the fact the priority field needs
>   to be accessed with panthor_scheduler::lock held
> - Don't disable IRQs when acquiring the fdinfo lock
> - Link to v6: 
> https://patch.msgid.link/[email protected]
> 
> Changes in v6:
> - Rebase on drm-misc-next
> - Link to v5: 
> https://lore.kernel.org/r/[email protected]
> 
> Changes in v5:
> - Add a fix for a theoretical IOMEM access in suspended state (patch 1)
> - Make sure we don't delay a pending immediate tick in
>   sched_resume_tick() (patch 2)
> - Make sure we initialize panthor_irq::state properly in the irq_request
>   helper
> - Link to v4: 
> https://lore.kernel.org/r/[email protected]
> 
> Changes in v4:
> - Add a bunch of fixes for bugs reported by shashiko
> - Link to v3: 
> https://lore.kernel.org/r/[email protected]
> 
> Changes in v3:
> - Save/restore the irq state in the raw handler.
> - Rename panthor_irq::mask_lock into panthor_irq::lock
> - Use the __always_inline specifier on
>   panthor_irq_default_threaded_handler()
> - Use devm_request_threaded_irq() even when the threaded handler is
>   NULL
> - Drop the patch that dynamically enables request-related interrupts
>   (FW-side race) after the polling period has expired
> - Don't process FW events from the hardirq handler (too heavy for an
>   hardirq handler according to our testing)
> - Link to v2: 
> https://lore.kernel.org/r/[email protected]
> 
> Changes in v2:
> - Fix commit message in patch 4
> - Move devm_kasprintf() before panthor_irq_resume() in patch 3
> - Fix erroneous lockdep_assert_held() in patch 6
> - Make sure events_lock is held when calling
>   csg_slot_sync_update_locked() in patch 6
> - Restore a csg_slot_sync_update_locked() call in patch 7
> - Fix a potential deadlock in patch 9
> - Drop the IRQ coalescing patch (formerly patch 10)
> - Change panthor_irq_request() so we don't have to define a dummy
>   threaded handler, and we can let RT kernels move the hard handler
>   to a thread
> - Add patches to transition GPU event processing to the hard IRQ handler
> - Link to v1: 
> https://lore.kernel.org/r/[email protected]
> 
> ---
> Boris Brezillon (9):
>       drm/panthor: Make panthor_irq::state a non-atomic field
>       drm/panthor: Move the register accessors before the IRQ helpers
>       drm/panthor: Replace the panthor_irq macro machinery by inline helpers
>       drm/panthor: Don't update might_have_idle_groups in 
> process_idle_event_locked()
>       drm/panthor: Get rid of panthor_group::fatal_lock
>       drm/panthor: Protect events processing with a separate spinlock
>       drm/panthor: Don't defer job completion checks
>       drm/panthor: Don't defer FW event processing
>       drm/panthor: Automate CSG IRQ processing at group unbind time
> 
>  drivers/gpu/drm/panthor/panthor_device.h | 286 ++++++++---------
>  drivers/gpu/drm/panthor/panthor_fw.c     |  22 +-
>  drivers/gpu/drm/panthor/panthor_gpu.c    |  28 +-
>  drivers/gpu/drm/panthor/panthor_mmu.c    |  39 +--
>  drivers/gpu/drm/panthor/panthor_pwr.c    |  24 +-
>  drivers/gpu/drm/panthor/panthor_sched.c  | 518 
> +++++++++++++++----------------
>  6 files changed, 452 insertions(+), 465 deletions(-)
> ---
> base-commit: b961eb36d7b04147104cff2fd8bc0e94f4713324
> change-id: 20260429-panthor-signal-from-irq-d33684f4d292
> 
> Best regards,
> --  
> Boris Brezillon <[email protected]>
> 

Reply via email to