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

[Tomi Valkeinen]

On 10/09/2024 13:18, Jacopo Mondi wrote:
> Hi Tomi
>
> On Tue, Sep 10, 2024 at 12:56:38PM GMT, 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 =).
> >
> > 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
>
> cargo-cult ?
>
> > 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.
>
> Possibly more accurate, but there's no guarantee it's correct. The
> peripheral might have requirements on the clock or power rails
> enablement order and some might be managed by the parent. I know we're
> talking hypothesis but my point is that there's not correctness
> guarantee we can enforce unless the parent is powered up when the
> device probes ?
>
> Anyway, I'll defer the call to the group: either keep the patch as it
> is right now on the list, or go full runtime_pm. I understand there is
> no reason to care about !CONFIG_PM but somehow I feel "bad" in listing
> it as a dependency if the peripheral can actually work without it.
> Maybe I should just ignore that feeling ?

The runtime PM is just a software construct, so all peripherals can work 
without it.

I decided to ignore the feeling, very much based on this thread, and 
sent CFE v5 with it depending on PM.

 Tomi