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
| ||
|
Date: Sat, 22 Jan 2011 12:08:00 +0800 From: Richard Zhao <linuxzsc@...il.com> To: Jassi Brar <jassisinghbrar@...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 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. Thanks Richard -- 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/
Powered by blists - more mailing lists