Re: cio2 ipu3 module to automatically connect sensors via swnodes

[Dan Scally <djrscally@gmail.com>]

Hi Sakari - thanks for the reply

On 08/09/2020 09:03, Sakari Ailus wrote:
> On ACPI systems regulators and clocks as well as GPIOs to some extent are
> controlled by AML code in the DSDT and SSDT. There are different ways this
> can be implemented though. It may be that the PMIC in this case is
> controlled entirely from the AML code without the need for a driver.
>
> This might be the case here. It should be possible to figure this out from
> the DSDT and SSDT tables.

Ah - that's interesting, thanks. I'll delve into the SSDT and DSDT 
tables and see if I can spot that happening. Presumably it is the case 
though, as like I say it seems to be working fine without any 
intervention by our sensor drivers.

> If you do not change how the regulators in the PMIC are controlled I'd
> think it's very, very unlikely you'd be able to fry the sensors.
Very reassuring!
> The GPIOs there I'd expect to be reset GPIOs, one for each sensor.
> Interesting that they are not handled by ACPI in this case. FWIW, the
> tps68470 driver is present also in the upstream kernel.
Yeah we found the tps68470 gpio driver (actually andriy pointed it out I 
think) - it seems that the pins _provided_ by that driver don't actually 
have any affect when toggled though, only the ones allocated to the PMIC 
in its _CRM seem to turn the sensors on/off when toggled (at least, 
switching those off is the only thing that stops the sensor from 
appearing in i2cdetect). The pins from the PMIC's _CRM seem to just be 
system GPIO pins, controllable with `gpioset gpiochip0` for example. For 
the most part we've been controlling them in the sensor drivers by 
evaluating the sensor's _DEP entry in ACPI to get to the PMIC's 
acpi_device. That does seem a little hackish though, and it's definitely 
pretty ugly.