Locking in the clk API

[Richard Zhao]

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 at gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux at 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