[lkml]   [2011]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 1/7] clk: Add a generic clock infrastructure
On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette <> wrote:
> From: Jeremy Kerr <>
>  struct clk_hw_ops {
>        int             (*prepare)(struct clk_hw *);
>        void            (*unprepare)(struct clk_hw *);
>        int             (*enable)(struct clk_hw *);
>        void            (*disable)(struct clk_hw *);
>        unsigned long   (*recalc_rate)(struct clk_hw *);

In implementing recalc for divider clocks, I started to wonder, "why
not just pass struct clk *clk into the clk_hw_ops func ptrs?".

recalc is an obvious example whereby we need access to parent->rate.
The code usually ends up looking something like:

unsigned long omap_recalc_rate(struct clk_hw *hw)
struct clk *parent;
struct clk_hw_omap *oclk;

parent = hw->clk->parent;
oclk = to_clk_omap(hw);

That's a bit of a song and dance to have to do in almost every op, and
often these ops will need access to stuff like clk->rate also. Is
there any opposition to just passing in struct clk? e.g:

unsigned long omap_recalc_rate(struct clk *clk)
struct clk *parent;
struct clk_hw_omap *oclk;

parent = clk->parent;
oclk = to_clk_omap(clk->hw);

It is a small nitpick, but it affects the API for everybody so best to
get it right now before folks start migrating over to it.


>        int             (*set_rate)(struct clk_hw *,
>                                        unsigned long, unsigned long *);
>        long            (*round_rate)(struct clk_hw *, unsigned long);
>        int             (*set_parent)(struct clk_hw *, struct clk *);
>        struct clk *    (*get_parent)(struct clk_hw *);
>  };
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-10-14 20:17    [W:0.278 / U:4.812 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site