[Ksummit-discuss] [TECH TOPIC] PM dependencies

[Linus Walleij]

On Fri, May 23, 2014 at 2:18 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Tuesday 20 May 2014 09:57:14 Kevin Hilman wrote:

>> Alternatively, what would proably be even better would be that the
>> sensor driver has a reference to the actual device that provides its
>> input clock (possibly via a DT phandle?) so that the sensor driver can
>> simply do a pm_runtime_get() on the device providing the clock.
>
> Isn't it better for the sensor DT node to reference its input clock through
> the clocks property and enable/disable the clock on demand instead of
> explicitly calling pm_runtime_(get|put) on the clock provider device ?

This is tangent to another discussion we've had off and on whether
a device's resources (clocks, regulators, GPIOs, pins, pwms, D/As...)
should be handled explicitly by the driver or implicitly by e.g. a
PM domain.

It appears that currently we have bias such that for a discrete
component (such as some sensor) soldered on a board with
rails and stuff, these generally do explicit resource management
with clk_prepare_enable() and friends.

On the other hand there are some SoCs (OMAP especially but also
some Reneasa SH stuff IIRC!) that does implicit resource management
of devices on the SoC using PM domains.

This is a typical example of implicit resource management:
drivers/base/power/clock_ops.c

As PM domains are really not just for SoCs the broader question
of whether runtime resource management should be explicit using
handles in the drivers or implicit by referencing PM domain pops up.

The mixture of both that we have right now is a bit confusing,
admittedly.

Yours,
Linus Walleij