Hi, On 18-Dec-24 5:25 PM, duanek@xxxxxxxxxx wrote: > Dear Jacopo, > > Thanks for forwarding to libcamera - I'm a newbie and am not sure who all should be involved. > > When I specify the camera, I get: > duane@DuanesSpectre16:~/cameratest$ LIBCAMERA_LOG_LEVELS=0 qcam -c"\_SB_.PC00.LNK0" <snip> > [2:42:26.110235367] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.113343648] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.116390199] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.119374839] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.125329380] [29471] DEBUG Request request.cpp:369 Created request - cookie: 0 > [2:42:26.125505377] [29471] DEBUG Request request.cpp:369 Created request - cookie: 0 > [2:42:26.125523467] [29471] DEBUG Request request.cpp:369 Created request - cookie: 0 > [2:42:26.125531018] [29471] DEBUG Request request.cpp:369 Created request - cookie: 0 > [2:42:26.125546767] [29471] DEBUG Camera camera.cpp:1360 Starting capture > [2:42:26.135295574] [29488] DEBUG V4L2 v4l2_videodevice.cpp:1311 /dev/video0[28:cap]: 3 buffers requested. > [2:42:26.135380273] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.135397476] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.135407136] [29488] DEBUG Buffer framebuffer.cpp:351 Buffer is contiguous > [2:42:26.135749405] [29488] DEBUG V4L2 v4l2_videodevice.cpp:1750 /dev/video0[28:cap]: Queueing buffer 0 > [2:42:26.294678108] [29488] DEBUG V4L2 v4l2_videodevice.cpp:1750 /dev/video0[28:cap]: Queueing buffer 1 > [2:42:26.294710299] [29488] DEBUG V4L2 v4l2_videodevice.cpp:1750 /dev/video0[28:cap]: Queueing buffer 2 Ok so we have set the mode on the camera, queued buffers, etc. and everything is looking great. Except that unfortunately the camera/sensor never starts streaming or at least no frames are received over CSI. Which matches with the dmesg from a later email in this thread which has: [ 197.992581] intel_ipu6_isys.isys intel_ipu6.isys.40: stream on Intel IPU6 CSI2 0 failed with -5 As Bingbu mentioned this means that the s_stream pad operation from the ov08x40 sensor driver has failed with -5, which means -EIO. I strongly suspect that this is the same issue as the one which I have been debugging with another reporter with a "HP Spectre x360 14-eu0xxx" laptop with a OVTI08F4 sensor. What is happening here is that we fail to properly power-on the sensor and probe() defers identifying the sensor till stream_on time, combined with a bug where stream_on actually is missing the call to identifty the sensor. So instead of getting an error about not being able to identify the sensor instead we get the return value from the first failed ov08x40_write_reg() call, which returns -EIO instead of propagating the actual error which is -EREMOTEIO which indicates that the sensor is not responding to its i2c address which typically means that we have failed to power the sensor on. I have posted a patch series which attempts to fix this here: https://lore.kernel.org/linux-media/20241219134940.15472-1-hdegoede@xxxxxxxxxx/ But at least for the reporter with the HP Spectre x360 this does not fix things, but it does make it much clearer that the i2c communications with the sensor are failing with -EREMOTEIO. One interesting aspect here is that the INT3472 sensor-power-supply-device on the HP Spectre x360 causes the following log messages: [ 11.594911] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work which you are seeing too. Another interesting data point is that this warning seen on your laptop: [ 11.595033] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 Points to \_SB.GPI0 which suggests that the sensor is directly connected to GPIOs on the main SoC/CPU, and I expect "ls -l /sys/bus/i2c/devices" to also show that it is using an I2C bus from the main Intel CPU/SoC rather then using some IO-expander as we typically see on Dell and Lenovo designs. Duane, I have been getting a lot of emails about IPU6 not working and I'm sort of loosing track of all of the issues which I'm handling. So now I'm working on tracking all the issues in Fedora's bugzilla, I have filed a new issue to track this issue: https://bugzilla.redhat.com/show_bug.cgi?id=2333331 One thing which I'm wondering is if there maybe is a powerdown GPIO which is not handled even after my patches. Can you add: "intel_skl_int3472_discrete.dyndbg" to your kernel commandline, reboot and then collect a new dmesg output ? If you are on Fedora then you can add this to your kernel commandline by running: sudo grubby --update-kernel=ALL --args="intel_skl_int3472_discrete.dyndbg" If possible please attach the new dmesg output to: https://bugzilla.redhat.com/show_bug.cgi?id=2333331 If you don't have a bugzilla account yet, all that is required to register is an email address, no other personal info is needed. If you don't want to use bugzilla directly, would it be ok if I attach your dmesg output there? Regards, Hans
