linux-kernel - Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdU6G35SP-P7bt6RJQk59CrGcKE2XM4N3o8Dv3qxZU7gxA@mail.gmail.com>
Date:	Fri, 21 Nov 2014 09:06:09 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Kevin Hilman <khilman@...nel.org>
Cc:	Grygorii Strashko <grygorii.strashko@...com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, ssantosh@...nel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains

Hi Kevin,

On Fri, Nov 21, 2014 at 2:30 AM, Kevin Hilman <khilman@...nel.org> wrote:
> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
>> On Thu, Nov 20, 2014 at 10:48 PM, Kevin Hilman <khilman@...nel.org> wrote:
>>>>> So what exactly are we talking about with "PM" clocks, and why are they
>>>>> "special" when it comes to PM domains?  IOW, why are the clocks to be
>>>>> managed during PM domain transitions for a given device any different
>>>>> than the clocks that need to be managed for a runtime suspend/resume (or
>>>>> system suspend/resume) sequence for the same device?
>>>>
>>>> (Speaking for my case, shmobile)
>>>>
>>>> They're not. The clocks to be managed during PM domain transitions are the
>>>> same as the clocks that need to be managed for a runtime suspend/resume
>>>> (or system suspend/resume) sequence.
>>>>
>>>> The special thing is that this is more a platform than a driver thing: the same
>>>> module may have a "PM/functional" clock (that is documented to enable/disable
>>>> the module) on one Soc, but noet on another.
>>>
>>> So why isn't the presence or absence of the clock described in the .dtsi
>>> for the SoC instead of being handled by special PM domain logic?
>>
>> It is. Cfr. the presence/absence of clocks for renesas,rcar-gpio nodes.
>
> Hmm, OK, Good.
>
> So now I'm confused about why the PM domain has to do anything special
> if the presence/absence of the clocks is already handled by the DT.

Just adding a clock property to a device node in DT doesn't enable the clock
automatically, nor make it runtime-managed automatically.
Compare this to e.g. pinctrl, where adding pinctrl properties to DT does enable
them automatically, without the driver for the device having to care about it.

Drivers interfacing external hardware typically do care about clocks, as they
have to program clock generators for the external hardware interface (e.g.
driving spi or i2c buses at specific frequencies).

Other random drivers don't care about clocks, so they don't handle them.
But as long as they make basic pm_runtime_{enable,get_sync,put}() calls,
the (optional) clocks (and hardware PM domains) will "work" fine, if handled
by the PM (clock) domain.

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/