lkml.org 
[lkml]   [2011]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2011-01-22 05:11    [W:2.571 / U:0.440 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site