Hi, On 20-Dec-24 1:47 AM, duanek@xxxxxxxxxx wrote: > 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 Thanks I have posted a long comment on bugzilla, which I think can mostly be ignored for now, because after that comment I learned of a bug in my earlier attempt at fixing the ov08x40 driver thanks to testing of my patches on an ARM device, quoting from my last comment in bugzilla: "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@xxxxxxxxxx/ 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@xxxxxxxxxx/ 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 " I think that that should do the trick. Regards, Hans > ----- 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 >
