linux-kernel - Re: [RFC PATCH 0/3] PM / clock_ops: allow to specify custom pm_clk

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]

Date:	Wed, 10 Sep 2014 14:34:02 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	Kevin Hilman <khilman@...aro.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-sh list <linux-sh@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] PM / clock_ops: allow to specify custom
 pm_clk_notifier callback

Hi Grygorii,

On Tue, Sep 9, 2014 at 3:41 PM, Grygorii Strashko
<grygorii.strashko@...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@...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/