Re: [PATCH] i2c: designware: size the RX FIFO threshold to the queued transfer

[Mika Westerberg]

Hi,

On Tue, Sep 22, 2026 at 06:53:34PM +0530, Navon John Lukose wrote:
> 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.

Turns out they don't have touch screens either :(

> 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.

Okay thanks for checking this. If the latency stays in low single digit ms
I think that's fine.

> 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 agree. Just wanted to check that there are no user visible (negative)
side-effects.

So no objections from me,

Acked-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>