From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Navon John Lukose" <navonjohnlukose@gmail.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Lee Jones" <lee@kernel.org>,
mfd@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] mfd: intel-lpss: Set d3hot_delay to 0
Date: Mon, 19 Oct 2026 06:34:37 +0200 [thread overview]
Message-ID: <20261019043437.GY176164@black.igk.intel.com> (raw)
In-Reply-To: <atIjpJn1Y0GPmQbP@ashevche-desk.local>
Hi,
On Fri, Oct 16, 2026 at 04:16:20PM +0300, Andy Shevchenko wrote:
> 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?
Like you say it's requirement of the PCI spec. However, since these are
really not PCI connected devices the delay likely is not needed as seen
here. No objections from my side.
prev parent reply other threads:[~2026-10-19 4:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 11:43 Navon John Lukose
2026-10-16 13:16 ` Andy Shevchenko
2026-10-16 13:33 ` Navon John Lukose
2026-10-19 4:34 ` Mika Westerberg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261019043437.GY176164@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfd@lists.linux.dev \
--cc=navonjohnlukose@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®