Messages in this thread | | | Date | Thu, 20 Nov 2014 22:54:07 +0100 | Subject | Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains | From | Geert Uytterhoeven <> |
| |
On Thu, Nov 20, 2014 at 10:48 PM, Kevin Hilman <khilman@kernel.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.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
| |