Re: [PATCH 3/3] ARM: dts: bcm281xx: define real clocks

[Alex Elder]

On 12/04/2013 05:19 AM, Mark Rutland wrote:
> On Wed, Dec 04, 2013 at 03:57:07AM +0000, Alex Elder wrote:
>> Replace the "fake" clocks defined in the "bcm11351.dtsi" device tree
>> file with real definitions backed by the new BCM281xx clock driver..
>>
>> Signed-off-by: Alex Elder <elder@xxxxxxxxxx>
>> Reviewed-by: Matt Porter <matt.porter@xxxxxxxxxx>
>> Reviewed-by: Tim Kryger <tim.kryger@xxxxxxxxxx>
>> ---
>>  arch/arm/boot/dts/bcm11351.dtsi |  222
>> ++++++++++++++++++++++++++++-----------
>>  1 file changed, 161 insertions(+), 61 deletions(-)
> 
> [...]
> 
>> +		/*
>> +		    * This is a place-holder clock for peripheral
>> +		    * clocks that set their parent clock to an
>> +		    * out-of-range value to explicitly select
>> +		    * "no clock" as a parent.
>> +		    */
>> +		not_selected_clk: not_selected {
>>  			#clock-cells = <0>;
>> -		};
> 
> Huh? This doesn't seem to be used at all in this series. Why is this
> here?

This has been the source of confusion before.

You're right, it's not used in the current patch.  And
because of this, I'll delete it, and add it back once
we have a clock supported that requires it.

But while we're on the subject, here's what it's for.

Each clock has a defined set of parent clocks, and
each has a small integer value that represents it in
a register that controls their selection.  In some
cases the reset value of that register field is a
(specific) value that has no defined clock associated
with it.

Here's an example.  There's a clock "hub_clk_ssp3_audio",
which has three parent clocks:  "ref_crystal" (selector
value 0),  "ref_312m" (selector value 1), and "cx40"
(selector value 2).  But on reset, the value in that
selector field is 3.

This clock is used to represent that "none selected" value.

> Thanks,
> Mark.
> 

Thank you.  I really appreciate the reviews Mark.

					-Alex
--
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/