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. Thanks, Mauro
