Messages in this thread | | | Date | Wed, 10 Sep 2014 14:34:02 +0200 | Subject | Re: [RFC PATCH 0/3] PM / clock_ops: allow to specify custom pm_clk_notifier callback | From | Geert Uytterhoeven <> |
| |
Hi Grygorii,
On Tue, Sep 9, 2014 at 3:41 PM, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >>> Also, It updates Keystone 2 platform code to provide custom >>> callback which fills list of clocks for Device with all clocks assigned to this >>> Device in DT. >>> More over, It's safe for Keystone 2 to perform CLK PM domain initialization >>> at device's binding time instead of device's creation time. >>> >>> I've posted these patches because I need fully enable Runtime PM on Keystone 2 >>> where all HW modules are controlled using clocks only. That's why CLK PM domain >>> fits our needs perfectly. >> >> Heh, doesn't seem like a perfect fit to me ;) >> >>> Also, on Keystone 2 clocks are initialized early and >>> they are available at device creation time. The main problems from my side are: >>> - every time when support for new HW modules is added the ".con_ids" array >>> need to be checked and updated; >>> - restriction for clock's names in DT - to be named using only above con_ids >>> It's ugly. >>> >>> I hope, this approach to be accepted at least as temporal solution until >>> the generic solution is not found. >> >> Sorry if I missed it, but is there ongoing discussion of a more generic >> solution other than this one: > > Yep. :( But It's ongoing more than 2 months already and seems there is no > light at the end of tunnel. > >> >>> [1] Previously, same problem was discussed in, but no final solution was accepted: >>> "[PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core" >>> https://lkml.org/lkml/2014/4/24/1118 >> >> Personally, I still like Geert's approach better. >> > > Unfortunately, Geert is not going to continue working on it (as I know).
For the record, I had postponed working on it, as we had an interim solution for multiplatform shmobile being broken in mainline (drivers/sh/pm_runtime.c).
Currently I'm tackling "real" power domains. As this is incompatible with the above hack (you can attach only one power domain to a device, as Ulf had pointed out before --- Hm, why is the DT property called "power-domains" (plural) then?), I'll have to revisit anyway, and get back to it. Furthermore, not all shmobile SoCs have such fine-grained power domains as sh7372/sh73a0/r8a7740/r8a73a4, so we still need something better there.
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
| |