Re: [Ksummit-discuss] [TECH TOPIC] PM dependencies

[Ulf Hansson <ulf.hansson@linaro.org>]

On 23 May 2014 10:25, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 23, 2014 at 2:18 AM, Laurent Pinchart
> <laurent.pinchart@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.

This discussion, touches several unresolved runtime PM and system PM
issues in general. I think it's good we bring this all together,
because certainly there still some pieces missing in the puzzle.

As we have brought up pm_domains in the discussion, we might as well
add the "generic power domain" here.

Currently I am working on simplifying genpd. I am trying to iron out
what responsibilities actually should reside in it. Like what SOC
specific actions should it control, how should "pm_runtime_irq_safe"
devices be handled, etc.

Kind regards
Ulf Hansson

>
> Yours,
> Linus Walleij
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss