lkml.org 
[lkml]   [2011]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Locking in the clk API, part 2: clk_prepare/clk_unprepare
    From
    On Fri, Feb 4, 2011 at 8:18 PM, Russell King - ARM Linux
    <linux@arm.linux.org.uk> wrote:
    > On Fri, Feb 04, 2011 at 08:04:03PM +0900, Jassi Brar wrote:
    >> On Fri, Feb 4, 2011 at 7:48 PM, Russell King - ARM Linux
    >> <linux@arm.linux.org.uk> wrote:
    >>
    >> > int clk_enable(struct clk *clk)
    >> > {
    >> >        unsigned long flags;
    >> >        int ret = 0;
    >> >
    >> >        if (clk) {
    >> >                if (WARN_ON(!clk->prepare_count))
    >> >                        return -EINVAL;
    >> >
    >> >                spin_lock_irqsave(&clk->lock, flags);
    >> >                if (clk->enable_count++ == 0)
    >> >                        ret = clk->ops->enable(clk);
    >> >                spin_unlock_irqrestore(&clk->lock, flags);
    >> >        }
    >> >        return ret;
    >> > }
    >> >
    >> > is entirely sufficient to catch the case of a single-use clock not being
    >> > prepared before clk_enable() is called.
    >> >
    >> > We're after detecting drivers missing calls to clk_prepare(), we're not
    >> > after detecting concurrent calls to clk_prepare()/clk_unprepare().
    >>
    >> I hope you mean 'making sure the clock is prepared before it's enabled
    >> ' rather than
    >> 'catching a driver that doesn't do clk_prepare before clk_enable'.
    >> Because, the above implementation still doesn't catch a driver that
    >> doesn't call clk_prepare
    >> but simply uses a clock that happens to have been already prepare'd by
    >> some other
    >> driver or the platform.
    >
    > No, I mean what I said.
    Then, how does that function catch a driver that, say, doesn't do clk_prepare
    but share the clk with another already active driver?
    Because you said - "We're after detecting drivers missing calls to
    clk_prepare()"

    The point is, there is difference between detecting drivers that miss
    the clk_prepare
    and ensuring clk_prepare has been called before any call to
    clk_enable. And making
    that clear helps get rid of lots of confusion/misunderstanding. Uwe
    seems to have
    had similar confusions.


    > The only way to do what you're asking is to attach a list of identifiers
    > which have prepared a clock to the struct clk, where each identifier is
    > unique to each driver instance.
    I am not asking what you think.
    In my second last post, I am rather asking the other way around - that
    let us not worry
    about drivers missing the clk_prepare and not try to catch those by the new API.


    > I think that's going completely over the top, and adds needless complexity
    > to drivers, which now have to pass an instance specific cookie into every
    > clk API call.
    Exactly.
    All we need is to ensure clk_prepare has been called atleast once before
    any call to clk_enable.
    --
    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-02-04 12:53    [W:4.750 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site