关于clk_enable()的奇怪问题

fjaygrfjaygr

关于COMMON_CLOCK子系统的，下面的代码大都在 drivers/clk/clk.c中。

static struct task_struct *enable_owner;

int clk_enable(struct clk *clk)
{
        unsigned long flags;
        int ret;
        flags = clk_enable_lock();
        ret = __clk_enable(clk);
        clk_enable_unlock(flags);
        return ret;
}

static unsigned long clk_enable_lock(void)
{
        unsigned long flags;
        if (!spin_trylock_irqsave(&enable_lock, flags)) {
                if (enable_owner == current) {
                        enable_refcnt++;
                        return flags;
                        /*enable_lock、enable_owner是全局唯一的，current是类似per-cpu的。如果当前获取锁没有成功，说明了已经有一个执行体[线程或中断]之前获取了锁。如果已经有一个执行体[线程或中断]之前获取了锁，那么执行这段代码的当前执行体，就不可能和 占有 锁的那个执行体 在一个 CPU上运行，因为spin_trylock_irqsave不仅关抢占 还关 本地中断！是这样吗？  在 当前执行体 所处的CPU中就 应该不可能 出现enable_owner == current 的情况啊！？？ 因为一个线程不可能同时在两个CPU上运行啊？
*/

                }
               
                spin_lock_irqsave(&enable_lock, flags);
        }
        WARN_ON_ONCE(enable_owner != NULL);
        WARN_ON_ONCE(enable_refcnt != 0);
        enable_owner = current;
        enable_refcnt = 1;
        return flags;
}
static void clk_enable_unlock(unsigned long flags)
{
        WARN_ON_ONCE(enable_owner != current);
        WARN_ON_ONCE(enable_refcnt == 0);

        if (--enable_refcnt)
                return;
        enable_owner = NULL;
        spin_unlock_irqrestore(&enable_lock, flags);
}


clk_enable_lock(void)函数中，我觉得 执行路径 永远不会到  上面的文字说明部分。。。。是不是这样，我想了一个小时，其实还是有点晕，，，

humjb_1983

个人理解~
其它流程是否也可能获取这把锁？

asuka2001

回复 1# fjaygrfjaygr

git blame drivers/clk/clk.c

查下 commit 533ddeb1，解释的非常清楚！clk: allow reentrant calls into the clk framework!

humjb_1983

asuka2001 发表于 2014-06-17 15:33
回复 1# fjaygrfjaygr

git blame drivers/clk/clk.c

看似
spin_lock_irqsave(&enable_lock, flags);
关中断之后，就没有重入的可能了吧？

asuka2001

回复 4# humjb_1983

commit 533ddeb1e86f506129ee388a6cc13796dcf31311
Author: Mike Turquette <mturquette@linaro.org>
Date:   Thu Mar 28 13:59:02 2013 -0700

    clk: allow reentrant calls into the clk framework

    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 against the current owner; a match
    implies a nested call and we reenter.  If the values do not match then
    we block on the lock until it is released.

    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
    Cc: David Brown <davidb@codeaurora.org>
    Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

humjb_1983

asuka2001 发表于 2014-06-17 20:56
回复 4# humjb_1983

commit 533ddeb1e86f506129ee388a6cc13796dcf31311

呵呵，感谢，看起来保证framework的可重入，并不限于这一个函数~~