This bug is to track an issue which I have been discussing with the reporter over email for quite a while now. The reporter's HP Spectre x360 14-eu0xxx has an OVTI08F4/ov08x40 sensor which is directly connected to GPIOs and a I2C bus coming directly from the main Intel SoC/CPU rather then using an IO-expander like the LJCA chip. The sensor presumably is failing to power-on properly, as the first I2C transfer attempted to the sensor fails with EREMOTEIO which typically means the sensor has not been powered on properly. Despite there not being an IO-expander the Intel IPU INT3472 ACPI sensor-power device driver logs the following: [ 11.594911] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work Where type 0x12 is "handshake" which normally is associated with the new Lattice MIPI aggregator IO-expander / MIPI chip which this laptop appears to not use. It is unclear how to handle this pin. I have provided a test kernel to the reporter which maps this to "reset" but that does not help. Generally speaking the mainline ov08x40 driver lacks code to control the clk and GPIOs which is necessary on Intel IPU6 designs. I have posted a series to add support for these here: https://lore.kernel.org/linux-media/20241219134940.15472-1-hdegoede@redhat.com/ But testing has shown that this is not enough to get things to work. There now also is another reporter with a similar HP laptop which appears to have the same sensor setup and is showing the same problem: https://lore.kernel.org/linux-media/1594170563.10937137.1728935697496.JavaMail.zimbra@chorus.net/ Reproducible: Always
Created attachment 2063303 [details] HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Duane Kaufman HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg
(In reply to Duane Kaufman from comment #1) > Created attachment 2063303 [details] > HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg > > Duane Kaufman > > HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Thank you, So the interesting new log lines here are: [ 4.907022] int3472-discrete INT3472:01: Sensor module id: 'CJFME62' [ 4.908016] int3472-discrete INT3472:01: unknown \_SB.GPI0 pin 65 active-high [ 4.908019] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work [ 4.908099] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 [ 4.908100] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high [ 4.912108] int3472-discrete INT3472:02: Sensor module id: 'CJFME62' [ 4.916184] int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 49 resource 209 [ 4.920658] int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low These show that there are 2 INT3472 power management devices. Likely one per sensor, I expect there will be both a normal camera sensor and an infrared sensor. Still this does not explain why we cannot get the ov08x40 sensor powered up since there are no unhandled GPIO entries other then the "GPIO type 0x12 unknown" which I already tried mapping to "reset" and that did not help. So the next step would be to write a dummy ov08x40 driver which at least enables the clks and then to manually try and see if we can talk to the chip using i2cdetect from userspace after driving all 3 GPIOs (GPI0 pin 65 107 and 209) high using gpioset from userspace. I'm going to turn off my computer real soon and then I'll be off from work for 2 weeks, returning on January 6th. So investigating this further will have to wait till January. In the mean time it would be useful to collect some info for January. Please install the gpiodetect and i2cdetect utilities and run: ls -l /sys/bus/i2c/devices on the "HP Spectre x360 14-eu0xxx" from the other reporter this outputs these lines (amongst others): lrwxrwxrwx 1 root root 0 Oct 5 23:42 i2c-OVTI00AB:00 -> ../../../devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-2/i2c-OVTI00AB:00 lrwxrwxrwx 1 root root 0 Oct 5 23:40 i2c-OVTI08F4:00 -> ../../../devices/pci0000:00/0000:00:19.0/i2c_designware.3/i2c-3/i2c-OVTI08F4:00 with the interesting thing being the /i2c-2/ and /i2c-3/ part of the paths, this shows that the OVTI08F4 sensor which is the normal camera sensor is on i2c bus 3. Assuming it is on i2c-bus 3 for you to, please run: i2cdetect -y -r 3 and post the output. I would expect this to show one UU entry which means that that address is claimed / in use and therefor probing is skipped. Note this should run pretty quickly, if it is slow then the i2c-bus has issues (likely due to the sensor not being powered on). It would also be interesting to remove the sensor doing: "sudo rmmod ov08x40" and then do the i2cdetect again. Now it will likely detect nothing. Also please run "sudo gpiodetect" and provide the output of that command too. If gpiodetect shows only 1 chip then we can be sure that that is GPI0 in ACPI and you could try manually setting the GPIOs high after doing the "sudo rmmod ov08x40" by running: gpioset -c gpiochip0 65=1 107=1 209=1 gpioset will keep running to keep the GPIOs claimed, you can do Ctrl+C to cancel it and then run: i2cdetect -y -r 3 again and see if an i2c-device shows up. Note this might not work for 2 possible reasons: 1. Without a dummy driver the ACPI call to enable the clk to the sensor will not be made 2. So far we have failed to power-up the sensor and we have effectively already tried the GPIOs so maybe something extra is needed and we just don't know what
Created attachment 2063345 [details] ov2740 dummy driver If you want to pursue this further yourself, here is a dummy driver which just enables the clk for the ov2740, to adjust this for the ov08x40 all you need to do really is change the ACPI HardwareID from INT3474 to OVTI08F4. I'll also attach a Makefile to build this out of tree.
Created attachment 2063346 [details] Makefile for ov2740dummy driver
One very important thing which I forgot to mention poking GPIOs manually might be dangerous / could in some cases damage your hardware! Which is why I suggested to only do that if "sudo gpiodetect" shows only 1 GPIO chip so that we are sure we are only poking camera related GPIOs.
Ugh, I just learned that my previous attempt to fix this on a "HP Spectre x360 14-eu0xxx" has a bug in one of my patches adding support to the driver to set the GPIO and clks on ACPI platforms, see: https://lore.kernel.org/linux-media/e3573352-f73e-43f5-8e21-6c313dc54057@redhat.com/ That might very well explain why things do not work. So poking GPIOs manually and running i2cdetect is probably not really necessary. Instead what is likely necessary is building a kernel with the patches from this series added: https://lore.kernel.org/linux-media/20241219134940.15472-1-hdegoede@redhat.com/ with the bug in that series which I linked to above fixed. *and* with this patch added as well: https://github.com/jwrdegoede/linux-sunxi/commit/c7803b1a32dab79f8a516e8aa9c08fb4ba74354d
Created attachment 2074443 [details] acpidump from HP Spectre x360 14-eu0xxx
Hello, sorry for the delay, I have a "HP Spectre x360 14-eu0xxx" with Fedora and Debian testing (kernel 6.13.5) The results are the same on Fedora and Debian, just on debian the i2c buses are 3 and 4, because Debian detects i2c-0 with the SMBus I801 adapter: /sys/bus/i2c/devices/i2c-3/i2c-TXNW3643:00 is a led flash for the IR camera (lm3643 with linux drivers to adapt) /sys/bus/i2c/devices/i2c-3/i2c-OVTI00AB:00 is the IR camera (og0va1b with no linux driver) /sys/bus/i2c/devices/i2c-4/i2c-OVTI08F4:00 is the camera and photo (ov08x40) I find it strange that the OVTI08F4 camera is seen as a led /sys/class/leds/OVTI08F4_00::privacy_led /sys/devices/pci0000:00/INT3472:01/leds/OVTI08F4_00::privacy_led (On Fedora as on Debian) I recompiled the kernet with the latest patch proposed on INT3472 discrete.c but with a small difference: + case INT3472_GPIO_TYPE_HANDSHAKE: + *func = "handshake"; + *polarity = GPIO_ACTIVE_HIGH; + break; The dmesg traces give: int3472-discrete INT3472:01: Sensor module id: 'YHEC' int3472-discrete INT3472:01: handshake \_SB.GPI0 pin 65 active-high int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high int3472-discrete INT3472:02: Sensor module id: 'YHEC' int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 49 resource 209 int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low The i2cdetect gives: sudo i2cdetect -y -r 3 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 60 -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- -- 70:70 -- -- -- -- -- -- -- sudo i2cdetect -y -r 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Results are the same on fedora with -r 2 and 3 Hope this helps
I have prepared a test-kernel with the following patches: 1. 2 hi566 power-on sequence fixes (not posted upstream yet) 2. ov02c10 support https://lore.kernel.org/linux-media/20250319145927.70534-1-hdegoede@redhat.com/ 3. ov02e10 support https://lore.kernel.org/linux-media/20250325-b4-media-comitters-next-25-03-13-ov02e10-v2-2-4d933ac8cff6@linaro.org/ 4. Lattice / usbio handshake pin support https://lore.kernel.org/platform-driver-x86/20250325161340.342192-1-hdegoede@redhat.com/ This should make the camera on the laptop from this bug work, please give the test kernel a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=130775742 Here are some instructions for directly installing a kernel from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Thank you for your feedback, I tested this kernel on my "HP Spectre x360 14-eu0xxx": BOOT_IMAGE=/boot/vmlinuz-6.14.0-63.ipu6.fc42.x86_64 root=/dev/nvme0n1p8 No logs for int3472-discrete. But the ov098x40 driver does not work: ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121
One small step... I managed to get a video with sudo qcam -s "width=1900,height=1200" This video is not stable. To do this, I compiled kernel 6.15-rc1 and rc2 with the 9 patches from https://lore.kernel.org/all/20250402202510.432888-1-hdegoede@redhat.com/ No more errors on int3472. But the ov098x40 driver randomly fails to work: ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 Errors -121 are random upon reboot or after rmmod ov08x40 modprobe ov08x40 When there is no error -121, qcam produces a video.
This should now work OOTB starting with Fedora kernels >= kernel-6.14.6-300.fc42, which has the same 9 patches mentioned in comment 11, closing. It would be great if someone can test a kernel >= kernel-6.14.6-300.fc42 on this laptop and confirm that things are really fixed. The colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. There also is a software-ISP issue where in some cases the auto-exposure algorithm gets into an oscillation and the image flickers pretty badly (bug 2368538).
I compiled on Debian, the latest version, linux 6.15, with the patch. At boot, the ov08x40 module is in error. After restarting the module, I get the flickering image. On Fedora, I have version 6.14.5 without the patch, so I can't test it on Fedora, sorry.
After installing Fedora 42 with the Linux kernel Fedora 6.14.8-300.fc42.x86_64 The patch appears to be installed, but it doesn't work because ov08x40 won't load even after numerous attempts : rmmod ov08x40 modprobe ov08x40 dmesg : ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 (Problem seems to be the sleep timer ?)
(In reply to alcousin from comment #14) > After installing Fedora 42 with the Linux kernel Fedora > 6.14.8-300.fc42.x86_64 > > The patch appears to be installed, but it doesn't work because ov08x40 won't > load even after numerous attempts : > rmmod ov08x40 > modprobe ov08x40 > > dmesg : > ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator > ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator > ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 > ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 > > (Problem seems to be the sleep timer ?) Ok, lets re-open this and investigate why things still do not work. For starters please collect various debug-logs as described here: https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement#How_To_Test and then attach the logs to this bug.
Created attachment 2092657 [details] 14-eu0xxx
Created attachment 2092658 [details] 14-eu0xxx
Created attachment 2092659 [details] 14-eu0xxx i2c-devices
Created attachment 2092660 [details] 14-eu0xxx -spi-devices
(In reply to Hans de Goede from comment #15) > https://fedoraproject.org/wiki/Changes/ > X86_MIPI_CameraHwEnablement#How_To_Test > > and then attach the logs to this bug. I attached logs with 14-eu0xxx in this order : kernel.txt lsusb.txt i2c-devices.txt spi-devices.txt Kernel : Linux fedora 6.14.8-300.fc42.x86_64
Hmm, nothing stands out in the logs. Can you please enable INT3472 dynamic debugging by running: sudo grubby --update-kernel=ALL --args="intel_skl_int3472_discrete.dyndbg" And then reboot and collect a new kernel log ?
Sorry, I thought I did it. I updated everything, then grubby and rebooted. But I got the same results. Sorry, I thought I did it. I updated everything, then grubby and rebooted. But I have the same results, which I'm going to upload. Linux fedora 6.14.9-300.fc42.x86_64
Created attachment 2092674 [details] kernel2
Created attachment 2092679 [details] lsusb2
Created attachment 2092680 [details] i2c-devices2
Created attachment 2092681 [details] spi-devices2
Hmm, the "intel_skl_int3472_discrete.dyndbg" commandline argument is still not there on the kernel commandline. You should have a: /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf File, can you try editing this as root: sudo su - nano /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf or if you prefer: vim /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf And then manually add " intel_skl_int3472_discrete.dyndbg" to the end of the options line. Then reboot and after rebooting run: cat /proc/cmdline and check the option is now there ? And then collect a new kernel log, note only the kernel log will change there is no need to collect a new version of the other logs.
Created attachment 2092703 [details] kernel3 I found, I use debian grub, so grubby was not taken into account. I modified and only kernel.txt attached changes
Is this okay? Hello Hans, if I can help, I'd be happy to help. I'm an old engineer, I've been working with Unix since 1984, and I'm a developer in C and other languages... I'm compiling kerner.org on Debian. If you insist, I can do it on Fedora. Thank you.
Hi, I compiled kernel 6.16-rc1 (Debian) for my HP Spectre 16 Attached is dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Sincerely, Duane Kaufman
Created attachment 2093657 [details] HP Spectre 16 kernel 6.16-rc1 dmesg HP Spectre 16 kernel 6.16-rc1 dmesg
(In reply to alcousin from comment #28) > Created attachment 2092703 [details] > kernel3 > > I found, I use debian grub, so grubby was not taken into account. I modified > and only kernel.txt attached changes Thanks, ok so everything looks good but for some reason things are not working. The only theory I can come up with is that the privacy-LED GPIO actually controls some regulator or something like that so that it actually needs to be on during probe. Can you try doing: sudo sh -c 'echo 1 > /sys/class/leds/OVTI08F4_00::privacy_led/brightness' sudo rmmod ov08x40 sudo modprobe ov08x40 and see if these errors: juin 02 14:06:16 fedora kernel: ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 juin 02 14:06:16 fedora kernel: ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 are gone after the second attempt to load the driver ?
(In reply to Duane Kaufman from comment #31) > Created attachment 2093657 [details] > HP Spectre 16 kernel 6.16-rc1 dmesg > > HP Spectre 16 kernel 6.16-rc1 dmesg Duane, I believe that the camera was working on your laptop with the handshake GPIO patches before, right ? Looking at your log, this seems to be the problem: [ 18.207338] i2c i2c-OVTI08F4:00: deferred probe pending: ov08x40: waiting for fwnode graph endpoint The fwnode for the sensor is populated by the CSI/bridge driver which is part of the ipu6 drivers, and in dmesg I do see the ipu6 driver loading. So it is weird that this is not working. Can you check the .config for your kernel ? I guess that you have CONFIG_IPU_BRIDGE disabled and you need to have that enabled. If that is already enabled please attach your kernel's .config.
(In reply to Hans de Goede from comment #32) > (In reply to alcousin from comment #28) > > are gone after the second attempt to load the driver ? After updating to Linux Fedora 6.14.11-300.fc42.x86_64 I ran the indicated commands (sudo echo 1...), but nothing changed: (sudo dmesg -l err,warn) [ 148.953150] ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator [ 148.953176] ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator [ 148.984006] ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 [ 148.984455] ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 On Debian with kernel 6.16-rc1 compiled, I don't get any errors and "qcam" produces a video. But I'm compiling with optimization and with unnecessary modules reduced.(On rc1, I have another problem, but unrelated to the video. iwlwifi crashes the system, I wait for rc2). Hence, I think it's related to the sleep you indicated here: https://lore.kernel.org/all/20250311114844.25593-1-hdegoede@redhat.com/