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?
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.
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 linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
