Hi Thierry, On Fri, Sep 26, 2014 at 11:56 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: >> > 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. >> 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@xxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
