lkml.org 
[lkml]   [2011]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Locking in the clk API, part 2: clk_prepare/clk_unprepare
    On Fri, Feb 04, 2011 at 08:45:34PM +0800, Richard Zhao wrote:
    > > == Implementation ==
    > >
    > > Basically:
    > >
    > > struct clk {
    > > const struct clk_ops *ops
    > > int enable_count;
    > > spinlock_t enable_lock;
    > > int prepare_count;
    > > struct mutex prepare_lock;
    > > };
    > >
    > > int clk_enable(struct clk *clk)
    > > {
    > > int ret = 0;
    > >
    > > spin_lock(&clk->enable_lock);
    > > if (!clk->enable_count)
    > > ret = clk->ops->enable(clk);
    > >
    > > if (!ret)
    > > clk->enable_count++;
    > > spin_unlock(&clk->enable_lock);
    > >
    > > return ret;
    > > }
    > Why do we not call parent's clk_enable in this function? For flexible? How many
    > different cases is causing us to move the effert to platform clock driver?

    You may notice that struct clk above doesn't have a parent.


    \
     
     \ /
      Last update: 2011-02-04 14:23    [W:0.021 / U:60.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site