[PATCH RFC] mfd: intel-lpss: Set d3hot_delay to 0

[PATCH RFC] mfd: intel-lpss: Set d3hot_delay to 0

[Navon John Lukose]

intel-lpss-pci already clears d3cold_delay, but every runtime resume of an
LPSS controller still sleeps the default 10 ms d3hot_delay in
pci_power_up().

On Arrow Lake-H (Lenovo Yoga Pro 7 14IAH10) the delay costs 8-16 ms per
resume of the touchpad's I2C controller, which lands on the first
touchpad report after each 1 s autosuspend. With d3hot_delay set to 0 the
power-up takes 64-256 us and the I2C transfers that follow complete
without errors.

Commit 815b4448198f ("i3c: mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel
controllers") does the same for the Intel I3C controllers.

Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>
---

Notes:
    RFC because I could only test Arrow Lake-H, and this applies to every LPSS
    generation the driver handles, back to Sunrise Point. Andy, do any of the
    older ones need the D3hot->D0 delay? If so I can limit it to newer IDs
    through the driver data.

 drivers/mfd/intel-lpss-pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 63a3fb58566..5672f033e5c 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -70,6 +70,7 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev,
 		info->quirks = quirk_pci_info->driver_data;
 
 	pdev->d3cold_delay = 0;
+	pdev->d3hot_delay = 0;
 
 	/* Probably it is enough to set this for iDMA capable devices only */
 	pci_set_master(pdev);
-- 
2.56.0

Re: [PATCH RFC] mfd: intel-lpss: Set d3hot_delay to 0

[Andy Shevchenko]

On Fri, Oct 16, 2026 at 05:13:47PM +0530, Navon John Lukose wrote:
> intel-lpss-pci already clears d3cold_delay, but every runtime resume of an
> LPSS controller still sleeps the default 10 ms d3hot_delay in
> pci_power_up().
> 
> On Arrow Lake-H (Lenovo Yoga Pro 7 14IAH10) the delay costs 8-16 ms per
> resume of the touchpad's I2C controller, which lands on the first
> touchpad report after each 1 s autosuspend. With d3hot_delay set to 0 the
> power-up takes 64-256 us and the I2C transfers that follow complete
> without errors.

So, do you state that this patch fixes some bad touchpad behaviour? If so,
please, provide some logs.

> Commit 815b4448198f ("i3c: mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel
> controllers") does the same for the Intel I3C controllers.

Okay, it means they were tested.

...

> Notes:
>     RFC because I could only test Arrow Lake-H, and this applies to every LPSS
>     generation the driver handles, back to Sunrise Point. Andy, do any of the
>     older ones need the D3hot->D0 delay? If so I can limit it to newer IDs
>     through the driver data.

AFAIK 10 ms for D3hot delay is in accordance with PCI specification.
Yes, we use quirk_remove_d3hot_delay() for very old Intel Atom SoCs,
but I have no idea about Skylake line of products.

Mika, Ilpo, do you have any ideas or comments on this?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] mfd: intel-lpss: Set d3hot_delay to 0

[Navon John Lukose]

On Fri, Oct 16, 2026 at 04:16:20PM +0300, Andy Shevchenko wrote:
> So, do you state that this patch fixes some bad touchpad behaviour? If so,
> please, provide some logs.

No, nothing misbehaves without it, so this is only an optimisation. It
shortens the first touchpad report after the controller has autosuspended.
I went after it because the driver already clears d3cold_delay and the
D3hot one looked like it had been missed.

I timed the i2c-hid threaded IRQ handler for the touchpad (CIRQ1080 behind
00:15.0) with bpftrace, switching d3hot_delay at runtime:

                                   d3hot_delay=10   d3hot_delay=0
  controller already awake         ~1.1 ms          ~1.1 ms
  controller resumed in handler    12.6-14.4 ms     1.1-1.9 ms

There were no I2C errors with either value. That is about 12 ms saved once
per idle period, which is not much. If nobody can vouch for the older
generations, limiting it to newer IDs or dropping it is fine with me.