Messages in this thread | | | Date | Sat, 22 Jan 2011 12:08:00 +0800 | From | Richard Zhao <> | 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@gmail.com> wrote: > > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux > > <linux@arm.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |