[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWAXDVtHN2bTW515eDqkob=nXm3YFd6SCjjYcmWy_OEyA@mail.gmail.com>
Date: Wed, 30 Apr 2014 23:47:14 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Kevin Hilman <khilman@...aro.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
Simon Horman <horms@...ge.net.au>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Ben Dooks <ben.dooks@...ethink.co.uk>,
Felipe Balbi <balbi@...com>,
Mike Turquette <mturquette@...aro.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux-sh list <linux-sh@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM
with the PM core
Hi Kevin,
On Sat, Apr 26, 2014 at 1:44 AM, Kevin Hilman <khilman@...aro.org> wrote:
> Geert Uytterhoeven <geert+renesas@...der.be> writes:
>> When adding a device from DT, check if its clocks are suitable for Runtime
>> PM, and register them with the PM core.
>> If Runtime PM is disabled, just enable the clock.
>>
>> This allows the PM core to automatically manage gate clocks of devices for
>> Runtime PM.
>
> ...unless the device is already in an existing pm_domain, right?
At this point in the kernel boot process, the device cannot be in a
pm_domain yet.
> I like this approach, and it extends nicely what we already do on
> platforms using drivers/base/power/clock_ops.c into DT land.
>
> My only concern is how this will interact if it's used along with
> devices that have existing pm_domains. I don't have any specific
> concerns (yet, because it's Friday, and my brain is turing off), but it
> just made me wonder if this will be potentially confusing.
Adding devices to pm_domains is done later, so it can be overridden.
> Also...
>
> [...]
>
>> +static int of_clk_register(struct device *dev, struct clk *clk)
>> +{
>> + int error;
>> +
>> + if (!dev->pm_domain) {
>> + error = pm_clk_create(dev);
>> + if (error)
>> + return error;
>> +
>> + dev->pm_domain = &of_clk_pm_domain;
>> + }
>> +
>> + dev_dbg(dev, "Setting up clock for runtime PM management\n");
>> + return pm_clk_add_clk(dev, clk);
>
> I would've expected these 2 lines to be inside the pm_domain check.
>
> What's the reason for doing the pm_clk_add() when the pm_domain isn't
> going to be used? I suppose it's harmless, but it's a bit confusing.
Sorry, the !dev->pm_domain check does deserve a comment explaining this.
If there are multiple clocks suitable for pm_runtime, the pm_clk_create(dev)
should be done only once.
Currently e.g. davinci registers 3 clocks with pm_clk ("fck",
"master", and "slave").
Omap has 2 ("fck" and "ick").
BTW, keystone doesn't seem to set pm_clk_notifier_block.con_ids. From a quick
look, this will crash with a NULL-pointer dereference in pm_clk_notify()? Or am
I missing something here?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists