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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 25 Nov 2014 13:08:57 +0200
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Arnd Bergmann <arnd@...db.de>,
	Mike Turquette <mturquette@...aro.org>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Kevin Hilman <khilman@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Rob Herring" <robh+dt@...nel.org>, <ssantosh@...nel.org>
Subject: Re: [PATCH v4 1/2] ARM: keystone: pm: switch to use generic pm domains

Hi Arnd,

On 11/25/2014 12:33 PM, Arnd Bergmann wrote:
> On Monday 24 November 2014 22:44:06 Mike Turquette wrote:
>> Quoting Arnd Bergmann (2014-11-24 02:50:28)
>>>
>>> Could the driver maybe identify the clocks that it wants to manage itself
>>> to the pm-domain code? If it's safe for a device to have the clock turned
>>> on at the default rate before loading the driver, any device that is connected
>>> to the simple clk-pm-domain code could have all its clocks start out as
>>> owned by the pm-domain, but then claim the clocks it needs to reprogram for
>>> itself and take them out of the pmdomain.
>>
>> I was thinking along similar lines. The functional versus optional stuff
>> is really a property of the consuming device, not the clock signal
>> itself.
>>
>> Instead of adding a new property to the clock binding (e.g. fck-clocks
>> or optional-clocks), could we simply wrap those lists of clocks in
>> another node? E.g:
>>
>> mandatory-clocks {
>>         clocks = <&papllclk>, <&clkcpgmac>;
>>         clock-names = "clk_pa", "clk_cpgmac";
>> }
>>
>> clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;

optional-clocks { ?
>>         clocks = <&clkcpgmac>;         

	   clocks = <&chipclk12>; ?

>>         clock-names = "cpsw_cpts_rft_clk";
>> }
>>
>> I'm showing my DT ignorance on this one. I haven't really thought
>> through how these sub-nodes would work with of_clk_* handlers in
>> drivers/clk/clkdev.c.

As I remember, there was nack for sub-nodes approach from Olof :(
"[RFC 0/2] pwrseq: Add subsystem for power sequences"
http://thread.gmane.org/gmane.linux.power-management.general/46635

> 
> I'm not sure I even understand what you intended the example to look
> like, it does't parse ;-)
> 
> My point above was completely different, the suggestion I made was
> to not classify the clocks in DT at all, but to leave it all in
> the client driver.

I slept with this idea :) From one side it sounds good. Pls, Correct me if I'm wrong:
- there still will be "simple-pmdomain" and all devices will be attached to it by
   default (or as specified in DT power-domains = <&simple_pmdomain>;);
- drivers will use smth. like pm_clk_remove() to remove optional clocks from pm_clk;

>From another side:
- drivers will get dependency from pm_clk;
- HW limitations can't be taken into account - it's possible that some clocks should
  not be enabled until it's allowed. And only driver know when it's allowed.
  Otherwise, HW state may become unspecified or wrong output can be generated.

regards,
-grygorii
--
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/