From: Troy Mitchell <troy.mitchell@linux.dev>
To: "Thomas Gleixner" <tglx@kernel.org>,
"Radu Rendec" <radu@rendec.net>,
"Anup Patel" <anup@brainfault.org>,
"Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Björn Töpel" <bjorn@rivosinc.com>
Cc: Anup Patel <apatel@ventanamicro.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-rt-devel@lists.linux.dev,
Troy Mitchell <troy.mitchell@linux.dev>
Subject: [PATCH v2 0/2] irqchip/riscv-imsic: Synchronize remote state with IRQ work
Date: Thu, 12 Nov 2026 07:54:31 +0000 [thread overview]
Message-ID: <20261112-imsic-remote-sync-irqwork-v2-0-680f65b24ff6@linux.dev> (raw)
This was found while bringing up the SoC timer on SpacemiT K3 as a tick
broadcast device.
Without a real broadcast device, the tick code falls back to the hrtimer
based broadcast, which keeps one CPU's local timer running. Once the SoC
timer is registered it replaces the hrtimer broadcast, and every CPU may
stop its local timer in idle.
On K3 the SoC timer interrupt goes through APLIC in MSI mode to IMSIC.
When the CPU owning it goes offline, the interrupt is moved to a CPU
that may already be idle with its local timer stopped. IMSIC leaves the
enable on the new target to a timer on that CPU, and that timer can only
fire through the broadcast interrupt, which is not enabled yet. The
system stalls.
Patch 1 makes remote synchronization use hard IRQ work, which fixes the
stall.
A vector move can still take long to finish. The CPU entering idle
takes over the broadcast interrupt and syncs the new vector before the
old CPU has released the old one, so it arms a retry timer on itself
with its tick already stopped. The move then completes only on its next
interrupt, up to 0.5s later on an idle K3, and affinity changes of the
IRQ return -EBUSY until then. Patch 2 lets the old CPU kick the new CPU
instead and removes the retry timer.
---
Changes in v2:
- Patch 1 unchanged.
- New patch 2: once the old CPU has released the old vector it queues the
sync work on the new CPU, which then completes the move from its own
IRQ work. The per-CPU retry timer is dropped, since a move that has to
wait for the old CPU could only complete on an interrupt driven by a
timer that may itself be stopped.
- Link to v1: https://patch.msgid.link/20261103-imsic-remote-sync-irqwork-v1-1-8b5c951fc62a@linux.dev
To: Thomas Gleixner <tglx@kernel.org>
To: Radu Rendec <radu@rendec.net>
To: Anup Patel <anup@brainfault.org>
To: Paul Walmsley <pjw@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
To: Albert Ou <aou@eecs.berkeley.edu>
To: Alexandre Ghiti <alex@ghiti.fr>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Clark Williams <clrkwllms@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
To: Björn Töpel <bjorn@rivosinc.com>
Cc: Anup Patel <apatel@ventanamicro.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: linux-rt-devel@lists.linux.dev
---
Troy Mitchell (2):
irqchip/riscv-imsic: Synchronize remote state with IRQ work
irqchip/riscv-imsic: Complete vector moves without a timer
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-riscv-imsic-early.c | 5 +-
drivers/irqchip/irq-riscv-imsic-state.c | 87 ++++++++++++++-------------------
drivers/irqchip/irq-riscv-imsic-state.h | 6 +--
4 files changed, 42 insertions(+), 57 deletions(-)
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20261103-imsic-remote-sync-irqwork-9cfec6c410de
Best regards,
--
Troy Mitchell <troy.mitchell@linux.dev>
next reply other threads:[~2026-11-12 7:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 7:54 Troy Mitchell [this message]
2026-11-12 7:54 ` [PATCH v2 1/2] " Troy Mitchell
2026-11-12 7:54 ` [PATCH v2 2/2] irqchip/riscv-imsic: Complete vector moves without a timer Troy Mitchell
2026-11-12 8:35 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112-imsic-remote-sync-irqwork-v2-0-680f65b24ff6@linux.dev \
--to=troy.mitchell@linux.dev \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=bigeasy@linutronix.de \
--cc=bjorn@rivosinc.com \
--cc=clrkwllms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=radu@rendec.net \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®