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

[Navon John Lukose <navonjohnlukose@gmail.com>]

On Tue, Sep 22, 2026 at 12:57:31PM +0300, Andy Shevchenko wrote:
> Nobody will go with 0 in cpu_dma_latency. It basically kills the idea of CPU
> power states.

Agreed, and the patch does not ask anyone to. Holding it at 0 was how I
measured where the added latency comes from. Mika raised the same point and
there is more detail in that subthread:

https://lore.kernel.org/all/20260921170456.53354-1-navonjohnlukose@gmail.com/

> If you need a dynamic run-time PM QoS, patch the HID subsystem to
> make those when they want to heavily communicate with the HW.

A QoS request would bound the latency, AFAIK. It would not change that the
controller raises RX_FULL once per received byte, which is what this patch
is about, so I do not think one blocks the other.

> There is also the issue of the interrupt locality.

I am not sure what the i2c driver can do about that. What did you have in
mind?

Worth noting i2c_dw_configure_mode() sets TX_TL to half the FIFO and
RX_TL to 0 on adjacent lines, so a transmit interrupt moves up to half a
FIFO and a receive interrupt moves one byte, which is what this patch
changes.