Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Turquette, Mike
Date: Fri Oct 14 2011 - 14:14:40 EST
On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette <mturquette@xxxxxx> wrote:
> From: Jeremy Kerr <jeremy.kerr@xxxxxxxxxxxxx>
> 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.
Thanks,
Mike
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/