Closed FlyingPC closed 1 year ago
Here is the output of qcam : """ [0:39:32.913634636] [9512] INFO Camera camera_manager.cpp:299 libcamera v0.0.3+10-0a8ac1ee [0:39:32.968496469] [9523] ERROR V4L2 v4l2_device.cpp:92 'dw9719 2-000c': Failed to open V4L2 device '': Aucun fichier ou dossier de ce type [0:39:32.968624536] [9523] ERROR CameraSensor camera_sensor.cpp:501 'ov8865 2-0010': Lens initialisation failed, lens disabled [0:39:33.000939927] [9523] ERROR IPAProxy ipaproxy.cpp:149 Configuration file 'ov8865.yaml' not found for IPA module 'ipu3' [0:39:33.003659914] [9523] INFO IPU3 ipu3.cpp:1206 Registered Camera[0] "_SB.PCI0.LNK0" connected to CSI-2 receiver 0 [0:39:33.020537561] [9523] ERROR IPAProxy ipaproxy.cpp:149 Configuration file 'ov5693.yaml' not found for IPA module 'ipu3' [0:39:33.021198924] [9523] INFO IPU3 ipu3.cpp:1206 Registered Camera[1] "_SB.PCI0.LNK1" connected to CSI-2 receiver 1 [0:39:34.796592988] [9512] INFO Camera camera.cpp:1026 configuring streams: (0) 1280x720-NV12 Using software format conversion from 842094158 [0:39:35.028395346] [9523] INFO V4L2 v4l2_videodevice.cpp:1820 /dev/video10[46:cap]: Zero sequence expected for first frame (got 1) [0:39:35.039887799] [9523] INFO V4L2 v4l2_videodevice.cpp:1820 /dev/video2[34:cap]: Zero sequence expected for first frame (got 1) [0:39:35.040341503] [9523] INFO V4L2 v4l2_videodevice.cpp:1820 /dev/video4[37:cap]: Zero sequence expected for first frame (got 1) """
Same on the Go3
@FlyingPC sorry I missed this. Can you give me outputs from lsmod and dmesg to look at please?
@djrscally my surface go unfortunately does not start anymore. So I can no longer answer to your question.
I'll try to see if I can fix it but it seems complicated! :-)
Maybe @PhilDevProg can give the output of lsmod and dmesg.
@FlyingPC djrscally already has my output due to another camera issue and I don't really know if I really have the same issue as you. Maybe it's just because my lens doesn't work. (@djrscally already found out what's the problem and showed a fix in the main Camera issue but I haven't gotten it to work yet because it needs to build the kernel which I failed)
@djrscally @FlyingPC Okay, I now have the lens working and the autofocus works sometimes when the rear camera sees the same picture for a very long time...
Any fix for the autofocus ? It's the same on the surface pro 5 with ubuntu 22.04 and the last version of libcamera
@Lijwent can you share the output of dmesg and lsmod please (@PhilDevProg's issue is different and now fixed)? Sorry @FlyingPC for the delay on this one, I'll try to get back to figuring out what went wrong - did you get your surface booting again?
@Lijwent ah; but does it "work" in the sense that it tries to autofocus, it just struggles on some objects?
@Lijwent ah; but does it "work" in the sense that it tries to autofocus, it just struggles on some objects?
@djrscally It tries to autofocus but it doesnt work, I tried the trick to go from further away to closer to force it to autofocus, but it stays blured, even after waiting a while
@Lijwent ah; but does it "work" in the sense that it tries to autofocus, it just struggles on some objects?
@djrscally It tries to autofocus but it doesnt work, I tried the trick to go from further away to closer to force it to autofocus, but it stays blured, even after waiting a while
OK. The actual functioning of the autofocus is really outside the scope of this project - it needs to be handled within the libcamera development process (as that's the library that runs the autofocus). Can you log that problem on https://bugs.libcamera.org/ perhaps?
The issue FlyingPC has is different, but the dmesg output you posted has lead me to understand the problem, so thank you for that!
@FlyingPC this tree or the patch pasted below should fix your issue. None of my devices exhibits the problem unfortunately, so I can't test it. If you (or anyone else with a Surface that isn't one of the Go line could test it and let me know the results that would be appreciated.
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 974a132db651..e31acae1199a 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -108,6 +108,9 @@ static int skl_int3472_map_gpio_to_sensor(struct int3472_discrete_device *int347
{
const struct int3472_sensor_config *sensor_config;
char *path = agpio->resource_source.string_ptr;
+ const struct acpi_device_id ov7251_ids[] = {
+ { "INT347E" },
+ };
struct gpiod_lookup *table_entry;
struct acpi_device *adev;
acpi_handle handle;
@@ -130,6 +133,14 @@ static int skl_int3472_map_gpio_to_sensor(struct int3472_discrete_device *int347
}
}
+ /*
+ * In addition to the function remap table we need to bulk remap the
+ * "reset" GPIO for the OmniVision 7251 sensor, as the driver for that
+ * expects its only GPIO pin to be called "enable".
+ */
+ if (!strcmp(func, "reset") && acpi_match_device_ids(int3472->sensor, ov7251_ids))
+ func = "enable";
+
/* Functions mapped to NULL should not be mapped to the sensor */
if (!func)
return 0;
@djrscally sorry, I couldn't repair my surface book 2 (it's quite complicated to disassemble...).
Np, I'll see if anyone else can try. What happened to it!?
I can give it a try later, once I'm back at my workstation (in ~ 4 hours).
@djrscally I still get the "cannot get enable gpio" with your tree.
Nuts...ok - I'll try to dump a bunch of debug output into there and push again later today so we can see why that's not worked.
@qzed OK I pushed again...bit minimal but I'm struggling to see where it can be failing other than that point!
Thanks, I'll give it a try and let you know. I'll also try to figure out what's going wrong.
Found one issue: acpi_match_device_ids()
returns 0
if it matches and -ENOENT
if it doesn't... gotta love the functions that do the opposite of what they're named after xD
So replacing
if (!strcmp(func, "reset") && acpi_match_device_ids(int3472->sensor, ov7251_ids)) {
with
if (!strcmp(func, "reset") && !acpi_match_device_ids(int3472->sensor, ov7251_ids)) {
does the trick. Maybe acpi_match_device()
is better for readability here, because that actually does (more or less) what its name says.
Now it fails with -EREMOTEIO
. Let me first check that that isn't a hardware issue on my side again... after that I'll post some logs.
Alright, it does seem to work on Windows... Here's a log: dmesg.log. Ignore the ov5693, that's dead.
I think here are the relevant parts:
INT3472 looks like it works now:
[ 30.122093] skl_int3472_map_gpio_to_sensor() handling reset GPIO for INT347A:00
[ 30.133890] skl_int3472_map_gpio_to_sensor() handling reset GPIO for INT347E:00
[ 30.133895] skl_int3472_map_gpio_to_sensor() remapping reset->enable for INT347E:00
INT347E failure:
[ 30.378878] ov7251 i2c-INT347E:00: supply vdddo not found, using dummy regulator
[ 30.378924] ov7251 i2c-INT347E:00: supply vddd not found, using dummy regulator
[ 30.378941] ov7251 i2c-INT347E:00: supply vdda not found, using dummy regulator
[ 30.383529] ov7251 i2c-INT347E:00: ov7251_write_reg: write reg error -121: reg=103, val=1
[ 30.383536] ov7251 i2c-INT347E:00: error during global init
[ 30.383686] ov7251: probe of i2c-INT347E:00 failed with error -121
So if I'm not mistaken, it fails here: https://elixir.bootlin.com/linux/v6.1.2/source/drivers/media/i2c/ov7251.c#L932, which seems to be the first register access of the driver.
Yep so it's not powered on. Which device do you have again so I can look at the DSDT?
On Thu, 9 Mar 2023, 17:33 Maximilian Luz, @.***> wrote:
So if I'm not mistaken, it fails here: https://elixir.bootlin.com/linux/v6.1.2/source/drivers/media/i2c/ov7251.c#L932, which seems to be the first register access of the driver.
— Reply to this email directly, view it on GitHub https://github.com/linux-surface/linux-surface/issues/1022#issuecomment-1462474379, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDBE245H3FWDKSTRVMS3QDW3IH7HANCNFSM6AAAAAATM7NHAM . You are receiving this because you were mentioned.Message ID: @.***>
Surface Book 2
OK, and if you run sudo i2cdetect -r -y 3
I expect no device at address 0x60. If you then run sudo gpioset --mode=wait 0 85=1 130=1
and then try i2cdetect again, the device should show up...does that happen?
After checking i2cdetect again hit enter on gpioset so it finishes and run sudo gpioset 85=0 130=0
to make sure they're off.
OK, and if you run
sudo i2cdetect -r -y 3
I expect no device at address 0x60.
Correct.
If you then run
sudo gpioset --mode=wait 0 85=1 130=1
and then try i2cdetect again, the device should show up...does that happen?
Yes. There's the one at 0x60 and then also another(?) at 0x70.
Should I try to increase the timeout in the driver?
Should I try to increase the timeout in the driver?
Tried setting that to 100ms, didn't work.
@qzed OK. At least it shows up alright, and that means something in the handling code is screwed up. I think the polarity is wrong; let me push an update for you (and I'll fix the acpi matching)
@qzed ok ready to test when you're able.
Aaaand force pushed again with a less hacky fix.
Awesome, that seems to work:
[ 29.994970] ov7251 i2c-INT347E:00: OV7251 revision 7 (1F) detected at address 0x60
Any way I can test the sensor?
Sweet! I'll upstream that, and open a PR here. You can currently run:
#!/bin/bash
# Get the devnode
VDEV=$(media-ctl -d1 -e "ipu3-cio2 2");
# Set links and format
media-ctl -d1 -l "'ov7251 3-0060':0 -> 'ipu3-csi2 2':0[1]";
media-ctl -d1 -V "'ipu3-csi2 2':0 [fmt:Y10_1X10/640x480]";
v4l2-ctl -d "$VDEV" --set-fmt-video="width=640,height=480,pixelformat=4";
# Capture
v4l2-ctl -d "$VDEV" --stream-mmap --stream-to=/home/djrscally/ov7251.bin --stream-count=1;
# Convert
ipu3-unpack ~/ov7251.bin ~/ov7251.raw
raw2rgbpnm -s 640x480 -f Y10 ~/ov7251.raw ~/ov7251.ppm
To capture from it, where "ipu3-unpack" in libcamera/utils/ipu3 and "raw2rgbpnm" is at git://salottisipuli.retiisi.org.uk/~sailus/raw2rgbpnm.git. The image will likely be very dark because of the non-functional IR LED. Now that it works on the Surface Go I'm working on getting libcamera to work with this camera in its IPU3 pipeline (which it currently doesn't because it works differently to the others), and then I'll see what I can do about getting the IR LED to work for the discrete type PMIC.
Nice, that worked! It's rotated 90° clockwise and I can barely see anything, but it's an image, yay.
Thanks!
@qzed try maxing the exposure of the sensor;
VSDEV=$(media-ctl -d1 -e 'ov7251 3-0060')
v4l2-ctl -d $VSDEV -c exposure=1500
and then run the capture script again; it might be reasonably visible. You could bump it even higher by increasing the vertical_blanking control (exposure is capped at VBLANK). Run v4l2-ctl -d $VSDEV -l
to enumerate the controls and their maximums (increasing vertical_blanking should raise the maximum for exposure)
EDIT: I get an okish image at exposure=5000 with the LED off...framerate of 4.5fps though :D
Ah neat, I basically just saw some and white in the background where my window was. But some tweaking with gimp produced reasonable output. Bit noisy, but I guess that's to be expected at the moment without the LED (and probably also some config tuning). So all in all looks like the sensor driver is doing it's job correctly.
The patch is in the latest release. I believe this can be closed then?
I think so yes.
Hardware: Surface Go 2 Distro: Fedora 37 Kernel: 6.0.12-1.surface libcamera build from repository (last commit)
Problem : Last August, the rear camera's autofocus was working. But, I recently tested again and found that it no longer works.
I tried looking for a libcamera commit that was working (around last August) with autofocus but couldn't find one. Therefore, I think the problem comes from the kernel.