Hi, Danny,

Thank you very much!
Very appreciate your testing!

I noticed one thing in your description " there's no fresh 'Wait RESET_RESPONSE timeout' line this cycle ".
Generally, during reset_tic() execution, THC will send/receive data to/from TIC for RESET response, device descriptor.
If there is no any error log after you only add reset_tic() in resume() callback, that means THC isn't power gated, it still keep previous setting and can receive interrupt and response interrupt correctly.

Suddenly, I recognized, reset_tic() will set device state to RESETTING:
qsdev->state = QUICKSPI_RESETING;
So after reset_tic() call, driver must manually set device state to ENABLE:
qsdev->state = QUICKSPI_ENABLED;
If no this setting, THC hardware works normally, but driver will ignore all input data, the phenomenon is that the touch screen still has no response.
That's my bad, I forgot this.

So would you mind try again, to add the missed line, like this:

--- i/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ w/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -822,10 +822,17 @@ static int quickspi_resume(struct device *device)
        if (ret)
                return ret;

+       /* TIC may lose power, needs go through reset flow */
+       ret = reset_tic(qsdev);
+       if (ret)
+               return ret;
+
        ret = thc_interrupt_quiesce(qsdev->thc_hw, false);
        if (ret)
                return ret;

+       qsdev->state = QUICKSPI_ENABLED;
+
        if (!device_may_wakeup(qsdev->dev))
                return quickspi_set_power(qsdev, HIDSPI_ON);

Thanks!

Best Regards,
Even Xu

> -----Original Message-----
> From: d3z <d3z.the.dev@gmail.com>
> Sent: Tuesday, June 2, 2026 11:13 PM
> To: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <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
> 
> 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

From: Danny D. <d3z.the.dev@gmail.com>

Hi Even,

Good catch on the missing state restore. I rebuilt with your version and
re-ran the test.

This is exactly your proposal: reset_tic() after thc_dma_configure(),
then qsdev->state = QUICKSPI_ENABLED, with no thc_spi_*_config and no
thc_ltr_*. I built it as a module and swapped it into a clean
linux-surface 6.19.8 on the Surface Pro 10.

It still doesn't survive s2idle - touch is fine at probe, but after one
suspend/resume it's dead again. This time resume() fails outright instead
of coming back quietly broken:

    intel_quickspi 0000:00:10.0: Wait DEVICE_DESCRIPTOR timeout, ret:0
    intel_quickspi 0000:00:10.0: PM: dpm_run_callback(): pci_pm_resume returns -110
    intel_quickspi 0000:00:10.0: PM: failed to resume async: error -110

So reset_tic() can't complete here. It clears the reset handshake, then
times out in quickspi_get_device_descriptor() and the whole resume bails
with -ETIMEDOUT. The device isn't a wake source on this box - "Can't find
wake GPIO resource" - so device_may_wakeup() is false and we're on the
reset path, as expected.

And the timeout is the THC, not the touch IC: across s2idle its SPI
input/output address and read/write config are gone, so reset_tic()'s
descriptor exchange has nothing valid to run against. Reprogram those
first - the thc_spi_input_output_address_config + read_config +
write_config block, same as quickspi_restore(), same as v2 on the no-wake
path - and reset_tic() completes and touch comes back. That's exactly why
v2 reconfigures the THC instead of only resetting the IC.

One more platform note: the SP10 never reaches S3. Firmware only offers
s2idle - mem_sleep is just "[s2idle]", with no "deep" entry to select -
yet the THC still loses its context across plain s2idle. So a reset gated
on S3 would never fire here, which is why it has to run on the ordinary
resume path.

Thanks,
Danny

Hi, Danny,

Thanks for your patient to have some many tries.

According to above tests, it seems Surface Pro 10 does not only power off the TIC but also the THC for suspend.
Then your patch is need for this case.
I will add my review flag for your patch, thanks for your attribution!

Best Regards,
Even Xu

> -----Original Message-----
> From: d3z <d3z.the.dev@gmail.com>
> Sent: Friday, June 5, 2026 4:27 AM
> To: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <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
> 
> From: Danny D. <d3z.the.dev@gmail.com>
> 
> Hi Even,
> 
> Good catch on the missing state restore. I rebuilt with your version and re-ran the
> test.
> 
> This is exactly your proposal: reset_tic() after thc_dma_configure(), then qsdev-
> >state = QUICKSPI_ENABLED, with no thc_spi_*_config and no thc_ltr_*. I built it
> as a module and swapped it into a clean linux-surface 6.19.8 on the Surface Pro
> 10.
> 
> It still doesn't survive s2idle - touch is fine at probe, but after one
> suspend/resume it's dead again. This time resume() fails outright instead of
> coming back quietly broken:
> 
>     intel_quickspi 0000:00:10.0: Wait DEVICE_DESCRIPTOR timeout, ret:0
>     intel_quickspi 0000:00:10.0: PM: dpm_run_callback(): pci_pm_resume returns
> -110
>     intel_quickspi 0000:00:10.0: PM: failed to resume async: error -110
> 
> So reset_tic() can't complete here. It clears the reset handshake, then times out
> in quickspi_get_device_descriptor() and the whole resume bails with -
> ETIMEDOUT. The device isn't a wake source on this box - "Can't find wake GPIO
> resource" - so device_may_wakeup() is false and we're on the reset path, as
> expected.
> 
> And the timeout is the THC, not the touch IC: across s2idle its SPI input/output
> address and read/write config are gone, so reset_tic()'s descriptor exchange has
> nothing valid to run against. Reprogram those first - the
> thc_spi_input_output_address_config + read_config + write_config block, same
> as quickspi_restore(), same as v2 on the no-wake path - and reset_tic() completes
> and touch comes back. That's exactly why
> v2 reconfigures the THC instead of only resetting the IC.
> 
> One more platform note: the SP10 never reaches S3. Firmware only offers s2idle -
> mem_sleep is just "[s2idle]", with no "deep" entry to select - yet the THC still
> loses its context across plain s2idle. So a reset gated on S3 would never fire here,
> which is why it has to run on the ordinary resume path.
> 
> Thanks,
> Danny