lkml.org 
[lkml]   [2013]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] clk: allow reentrant calls into the clk framework
    On Wed, 27 Mar 2013, Mike Turquette wrote:

    > Reentrancy into the clock framework is necessary for clock operations
    > that result in nested calls to the clk api. A common example is a clock
    > that is prepared via an i2c transaction, such as a clock inside of a
    > discrete audio chip or a power management IC. The i2c subsystem itself
    > will use the clk api resulting in a deadlock:
    >
    > clk_prepare(audio_clk)
    > i2c_transfer(..)
    > clk_prepare(i2c_controller_clk)
    >
    > The ability to reenter the clock framework prevents this deadlock.
    >
    > Other use cases exist such as allowing .set_rate callbacks to call
    > clk_set_parent to achieve the best rate, or to save power in certain
    > configurations. Yet another example is performing pinctrl operations
    > from a clk_ops callback. Calls into the pinctrl subsystem may call
    > clk_{un}prepare on an unrelated clock. Allowing for nested calls to
    > reenter the clock framework enables both of these use cases.
    >
    > Reentrancy is implemented by two global pointers that track the owner
    > currently holding a global lock. One pointer tracks the owner during
    > sleepable, mutex-protected operations and the other one tracks the owner
    > during non-interruptible, spinlock-protected operations.
    >
    > When the clk framework is entered we try to hold the global lock. If it
    > is held we compare the current task id against the current owner; a

    s/task id/task/ We store a the task pointer in the owner variable.

    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>


    \
     
     \ /
      Last update: 2013-03-28 11:01    [W:9.134 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site