Re: atomisp kernel driver(s)

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

 



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




[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