From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B271C3AA4EB for ; Thu, 25 Jun 2026 12:43:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782391402; cv=none; b=r+GQ6cRDMrlt9EeyRf669GlTr3ugwzuX7POSPQPN47KjNslArppqLxaPpyjD+gtW6tz2aNajOqtRIJfhmcxhwhZQtLpft97a45LH7oDc8Y7Uk3PE0NMu8FG1oI2haMX9bnXnkFYZBXCBVICr/wyKqfQDXpfpnrFWeKHJ4uNZuVY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782391402; c=relaxed/simple; bh=l/HmvLeKbqzUTyJ+tBW+QxidJ66+fgQQlz4MoTP4rig=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HF7pmK4ESp+f5kUe/wzTKwCx28BOU8ddrVFZ8Eeee7j9DlIgOcTPR7tO62Bq8zqrm2zn/xccXogPc/Q/IjfwQu/bGwY6WAxM+qf6hHISG1v0mC/sbkQT6ezZU/H+ls13eSanaWgtKJZI1QC6yizeFYzfWyRsl70/7RGx7M/rhmg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=TWjGaG1h; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="TWjGaG1h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1782391399; bh=l/HmvLeKbqzUTyJ+tBW+QxidJ66+fgQQlz4MoTP4rig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TWjGaG1hb7io//YzYGJrvlINU1BMsI9iXMicHEiQPnNy5dNKvytzhyPC4+o4lQ398 hIwC3i4y893i6OaRAvU93xm1Sa9xnaNG5RtFvmMOQjITmHHkF9nE/VXJu9AmE/VZzi KZuQIowq0GUaWm853ieQNCE6W1YCQiBBVtclZe+t5cDdgg6pba0n7wBGjvimRjmTKv jRed/hqnZ6LUZYWhCB41Rvc6JQAvRKKsqz4ZeECniIzZZm702HXN/2mXhqRhq1JPrk QyFkCfwCD9oBLn7IIZ6rIV/yPFG4Idl74lL4a+0hb02MOD7K+ZbWBhhOiJuyl4kur6 TKskq+eqLssnQ== Received: from fedora-2.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 9541817E0C88; Thu, 25 Jun 2026 14:43:18 +0200 (CEST) Date: Thu, 25 Jun 2026 14:43:13 +0200 From: Boris Brezillon To: Steven Price , Liviu Dudau , Chia-I Wu Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, sashiko-bot@kernel.org Subject: Re: [PATCH v5 00/16] drm/panthor: Reduce dma_fence signalling latency Message-ID: <20260625144313.5a9c872f@fedora-2.home> In-Reply-To: <20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com> References: <20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 25 Jun 2026 11:36:15 +0200 Boris Brezillon 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. > > Sorry for the high submission rate (v4 was sent this morning), > but I'd like get the remaining blockers out of the way, and > shashiko keeps finding new legitimate issues :-). > > Signed-off-by: Boris Brezillon > --- > 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/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com > > Changes in v4: > - Add a bunch of fixes for bugs reported by shashiko > - Link to v3: https://lore.kernel.org/r/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com > > 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/20260512-panthor-signal-from-irq-v2-0-95c614a739cb@collabora.com > > 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/20260429-panthor-signal-from-irq-v1-0-4b92ae4142d2@collabora.com > > --- > Boris Brezillon (16): > drm/panthor: Fix theoretical IOMEM access in suspended state > drm/panthor: Don't overrule pending immediate ticks in sched_resume_tick() > drm/panthor: Fix panthor_pwr_unplug() > drm/panthor: Drop a needless check in panthor_fw_unplug() > drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced > drm/panthor: Interrupt group start/resumption if group_bind_locked() fails > drm/panthor: Keep interrupts masked until they are needed If you're reviewing this version, please ignore anything coming before patch 8, since those have been re-posted as a separate misc-fixes series[1]. Thanks, Boris > 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 [1]https://lore.kernel.org/dri-devel/20260625-panthor-misc-fixes-v1-0-b67ed973fea6@collabora.com/T/#t