search

akobel / linux-thinkpad-x1-tablet

2 stars 0 forks source link

Camera support #1

Open akobel opened 2 years ago

akobel commented 2 years ago

Continued from https://github.com/linux-surface/linux-surface/issues/91, where similar work has been done for the camera of Surface Go 2; let's hope that migrating that effort to the X1 tablet is feasible...

(more precisely, coming over from this comment)

akobel commented 2 years ago

Uhm, right... Would it be the one at INT3474:00??

Another huh:

static const struct int3472_tps68470_board_data thinkpad_x1_tps68470_board_data = {
    .dev_name = "i2c-INT3474:01",

For the Surface devices, .dev_name is i2c-INT3472:0x with x = 1 or 5; since I have

x1t2 kernel: int3472-tps68470 i2c-INT3472:05: TPS68470 REVID: 0x21

should I rather change that to .dev_name = "i2c-INT3472:05" as well?

akobel commented 2 years ago

(If you couldn't tell, I'm just doing shotgun debugging here. ;-))

akobel commented 2 years ago

Another huh:

static const struct int3472_tps68470_board_data thinkpad_x1_tps68470_board_data = {
  .dev_name = "i2c-INT3474:01",

For the Surface devices, .dev_name is i2c-INT3472:0x with x = 1 or 5; since I have

x1t2 kernel: int3472-tps68470 i2c-INT3472:05: TPS68470 REVID: 0x21

should I rather change that to .dev_name = "i2c-INT3472:05" as well?

And apparently the shotgun hit the target:

% ls -l /sys/bus/i2c/devices                                     
<snip>
lrwxrwxrwx 1 root root 0 Mar 17 00:26 i2c-INT3472:05 -> ../../../devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-8/i2c-INT3472:05
lrwxrwxrwx 1 root root 0 Mar 17 00:27 i2c-INT3474:01 -> ../../../devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-9/i2c-INT3474:01
lrwxrwxrwx 1 root root 0 Mar 17 00:27 i2c-INT3477:00 -> ../../../devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-8/i2c-INT3477:00
lrwxrwxrwx 1 root root 0 Mar 17 00:27 i2c-WCOM5116:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM5116:00

And:

% cam -l                                         
[0:01:21.180830775] [1661]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3384-44d59841
[0:01:21.191353835] [1662]  WARN CameraSensor camera_sensor.cpp:197 'ov2740 9-0010': Recommended V4L2 control 0x009a0922 not supported
[0:01:21.191375047] [1662]  WARN CameraSensor camera_sensor.cpp:249 'ov2740 9-0010': The sensor kernel driver needs to be fixed
[0:01:21.191380661] [1662]  WARN CameraSensor camera_sensor.cpp:251 'ov2740 9-0010': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information
[0:01:21.191581503] [1662]  WARN CameraSensorProperties camera_sensor_properties.cpp:141 No static properties available for 'ov2740'
[0:01:21.191593815] [1662]  WARN CameraSensorProperties camera_sensor_properties.cpp:143 Please consider updating the camera sensor properties database
[0:01:21.191599681] [1662]  WARN CameraSensor camera_sensor.cpp:396 'ov2740 9-0010': Failed to retrieve the camera location
[0:01:21.191606420] [1662] ERROR CameraSensor camera_sensor.cpp:535 'ov2740 9-0010': Camera sensor does not support test pattern modes.
[0:01:21.203558875] [1662] ERROR IPU3 ipu3.cpp:1244 Failed to initialise the IPU3 IPA
Available cameras:
1: 'Lenovo 500 RGB Camera: Lenovo 5' (\_SB_.PCI0.XHC_.RHUB.HS01-1.2:1.0-17ef:482f)
2: 'Lenovo 500 RGB Camera: Lenovo 5' (\_SB_.PCI0.XHC_.RHUB.HS01-1.2:1.2-17ef:482f)

This entry is my external webcam, but I suspect everything else looks good apart from the missing patch for libcamera.

I will polish that tomorrow, get rid of my debugging noise and let you know, but now I desperately need some sleep...

djrscally commented 2 years ago

Argh derp, my bad with the device name there - thanks for spotting that. Yep ok, with the extra patches into libcamera I'd expect this to work now - the sensor must have powered on properly to get past probe.

but now I desperately need some sleep...

Same for me - goodnight!

markum commented 2 years ago

I will try tonight to compile. Does this make still sense or do I need to wait until some modifications are done?

djrscally commented 2 years ago

This line would need changing to say "i2c-INT3472:05" instead of "i2c-INT3474:01", I mixed up the sensor and PMIC device names. Otherwise I think OK at this point.

kbingham commented 2 years ago

I will try tonight to compile. Does this make still sense or do I need to wait until some modifications are done?

The OV2740 CameraSensor Helper is now merged in libcamera. (Assuming that's what this refers to).

akobel commented 2 years ago

Thanks Kieran! @markum: Now following https://github.com/linux-surface/linux-surface/wiki/Camera-Support#libcamera-support should be enough to get the libcamera part going. You still need the tweak on the kernel part.

akobel commented 2 years ago

So, regarding our little beauty here: With the change from last night, I get

% cam -l               
[3:57:04.631124019] [46911]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3442-082cd76c-dirty (2022-03-17T10:13:53+01:00)
[3:57:04.639883230] [46912]  WARN CameraSensor camera_sensor.cpp:212 'ov2740 8-0010': Recommended V4L2 control 0x009a0922 not supported
[3:57:04.639931497] [46912]  WARN CameraSensor camera_sensor.cpp:264 'ov2740 8-0010': The sensor kernel driver needs to be fixed
[3:57:04.639939300] [46912]  WARN CameraSensor camera_sensor.cpp:266 'ov2740 8-0010': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information
[3:57:04.642016073] [46912]  WARN CameraSensor camera_sensor.cpp:411 'ov2740 8-0010': Failed to retrieve the camera location
[3:57:04.662811336] [46912]  WARN IPU3 ipu3.cpp:1151 Rotation control not exposed by \_SB_.PCI0.LNK2. Assume rotation 0
[3:57:04.662846700] [46912] ERROR V4L2 v4l2_device.cpp:185 'ov2740 8-0010': Control 0x00980914 not found
[3:57:04.663077560] [46912]  INFO IPU3 ipu3.cpp:1204 Registered Camera[0] "\_SB_.PCI0.LNK2" connected to CSI-2 receiver 2
Available cameras:
1: 'ov2740' (\_SB_.PCI0.LNK2)

I'm a bit puzzled, looking at the results from over there at the Surface thread, I'd expect to find the camera named \_SB_.PCI0.I2C4.CAM1 (corresponding to /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT3446:00/INT3474:00/path:\_SB_.PCI0.I2C4.CAM1).

Running qcam produces no visible image. And it makes some very mild rattling noise, like an autofocus permanently wiggling; which is surprising cause I do not expect moving parts here. Or it could be some loud coil whine, not quite sure.

djrscally commented 2 years ago

So, regarding our little beauty here: With the change from last night, I get

% cam -l               
[3:57:04.631124019] [46911]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3442-082cd76c-dirty (2022-03-17T10:13:53+01:00)
[3:57:04.639883230] [46912]  WARN CameraSensor camera_sensor.cpp:212 'ov2740 8-0010': Recommended V4L2 control 0x009a0922 not supported
[3:57:04.639931497] [46912]  WARN CameraSensor camera_sensor.cpp:264 'ov2740 8-0010': The sensor kernel driver needs to be fixed
[3:57:04.639939300] [46912]  WARN CameraSensor camera_sensor.cpp:266 'ov2740 8-0010': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information
[3:57:04.642016073] [46912]  WARN CameraSensor camera_sensor.cpp:411 'ov2740 8-0010': Failed to retrieve the camera location
[3:57:04.662811336] [46912]  WARN IPU3 ipu3.cpp:1151 Rotation control not exposed by \_SB_.PCI0.LNK2. Assume rotation 0
[3:57:04.662846700] [46912] ERROR V4L2 v4l2_device.cpp:185 'ov2740 8-0010': Control 0x00980914 not found
[3:57:04.663077560] [46912]  INFO IPU3 ipu3.cpp:1204 Registered Camera[0] "\_SB_.PCI0.LNK2" connected to CSI-2 receiver 2
Available cameras:
1: 'ov2740' (\_SB_.PCI0.LNK2)

I'm a bit puzzled, looking at the results from over there at the Surface thread, I'd expect to find the camera named \_SB_.PCI0.I2C4.CAM1 (corresponding to /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT3446:00/INT3474:00/path:\_SB_.PCI0.I2C4.CAM1).

Running qcam produces no visible image. And it makes some very mild rattling noise, like an autofocus permanently wiggling; which is surprising cause I do not expect moving parts here. Or it could be some loud coil whine, not quite sure.

Is it the world-facing or user-facing camera? We did add autofocus support recently, or at least a preliminary version, so it's possible. I'd only expect that on the world-facing one though.

Is there any output in dmesg or from qcam when it's running?

akobel commented 2 years ago

Given the black image, I can't tell for sure. ;-) But OV2740 should be the front (user-facing) one. LED doesn't turn on, by the way (but it should for both cams, that's the behavior in Win).

Tons of output in dmesg:

kernel: ipu3-cio2 0000:00:14.3: CSI-2 receiver port 2: frame sync error
kernel: ipu3-cio2 0000:00:14.3: payload length is 2725632, received 0
akobel commented 2 years ago

qcam: same output as cam -l, plus:

[4:16:01.746159652] [51178]  INFO Camera camera.cpp:1028 configuring streams: (0) 1280x720-NV12
Using software format conversion from NV12
markum commented 2 years ago
  • Run make menuconfig and make sure that the ov2740, cio2-bridge and anything called TPS68470 are enabled (use / to search) I compiled and installed libcamera. But with the kernel I could not get past this point. Even though I could find "ov2740, cio2-bridge and anything called TPS68470" there was no way to directly select them out. The search results should show me where those modules are, but I somehow could not retrace the steps so that I could find and select them.
djrscally commented 2 years ago
  • Run make menuconfig and make sure that the ov2740, cio2-bridge and anything called TPS68470 are enabled (use / to search) I compiled and installed libcamera. But with the kernel I could not get past this point. Even though I could find "ov2740, cio2-bridge and anything called TPS68470" there was no way to directly select them out. The search results should show me where those modules are, but I somehow could not retrace the steps so that I could find and select them.

You should be able to just press 1/2/3/whatever number they're listed as in the search results and be taken directly to them. Failing that they'll have some unmet dependency you need to enable first, for example they might have "depends on CONFIG_REGULATOR=n" listed in the search results; you'll need to search for and enable any dependencies that are shown with an n

martin9959 commented 2 years ago

qcam: same output as cam -l, plus:

[4:16:01.746159652] [51178]  INFO Camera camera.cpp:1028 configuring streams: (0) 1280x720-NV12
Using software format conversion from NV12

I have an X1 Tablet Gen 1, and I can confirm I get to exactly the same results. I just have to use 3474:00 instead of 3474:01, 3472:04 instead of 3472:05 and (obviously) 20GG002AGE instead of 20JCS00C00 in tps68470_board_data.c.

nidico commented 2 years ago

@markum and I tried to follow the proposed instructions on a X1 Tablet Gen 2 (KDE Neon user edition, based on Ubuntu Focal) with the following diff:

--- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c
+++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
@@ -205,7 +205,7 @@ static struct gpiod_lookup_table thinkpad_x1_int3474_gpios = {
 };

 static const struct int3472_tps68470_board_data thinkpad_x1_tps68470_board_data = {
-       .dev_name = "i2c-INT3474:01",
+       .dev_name = "i2c-INT3472:05",
        .tps68470_regulator_pdata = &thinkpad_x1_tps68470_pdata,
        .n_gpiod_lookups = 1,
        .tps68470_gpio_lookup_tables = {
@@ -238,7 +238,7 @@ static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
        {
                .matches = {
                        DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-                       DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "20JCS00C00"),
+                       DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "20JBCTO1WW"),
                },
                .driver_data = (void *)&thinkpad_x1_tps68470_board_data,
        },

In order to get a running kernel, we had to use the kernel config from the running linux-surface (5.16.13) kernel as a starting point instead of the proposed config, otherwise the system was stuck in "Loading".

Result:

$ sudo cam --list
[0:16:04.240746522] [5359]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3447-a8284e35
[0:16:04.245944467] [5360]  WARN CameraSensor camera_sensor.cpp:212 'ov2740 3-0010': Recommended V4L2 control 0x009a0922 not supported
[0:16:04.245997834] [5360]  WARN CameraSensor camera_sensor.cpp:264 'ov2740 3-0010': The sensor kernel driver needs to be fixed
[0:16:04.246019394] [5360]  WARN CameraSensor camera_sensor.cpp:266 'ov2740 3-0010': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information
[0:16:04.248622669] [5360]  WARN CameraSensor camera_sensor.cpp:411 'ov2740 3-0010': Failed to retrieve the camera location
[0:16:04.261119144] [5360]  WARN IPU3 ipu3.cpp:1151 Rotation control not exposed by \_SB_.PCI0.LNK2. Assume rotation 0
[0:16:04.261155414] [5360] ERROR V4L2 v4l2_device.cpp:185 'ov2740 3-0010': Control 0x00980914 not found
[0:16:04.261504996] [5360]  INFO IPU3 ipu3.cpp:1204 Registered Camera[0] "\_SB_.PCI0.LNK2" connected to CSI-2 receiver 2
Available cameras:
1: 'ov2740' (\_SB_.PCI0.LNK2)

sudo qcam only shows a black screen, the LED doesn't turn on.

akobel commented 2 years ago

@martin9959 @nidico Thanks, that'll be useful once we make the camera work.

  1. Could you provide the output of sudo dmidecode -t 1? I think we might want to filter not based on the huge list of individual product names (they also encode sales regions, IIUC), but perhaps based only on the first 5 chars of DMI_PRODUCT_NAME or DMI_PRODUCT_FAMILY or something.
  2. Could you also prepare a dump of the DSDT? That'd be with acpidump -b from package acpica and iasl -d *.dat to disassemble; the interesting file should be dsdt.dsl. Not sure whether we'll need it, but the fact that there are deviations between device naming in 1st Gen to 2nd Gen makes me wonder.
akobel commented 2 years ago

Regarding testing to get some more output: I confirmed that ov2740_powerup is called during probing and on each start of qcam.

Under the assumption that we accidentally enable the power saving mode: I tried to only use two of the gpios (all three combinations) in the sequence, but to no avail. LED doesn't light up, either.

I'm still pretty much stumbling in the dark. I think I understand the powerup sequence now, and it looks correct; but I do not know why/whether we know that the assignment of powerdown/powerdown2/reset is correct. Is there a way to manually activate the lines without the ov2740, and measure similar to I2cTestTool? Monitoring the GPIOs in Windows is probably not possible purely in software, is it?

On a side note, I feel that a lot of this debugging already happened in the Surface thread. Does someone know a way to fold out all the hidden items in and/or store that long thread to make them searchable and browsable? It's a pain to do this manually, just to redo it again after a reboot. I know that there is a gh command-line tool, and gh issue view 91 --comments -R linux-surface/linux-surface gives me the entire issue. But even though I don't mind the console, it's not the most convenient tool to read...

markum commented 2 years ago

@martin9959 @nidico Thanks, that'll be useful once we make the camera work.

1. Could you provide the output of `sudo dmidecode -t 1`? I think we might want to filter not based on the huge list of individual product names (they also encode sales regions, IIUC), but perhaps based only on the first 5 chars of DMI_PRODUCT_NAME or DMI_PRODUCT_FAMILY or something.

2. Could you also prepare a dump of the DSDT? That'd be with `acpidump -b` from package acpica and `iasl -d *.dat` to disassemble; the interesting file should be `dsdt.dsl`. Not sure whether we'll need it, but the fact that there are deviations between device naming in 1st Gen to 2nd Gen makes me wonder.

sudo dmidecode -t 1

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x000B, DMI type 1, 27 bytes
System Information
        Manufacturer: LENOVO
        Product Name: 20JBCTO1WW
        Version: ThinkPad X1 Tablet Gen 2
        Serial Number: R90PFTDS
        UUID: 5234cbcc-1e9b-11b2-a85c-d3432ea2f066
        Wake-up Type: Power Switch
        SKU Number: LENOVO_MT_20JB_BU_Think_FM_ThinkPad
        Family: ThinkPad
markum commented 2 years ago

acpidump -b just gives no result, nothing appears.

markum commented 2 years ago

sudo iasl -d *.dat

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20190509
Copyright (c) 2000 - 2019 Intel Corporation

File appears to be binary: found 158 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file apic.dat, Length 0xBC (188) bytes
ACPI: APIC 0x0000000000000000 0000BC (v03 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [APIC] decoded
Formatted output:  apic.dsl - 9150 bytes
File appears to be binary: found 115 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file asf!.dat, Length 0xA0 (160) bytes
ACPI: ASF! 0x0000000000000000 0000A0 (v32 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [ASF!] decoded
Formatted output:  asf!.dsl - 6349 bytes
File appears to be binary: found 40 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file batb.dat, Length 0x4A (74) bytes
ACPI: BATB 0x0000000000000000 00004A (v02 LENOVO TP-N1O   00001430 PTEC 00000002)
Unknown ACPI table signature [BATB], decoding ACPI table header only
Acpi Data Table [BATB] decoded
Formatted output:  batb.dsl - 1274 bytes
File appears to be binary: found 31 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file bgrt.dat, Length 0x38 (56) bytes
ACPI: BGRT 0x0000000000000000 000038 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [BGRT] decoded
Formatted output:  bgrt.dsl - 1606 bytes
File appears to be binary: found 14 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file boot.dat, Length 0x28 (40) bytes
ACPI: BOOT 0x0000000000000000 000028 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [BOOT] decoded
Formatted output:  boot.dsl - 1199 bytes
File appears to be binary: found 54 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file dbg2.dat, Length 0x54 (84) bytes
ACPI: DBG2 0x0000000000000000 000054 (v00 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [DBG2] decoded
Formatted output:  dbg2.dsl - 2599 bytes
File appears to be binary: found 25 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file dbgp.dat, Length 0x34 (52) bytes
ACPI: DBGP 0x0000000000000000 000034 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [DBGP] decoded
Formatted output:  dbgp.dsl - 1639 bytes
File appears to be binary: found 138 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file dmar.dat, Length 0xA8 (168) bytes
ACPI: DMAR 0x0000000000000000 0000A8 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [DMAR] decoded
Formatted output:  dmar.dsl - 4978 bytes
File appears to be binary: found 52095 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file dsdt.dat, Length 0x2A2E9 (172777) bytes
ACPI: DSDT 0x0000000000000000 02A2E9 (v02 LENOVO SKL      00000000 INTL 20160527)
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    dsdt.dsl - 1218142 bytes
File appears to be binary: found 40 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ecdt.dat, Length 0x53 (83) bytes
ACPI: ECDT 0x0000000000000000 000053 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [ECDT] decoded
Formatted output:  ecdt.dsl - 2259 bytes
File appears to be binary: found 207 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file facp.dat, Length 0xF4 (244) bytes
ACPI: FACP 0x0000000000000000 0000F4 (v05 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [FACP] decoded
Formatted output:  facp.dsl - 9265 bytes
File appears to be binary: found 57 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file facs.dat, Length 0x40 (64) bytes
ACPI: FACS 0x0000000000000000 000040
Acpi Data Table [FACS] decoded
Formatted output:  facs.dsl - 1368 bytes
File appears to be binary: found 43 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file fpdt.dat, Length 0x44 (68) bytes
ACPI: FPDT 0x0000000000000000 000044 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [FPDT] decoded
Formatted output:  fpdt.dsl - 1804 bytes
File appears to be binary: found 30 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file hpet.dat, Length 0x38 (56) bytes
ACPI: HPET 0x0000000000000000 000038 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [HPET] decoded
Formatted output:  hpet.dsl - 1865 bytes
File appears to be binary: found 109 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file lpit.dat, Length 0x94 (148) bytes
ACPI: LPIT 0x0000000000000000 000094 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [LPIT] decoded
Formatted output:  lpit.dsl - 4313 bytes
File appears to be binary: found 36 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file mcfg.dat, Length 0x3C (60) bytes
ACPI: MCFG 0x0000000000000000 00003C (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [MCFG] decoded
Formatted output:  mcfg.dsl - 1526 bytes
File appears to be binary: found 31 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file msdm.dat, Length 0x55 (85) bytes
ACPI: MSDM 0x0000000000000000 000055 (v03 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [MSDM] decoded
Formatted output:  msdm.dsl - 1557 bytes
File appears to be binary: found 20 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file nhlt.dat, Length 0x2D (45) bytes
ACPI: NHLT 0x0000000000000000 00002D (v00 LENOVO TP-N1O   00001430 PTEC 00000002)
Unknown ACPI table signature [NHLT], decoding ACPI table header only
Acpi Data Table [NHLT] decoded
Formatted output:  nhlt.dsl - 1119 bytes
File appears to be binary: found 309 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt10.dat, Length 0x626 (1574) bytes
ACPI: SSDT 0x0000000000000000 000626 (v02 LENOVO UsbCTabl 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt10.dsl - 9076 bytes
File appears to be binary: found 75 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt11.dat, Length 0xCA (202) bytes
ACPI: SSDT 0x0000000000000000 0000CA (v02 LENOVO HdaDsp   00000000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt11.dsl - 1405 bytes
File appears to be binary: found 225 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt12.dat, Length 0x29F (671) bytes
ACPI: SSDT 0x0000000000000000 00029F (v02 LENOVO sensrhub 00000000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt12.dsl - 5021 bytes
File appears to be binary: found 417 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt13.dat, Length 0x4C5 (1221) bytes
ACPI: SSDT 0x0000000000000000 0004C5 (v02 LENOVO TbtTypeC 00000000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt13.dsl - 12373 bytes
File appears to be binary: found 75 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt14.dat, Length 0x144 (324) bytes
ACPI: SSDT 0x0000000000000000 000144 (v02 LENOVO ADebTabl 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt14.dsl - 2349 bytes
File appears to be binary: found 753 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt15.dat, Length 0x507 (1287) bytes
ACPI: SSDT 0x0000000000000000 000507 (v02 PmRef  Cpu0Ist  00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt15.dsl - 9548 bytes
File appears to be binary: found 443 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt16.dat, Length 0x3FF (1023) bytes
ACPI: SSDT 0x0000000000000000 0003FF (v02 PmRef  Cpu0Cst  00003001 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt16.dsl - 7130 bytes
File appears to be binary: found 52 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt17.dat, Length 0xBA (186) bytes
ACPI: SSDT 0x0000000000000000 0000BA (v02 PmRef  Cpu0Hwp  00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt17.dsl - 1339 bytes
File appears to be binary: found 289 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt18.dat, Length 0x628 (1576) bytes
ACPI: SSDT 0x0000000000000000 000628 (v02 PmRef  HwpLvt   00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt18.dsl - 8492 bytes
File appears to be binary: found 1057 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt19.dat, Length 0xD14 (3348) bytes
ACPI: SSDT 0x0000000000000000 000D14 (v02 PmRef  ApIst    00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt19.dsl - 22678 bytes
File appears to be binary: found 5027 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt1.dat, Length 0x3CFB (15611) bytes
ACPI: SSDT 0x0000000000000000 003CFB (v02 LENOVO DptfTabl 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt1.dsl - 83496 bytes
File appears to be binary: found 144 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt20.dat, Length 0x317 (791) bytes
ACPI: SSDT 0x0000000000000000 000317 (v02 PmRef  ApHwp    00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt20.dsl - 3975 bytes
File appears to be binary: found 155 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt21.dat, Length 0x30A (778) bytes
ACPI: SSDT 0x0000000000000000 00030A (v02 PmRef  ApCst    00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt21.dsl - 3874 bytes
File appears to be binary: found 363 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt2.dat, Length 0x3CC (972) bytes
ACPI: SSDT 0x0000000000000000 0003CC (v02 LENOVO Tpm2Tabl 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt2.dsl - 8345 bytes
File appears to be binary: found 4216 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt3.dat, Length 0x30E4 (12516) bytes
ACPI: SSDT 0x0000000000000000 0030E4 (v02 LENOVO SaSsdt   00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt3.dsl - 77655 bytes
File appears to be binary: found 682 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt4.dat, Length 0x5B6 (1462) bytes
ACPI: SSDT 0x0000000000000000 0005B6 (v02 LENOVO PerfTune 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt4.dsl - 13272 bytes
File appears to be binary: found 1101 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt5.dat, Length 0x14D0 (5328) bytes
ACPI: SSDT 0x0000000000000000 0014D0 (v02 LENOVO RVP7Rtd3 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt5.dsl - 15406 bytes
File appears to be binary: found 72 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt6.dat, Length 0x21C (540) bytes
ACPI: SSDT 0x0000000000000000 00021C (v01 LENOVO Rmv_Batt 00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt6.dsl - 1942 bytes
File appears to be binary: found 2527 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt7.dat, Length 0x1AB0 (6832) bytes
ACPI: SSDT 0x0000000000000000 001AB0 (v02 LENOVO ProjSsdt 00000010 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt7.dsl - 49935 bytes
File appears to be binary: found 1395 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt8.dat, Length 0x17AE (6062) bytes
ACPI: SSDT 0x0000000000000000 0017AE (v02 LENOVO CpuSsdt  00003000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt8.dsl - 29125 bytes
File appears to be binary: found 347 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt9.dat, Length 0x56D (1389) bytes
ACPI: SSDT 0x0000000000000000 00056D (v02 LENOVO CtdpB    00001000 INTL 20160527)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output:    ssdt9.dsl - 7194 bytes
File appears to be binary: found 27 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file tpm2.dat, Length 0x34 (52) bytes
ACPI: TPM2 0x0000000000000000 000034 (v03 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [TPM2] decoded
Formatted output:  tpm2.dsl - 1372 bytes
File appears to be binary: found 37 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file uefi1.dat, Length 0x42 (66) bytes
ACPI: UEFI 0x0000000000000000 000042 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [UEFI] decoded
Formatted output:  uefi1.dsl - 1390 bytes
File appears to be binary: found 201 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file uefi2.dat, Length 0x13E (318) bytes
ACPI: UEFI 0x0000000000000000 00013E (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [UEFI] decoded
Formatted output:  uefi2.dsl - 2589 bytes
File appears to be binary: found 15 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file wsmt.dat, Length 0x28 (40) bytes
ACPI: WSMT 0x0000000000000000 000028 (v01 LENOVO TP-N1O   00001430 PTEC 00000002)
Acpi Data Table [WSMT] decoded
Formatted output:  wsmt.dsl - 1313 bytes
martin9959 commented 2 years ago 
1. Could you provide the output of `sudo dmidecode -t 1`? 
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000D, DMI type 1, 27 bytes
System Information
    Manufacturer: LENOVO
    Product Name: 20GG002AGE
    Version: ThinkPad X1 Tablet
    Serial Number: R90KP7Q4
    UUID: da51d3cc-3522-11b2-a85c-effbc28c5979
    Wake-up Type: Power Switch
    SKU Number: LENOVO_MT_20GG_BU_Think_FM_ThinkPad X1 Tablet
    Family: ThinkPad X1 Tablet

I think we might want to filter not based on the huge list of individual product names (they also encode sales regions, IIUC), but perhaps based only on the first 5 chars of DMI_PRODUCT_NAME or DMI_PRODUCT_FAMILY or something.

I think rather the first 4 digits, as Lenovo does as well to identify a model.

  1. Could you also prepare a dump of the DSDT? That'd be with acpidump -b from package acpica and iasl -d *.dat to disassemble; the interesting file should be dsdt.dsl. Not sure whether we'll need it, but the fact that there are deviations between device naming in 1st Gen to 2nd Gen makes me wonder.

acpidump -b just gives no result, nothing appears.

Same here, I did a cat /sys/firmware/acpi/tables/DSDT > dsdt.aml and iasl -d dsdt.aml and got the attached dsdt.dsl.

markum commented 2 years ago

Same here, I did a cat /sys/firmware/acpi/tables/DSDT > dsdt.aml and iasl -d dsdt.aml and got the attached dsdt.dsl.

Tried the same with and without sudo, but I get a permission denied. cd /sys/firmware/acpi/tables/ shows that DSDT does not exist.

markum commented 2 years ago

During boot I shortly see the following: [ 1.378689.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.397168.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.405682.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.472516.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517

djrscally commented 2 years ago

Regarding testing to get some more output: I confirmed that ov2740_powerup is called during probing and on each start of qcam.

Under the assumption that we accidentally enable the power saving mode: I tried to only use two of the gpios (all three combinations) in the sequence, but to no avail. LED doesn't light up, either.

Nuts. I'll take a closer look at the code and datasheet, see if I can spot something. Note that the LED won't work for you yet because I haven't shared the LED driver; it's in the works :)

I'm still pretty much stumbling in the dark. I think I understand the powerup sequence now, and it looks correct; but I do not know why/whether we know that the assignment of powerdown/powerdown2/reset is correct. Is there a way to manually activate the lines without the ov2740, and measure similar to I2cTestTool? Monitoring the GPIOs in Windows is probably not possible purely in software, is it?

We don't! All we can see from the register dump of the TPS68470 you got was that all three were set high. When the camera was running. The specifics of which line represents powerdown/powerdown2/reset we do not know, nor do we know the ordering.

You can manually activate the lines using sudo gpioset --mode wait 1 4=1 5=1 6=1. CTRL-C to cancel and sudo gpioset 4=0 5=0 6=0 to turn off (no need for --wait)

Monitoring the GPIOs in Windows is done through the I2CTestTool talking to the TPS68470 chip.

On a side note, I feel that a lot of this debugging already happened in the Surface thread. Does someone know a way to fold out all the hidden items in and/or store that long thread to make them searchable and browsable? It's a pain to do this manually, just to redo it again after a reboot. I know that there is a gh command-line tool, and gh issue view 91 --comments -R linux-surface/linux-surface gives me the entire issue. But even though I don't mind the console, it's not the most convenient tool to read...

I know right? Man it's annoying as hell, I hate it. Never found another way though sorry.

djrscally commented 2 years ago

During boot I shortly see the following: [ 1.378689.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.397168.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.405682.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517 [ 1.472516.] ov2740 i2c-INT3474:01: failed to check HW configuration: -517

Ooops; that's my bad, it's not an error, it just means deferring probe until the cio2-bridge is ready. You can ignore it, and I'll fix it so it doesn't show the error unless it's actually an error.

akobel commented 2 years ago

Note that the LED won't work for you yet because I haven't shared the LED driver; it's in the works :)

Ah, of course; it's a separate input. I was thinking about the privacy LED as being always honest (read: connected in hardware to the power supply of the camera chip), so that you can't just bypass the LED by not activating it; but of course I shouldn't be surprised that this is wishful thinking.

I'm still pretty much stumbling in the dark. I think I understand the powerup sequence now, and it looks correct; but I do not know why/whether we know that the assignment of powerdown/powerdown2/reset is correct. Is there a way to manually activate the lines without the ov2740, and measure similar to I2cTestTool? Monitoring the GPIOs in Windows is probably not possible purely in software, is it?

We don't! All we can see from the register dump of the TPS68470 you got was that all three were set high. When the camera was running. The specifics of which line represents powerdown/powerdown2/reset we do not know, nor do we know the ordering.

IIUC, then I should also try to change the order in which those GPIOs are activated, to increase the chances of hitting the proper powerup sequence. Will do that.

You can manually activate the lines using sudo gpioset --mode wait 1 4=1 5=1 6=1. CTRL-C to cancel and sudo gpioset 4=0 5=0 6=0 to turn off (no need for --wait)

On a second thought, probably not much help unless I can also check whether the camera works after that. Perhaps if it's possible to activate/powerup the camera from the outside, bypassing the driver; but then again, rebuilding and reloading the module isn't too much hassle.

Monitoring the GPIOs in Windows is done through the I2CTestTool talking to the TPS68470 chip.

I meant monitoring in an "strace-like" fashion, such that one can monitor the powerup sequence...

djrscally commented 2 years ago

Note that the LED won't work for you yet because I haven't shared the LED driver; it's in the works :)

Ah, of course; it's a separate input. I was thinking about the privacy LED as being always honest (read: connected in hardware to the power supply of the camera chip), so that you can't just bypass the LED by not activating it; but of course I shouldn't be surprised that this is wishful thinking.

Yeah you'd think they'd be designed like that, but they haven't been on any model I've worked on so far. The lesson is; don't trust your laptop's privacy light! I've got the LED working with the alternative PMIC and set that to be always on when the camera is, will try and do it that way for the TPS68470 ones too.

I'm still pretty much stumbling in the dark. I think I understand the powerup sequence now, and it looks correct; but I do not know why/whether we know that the assignment of powerdown/powerdown2/reset is correct. Is there a way to manually activate the lines without the ov2740, and measure similar to I2cTestTool? Monitoring the GPIOs in Windows is probably not possible purely in software, is it?

We don't! All we can see from the register dump of the TPS68470 you got was that all three were set high. When the camera was running. The specifics of which line represents powerdown/powerdown2/reset we do not know, nor do we know the ordering.

IIUC, then I should also try to change the order in which those GPIOs are activated, to increase the chances of hitting the proper powerup sequence. Will do that.

It might help yeah.

You can manually activate the lines using sudo gpioset --mode wait 1 4=1 5=1 6=1. CTRL-C to cancel and sudo gpioset 4=0 5=0 6=0 to turn off (no need for --wait)

On a second thought, probably not much help unless I can also check whether the camera works after that. Perhaps if it's possible to activate/powerup the camera from the outside, bypassing the driver; but then again, rebuilding and reloading the module isn't too much hassle.

Not really sure how to drive the clock / regulators externally. There might be some way through debugfs, but I've never tried it.

Monitoring the GPIOs in Windows is done through the I2CTestTool talking to the TPS68470 chip.

I meant monitoring in an "strace-like" fashion, such that one can monitor the powerup sequence...

Ah-ha sorry; there's this driver which again requires some ACPI editing, but that inserts a trace between the OS and the I2C bus and reports out the settings as they're passed in. That ought to do the trick - I've had it working on my Go2 but found it quite difficult to interpret, so switched to using the I2cTestTool instead.

martin9959 commented 2 years ago

I just realised that when I start qcam for the first time after a reboot, it actually records something - see attached. But the (flickering) image stays the same when I move the device, so it seems that it's only recorded once at the beginning. When I close the window and start qcam again, the window stays black.

akobel commented 2 years ago

Oh, nice! I observed the same behavior, but I didn't realize that this is more than just plain noise in the upper part of the view; probably because it was too dark in the room, and thus impossible to make out any shapes.

djrscally commented 2 years ago

O...kay. Well that demonstrates that the power-on sequence is working fine I think...let me double check all the PLL settings and make sure it's setting the clock as we expect, as that can have weird effects sometimes.

djrscally commented 2 years ago

Can I get a dmesg dump of the output whilst qcam is running please?

akobel commented 2 years ago

Sure, find it attached. The gist is

[  112.616907] ipu3-cio2 0000:00:14.3: CSI-2 receiver port 2: escape mode ultra-low power state exit for clock lane
[  112.655053] ipu3-cio2 0000:00:14.3: payload length is 2725632, received 1123200
[  112.682311] use of bytesused == 0 is deprecated and will be removed in the future,
[  112.682314] use the actual size instead.
[  112.747314] ipu3-cio2 0000:00:14.3: CSI-2 receiver port 2: frame sync error
[  112.812960] ipu3-cio2 0000:00:14.3: payload length is 2725632, received 0

and then interspersed repeats of the latter two messages.

I left some pr_info output, line numbers are not quite matching the original. Please let me know if I can offer anything else by adding debug statements...

dmesg.log qcam.log

djrscally commented 2 years ago

So this is the message from the ipu3-cio2 driver complaining that something's wrong:

[  112.655053] ipu3-cio2 0000:00:14.3: payload length is 2725632, received 1123200
[  112.747314] ipu3-cio2 0000:00:14.3: CSI-2 receiver port 2: frame sync error
[  112.780219] ipu3-cio2 0000:00:14.3: CSI-2 receiver port 2: frame sync error
[  112.812960] ipu3-cio2 0000:00:14.3: payload length is 2725632, received 0

The payload length is the calculated length of the frame that should be received, which is the 1932x1092 output of the driver packed into a 10-pixels-per-32-bytes format (which comes out as 2700480 bytes and I guess some padding). The received figure is the data actually received from the sensor, which means you're getting about half of a single frame and then nothing after that...which does tally with @martin9959's observation.

I think I'm wavering back towards the power-on sequence being bad. Any chance of the dmesg output with each of these three commented out in turn?

martin9959 commented 2 years ago

I think I'm wavering back towards the power-on sequence being bad. Any chance of the dmesg output with each of these three commented out in turn?

Here are my findings so far: 

[0:02:16.919050028] [2529]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3446-a8284e35
[0:02:16.961733756] [2537]  WARN CameraSensor camera_sensor.cpp:212 'ov2740 3-0010': Recommended V4L2 control 0x009a0922 not supported
[0:02:16.961956343] [2537]  WARN CameraSensor camera_sensor.cpp:264 'ov2740 3-0010': The sensor kernel driver needs to be fixed
[0:02:16.962018426] [2537]  WARN CameraSensor camera_sensor.cpp:266 'ov2740 3-0010': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information
[0:02:16.969136107] [2537]  WARN CameraSensor camera_sensor.cpp:411 'ov2740 3-0010': Failed to retrieve the camera location
[0:02:17.021371505] [2537]  WARN IPU3 ipu3.cpp:1151 Rotation control not exposed by \_SB_.PCI0.LNK2. Assume rotation 0
[0:02:17.021494695] [2537] ERROR V4L2 v4l2_device.cpp:185 'ov2740 3-0010': Control 0x00980914 not found
[0:02:17.022534900] [2537]  INFO IPU3 ipu3.cpp:1204 Registered Camera[0] "\_SB_.PCI0.LNK2" connected to CSI-2 receiver 2
[0:02:17.327451695] [2529]  INFO Camera camera.cpp:1028 configuring streams: (0) 1280x720-NV12
Using software format conversion from NV12
[0:02:17.398866834] [2537] ERROR V4L2 v4l2_videodevice.cpp:1612 /dev/video12[40:cap]: Failed to queue buffer 0: Ein-/Ausgabefehler der Gegenstelle (remote)
[0:02:17.438664294] [2537] ERROR V4L2 v4l2_videodevice.cpp:1612 /dev/video12[40:cap]: Failed to queue buffer 1: Ein-/Ausgabefehler der Gegenstelle (remote)
[0:02:17.478852116] [2537] ERROR V4L2 v4l2_videodevice.cpp:1612 /dev/video12[40:cap]: Failed to queue buffer 2: Ein-/Ausgabefehler der Gegenstelle (remote)
[0:02:17.522582833] [2537] ERROR V4L2 v4l2_videodevice.cpp:1612 /dev/video12[40:cap]: Failed to queue buffer 3: Ein-/Ausgabefehler der Gegenstelle (remote)

dmesg | grep INT347: 

[   13.468077] int3472-tps68470 i2c-INT3472:04: TPS68470 REVID: 0x21
[   13.545655] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   13.550340] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   13.551828] ipu3-cio2 0000:00:14.3: Found supported sensor INT3474:00
[  137.405132] ov2740 i2c-INT3474:00: failed to read ISP CTRL00
[  137.405266] ov2740 i2c-INT3474:00: write reg 0x0103 return err = -121
[  137.405274] ov2740 i2c-INT3474:00: failed to set plls
[  137.405406] ov2740 i2c-INT3474:00: failed to stop streaming
[  137.444923] ov2740 i2c-INT3474:00: failed to read ISP CTRL00
[  137.445060] ov2740 i2c-INT3474:00: write reg 0x0103 return err = -121
[  137.445068] ov2740 i2c-INT3474:00: failed to set plls
[  137.445202] ov2740 i2c-INT3474:00: failed to stop streaming
[  137.484875] ov2740 i2c-INT3474:00: failed to read ISP CTRL00
[  137.484969] ov2740 i2c-INT3474:00: write reg 0x0103 return err = -121
[  137.484979] ov2740 i2c-INT3474:00: failed to set plls
[  137.485336] ov2740 i2c-INT3474:00: failed to stop streaming
[  137.528916] ov2740 i2c-INT3474:00: failed to read ISP CTRL00
[  137.529097] ov2740 i2c-INT3474:00: write reg 0x0103 return err = -121
[  137.529105] ov2740 i2c-INT3474:00: failed to set plls
[  137.529274] ov2740 i2c-INT3474:00: failed to stop streaming

(full dmesg)

dmesg | grep INT347: 

[   11.919794] int3472-tps68470 i2c-INT3472:04: TPS68470 REVID: 0x21
[   11.973890] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   11.977095] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   11.978363] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   11.985098] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   11.989020] ov2740 i2c-INT3474:00: failed to check HW configuration: -517
[   12.012651] ipu3-cio2 0000:00:14.3: Found supported sensor INT3474:00
[   12.043019] ov2740 i2c-INT3474:00: failed to find sensor: -121
[   12.045778] ov2740: probe of i2c-INT3474:00 failed with error -121

(full dmesg)

djrscally commented 2 years ago

@martin9959

last line (reset) commented out: qcam starts with black screen and message:

This means that it did power on during probe (at least enough to take a single i2c message so the driver could read the sensor ID), but subsequently didn't seem to work during an attempted stream. That's...weird, to say the least.

middle line commented out (powerdown2): qcam finds no camera first line commented out (powerdown): same as with powerdown2 commented out.

This means it failed to power up correctly at all.

My guess, from those results, is that the line I've labelled reset is tied to XSHUTDN2 and is the one that drives the power saving mode...but it's weird that it wouldn't even take i2c transfers (error number 121 is "Remote I/O Error" and comes from I2C core)

It's a bit confusing; reading the datasheet it definitely seems like we toggle the PSV mode by setting all three GPIOs, but not doing so doesn't work and the Windows driver seems to do the same thing

akobel commented 2 years ago

Trying further (more or less random) things to gain insight.

First observation: while qcam is running, four regulators of INT3472:05 are active with the following voltages:

CORE: disabled  900000
ANA:  disabled  875000
VCM:  disabled  875000
VIO:  enabled  1800600
VSIO: enabled  1800600  -> i2c-INT3474:01-dovdd
AUX1: enabled  1213200  -> i2c-INT3474:01-dvdd
AUX2: enabled  1800600  -> i2c-INT3474:01-avdd

The OV2740 preliminary datasheet says:

But according to the I2cTestTool output and interpretation, only VCM and ANA run 2.8V; so I wonder whether one of them should be the avdd source rather than AUX2. On the other hand, both shouldn't be active according to the I2cTestTool output?

Second, I tried to reproduce something similar to I2cTestTool while qcam is running on Linux, but failed miserably. Would something like i2cget 7 0x4c (not sure about 7 or 8, and not sure about 0x4c or 0x4d) be correct? IIUC, I would need the same/similar tweak as on Windows with the patched DSDT (no problem, worked following the Arch Wiki instructions) to add a proxy device, but also one with an appropriate driver - anyone aware of the equivalent on Linux?

djrscally commented 2 years ago

But according to the I2cTestTool output and https://github.com/akobel/linux-thinkpad-x1-tablet/issues/1#issuecomment-1059847916, only VCM and ANA run 2.8V; so I wonder whether one of them should be the avdd source rather than AUX2. On the other hand, both shouldn't be active according to the I2cTestTool output?

No I'm confident we got the right lines, or the chip simply wouldn't turn on at all and it definitely is doing. The 1.8V supply when the datasheet says we should have 2.8V is weird but I suppose it could be compensated for in other ways...passing that line through a voltage convertor or something maybe.

Second, I tried to reproduce something similar to I2cTestTool while qcam is running on Linux, but failed miserably. Would something like i2cget 7 0x4c (not sure about 7 or 8, and not sure about 0x4c or 0x4d) be correct?

Assuming the sensor is on bus 7 with address 0x4c, you could do something like this:

sudo i2ctransfer -y -f 7 w2@0x4c 0x30 0x0a r2

Which is i2ctransfer -y (meaning skip the confirmation) -f (meaning run even though there's a driver holding the device) 7 (the bus number) w2 (write 3 bytes) @0x4c (the address of the chip) 0x30 0x0a (the 2 bytes to write, which sets the internal pointer to register 0x300a) r2 (meaning read 2 bytes) - that should return the chips ID which is 0x2740

martin9959 commented 2 years ago

Assuming the sensor is on bus 7 with address 0x4c, you could do something like this:

sudo i2ctransfer -y -f 7 w2@0x4c 0x30 0x0a r2

Which is i2ctransfer -y (meaning skip the confirmation) -f (meaning run even though there's a driver holding the device) 7 (the bus number) w2 (write 3 bytes) @0x4c (the address of the chip) 0x30 0x0a (the 2 bytes to write, which sets the internal pointer to register 0x300a) r2 (meaning read 2 bytes) - that should return the chips ID which is 0x2740

hm, I have 

root@x1t:/home/martin# ls -l /sys/bus/i2c/devices/
insgesamt 0
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-0 -> ../../../devices/pci0000:00/0000:00:1f.4/i2c-0
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-1 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-2 -> ../../../devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-2
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-3 -> ../../../devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-3
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-4 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-5 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-5
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-6 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-6
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-7 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/i2c-7
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-8 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/i2c-8
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-9 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-2/i2c-9
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-BCM2F3D:00 -> ../../../devices/pci0000:00/0000:00:1f.4/i2c-0/i2c-BCM2F3D:00
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-INT3472:04 -> ../../../devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-2/i2c-INT3472:04
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-INT3474:00 -> ../../../devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-3/i2c-INT3474:00
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-INT3477:00 -> ../../../devices/pci0000:00/0000:00:15.2/i2c_designware.1/i2c-2/i2c-INT3477:00
lrwxrwxrwx 1 root root 0 26. Mär 08:33 i2c-WCOM5077:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-WCOM5077:00

and 

root@x1t:/home/martin# i2cdetect -l
i2c-0   smbus       SMBus I801 adapter at efa0          SMBus adapter
i2c-1   i2c         Synopsys DesignWare I2C adapter     I2C adapter
i2c-2   i2c         Synopsys DesignWare I2C adapter     I2C adapter
i2c-3   i2c         Synopsys DesignWare I2C adapter     I2C adapter
i2c-4   i2c         i915 gmbus dpc                      I2C adapter
i2c-5   i2c         i915 gmbus dpb                      I2C adapter
i2c-6   i2c         i915 gmbus dpd                      I2C adapter
i2c-7   i2c         AUX A/DDI A/PHY A                   I2C adapter
i2c-8   i2c         AUX B/DDI B/PHY B                   I2C adapter
i2c-9   i2c         AUX C/DDI C/PHY C                   I2C adapter

So I tried

root@x1t:/home/martin# i2ctransfer -y -f 2 w2@0x4d 0x30 0x0a r2

which returned 

0x38 0x00

both when the camera is running and when it's not.

When I try

root@x1t:/home/martin# i2cdetect 2

the result is different though - with running camera it returns 

Warning: Can't use SMBus Quick Write command, will skip some addresses
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                                                 
10:                                                 
20:                                                 
30: -- -- -- -- -- -- -- --                         
40:                                                 
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60:                                                 
70:

and with camera off

Warning: Can't use SMBus Quick Write command, will skip some addresses
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                                                 
10:                                                 
20:                                                 
30: -- -- -- -- -- -- -- --                         
40:                                                 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60:                                                 
70:

Is that expected? I don't have the lines as in https://github.com/akobel/linux-thinkpad-x1-tablet/issues/1#issuecomment-1058679629 in my DSDT, so 0x4d is a complete guess based on nothing but what I've read in the discussion above.

As to be expected from https://github.com/akobel/linux-thinkpad-x1-tablet/issues/1#issuecomment-1059218290, 

i2ctransfer -y -f 2 w2@0x4c 0x30 0x0a r2

failed with

Error: Sending messages failed: Remote I/O error
akobel commented 2 years ago

Thanks, worked like a charm. (Can't read past the first 256 bytes, so I can't find the 0x2740; but that's the same on Windows.)

Didn't really analyze yet, but here's the readings. [ ] marks differences

Windows, camera off:

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00  20  02  00  00  00  01  03    02  11  aa  20  01  d0  00  00 
0010:   05  00  00  00  01  08  01  08    01  08  8a  08  8a  08  c2  08 
0020:   c2  08  00  00  00  00  00  00    00  00  0a  00  00  00  00  00 
0030:   07  38  00  00  00  00  00  00    00  00  00  00  6d  13  34  34 
0040:   34  6d  0c  00  00  00  00  00    04  00  00  00  00  00  00  00

Linux, camera off: ([ ] marks changes over Windows with camera off)

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00 [00] 02  00  00  00  01 [00]  [00][00][00][00][00] d0  00  00 
0010:  [00] 00  00  00  01  08  01  08    01  08 [01] 08 [02] 08 [02] 08 
0020:  [02] 08  00  00  00  00 [08] 00    00  00  0a  00  00  00  00  00 
0030:  [02] 38  00  00  00  00  00  00    00  00  00  00 [00] 13 [6d] 34 
0040:   34 [00][00] 00  00  00  00  00    04  00  00  00  00  00  00  00

Windows, (front) camera active: ([ ] marks changes over Windows with camera off)

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00  20 [d2] 00  00  00  01  03    02  11  aa  20  01 [d7] 00 [0a]
0010:   05  00  00  00  01  08  01  08    01  08  8a  08  8a  08  c2  08 
0020:   c2  08  00  00  00  00  00 [70]  [c0] 00  0a  00  00  00  00  00 
0030:   07  38  00  00  00  00  00  00    00  00  00  00  6d  13  34  34 
0040:   34  6d  0c [03] 00 [01][01] 00    04  00  00  00  00  00  00  00

Linux, (front) camera as active as we currently get it (qcam running): ([ ] marks changes over Windows with camera active)

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00 [00] d2  00  00  00  01  03    02 [03] aa  20  01  d7  00  0a 
0010:   05  00  00  00  01  08  01  08    01  08 [01] 08 [02] 08 [02] 08 
0020:  [02] 08  00  00  00  00 [08] 70   [00] 00  0a  00  00  00  00  00 
0030:  [02] 38  00  00  00  00  00  00    00  00  00  00 [00] 13  34  34 
0040:   34 [00][00] 03  00  01  01  00    04  00  00  00  00  00  00  00

As before, bytes 0x50 to 0xfe are only zeros, 0xff stays 21. Skipping those.

djrscally commented 2 years ago

Hang on sorry, are we sure that's the address of the camera sensor, as opposed to the PMIC?

On Sat, 26 Mar 2022, 08:20 Alexander Kobel, @.***> wrote:

Thanks, worked like a charm. (Can't read past the first 256 bytes, so I can't find the 0x2740; but that's the same on Windows.)

Didn't really analyze yet, but here's the readings. [ ] marks differences

Windows, camera off:

    00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f

0000: 00 20 02 00 00 00 01 03 02 11 aa 20 01 d0 00 00 0010: 05 00 00 00 01 08 01 08 01 08 8a 08 8a 08 c2 08 0020: c2 08 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 0030: 07 38 00 00 00 00 00 00 00 00 00 00 6d 13 34 34 0040: 34 6d 0c 00 00 00 00 00 04 00 00 00 00 00 00 00

Linux, camera off: ([ ] marks changes over Windows with camera off)

    00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f

0000: 00 [00] 02 00 00 00 01 [00] [00][00][00][00][00] d0 00 00 0010: [00] 00 00 00 01 08 01 08 01 08 [01] 08 [02] 08 [02] 08 0020: [02] 08 00 00 00 00 [08] 00 00 00 0a 00 00 00 00 00 0030: [02] 38 00 00 00 00 00 00 00 00 00 00 [00] 13 [6d] 34 0040: 34 [00][00] 00 00 00 00 00 04 00 00 00 00 00 00 00

Windows, (front) camera active: ([ ] marks changes over Windows with camera off)

    00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f

0000: 00 20 [d2] 00 00 00 01 03 02 11 aa 20 01 [d7] 00 [0a] 0010: 05 00 00 00 01 08 01 08 01 08 8a 08 8a 08 c2 08 0020: c2 08 00 00 00 00 00 [70] [c0] 00 0a 00 00 00 00 00 0030: 07 38 00 00 00 00 00 00 00 00 00 00 6d 13 34 34 0040: 34 6d 0c [03] 00 [01][01] 00 04 00 00 00 00 00 00 00

Linux, (front) camera as active as we currently get it (qcam running): ([ ] marks changes over Windows with camera active)

    00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f

0000: 00 [00] d2 00 00 00 01 03 02 [03] aa 20 01 d7 00 0a 0010: 05 00 00 00 01 08 01 08 01 08 [01] 08 [02] 08 [02] 08 0020: [02] 08 00 00 00 00 [08] 70 [00] 00 0a 00 00 00 00 00 0030: [02] 38 00 00 00 00 00 00 00 00 00 00 [00] 13 [6d] 34 0040: 34 [00][00] 03 00 01 01 00 04 00 00 00 00 00 00 00

As before, bytes 0x50 to 0xfe are only zeros, 0xff stays 21. Skipping those.

— Reply to this email directly, view it on GitHub https://github.com/akobel/linux-thinkpad-x1-tablet/issues/1#issuecomment-1079638506, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDBE23ZN5CMNUZQ3RUCBRLVB3CDBANCNFSM5PPEUDAQ . You are receiving this because you were mentioned.Message ID: @.***>

akobel commented 2 years ago

Ah, dang. Yeah, that explains why I can't find 0x2740. :D

Of course, PMIC. Wanted to check for any more or less obvious problems there first - lacking any better idea, mostly... But doesn't seem like there's anything suspicious at first glance.

akobel commented 2 years ago

Oh, and as for @martin9959, I can't seem to find a way to read from the camera.

IIUC, the following entry in the DSDT for CAM1 suggests that the chip address is 0x36:

I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
    AddressingMode7Bit, "\\_SB.PCI0.I2C4",
    0x00, ResourceConsumer, , Exclusive,
    )

but that doesn't work, no matter if the camera is running or not.

martin9959 commented 2 years ago

I tried a script to do i2ctransfer -y -f 2 w2@<address> 0x30 0x0a r2 on every address from 0x08 to 0x77 of the camera (which is i2c-3 in my device, I believe). I got no reply on any address while the camera is off, and only replies from 0x10 and 0x21 while the camera is running, the reply being 0x00 0x27 in both cases.

akobel commented 2 years ago

Confirmed, I can also talk to the camera with i2ctransfer -y -f 8 w2@0x10 0x30 0x0a r3 (i2c-8 for me now) while qcam is running. The above command return 0x00 0x27 0x40 as expected from the datasheet (chip ID has 3 bytes).

Concerning the power saving mode, the vicinity of 0x2000 is filled with zeros throughout. Which is not exactly the default setting according to the spec, but should mean that the power saving mode is disabled...

djrscally commented 2 years ago

Based on the dump you guys got I'd expect to have to set to bus 3, device 0x10 to talk to the camera:

kern :info : [ 1387.864633] __dump_i2c_dev_dsm(): i2c device _DSM data (1 of 1): 0x03001000, bus: 0x03, second_byte: 0x00, addr: 0x10, dev_type: 0x00

If you're getting the 0x00 0x27 0x40 back though you're doing the right thing.

Windows, (front) camera active: ([ ] marks changes over Windows with camera off)

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00  20 [d2] 00  00  00  01  03    02  11  aa  20  01 [d7] 00 [0a]
0010:   05  00  00  00  01  08  01  08    01  08  8a  08  8a  08  c2  08 
0020:   c2  08  00  00  00  00  00 [70]  [c0] 00  0a  00  00  00  00  00 
0030:   07  38  00  00  00  00  00  00    00  00  00  00  6d  13  34  34 
0040:   34  6d  0c [03] 00 [01][01] 00    04  00  00  00  00  00  00  00

Linux, (front) camera as active as we currently get it (qcam running): ([ ] marks changes over Windows with camera active)

        00  01  02  03  04  05  06  07    08  09  0a  0b  0c  0d  0e  0f 
-------------------------------------------------------------------------
0000:   00 [00] d2  00  00  00  01  03    02 [03] aa  20  01  d7  00  0a 
0010:   05  00  00  00  01  08  01  08    01  08 [01] 08 [02] 08 [02] 08 
0020:  [02] 08  00  00  00  00 [08] 70   [00] 00  0a  00  00  00  00  00 
0030:  [02] 38  00  00  00  00  00  00    00  00  00  00 [00] 13  34  34 
0040:   34 [00][00] 03  00  01  01  00    04  00  00  00  00  00  00  00

As before, bytes 0x50 to 0xfe are only zeros, 0xff stays 21. Skipping those.

So of these differences...

0x01 is a status field

0x09 is a PLL field, I don't think that it should matter - we're not setting it in the TPS68470 clock driver.

0x1a is the settings for GPIO3; it's not in use here

0x1c is the settings for GPIO4, which is in use for this sensor. Windows is setting it as an output at 3V3 and 4mA drive strength. In Linux we're leaving it as the default LDO_IO / 1mA output

0x1e is the settings for GPIO5, which again is in use for this sensor. Windows is setting 0xc2, which means an 8mA output line.

0x20 is the settings for GPIO6 and is the same story as GPIO5

0x26 is the inputs and shows GPIO3 is reading as high. Not sure why, but as I say not in use for this sensor.

0x28 and 0x30 are LED controls

0x3c is the register for the VCM - the focus coil. We can enable that too, but one problem at a time I think

0x41 and 0x42 are the voltage settings for the VA and VD regulators, which aren't in use here so I'm not worried.

From all that then, the only thing I can see to try is the drive strength settings for the GPIO lines, which never seemed to matter before but perhaps does in this case...

Perhaps you could try setting those registers up before running qcam:

sudo i2ctransfer -f -y 2 w2@0x4d 0x1c 0x8a
sudo i2ctransfer -f -y 2 w2@0x4d 0x1e 0xc2
sudo i2ctransfer -f -y 2 w2@0x4d 0x20 0xc2

and see if that makes a difference? If so I'll test them on my Go2 and if they still work there, we can recode the driver to set those strengths.

martin9959 commented 2 years ago

sudo i2ctransfer -f -y 2 w2@0x4d 0x1c 0x8a sudo i2ctransfer -f -y 2 w2@0x4d 0x1e 0xc2 sudo i2ctransfer -f -y 2 w2@0x4d 0x20 0xc2

No, that didn't make any difference for me.

To check whether it actually applied, I did a i2cdump -f 2 0x4d:

djrscally commented 2 years ago

Let's try the PLL too; can you sudo i2ctransfer -f -y 2 w2@0x4d 0x09 0x13? Note that on Windows it's 0x11, but that seems to be a mistake, as it's making a setting that the datasheet calls out as "Reserved".

Failing that, can we dump the contents of the sensor's registers on Windows and Linux so we can compare them too?

akobel commented 2 years ago

Let's try the PLL too; can you sudo i2ctransfer -f -y 2 w2@0x4d 0x09 0x13? Note that on Windows it's 0x11, but that seems to be a mistake, as it's making a setting that the datasheet calls out as "Reserved".

Changes nothing for me, with or without the previous changes.

Failing that, can we dump the contents of the sensor's registers on Windows and Linux so we can compare them too?

Can do so on Linux, I will prepare that I think. On Windows, I2cTestTool fails to read from I2C4 where the camera is located, at least without further changes to the DSDT. Not surprising. I tried to blindly change I2C2 to I2C4 for the entry of the proxy device, but was greeted by a bluescreen once again; will try to get further...

djrscally commented 2 years ago

On Windows, I2cTestTool fails to read from I2C4 where the camera is located, at least without further changes to the DSDT. Not surprising. I tried to blindly change I2C2 to I2C4 for the entry of the proxy device, but was greeted by a bluescreen once again; will try to get further...

Ah yes; you'll have to edit the DSDT patch to speak to the sensor. Try to get both the sensor and the PMIC bus in there so you can talk to both in the same boot - it'll make your life easier