Re: [PATCH/RFC v6 0/7] PM / Domains: DT power-on/off and QoS device latencies

From: Ulf Hansson
Date: Wed May 13 2015 - 04:44:57 EST


On 27 April 2015 at 14:43, Geert Uytterhoeven <geert+renesas@xxxxxxxxx> wrote:
> Hi all,
>
> This patch series is an RFC to add (1) PM Domain power-on/off latencies
> and (2) QoS device latencies to DT.
>
> To provide a good quality of service, the PM subsystem suspends PM
> Domains and devices only if this doesn't break QoS constraints. While
> the PM subsystem performs measurements of the various latencies
> involved, and adapts automatically according to these measurements, it's
> still beneficial to provide initial values for these latencies.
> Currently these initial values, which are properties of the hardware,
> can only be specified from C code. This RFC adds DT support for
> specifying them.
>
> All of these patches have been sent before (change logs are available in
> the individual patches). I'm resending them upon request from Kevin
> Hilman, and synced them all to the same version number (v6).
>
> - Patch 1 adds DT bindings for PM Domain power-on/off latencies,
> - Patches 2 and 3 update the DT bindings and support code for the
> Renesas R-Mobile system controller, providing a sample
> implementation,
> - Patch 4 adds DT bindings for QoS device latencies,
> - Patches 5 and 6 implement retrieving the QoS device latencies in the
> genpd code,
> - Patch 7 updates the DT bindings for the Renesas R-Mobile system
> controller, adding an example.
>
> Compared to previous submissions, I've left out the (preliminary)
> patches adding the actual latency values to the .dtsi files, as they
> just used a single default value taken from the legacy code[*].
>
> In the mean time, support for PM Domains with multiple states has been
> proposed, cfr. "[RFC v5 0/8] genpd multiple states v5"
> (http://marc.info/?l=linux-pm&m=142989694214237&w=2).
> If this is accepted, I think we have to rethink how to specify PM Domain
> latencies (and be happy we didn't have the DT part cast in stone yet
> ;-), as they won't be limited to power-on/off latencies anymore.

In regard to the above, how about posting patch 4 and onwards separately?

Then we can come back to patch 1 -> 3, once the above patchset has
been thoroughly discussed.

>
> Perhaps we should switch to a mechanism similar to what's used for idle
> states (cfr. Documentation/devicetree/bindings/arm/idle-states.txt)?
> I.e. a single "idle-states" node, with subnodes for each state, being
> pointed to by phandles in the actual PM domain provider nodes.

Seems reasonable.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/