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
