Re: IPU6 Camera with ov08x40 (OVTI08F4 sensor) HP Spectre 16" Meteor Lake doesn't work

["duanek@chorus.net" <duanek@chorus.net>]

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@redhat.com wrote:

> Hi,
> 
> On 18-Dec-24 5:25 PM, duanek@chorus.net 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@redhat.com/
> 
> 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