Re: intel_vsc probe issues on XPS 9320 (was Re: [PATCH] spi: Fix acpi deferred irq probe)

[Alexis Lothoré <alexis.lothore@xxxxxxxxxxx>]

On 11/25/24 13:44, Hans de Goede wrote:
> Hi,
> 
> On 25-Nov-24 1:34 PM, Alexis Lothoré wrote:
>> Hi Hans, thanks a lot for the the help !
>>
>> On Mon Nov 25, 2024 at 11:05 AM CET, Hans de Goede wrote:
>>> Hi Alexis,
>>>
>>> On 24-Nov-24 8:23 PM, Alexis Lothoré wrote:
>>>> Hello,
>> [...]
>>
>>>> I systematically observe this issue (probe failure with -22) on each boot,
>>>> and reached the same intermediate conclusion (IRQ failing to register, and
>>>> spi->irq value being -EPROBE_DEFER).
>>>> I can confirm that this patch makes the vsc-tp -22 error disappear on my
>>>> machine, and that I have now /sys/devices/platform/intel_vsc.
>>>>
>>>> Unfortunately, I now encounter a new issue preventing the camera to work
>>>> (ipu6 still fails with -EPROBE_DEFER, I now have
>>>> ipu_bridge_get_ivsc_csi_dev failing while searching for child device
>>>> intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da).
>>>
>>> This sounds like you may not have the actual MEI driver enabled or
>>> that it is not binding.
>>
>> You were right, it looks like I have been missing CONFIG_INTEL_MEI_VSC. My
>> config is comming from the archlinux kernel, there may be a miss here.
>>
>>> Do you have both CONFIG_INTEL_MEI_VSC_HW and CONFIG_INTEL_MEI_VSC enabled?
>>
>> So now with this change, I still have no success with ipu loading, because
>> of new errors on vsc-tp, but those errors have actually changed:
>>
>> $ dmesg|grep vsc
>> [    8.594501] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
>> [    8.594506] intel_vsc intel_vsc: hw_reset failed ret = -110
>> [    9.138269] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
>> [    9.138287] intel_vsc intel_vsc: hw_reset failed ret = -110
>> [    9.678712] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
>> [    9.678729] intel_vsc intel_vsc: hw_reset failed ret = -110
>> [    9.678750] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
>> [    9.678755] intel_vsc intel_vsc: reset failed ret = -19
>> [    9.678758] intel_vsc intel_vsc: link layer initialization failed.
>> [    9.678761] intel_vsc intel_vsc: error -ENODEV: init hw failed
>>
>> I have seen some mentions of this -110 error in the many redhat bugzilla
>> issues you have been helping with, I'll check more thoroughly if some hints
>> and/or patches have emerged from there.
> 
> Right. So this is a problem where the VSC chip is unresponsive which we
> still do not fully understand. power-cycling the laptop; or sometimes
> a power-cycle + if things still don't work a reboot after the power-cycle
> clears this.
> 
>> For the record, I am doing my tests with the current Archlinux kernel
>> (6.12.1-arch1), with those 3 patches on top:
>>
>> "mei: vsc: Do not re-enable interrupt from vsc_tp_reset()"
>> "media: intel/ipu6: do not handle interrupts when device is disabled"
>> "spi: Fix acpi deferred irq probe"
> 
> You may also want to throw these 2 into the mix. I've some hope that
> those will avoid the VSC chip getting stuck, requiring a power-cycle
> again (they do not help to "unstuck" the chip):
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=5c5d8eb8af06df615e8b1dc88e5847196c846045
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=2481af79671a6603fce201cbbc48f31e488e9fae

ACK, I'll do the tests with those as well, and check if some power cycles help
as well.
> 
>>> And do you get a driver symlink under /sys/devices/platform/intel_vsc
>>> indicating that a driver has bound to it ?
>>
>> With the updated config: no, but I guess the dmesg output above explains it.
> 
> Right, the dmesg explains that.
> 
>> Sorry for the thread hijack, that's totally fine for me to continue the
>> discussions elsewhere if relevant.
> 
> I have changed the topic to reflect the new somewhat offtopic discussions.
> 
> Another place to discuss the -110 error would be:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2316918

ACK, I'll perform the tests mentioned above and report back to this issue.

Many thanks again for your support !

Alexis


-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com