Dear Hans, I appreciate your determination, and uploaded a dmesg file with "intel_skl_int3472_discrete.dyndbg" passed as a kernel parameter (I hope I did it right) to RH Bugzilla Sincerely, Duane ----- On Dec 19, 2024, at 9:02 AM, Hans de Goede hdegoede@xxxxxxxxxx wrote: > 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
