[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6477da61-4e7f-418c-b586-39c7b34066f8@ideasonboard.com>
Date: Tue, 10 Sep 2024 13:26:39 +0300
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Jacopo Mondi <jacopo.mondi@...asonboard.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>,
Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>, oe-kbuild-all@...ts.linux.dev,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, Naushir Patuck
<naush@...pberrypi.com>, Kieran Bingham <kieran.bingham@...asonboard.com>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE
Hi,
On 10/09/2024 13:11, Laurent Pinchart wrote:
> On Tue, Sep 10, 2024 at 12:56:38PM +0300, Tomi Valkeinen wrote:
>> On 10/09/2024 12:19, Jacopo Mondi wrote:
>>
>>> However, I think this current patch is correct (assuming the above
>>> reasoning on i2c sensor drivers is correct) and doesn't require
>>> CONFIG_PM, so I would be tempted to keep this version.
>>
>> I think the existence of this discussion alone proves my point that we
>> should only support PM-case, unless !PM is a requirement =).
>
> For me it proves there's a dire need to document the runtime PM API in a
> way that a human could understand :-)
That too, but it's a parallel track =).
>> But if you do want to keep !PM:
>>
>> Is there a reason why not mark the device as active with
>> pm_runtime_set_active() after calling pispbe_runtime_resume and before
>> accessing the device? That feels like the most logical way to use the
>> function, and it would be right regardless whether the core will enable
>> the parents before probe() or not.
>
> Does pm_runtime_set_active() resume the parent ?
I thought so, but I'm not sure anymore:
> if the device has a parent and the parent is not active, and the
> parent's power.ignore_children flag is unset, the device's status
> cannot be set to RPM_ACTIVE, so -EBUSY is returned in that case.
It does resume the suppliers, though.
So using pm_runtime_set_active() only works if you know that the parent
has been activated earlier? If there's such a guarantee for probe() and
remove(), does it then mean that you can only call
pm_runtime_set_active() in probe()/remove()...
Tomi
Powered by blists - more mailing lists