Re: [PATCH 4/7] dt/clock: Add handling for fixed clocks and a clock node setup iterator

[Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Shawn,

On 03/14/2012 02:59 AM, Shawn Guo wrote:
> On Tue, Mar 13, 2012 at 06:22:24PM -0500, Rob Herring wrote:
> ...
>> +/**
>> + * of_fixed_clk_setup() - Setup function for simple fixed rate clock
>> + */
>> +void __init of_fixed_clk_setup(struct device_node *node)
>> +{
>> +	struct clk *clk;
>> +	const char *clk_name = node->name;
>> +	u32 rate;
>> +
>> +	if (of_property_read_u32(node, "clock-frequency", &rate))
>> +		return;
>> +
>> +	of_property_read_string(node, "clock-output-names", &clk_name);
>> +
>> +	clk = clk_register_fixed_rate(NULL, clk_name, NULL, CLK_IS_ROOT, rate);
>> +	if (clk)
>> +		of_clk_add_provider(node, of_fixed_clk_get, clk);
>> +}
> 
> It seems my comment[1] did not get addressed in this post.
> 
> Regards,
> Shawn
> 
> [1] http://article.gmane.org/gmane.linux.drivers.devicetree/10589

So I started implementing support for multiple outputs, but ran into a
complication. If you have multiple clocks on a node, then you have to
have a clk_src_get function to translate the clock cell value to a
struct clk. This would also require allocating an array of struct clk's
to do the lookup. This is all doable, but I don't see the benefit over
having a single node per fixed clock. We're not likely to have *lots* of
fixed clocks. I think we should leave fixed-clock defined as a single
output. If you really see the benefit, you can add a new binding
"multiple-fixed-clocks" or something platform specific.

Rob