Linux Input/HID development
 help / color / mirror / Atom feed
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

  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