Re: atomisp kernel driver(s)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
Em Sun, 26 Apr 2020 13:38:19 +0200
Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu:

On 25.04.20 13:22, Mauro Carvalho Chehab wrote:
Hi Patrik,

Em Fri, 24 Apr 2020 12:07:30 +0200
Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu:
On 24.04.20 11:10, Patrik Gfeller wrote:
On 24.04.20 10:52, Patrik Gfeller wrote:
On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
Em Wed, 22 Apr 2020 19:56:56 +0200
Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu:
On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
Em Mon, 20 Apr 2020 20:27:25 +0200
Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu:
Me again ... sorry to ask such a basic question, but I can't get
your
modified source code. I get the following error:
       > git clone https://git.linuxtv.$ sudo make M=drivers/staging/media/atomisp/ modules_install
org/mchehab/experimental.git/
Cloning into 'experimental'...
warning: adding alternate object store:
https://git.linuxtv.org/git/linux.git/
warning: adding alternate object store:
https://git.linuxtv.org/git/media_tree.git/
warning: adding alternate object store:
https://git.linuxtv.org/git/linux.git/
error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
https://git.linuxtv.org/mchehab/experimental.git
Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
error: fetch failed.

Do I use the wrong command?
Better to use git:// url:

      git clone git://git.linuxtv.org/mchehab/experimental.git/
I was able to download and compile the code. I installed the kernel
and
tried to boot; unfortunately it hangs with the message "Loading
initial
ramdisk ..." - after I start the old kernel I check kern.log and
syslog
- but I do not see entries from the failed boot attempt. I'll read
into
the topic and try around. This will take some time ... so there
will be
a dealy, but it's not that I do not care or lacking interest, I just
first have to sort this out.
Well, try to build it first without the atomisp driver. This would
allow
you to see what's going on.
I was able to solve the problem I had with the ramdisk - I had to
strip the kernel modules, probably the ramdisk file was too big.

It is possible to boot with the atomisp driver, but I can not see the
camera yet - but maybe that's due to missing firmware, as there were
warnings when I installed the kernel that firmware files are missing.
I've added the missing firmware files and now I do not have warnings
when I create the ramdisk. Unfortunately it makes no difference - the
device does not work yet (dmesg looks the same).
The following I found in dmesg:

[    9.331011] kernel: atomisp_ov2680: module is from the staging
directory, the quality is unknown, you have been warned.
[    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
atomisp module subdev data.PMIC ID 1
[    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CamClk
[    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_ClkSrc
[    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CsiPort
[    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CsiLanes
[    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not
found, using dummy regulator
[    ...
[    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not
found, using dummy regulator
[    ...
[    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
found, using dummy regulator
[    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
found, using dummy regulator
[   ...'
[    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
lanes: 1 order: 00000002
[    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
0x2680, rev= 0
[    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
module type 1

The first signs of live :-) ... I'll try to find the firmware files
to see if it makes a difference.
Atomisp driver uses ACPI to detect the camera configuration. As you
can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:

	static const struct acpi_device_id ov2680_acpi_match[] = {
	        {"XXOV2680"},
	        {"OVTI2680"},
	        {},
	};
	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);

The regulator data is parsed at
drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:

          if (pmic_id == PMIC_REGULATOR) {
                  gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
                  gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
                  gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
                  gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");

                  /* Note: ideally we would initialize v[12]p8_on to the
                   * output of regulator_is_enabled(), but sadly that
                   * API is broken with the current drivers, returning
                   * "1" for a regulator that will then emit a
                   * "unbalanced disable" WARNing if we try to disable
                   * it.
                   */
          }

There are two things that could be the cause of this issue:

1) Some patch could have broken support for it.

Doing a:

	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c

will allow you to check the changes on this file.

2) Maybe recent BIOSes may have changed the names of the ACPI variables.

For instance, from the code, the driver should be seeking for those
variables for OV2680 (and several others that seem to be common among
multiple combinations):

	XXOV2680:00_CsiPort
	XXOV2680:00_CsiLanes
	XXOV2680:00_CamClk

It would be possible, that, on a modern BIOS, such vars were, for example,
renamed to 'XXOV2680_V2*'.
Thank you for the explanations. I've read the article about ACPI and
have now a basic idea what it is.

I tried to figure out if the ACPI variable names changed ... in the ACPI
dump the variables seem to match the code (if I understood correctly). I
tried to scan the firmware file to check if there's a hint regarding a
changed variable:

$ strings shisp_2401a0_v21.bin | grep 2680
$ strings shisp_2401a0_v21.bin | grep OV
No, you're looking at the wrong place. This should be at the system
board's BIOS, and not at something that the driver would load.

Just run (as root):

	# dmidecode

and check the name of your board. It should be similar to this:

	...
	System Information
	        Manufacturer: Intel Corporation
	        Product Name: (something)

The "(something)" is the board name. The atomisp driver will seek for
it. So, you need to patch the driver (using the example I gave) in
order for it to look at the right DMI_MATCH() table. Right now,
the driver knows only those:

	$ git grep DMI_MATCH drivers/staging/media/atomisp/
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),

Your asus board should likely use "ASUS", "_ASUS_" or something similar.
So, you should take a look on the patch I sent you and modify it to
match whatever name dmidecode printed.

See for example this patch:

	https://www.spinics.net/lists/linux-media/msg126880.html

If it finds the right table, it should end by calling gmin_subdev_add(),
with should use DTST table, also from the ACPI table inside the system's BIOS.
Now I understood :-). I've made the modifications as you explained and indeed the errors regarding

OVTI2680:00_CamClk
OVTI2680:00_ClkSrc
OVTI2680:00_CsiPort
OVTI2680:00_CsiLanes

are gone. Now we have the following in dmesg:

[    8.815960] kernel: mc: Linux media interface: v0.10
[    8.858458] kernel: videodev: Linux video capture interface: v2.00
[    8.876864] kernel: input: Intel HID events as /devices/pci0000:00/INT33D5:00/input/input16 [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40, base_baud = 2764800) is a 16550A [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels [    8.929818] kernel: atomisp_ov2680: module is from the staging directory, the quality is unknown, you have been warned. [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1 [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found, using dummy regulator [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found, using dummy regulator [    8.989977] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, using dummy regulator [    8.989998] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, using dummy regulator
[    9.033505] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.061511] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1 order: 00000002 [    9.065178] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0 [    9.071095] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1

Laurent explained me how to enable internal debug messages. I'll read more about this to understand how to use it and hope this will give a more detailed insight.


great to see some progress :-),

thanks and kind regards,

Patrik



Thanks,
Mauro



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux