Em Wed, 29 Apr 2020 19:56:49 +0200 Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu: > On 29.04.20 01:13, Mauro Carvalho Chehab wrote: > > Em Tue, 28 Apr 2020 19:59:28 +0200 > > Patrik Gfeller<patrik.gfeller@xxxxxxxxx> escreveu: > > > >> On 27.04.20 23:50, Mauro Carvalho Chehab wrote: > >>> Em Mon, 27 Apr 2020 20:31:31 +0200 > >>> Patrik Gfeller<patrik.gfeller@xxxxxxxxx> escreveu: > >>>> On 26.04.20 18:50, Mauro Carvalho Chehab wrote: > >>>>> 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. > >>> Great! Could you please submit the exact patch you applied? I'll place > >>> it on my experimental tree: > >> Here is the patch for the change I made: > >> > >> diff --git > >> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > >> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > >> index eef7123a586f..081f9be6ec29 100644 > >> --- > >> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > >> +++ > >> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > >> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = { > >> {}, > >> }; > >> > >> +static struct gmin_cfg_var asus_vars[] = { > >> + {"OVTI2680:00_CsiPort", "0"}, > >> + {"OVTI2680:00_CsiLanes", "1"}, > >> + {"OVTI2680:00_CsiFmt", "15"}, > >> + {"OVTI2680:00_CsiBayer", "0"}, > >> + {"OVTI2680:00_CamClk", "1"}, > >> + {}, > >> +}; > >> + > >> static const struct dmi_system_id gmin_vars[] = { > >> { > >> .ident = "BYT-T FFD8", @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] > >> = { }, .driver_data = i8880_vars, }, + { > >> + .ident = "T101HA", > >> + .matches = { > >> + DMI_MATCH(DMI_BOARD_NAME, "T101HA"), > >> + }, > >> + .driver_data = asus_vars, > >> + }, > >> {} > >> }; > > Thanks for testing it. Just applied this patch upstream, together with a > > bunch of other cleanup patches. > > > >>>> 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 > >>> Did you apply this patch also? > >>> > >>> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940 > >>> > >>> I guess this would get rid of the two above warnings. > >>> > >> The patch was already applied when I did the test width the driver - the > >> warnings are also present with it. > > Ok. Yet, I found an issue on that patch. Just merged an improvement. > > > > Could you please test it again? > > Of course - I pulled the changes and recompiled the kernel. This is > what we see if I reboot the system: > > Apr 29 19:49:04 ASUS kernel: [ 8.821277] atomisp_ov2680: loading > out-of-tree module taints kernel. > Apr 29 19:49:04 ASUS kernel: [ 8.824016] atomisp_ov2680: module is > from the staging directory, the quality is unknown, you have been warned. > Apr 29 19:49:04 ASUS kernel: [ 8.945856] ov2680 i2c-OVTI2680:00: > gmin: initializing atomisp module subdev data.PMIC ID 1 > Apr 29 19:49:04 ASUS kernel: [ 8.949070] ov2680 i2c-OVTI2680:00: > supply V1P8SX not found, using dummy regulator > Apr 29 19:49:04 ASUS kernel: [ 8.952036] ov2680 i2c-OVTI2680:00: > supply V2P8SX not found, using dummy regulator The above don't sound right. I changed the logic to use regulator_get_optional(): gmin_subdevs[i].v1p8_reg = regulator_get_optional(dev, "V1P8SX"); gmin_subdevs[i].v2p8_reg = regulator_get_optional(dev, "V2P8SX"); With that, probing to "V1P8SX" and "V2P8SX" wouldn't print any messages. So, I suspect that either you're missing patches on your tree or you booted an older Kernel. The last patch on my tree is currently this one: commit 4c922df10252f4bd3f28187eba36056aa3c3c06e (experimental/atomisp) Author: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> Date: Wed Apr 29 11:50:52 2020 +0200 media: atomisp2: get rid of ia_css_sc_param.h version dependency > Apr 29 19:49:04 ASUS kernel: [ 8.954893] ov2680 i2c-OVTI2680:00: > supply V1P2A not found, using dummy regulator > Apr 29 19:49:04 ASUS kernel: [ 8.957849] ov2680 i2c-OVTI2680:00: > supply VPROG4B not found, using dummy regulator > Apr 29 19:49:04 ASUS kernel: [ 9.013717] ov2680 i2c-OVTI2680:00: > unable to set PMC rate 1 > Apr 29 19:49:04 ASUS kernel: [ 9.041777] ov2680 i2c-OVTI2680:00: > camera pdata: port: 0 lanes: 1 order: 00000002 > Apr 29 19:49:04 ASUS kernel: [ 9.048368] ov2680 i2c-OVTI2680:00: > sensor_revision id = 0x2680, rev= 0 > Apr 29 19:49:04 ASUS kernel: [ 9.051525] ov2680 i2c-OVTI2680:00: > register atomisp i2c module type 1 > > I've also added the following boot parameter to make sure we get all > debug messages from the module: dyndbg="module atomisp_ov2680 +pm" (as > explained by Laurent) > > I've checked the code of atomisp_ov2680 and there are some dev_dbg > calls, but either I did the configuration not correct, or we do not > reach those lines yet (or I looked at the wrong place; I checked dmesg > and kern.log). Maybe you built your Kernel without dyndbg support. The kernel needs this at .config: CONFIG_DYNAMIC_DEBUG=y This depends on those symbols: CONFIG_PRINTK [=y] && (CONFIG_DEBUG_FS [=y] || CONFIG_PROC_FS [=y]) > > >> But if I read the code correctly this is expected, as we try to get > >> those regulators in any case - only if we have an error on two of them > >> we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings > >> for those two regulators I assume this worked. > > No. It probably returned a valid "dummy" regulator. That's not what > > we want. > > > > There are still some things that could be missing for it to work > > properly with ISP2401. I'm trying to do some cleanups in order to > > be sure that everything needed for isp2401 will be there. > Just let me know if I shall try something. Sure. Thanks, Mauro
