Hi Hans, On Tue, May 14, 2024 at 05:38:45PM +0200, Hans de Goede wrote: > Hi, > > On 5/14/24 5:21 PM, Andy Shevchenko wrote: > > On Tue, May 14, 2024 at 02:33:31PM +0000, Sakari Ailus wrote: > >> On Fri, May 10, 2024 at 06:43:31PM +0300, Dan Carpenter wrote: > > > > ... > > > >> Neither IPU3-CIO2 or IPU6 ISYS drivers should be of any functional use > >> without sensors. But the power states of the devices could be affected by > >> this: the drivers should power off these devices but without drivers they > >> maybe left powered on. I haven't made any measurements though. > > > > FWIW, Hans mentioned AtomISPv2 case with somewhat 7W consumption on top of > > the idling machine. That's why we have a stub driver in PDx86 exactly for > > the purpose of turning it off when not used. > > I'm not sure if I ever mentioned the 7W, that seems a lot. But in > the atomisp case the SoC will never reach S0i3 when the ISP is not > properly turned off. And in this case the ISP is special and just letting > PCI / ACPI put it in D3 is not enough it needs some special writes on > the IO-Sideband-Fabric to be turned off. > > I don't know if something similar applies to the IPU3 / IPU6, but > the bridge code is used by the atomisp code now too. So at a minimum > if an error gets returned when there are no sensors then this must be unique > enough that the atomisp code can check for it. Maybe -ENODEV ? -ENODEV is also used for a number of different conditions. Different error codes are also returned by functions the ipu bridge calls and they seem to be passed onwards as-is mostly. Maybe add an argument to ipu_bridge_init() to tell whether to fail if there are no sensors? -- Regards, Sakari Ailus