From: d3z <d3z.the.dev@gmail.com>
To: even.xu@intel.com, xinpeng.sun@intel.com, jikos@kernel.org,
bentiss@kernel.org
Cc: "Danny D ." <d3z.the.dev@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
abhishektamboli9@gmail.com, sakari.ailus@linux.intel.com
Subject: Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
Date: Tue, 2 Jun 2026 18:13:15 +0300 [thread overview]
Message-ID: <20260602151317.27768-1-d3z.the.dev@gmail.com> (raw)
In-Reply-To: <IA1PR11MB60985A7B3D9EA4583C2DDBF7F4122@IA1PR11MB6098.namprd11.prod.outlook.com>
From: Danny D. <d3z.the.dev@gmail.com>
Hi Even,
Good way to split it - "touch IC off" vs "THC power-gated" - so I ran the
reset_tic()-only test you asked for.
I added just reset_tic() to a pristine quickspi_resume(), with none of the
THC reconfig (no thc_spi_*_config, no thc_ltr_*). On the Surface Pro 10,
after an s2idle suspend/resume, the touchscreen does NOT come back - so
reset_tic() alone isn't enough here.
The interesting bit is why. The one new line on resume is:
intel_quickspi 0000:00:10.0: THC interrupt already unquiesce
That's reset_tic() -> thc_interrupt_quiesce(dev, false) finding
DEVINT_QUIESCE_EN already clear - even though quickspi_suspend() set it in
suspend. thc_regmap is REGCACHE_NONE, so that's the real register, not a
cached value. So the THC port-control state we wrote in suspend is gone
after resume.
That's your second case: the THC itself loses its register context across
s2idle, without ever hitting PM_SUSPEND_MEM. reset_tic()'s SPI exchange
then runs against a THC whose I/O address and read/write config are wiped,
so the reset never completes. Reprogramming those first (like
quickspi_restore(), and like v2 on the no-wake path) is what brings touch
and pen back.
So on the SP10 both are needed - reset the touch IC AND reconfigure the
THC - the full reconfigure looks necessary here.
One note on the log: there's no fresh "Wait RESET_RESPONSE timeout" line
this cycle, but that path is dev_err_once() and the box had ~12h uptime, so
an earlier cycle likely already consumed it.
Thanks,
Danny
next prev parent reply other threads:[~2026-06-02 15:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 22:22 [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume d3z-the-dev
2026-05-29 23:12 ` sashiko-bot
2026-06-01 3:24 ` Xu, Even
2026-06-01 3:26 ` Xu, Even
2026-06-01 21:30 ` d3z
2026-06-02 8:47 ` Xu, Even
2026-06-02 15:13 ` d3z [this message]
2026-06-01 21:18 ` [PATCH v2] " d3z
2026-06-01 21:31 ` sashiko-bot
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=20260602151317.27768-1-d3z.the.dev@gmail.com \
--to=d3z.the.dev@gmail.com \
--cc=abhishektamboli9@gmail.com \
--cc=bentiss@kernel.org \
--cc=even.xu@intel.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=xinpeng.sun@intel.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