Re: cio2 ipu3 module to automatically connect sensors via swnodes

From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Dan Scally <djrscally@gmail.com>
Cc: linux-media@vger.kernel.org, heikki.krogerus@linux.intel.com,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	kitakar@gmail.com, jorhand@linux.microsoft.com,
	andriy.shevchenko@linux.intel.com
Subject: Re: cio2 ipu3 module to automatically connect sensors via swnodes
Date: Wed, 9 Sep 2020 12:29:57 +0300	[thread overview]
Message-ID: <20200909092957.GB6566@paasikivi.fi.intel.com> (raw)
In-Reply-To: <5614b37e-c263-c9e7-fe5b-a523401c58e2@gmail.com>

Hi Dan,

On Tue, Sep 08, 2020 at 10:40:09AM +0100, Dan Scally wrote:
> 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.

In the end there should be no driver changes required to the sensor or
other peripheral drivers. But I guess at this point it'd be important to
get things in working order, before they can be cleaned up.

Would you be able to pass me the ACPI tables from this machine btw.?

-- 
Kind regards,

Sakari Ailus