Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE

[Tomi Valkeinen]

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