linux-kernel - Re: [PATCH v5 4/4] clk: basic clock hardware types

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: <CAJOA=zNWN6L+-YEkNKoQnjnrrswNpCBmtnhKBm04HekWP46i5w@mail.gmail.com>
Date:	Sun, 4 Mar 2012 16:30:08 -0800
From:	"Turquette, Mike" <mturquette@...com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Russell King <linux@....linux.org.uk>, patches@...aro.org,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnd Bergman <arnd.bergmann@...aro.org>,
	Paul Walmsley <paul@...an.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Jamie Iles <jamie@...ieiles.com>,
	Richard Zhao <richard.zhao@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Deepak Saxena <dsaxena@...aro.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH v5 4/4] clk: basic clock hardware types

On Sun, Mar 4, 2012 at 9:42 AM, Andrew Lunn <andrew@...n.ch> wrote:
> On Sat, Mar 03, 2012 at 12:29:01AM -0800, Mike Turquette wrote:
>> Many platforms support simple gateable clocks, fixed-rate clocks,
>> adjustable divider clocks and multi-parent multiplexer clocks.
>>
>> This patch introduces basic clock types for the above-mentioned hardware
>> which share some common characteristics.
>
> Hi Mike
>
> These basic clocks don't allow the use of prepare/unprepare, from the
> side of the clock provider. I think i need this.

This is an interesting point and might help us nail down exactly what
we expect from clk_prepare/clk_unprepare.

>
> The Orion Kirkwood SoC has clock gating for most of its on chip
> peripherals, which the other older Orion devices don't have. The SATA
> and PCIe also allows the PHY to be shut down, again which older Orion
> devices don't have. The current code links the clock and the PHY
> together, shutting both down are the same time. So i would like to
> perform the PHY shutdown in the unprepare() function of the clk
> driver.

Do you feel it is The Right Thing to enable/disable the phy from
clk_prepare/clk_unprepare?  I had always imagined that clk_prepare's
purpose was always specific to clock-related activities; for example
maybe turn on a parent PLL that takes a long time to lock, as well as
for the sleepable cases such as clocks over i2c, etc.

However, I know that some others have already started performing
voltage scaling from clk_prepare, so clearly the api is not strict in
it's purpose.

Have you investigated powering up/down the phy from a different layer
such pm_runtime?  That might create a better layer of separation
between other resources needed by an IP block and the clock framework.
 For instance on OMAP we use pm_runtime_get(_sync) to call clk_prepare
& clk_enable and handle other power management-related resources.
Perhaps using the clock framework to power up/down your IP block is
not the right tool for the job.

>
> Is allowing to pass prepare/unprepare functions to basic clocks
> something you want to support? If i prepare a patch would you consider
> it?

My original instinct was "no".  The simple gate clock was always
supposed to be "simple" and if you need more than it provides then it
might be best for your platform to implement a specific clock type.
Especially since the purpose of clk_prepare is still up in the air.

But I'll keep an open mind and hopefully others can chime in.  Please
let me know what you think about my pm_runtime suggestion.  I've Cc'd
Rafael just in case he has something to add here from a design
perspective.

Regards,
Mike

>
>        Thanks
>                Andrew
--
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/