On Tue, Sep 08, 2020 at 10:40:09AM +0100, Dan Scally wrote: > 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. There are 3 GPIOs (per PMIC, AFAIR) that are controlled via AML. But I dunno what is going on in those methods and what the purpose is. > 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. -- With Best Regards, Andy Shevchenko
