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.
