* [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI
@ 2026-08-10 1:30 Stanley Chu
2026-08-10 18:27 ` Mukesh Savaliya
2026-09-17 14:51 ` Alexandre Belloni
0 siblings, 2 replies; 3+ messages in thread
From: Stanley Chu @ 2026-08-10 1:30 UTC (permalink / raw)
To: frank.li, miquel.raynal, alexandre.belloni, linux-i3c
Cc: linux-kernel, tomer.maimon, kwliu, yschu
From: Stanley Chu <yschu@nuvoton.com>
The IBI (In-Band Interrupt) workqueue is allocated with only
WQ_MEM_RECLAIM, which places IBI payload processing at normal
worker priority. This is inadequate given the time-sensitive
nature of IBI handling.
In the I3C protocol, when a target asserts an IBI, the SDA line
is held low until the master acknowledges and completes the
exchange. The IRQ handler (top half) ACKs the IBI, reads the
payload, emits a STOP, and immediately queues the payload
processing to the per-device ordered workqueue via
i3c_master_queue_ibi() — effectively the bottom half of the
IBI interrupt path.
If this workqueue worker is delayed by competing normal-priority
tasks, the IBI notification reaches the client driver late. For
latency-sensitive clients (e.g. sensors reporting alerts,
hotplug events), this defeats the purpose of using IBI over
polling. Furthermore, because the ordered workqueue serialises
slots, a backlog of delayed slots can exhaust the pre-allocated
IBI slot pool, causing subsequent IBIs to be dropped at the
hardware level.
Add WQ_HIGHPRI to ensure IBI bottom-half work is scheduled
promptly after the top-half IRQ handler enqueues it, keeping
the IBI processing pipeline consistent with the interrupt-like
semantics the protocol demands.
Signed-off-by: Stanley Chu <yschu@nuvoton.com>
---
drivers/i3c/master.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index f1be38a640ca..8fdd67a031ff 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -3505,7 +3505,8 @@ int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev,
if (!ibi)
return -ENOMEM;
- ibi->wq = alloc_ordered_workqueue(dev_name(i3cdev_to_dev(dev->dev)), WQ_MEM_RECLAIM);
+ ibi->wq = alloc_ordered_workqueue(dev_name(i3cdev_to_dev(dev->dev)),
+ WQ_MEM_RECLAIM | WQ_HIGHPRI);
if (!ibi->wq) {
kfree(ibi);
return -ENOMEM;
--
2.34.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI
2026-08-10 1:30 [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI Stanley Chu
@ 2026-08-10 18:27 ` Mukesh Savaliya
2026-09-17 14:51 ` Alexandre Belloni
1 sibling, 0 replies; 3+ messages in thread
From: Mukesh Savaliya @ 2026-08-10 18:27 UTC (permalink / raw)
To: Stanley Chu, frank.li, miquel.raynal, alexandre.belloni, linux-i3c
Cc: linux-kernel, tomer.maimon, kwliu, yschu
On 8/10/2026 7:00 AM, Stanley Chu wrote:
> From: Stanley Chu <yschu@nuvoton.com>
>
> The IBI (In-Band Interrupt) workqueue is allocated with only
> WQ_MEM_RECLAIM, which places IBI payload processing at normal
> worker priority. This is inadequate given the time-sensitive
> nature of IBI handling.
>
> In the I3C protocol, when a target asserts an IBI, the SDA line
> is held low until the master acknowledges and completes the
> exchange. The IRQ handler (top half) ACKs the IBI, reads the
> payload, emits a STOP, and immediately queues the payload
> processing to the per-device ordered workqueue via
> i3c_master_queue_ibi() — effectively the bottom half of the
> IBI interrupt path.
>
> If this workqueue worker is delayed by competing normal-priority
> tasks, the IBI notification reaches the client driver late. For
> latency-sensitive clients (e.g. sensors reporting alerts,
> hotplug events), this defeats the purpose of using IBI over
> polling. Furthermore, because the ordered workqueue serialises
> slots, a backlog of delayed slots can exhaust the pre-allocated
> IBI slot pool, causing subsequent IBIs to be dropped at the
> hardware level.
>
> Add WQ_HIGHPRI to ensure IBI bottom-half work is scheduled
> promptly after the top-half IRQ handler enqueues it, keeping
> the IBI processing pipeline consistent with the interrupt-like
> semantics the protocol demands.
>
> Signed-off-by: Stanley Chu <yschu@nuvoton.com>
> ---
Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI
2026-08-10 1:30 [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI Stanley Chu
2026-08-10 18:27 ` Mukesh Savaliya
@ 2026-09-17 14:51 ` Alexandre Belloni
1 sibling, 0 replies; 3+ messages in thread
From: Alexandre Belloni @ 2026-09-17 14:51 UTC (permalink / raw)
To: frank.li, miquel.raynal, linux-i3c, Stanley Chu
Cc: linux-kernel, tomer.maimon, kwliu, yschu
On Mon, 10 Aug 2026 09:30:59 +0800, Stanley Chu wrote:
> The IBI (In-Band Interrupt) workqueue is allocated with only
> WQ_MEM_RECLAIM, which places IBI payload processing at normal
> worker priority. This is inadequate given the time-sensitive
> nature of IBI handling.
>
> In the I3C protocol, when a target asserts an IBI, the SDA line
> is held low until the master acknowledges and completes the
> exchange. The IRQ handler (top half) ACKs the IBI, reads the
> payload, emits a STOP, and immediately queues the payload
> processing to the per-device ordered workqueue via
> i3c_master_queue_ibi() — effectively the bottom half of the
> IBI interrupt path.
>
> [...]
Applied, thanks!
[1/1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI
https://git.kernel.org/i3c/c/591980aaaa46
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-17 14:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-10 1:30 [PATCH v1] i3c: master: allocate IBI workqueue with WQ_HIGHPRI Stanley Chu
2026-08-10 18:27 ` Mukesh Savaliya
2026-09-17 14:51 ` Alexandre Belloni
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®