linux-kernel - Re: Locking in the clk API

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: <AANLkTimW70Wq7hEhgz021ZEknGgsaTXs3nVPNig4F3Tj@mail.gmail.com>
Date:	Sat, 22 Jan 2011 14:30:51 +0900
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Richard Zhao <linuxzsc@...il.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ben Dooks <ben-linux@...ff.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh <linux-sh@...r.kernel.org>,
	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Locking in the clk API

On Sat, Jan 22, 2011 at 1:08 PM, Richard Zhao <linuxzsc@...il.com> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@...il.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@....linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console.  clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds.  We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep.  So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
> I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
> If its clock tree has many plls and device clock is not far away from plls and
> may sleep, we may use prepare/unprepare to do actually clock enable/disable.

I am not against clk_prepare/unprepare.
I rather suggest make it part of common clock API.
Please read my last two posts again.
--
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/