Hi Thierry,

On Fri, Sep 26, 2014 at 11:56 AM, Thierry Reding
[off-list ref] wrote:

quoted

quoted

An alternative would be to make the power-domain controller look up the
clock within the user's device tree node. That could be problematic,
because while the module clock is always the first clock in current
device trees, there aren't ordering guarantees, so we'd have to rely on
the clock name.

Or on some other way.
Do you have a separate hardware block that controls all (and only) the
module clocks?

No, the "clock and reset controller" controls all clocks (and resets) on
the SoC.

Sorry, with "only the module clocks" I meant "not clocks that are not module
clocks". Having a reset controller function in there is fine.

So it seems you do have a clock provider that provides module clocks,
and can mark them CLK_RUNTIME_PM.

quoted

On shmobile SoCs, all module clocks are controlled using the MSTP
(Module SToP) clocks.

In my old RFC series "[PATCH/RFC 0/4] of: Register clocks for Runtime PM
with PM core" (https://lkml.org/lkml/2014/4/24/1118) the MSTP clock driver
advertised using a new CLK_RUNTIME_PM flag that its clocks are module
clocks and thus suitable for runtime PM.

There were some issues with that series, but the general idea of letting a
clock driver advertise that all its clocks are module clocks could still be
useful. Then the power domain driver knows which clocks to manage.

That sounds interesting. Although it would still mean that we need a way
to associate a clock with the correct power domain. I guess the driver
could do that by iterating over all available clocks in the device's
clocks property and grab only those that are marked CLK_RUNTIME_PM.

Yes, that's the idea.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds