On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Em Sat, 2 May 2020 19:08:36 +0300 > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> escreveu: > > > I follow your attempts to enable that driver (I, myself, spent a lot > > of time to an attempt of getting this driver in a shape). However, I > > guess you started from a wrong side. Even with access to internal tree > > for Android firmware we didn't manage to find a proper one to whatever > > has been published in drivers/staging. So, to get it done, one should > > first to find a *working* Android for the certain device. Without that > > it will be a journey of wasted time and big disappointment. > > I found a driver that is probably working: > https://github.com/intel-aero/meta-intel-aero.git > > It is for an Intel Mobile Aero AUV platform. I suspect that his one > should likely work. So, have anybody tried to build and get a picture (raw is very good start for it) out of that sources and respective firmware? > > My achievements end with no getting IRQ from the driver (and I was > > experimenting on MRD-7 CRB). > > > > P.S. I also have some (semi-) debug patches I can share. > > Perhaps they will give some more ideas. > > Anything you can share will be welcomed. https://paste.debian.net/1144410/ No SoB from me (despite patches have them). > > Btw, based on this discussion I think that > > it can be power issues with sensors that possible affect IRQ > > generation inside SiliconHive vector processor. > > Yeah, the current issue sounds simple to solve, but I need to understand > how an ACPI-based device would be calling regulator_register(). Using > regulators with ACPI is new to me. I suspect that this should be done > by ./arch/x86/platform/intel-mid, with of course doesn't have the needed > bits for this board. Also, there is a dummy regulator driver for atomisp > based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could > be causing some issues too. > > The atomisp driver uses regulator_get() to turn on the sensors. It should use PMIC to get them. > In order for regulator_get() to work, regulator_dev_lookup() should > be capable of finding a regulator either via DT or via the > regulator_map_list. > > The contents of the regulator_map_list should visible on a configfs > node (/sys/kernel/debug/regulator/supply_map). > > Yet, those aren't visible (probably because the ACPI data was written > for Windows). So, the atomisp code should very likely call > regulator_register() for the regulators with the atomisp driver > need, in order to setup the regulator list. > > > > In IPU3 the dedicated > > PMIC is used for camera devices, and I have no idea of the design for > > old ones. > > I have here a Dell notebook with IPU3 on it (marketed for MS windows): > > ipu3_imgu: module is from the staging directory, the quality is unknown, you have been warned. > ipu3-imgu 0000:00:05.0: enabling device (0000 -> 0002) > ipu3-imgu 0000:00:05.0: device 0x1919 (rev: 0x1) > ipu3-imgu 0000:00:05.0: physical base address 0x00000000ec000000, 4194304 bytes > ipu3-imgu 0000:00:05.0: loaded firmware version irci_irci_ecr-master_20161208_0213_20170112_1500, 17 binaries, 1212984 bytes > ipu3-cio2 0000:00:14.3: enabling device (0000 -> 0002) > ipu3-cio2 0000:00:14.3: device 0x9d32 (rev: 0x1) > > This command: > > # cat /sys/kernel/debug/regulator/supply_map > > Returns nothing. So, it seems that the very same issue may also be > happening on IPU3-based laptops that won't have BIOSes designed to > work on Linux. Because you have to have an OpRegion in ACPI for the camera PMIC (see this driver https://elixir.bootlin.com/linux/latest/source/drivers/acpi/pmic/tps68470_pmic.c). AFAIU ISPv2 uses the generic Atom PMIC (see other drivers in the above mentioned folder). -- With Best Regards, Andy Shevchenko
