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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Mon, Sep 21, 2026 at 10:34:56PM +0530, Navon John Lukose wrote:
> On Mon, Sep 21, 2026 at 02:05:26PM +0200, Mika Westerberg wrote:
> > I'm slightly worried about the latency increase here and the fact that
> > HIDIOCGINPUT is pretty much same as HID_REQ_GET_REPORT so it's not only
> > hidraw that is affected but everything else using HID_REQ_GET_REPORT as
> > well.
> 
> You are right, it is every HID_REQ_GET_REPORT user, not just hidraw.
> 
> The main motivation for this patch was cutting the wakeups from the
> interrupts, and I should have made that clearer. The /dev/cpu_dma_latency
> line was just to measure where the extra latency comes from.
> 
> What the wakeups cost, measured with a 21-byte HID GET_REPORT at 142 Hz
> pinned to one CPU, display off, 32 reps per arm in randomized order:
> 
>                         psys W
>     idle             1.87 +/- 0.28
>     patched          2.53 +/- 0.17
>     stock            4.11 +/- 0.44
> 
> Against the idle floor the polling costs 2.24 W without the patch and
> 0.66 W with it. Paired saving 1.58 W, 95% CI [1.42, 1.75].
> 
> So the added exit latency is the package idling deeper than it can when
> the controller interrupts once per received byte.

Yes power savings are always good but in this case it also affects the
latency visible to the user so we don't want devices like touchpads become
"sluggish" either. Do you see any such issues with the devices when you
have this enabled and not using /dev/cpu_dma_latency or any other interface
to limit the CPU low power states?