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
