Received-SPF: pass (google.com: domain of linux-kernel+bounces-178870-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <d2d71851-691f-45cf-9d52-1d16ede09b2b@redhat.com>
Date: Tue, 14 May 2024 17:38:45 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] media: ipu-bridge: fix error code in ipu_bridge_init()
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
 Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
 Bingbu Cao <bingbu.cao@intel.com>, Mauro Carvalho Chehab
 <mchehab@kernel.org>, Daniel Scally <dan.scally@ideasonboard.com>,
 linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
 kernel-janitors@vger.kernel.org
References: <f468c4ac-0629-41b5-b5d1-e26f70e44800@moroto.mountain>
 <ZkN2Ow6hASmKvHlz@kekkonen.localdomain> <ZkOBaUW1uLw6ildS@smile.fi.intel.com>
Content-Language: en-US, nl
From: Hans de Goede <hdegoede@redhat.com>
In-Reply-To: <ZkOBaUW1uLw6ildS@smile.fi.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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 ?

Regards,

Hans