Re: [PATCH] i2c: designware: size the RX FIFO threshold to the queued transfer
From: Navon John Lukose
Date: Tue Sep 22 2026 - 11:40:44 EST
On Tue, Sep 22, 2026 at 02:29:02PM +0200, Mika Westerberg wrote:
> Yeah I don't think 0.7ms is much but we have things like touchscreens and
> the like with various report sizes so at least it would be good to check if
> those have any issues.
>
> Unfortunately I don't have any of such devices anymore but I asked our
> validation to check if they have something that could be used to test this.
I have a Goodix touchscreen on a second controller on the same machine, so
I ran it at three report sizes. GET_REPORT at 100 Hz, 2000 transfers per
cell, three interleaved passes, ~normal desktop use in the background:
bytes interrupts/report mean latency
7 4.17 -> 2.00 1776 -> 2093 us
21 10.06 -> 2.00 2131 -> 2676 us
64 63.97 -> 3.21 2303 -> 3512 us
64 bytes is past rx_fifo_depth on this part, so that is also the first
exercise of the half-FIFO cap.
So the latency is not a fixed 0.7 ms as I implied earlier, it grows with
the report size. Breaking down where it goes, with kprobes on i2c_dw_xfer
and i2c_dw_isr, for 64 bytes:
segment stock patched
xfer start -> first ISR 78 146
first ISR -> last ISR 2157 2748
last ISR -> xfer return 101 147
i2c-hid and ioctl overhead 12 49
84% of it is between the first and last interrupt. Stock's 65 interrupts
are 33 us apart, too close together for the CPU to idle deeply, so each
wakeup is cheap. Patched leaves 3 gaps of around 900 us, deep enough to
idle properly, and pays the exit latency on each one.
So the power saving and the added latency are the same effect seen from
either end. Lowering the cap trades one back for the other at roughly the
same rate, so if the latency needs bounding (I personally think it is
overkill) it wants a QoS request as Andy suggested.
I can send the raw data and the scripts if needed.
Assisted-by: LLM # for the kprobe measurements :)