RE: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume

[Xu, Even]

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@xxxxxxxxx>
> Sent: Tuesday, June 2, 2026 11:13 PM
> To: Xu, Even <even.xu@xxxxxxxxx>; Sun, Xinpeng <xinpeng.sun@xxxxxxxxx>;
> jikos@xxxxxxxxxx; bentiss@xxxxxxxxxx
> Cc: Danny D . <d3z.the.dev@xxxxxxxxx>; linux-input@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; abhishektamboli9@xxxxxxxxx;
> sakari.ailus@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system
> resume
> 
> From: Danny D. <d3z.the.dev@xxxxxxxxx>
> 
> 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