I tested this kernel and it still fails but shows new debugging logs that Hans added:

$ uname -a
Linux xps 6.11.6-301.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov  8 13:29:16 UTC 2024 x86_64 GNU/Linux

$ sudo dmesg | grep intel_vsc
[   13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22
[   13.367970] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   13.367977] intel_vsc intel_vsc: hw_reset failed ret = -22
[   13.524948] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   13.524955] intel_vsc intel_vsc: hw_reset failed ret = -22
[   13.524973] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
[   13.524977] intel_vsc intel_vsc: reset failed ret = -19
[   13.524978] intel_vsc intel_vsc: link layer initialization failed.
[   13.524980] intel_vsc intel_vsc: error -ENODEV: init hw failed

(In reply to Andrew Gaul from comment #1)
> I tested this kernel and it still fails but shows new debugging logs that
> Hans added:
> 
> $ uname -a
> Linux xps 6.11.6-301.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov  8
> 13:29:16 UTC 2024 x86_64 GNU/Linux
> 
> $ sudo dmesg | grep intel_vsc
> [   13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
> [   13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22
> [   13.367970] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
> [   13.367977] intel_vsc intel_vsc: hw_reset failed ret = -22
> [   13.524948] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
> [   13.524955] intel_vsc intel_vsc: hw_reset failed ret = -22
> [   13.524973] intel_vsc intel_vsc: reset: reached maximal consecutive
> resets: disabling the device
> [   13.524977] intel_vsc intel_vsc: reset failed ret = -19
> [   13.524978] intel_vsc intel_vsc: link layer initialization failed.
> [   13.524980] intel_vsc intel_vsc: error -ENODEV: init hw failed

Ok, so this is not really where I expected things to fail, but still good to know that this is where it fails.

The only reason I can think of why this can happen (but I'm no intel_vsc expert, that code was all written by Intel) is some timing issue with us reading back the answer before the VSC is ready resulting in the unexpected 0 token value.

So I have made us wait a bit longer for the VSC to come out of reset when it is reset during probe() and added some short sleeps between the command we send and the CMD_GETCONT follow-up cmd we send after that to get the response.

Hopefully this will help.

A test kernel with these delays added is now building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125791183

Note the build typically takes a couple of hours to complete.

Testing instructions (unchanged):

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this new test-kernel a spin, let me know how things go and please collect:

dmesg | grep vsc

output again.

This build failed with:

drivers/misc/mei/vsc-fw-loader.c:325:9: error: implicit declaration of function ‘msleep’ [-Wimplicit-function-declaration]
  325 |         msleep(20);

(In reply to Andrew Gaul from comment #3)
> This build failed with:
> 
> drivers/misc/mei/vsc-fw-loader.c:325:9: error: implicit declaration of
> function ‘msleep’ [-Wimplicit-function-declaration]
>   325 |         msleep(20);

My bad I forgot to do a local test-build of the patch before submitting it to the buildsystem.

A new fixed kernel with the delays which hopefully fix things added is now building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125813843

As usual this should be done in a couple of hours.

The build is done now and this time it did succeed.

I tested the latest kernel but the added sleep doesn't seem to change the outcome:

$ uname -a
Linux xps 6.11.7-300.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 13 12:18:00 UTC 2024 x86_64 GNU/Linux

$ sudo dmesg | grep vsc
[   65.373768] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   65.373775] intel_vsc intel_vsc: hw_reset failed ret = -22
[   65.780272] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   65.780291] intel_vsc intel_vsc: hw_reset failed ret = -22
[   66.182195] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   66.182212] intel_vsc intel_vsc: hw_reset failed ret = -22
[   66.182240] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
[   66.182249] intel_vsc intel_vsc: reset failed ret = -19
[   66.182252] intel_vsc intel_vsc: link layer initialization failed.
[   66.182256] intel_vsc intel_vsc: error -ENODEV: init hw failed

Thank you for testing. I'm afraid that I'm all out of ideas. I have asked a couple of people from Intel to take a look at this.

I'm hitting similar issue. On my setup on Dell XP 9340

[    6.168577] vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22

I'm not entirely sure if it is the same problem, but at least according to this comment:
https://github.com/intel/ivsc-driver/issues/51#issuecomment-2399836830

it's diffrent manifestation of the same issue. 

My full dmesg on 6.12-rc6 kernel is here: 
https://gist.github.com/sgruszka/b067d7d09baafdec72135cd2d3e2ccc4

The vsc-tp probe fail at request_threaded_irq() because spi->irq is -EPROBE_DEFER.

So something is wrong with initializing SPI device from ACPI description.

(In reply to Stanislaw Gruszka from comment #8)
> I'm hitting similar issue. On my setup on Dell XP 9340
> 
> [    6.168577] vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with
> error -22
> 
> I'm not entirely sure if it is the same problem, but at least according to
> this comment:
> https://github.com/intel/ivsc-driver/issues/51#issuecomment-2399836830
> 
> it's diffrent manifestation of the same issue. 
> 
> My full dmesg on 6.12-rc6 kernel is here: 
> https://gist.github.com/sgruszka/b067d7d09baafdec72135cd2d3e2ccc4
> 
> The vsc-tp probe fail at request_threaded_irq() because spi->irq is
> -EPROBE_DEFER.
> 
> So something is wrong with initializing SPI device from ACPI description.

Ah that sounds like it is a probe() timing issue rather then what users are seeing on the XPS9315.

I think that you are hitting a race where the ljca GPIO driver has not loaded yet at the time that the GPIO lookup (+ IRQ translation) is done in drivers/spi/spi.c in acpi_register_spi_device() when setting spi->irq and there is no check done for -EPROBE_DEFER there.

Even if such a check was added there I'm not sure when acpi_register_spi_device() would get re-called then since it is not a normal device probe() function.

One possible fix is to check for spi->irq == -EPROBE_DEFER in drivers/misc/mei/vsc-tp.c probe() before requesting the IRQ and then redo the acpi_dev_gpio_irq_get(adev, 0); call there and return -EPROBE_DEFER from vsc_tp_probe() if spi->irq is still -EPROBE_DEFER after that.

This is not a nice fix, but I would start with trying that to confirm that this is a probe() ordering issue.

After a second look: in the dt/of case the IRQ lookup is done in spi_probe() so the proper fix would be to move the ACPI acpi_dev_gpio_irq_get(adev, 0) call there too and then return -EPROBE_DEFER there if the lookup returns that just like the dt/of code path does.

Created attachment 2059082 [details]
Proposed fix for spi probing issue

Tested this patch and camera sensor now is detected on XPS 9340

[   15.753192] intel-ipu6 0000:00:05.0: FW version: 20230925
[   15.755880] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00
[   15.756142] intel-ipu6 0000:00:05.0: Connected 1 cameras

(In reply to Stanislaw Gruszka from comment #11)
> Created attachment 2059082 [details]
> Proposed fix for spi probing issue
> 
> Tested this patch and camera sensor now is detected on XPS 9340
> 
> [   15.753192] intel-ipu6 0000:00:05.0: FW version: 20230925
> [   15.755880] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00
> [   15.756142] intel-ipu6 0000:00:05.0: Connected 1 cameras

Great, thank you.

About the patch with this change you can also drop the acpi_dev_gpio_irq_get() call from acpi_register_spi_device() since spi_probe() now takes care of this.

With the dropping of acpi_dev_gpio_irq_get() from acpi_register_spi_device() squashed in I believe this patch is ready for upstream, can you submit it upstream please with me in the Cc ?

Just built a plain 6.12 with just the proposed patch but it doesn't seem to fix it on my 9315 (Arch Linux though)

Nov 21 23:21:10 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
Nov 21 23:21:10 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset failed ret = -19
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: link layer initialization failed.
Nov 21 23:21:11 kernel: intel_vsc intel_vsc: error -ENODEV: init hw failed

(In reply to Thomas from comment #13)
> Just built a plain 6.12 with just the proposed patch but it doesn't seem to
> fix it on my 9315 (Arch Linux though)
> 
> Nov 21 23:21:10 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
> Nov 21 23:21:10 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
> Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
> Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset: reached maximal
> consecutive resets: disabling the device
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset failed ret = -19
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: link layer initialization
> failed.
> Nov 21 23:21:11 kernel: intel_vsc intel_vsc: error -ENODEV: init hw failed

I just noticed Hans' comment where it's stated that -110 is a different issue.

> I just noticed Hans' comment where it's stated that -110 is a different issue.

Right this is being tracked in bug 2316918 instead.

I hope (but do not have confirmation yet) that this is fixed by these 2 patches:

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

Another patch which might help is:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=49988a7975420eb206c783f8a384458aae85d938

Maybe you can build a kernel with those 3 patches and see if they help ?\

Please report your results in bug 2316918 .

(In reply to Hans de Goede from comment #15)
> Right this is being tracked in bug 2316918 instead.

Never mind I see that you have already found your way to bug 2316918 and that you have already added the patches.

I have been poking at the ivsc -ETIMEOUT issue tracked in bug 2316918 and I have fix for this now.

gkh has queued that fix in char-misc-linus:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-linus&id=fdb1ada57cf8b8752cdf54f08709d76d74999544

so that fix is on its way to Linus' tree.

I think / hope that the fix might explain this bug too. The fix is about the 'ready' signal from the VSC to the host getting inverted, which means that we could be talking the VSC before it is ready which explains why we're seeing an all 0 reply.

I have submitted pull-requests to get the -ETIMEOUT fix added to Fedora kernel builds:

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3704
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3705

And this Fedora kernel already has the fix:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2662670

This is going to show up in updates-testing soon, or you can grab it directly from koji to test the fix right away, see:

https://docs.fedoraproject.org/en-US/quick-docs/kernel-installing-from-koji/

For Arch users there is a pkg with the fix added available here:

https://github.com/twouters/kernel-images/tree/f83806f6d6c5708d4ddf825340d3c0dbf428bba1/works

if you have any questions about the Arch pkg please ask them in bug 2316918 where this pkgbuild was provided by Thomas.

I tested with the suggested kernel but still see an error:

$ sudo dmesg | grep vsc
[   21.760792] intel_vsc intel_vsc: silicon stepping version is 0:2
[   38.503336] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110

$ uname -a
Linux xps 6.13.3-201.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Feb 19 18:56:15 UTC 2025 x86_64 GNU/Linux

(In reply to Andrew Gaul from comment #18)
> I tested with the suggested kernel but still see an error:
> 
> $ sudo dmesg | grep vsc
> [   21.760792] intel_vsc intel_vsc: silicon stepping version is 0:2
> [   38.503336] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447:
> switch camera to host failed: -110

That actually is pretty good news, because this means that we are getting past the -EINVAL errors:

[   13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0
[   13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22

which we were seeing before.

Can you try if this -ETIMEOUT is a transient error?

So try from the camera a second time. Or reboot the machine twice in a row so that the error does not trigger at all ? and then try after the second reboot. Maybe the ivsc was still in a confused state from the problems we were having before.

If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines.

Correction the new "switch camera to host failed: -110" error does not happen when trying to start streaming from the camera, but rather at probe() time of the ivsc-ace.ko driver.

2 things to try:

1. Maybe a simple reboot / power-cycle clears the error ?

2. blacklist the ivsc-ace driver / kernel-module and then reboot, so that the ivsc gets initialized + reset on reboot with triggering any errors then reboot a second time and after the second reboot manually probe "ivsc-ace" by running "modprobe ivsc-ace"

I rebooted and tried again a few times with a newer kernel with the same results:

$ uname -a
Linux xps 6.13.4-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Feb 22 16:09:10 UTC 2025 x86_64 GNU/Linux

$ sudo dmesg | grep vsc
[   19.341673] intel_vsc intel_vsc: silicon stepping version is 0:2
[   35.958641] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110

One interesting thing is that https://mozilla.github.io/webrtc-landing/gum_test.html does not show any cameras but Google Meet actually detects the MIPI camera now (see attachment).  The latter starts with "Camera is starting" but times out and displays "Camera is off".

Created attachment 2077889 [details]
Google Meet with XPS 9315

Re-reading your comment, I blacklisted the module, rebooted, then modprobed with the same result:

$ sudo dmesg | tail
[   29.696550] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[   30.199920] fs-verity: sha256 using implementation "sha256-ni"
[   30.965096] rfkill: input handler disabled
[   31.608939] Bluetooth: RFCOMM TTY layer initialized
[   31.608948] Bluetooth: RFCOMM socket layer initialized
[   31.608955] Bluetooth: RFCOMM ver 1.11
[   31.794614] usb 3-3: reset full-speed USB device number 3 using xhci_hcd
[   37.735787] rfkill: input handler enabled
[   38.925530] rfkill: input handler disabled
[  104.036804] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110

I do have a setup similar to @gaul, an xps 9315 and I do have a similar error message in dmesg:

```
$ sudo dmesg | grep vsc
[   12.383641] intel_vsc intel_vsc: silicon stepping version is 0:2
[   28.774551] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110
```

I had never been able to setup the camera, but many of my coworkers do have the same laptop and same os configuration and have a perfectly fine camera.

I'm using nixos, but I can try a redhat install if required.

```
$ uname -a
Linux gecko 6.14.3 #1-NixOS SMP PREEMPT_DYNAMIC Sun Apr 20 08:23:22 UTC 2025 x86_64 GNU/Linux
```

@hdegoede, I've tried a few of the suggestions:

- reboot cycle: I've tried rebooting, full `halt` of the machine and immediate boot, `halt` for hours and then boot. reset of the machine in order to reboot (using magic rescue key). Boot from the bios. Boot after a bios "factory reset", and multiples boot after multiples bios upgrades. Always the same error.
- I've tried blacklisting the module + boot / reboot cycle, then `modprobe` in multiples context, no success.

> If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines.

Do you have released a patch that I can apply on my kernel in order to change the timeout? (Or just point me toward the right file so I can actually build the patch myself if I just need to change an hardcoded value. I'm completely OK to test a 20 minutes timeout if it can somehow work.

Anyway, thank you for the time you spent on this topic

(In reply to guillaum.bouchard from comment #24)
> ```
> $ sudo dmesg | grep vsc
> [   12.383641] intel_vsc intel_vsc: silicon stepping version is 0:2
> [   28.774551] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447:
> switch camera to host failed: -110
> ```

We had -ETIMEOUT / -110 errors before but those were different, and those are fixed, see bug 2316918.

I have only seen one other bug report with your "switch camera to host failed: -110" error I'm afraid and that is the report if the same error in this bug by Andrew Gaul. Andrew seems to be using Fedora so this is not a NixOS specific issue. No idea about what is actually the issue though I'm afraid.

One thing you could try is disable the camera in the BIOS, then boot Linux once with the camera disabled and after that power off the laptop. Then wait 30 seconds, power it back on, re-enable the camera in the BIOS and see if that clears the issue. Disabling + re-enableing the camera in the BIOS was reported by one user to clear some iVSC issues.

> > If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines.

I looked at the timeout after writing that and the timeout already is quite long, so do not think that that will help. As mentioned already I'm pretty much out of ideas to fix this.

> One thing you could try is disable the camera in the BIOS, then boot Linux once with the camera disabled and after that power off the laptop. Then wait 30 seconds, power it back on, re-enable the camera in the BIOS and see if that clears the issue. Disabling + re-enableing the camera in the BIOS was reported by one user to clear some iVSC issues.

Tried and unfortunately, no success.

I'm out of patience with this laptop and I think I will admit that camera will never work. Thank you for the time you took trying to understand and fix the issue.

Hans, I finally have more time to look into this.  However I see different symptoms using 6.15.9-201.fc42.x86_64.  Both cheese and firefox see the Intel MIPI Camera (V4L2) but I no longer see any kind of vsc messages via dmesg.  Can you suggest how I could troubleshoot this further?  I can probably iterate building my own kernel module if you have some hypotheses I should try.

(In reply to Andrew Gaul from comment #27)
> Hans, I finally have more time to look into this.  However I see different
> symptoms using 6.15.9-201.fc42.x86_64.  Both cheese and firefox see the
> Intel MIPI Camera (V4L2) but I no longer see any kind of vsc messages via
> dmesg.  Can you suggest how I could troubleshoot this further?  I can
> probably iterate building my own kernel module if you have some hypotheses I
> should try.

Please apply various kernel cmdline debug options and then collect logs as described here:

https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement#How_To_Test

and then attach the logs here.