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

[PATCH v2] 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().

The PCI spec asks for those 10 ms on D3hot->D0. Mika pointed out that the
LPSS controllers are not really PCI-connected devices, so the delay is
likely not needed. quirk_remove_d3hot_delay() drops it on several older
Intel chipsets, Cherry Trail among them, and commit 815b4448198f ("i3c:
mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel controllers") does the
same for the Intel I3C controllers.

Nothing misbehaves with the delay in place, so this only shortens resume.
On Arrow Lake-H (Lenovo Yoga Pro 7 14IAH10) the touchpad's I2C controller
autosuspends after 1 s idle, and the first report afterwards waits for the
resume. With d3hot_delay set to 0 the i2c-hid interrupt handler for that
report takes 1.1-1.9 ms instead of 12.6-14.4 ms, with no I2C errors. Only
Arrow Lake-H was tested.

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

Notes:
    Changes since RFC:
    - Drop RFC and add the review discussion to the changelog (Andy).
    
    RFC: https://lore.kernel.org/r/20261016114347.23633-1-navonjohnlukose@gmail.com

 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 v2] mfd: intel-lpss: Set d3hot_delay to 0

[Mika Westerberg]

On Thu, Oct 22, 2026 at 09:34:53AM +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().
> 
> The PCI spec asks for those 10 ms on D3hot->D0. Mika pointed out that the
> LPSS controllers are not really PCI-connected devices, so the delay is
> likely not needed. quirk_remove_d3hot_delay() drops it on several older
> Intel chipsets, Cherry Trail among them, and commit 815b4448198f ("i3c:
> mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel controllers") does the
> same for the Intel I3C controllers.
> 
> Nothing misbehaves with the delay in place, so this only shortens resume.
> On Arrow Lake-H (Lenovo Yoga Pro 7 14IAH10) the touchpad's I2C controller
> autosuspends after 1 s idle, and the first report afterwards waits for the
> resume. With d3hot_delay set to 0 the i2c-hid interrupt handler for that
> report takes 1.1-1.9 ms instead of 12.6-14.4 ms, with no I2C errors. Only
> Arrow Lake-H was tested.
> 
> Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

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

[Ilpo Järvinen]

On Thu, 22 Oct 2026, 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().
> 
> The PCI spec asks for those 10 ms on D3hot->D0. Mika pointed out that the

Please include the surname too. Since you'll have the email address in 
Mika's tag that's probably enough (otherwise you should include the email 
as well).

> LPSS controllers are not really PCI-connected devices, so the delay is
> likely not needed. quirk_remove_d3hot_delay() drops it on several older
> Intel chipsets, Cherry Trail among them, and commit 815b4448198f ("i3c:
> mipi-i3c-hci-pci: Set d3hot_delay to 0 for Intel controllers") does the
> same for the Intel I3C controllers.
> 
> Nothing misbehaves with the delay in place, so this only shortens resume.
> On Arrow Lake-H (Lenovo Yoga Pro 7 14IAH10) the touchpad's I2C controller
> autosuspends after 1 s idle, and the first report afterwards waits for the
> resume. With d3hot_delay set to 0 the i2c-hid interrupt handler for that
> report takes 1.1-1.9 ms instead of 12.6-14.4 ms, with no I2C errors. Only
> Arrow Lake-H was tested.

I don't like how this changelog is structured.

You should make it clear at the beginning that there's some delay 
(introducing the problem you're trying to address early) even if 
everything "works" with the delay and that the delay is due to default 10 
ms D3hot->D0 wait.

And only then proceed with in depth explanation about the delay and why 
it's not needed.

-- 
 i.

> Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>
> ---
> 
> Notes:
>     Changes since RFC:
>     - Drop RFC and add the review discussion to the changelog (Andy).
>     
>     RFC: https://lore.kernel.org/r/20261016114347.23633-1-navonjohnlukose@gmail.com
> 
>  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);
>