On Fri, Sep 26, 2014 at 10:06:24AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
>
> On Fri, Sep 26, 2014 at 9:31 AM, Thierry Reding
> <thierry.reding@xxxxxxxxx> wrote:
> > On Thu, Sep 25, 2014 at 03:45:11PM -0700, Kevin Hilman wrote:
> >> Thierry Reding <thierry.reding@xxxxxxxxx> writes:
> >> > I just noticed these patches because they conflicted with some of the
> >> > local patches I had to add a very similar framework. One of the reasons
> >> > why I hadn't posted these publicly yet is because the platform where I
> >> > want to use this (Tegra) is somewhat quirky when it comes to power
> >> > domains.
> >> >
> >> > On Tegra these domains are called power gates and they currently have
> >> > their own API. We've been looking at migrating things over to some
> >> > generic framework for some time and PM domains do seem like a good fit.
> >> > However one of the quirks regarding these domains on Tegra is that a
> >> > fixed sequence exists that needs to be respected when enabling or
> >> > disabling a power partition. The exact sequence can be found in the
> >> > drivers/soc/tegra/pmc.c driver's tegra_powergate_sequence_power_up()
> >> > function. Essentially we need to call into the clock and reset drivers
> >> > at very specific moments during the operations that the PMC does.
> >> >
> >> > One solution to this would be to make the needed clocks and resets
> >> > available to the power domain driver via DT, but then we have the
> >> > problem that two drivers would be controlling the same resources. For
> >> > example drivers could still want to disable the clock for more fine-
> >> > grained power management.
> >>
> >> I think you're on the right path here. You can get rid of this conflict
> >> by removing the direct/manual clock management from the drivers, and
> >> using runtime PM instead: s/clk_enable/pm_runtime_get_sync/,
> >> s/clk_disable/pm_runtime_put_sync/. When using runtime PM, those calls
> >> trickle down through the power domain driver, which can manage the
> >> device clocks, as well as any additional clocks and resets needed for
> >> power gating.
> >
> > Okay. The DT part of it is going to be pretty nasty (as usual) because
> > we currently have the clocks and resets within the device's device tree
> > node (which I think is where they really belong).
> >
> > So one possibility would be to move the clocks and resets to the power
> > domain controller's node, like so:
> >
> > pmc@... {
> > power-domains {
> > ...
> >
> > sata@... {
> > clocks = <&tegra_car 124>;
> > resets = <&tegra_car 124>;
> > };
> > };
> > };
> >
> > 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.
> 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.
Thierry
Attachment:
pgpuytwQEoCFm.pgp
Description: PGP signature
