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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Sep 22, 2026 at 05:42:49PM +0530, Navon John Lukose wrote:
> 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?

i2c-hid

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

-- 
With Best Regards,
Andy Shevchenko