Hi, Shawn,
On Tue, Mar 8, 2011 at 3:07 PM, Shawn Guo <shawn....@freescale.com> wrote:
> On Tue, Mar 08, 2011 at 02:56:52PM +0800, Jason Hui wrote:
>> Hi, Shawn,
>>
>> On Tue, Mar 8, 2011 at 12:22 AM, Shawn Guo <shawn....@linaro.org> wrote:
>> > The patch is to add all gpt, uart related dt clock nodes for babbage.
>> > It sticks to the clock name used in clock-mx51-mx53.c, so that
>> > everything gets consistent to Reference Manual. For example, the
>> > numbering in clock name usually starts from 1, while 'reg' property
>> > numbering starts from 0 to easy clock binding.
>> >
>> > Besides the generally used clock bindings, the following properties
>> > are proposed in this patch.
>> >
>> > * clock-alias
>> > Like clock-outputs to reflect cl->dev_id, property clock-alias is
>> > defined to reflect cl->con_id.
>> >
>> > * clock-depend
>> > The mxc 'struct clk' has the member 'secondary' to refer to the clock
>> > that the 'clk' has dependency on. This 'secondary' clock needs to be
>> > on whenever the 'clk' is set to on. This clock-depend property is
>> > defined to reflect this 'secondary' clock.
>> >
>> > Signed-off-by: Shawn Guo <shawn....@linaro.org>
>> > ---
>> > arch/arm/boot/dts/babbage.dts | 162
>> > +++++++++++++++++++++++++++++++++++++++--
>> > 1 files changed, 156 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/babbage.dts b/arch/arm/boot/dts/babbage.dts
>> > index 46a3071..1774cec 100644
>> > --- a/arch/arm/boot/dts/babbage.dts
>> > +++ b/arch/arm/boot/dts/babbage.dts
>> > @@ -35,19 +35,169 @@
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> >
>> > - uart0_clk: uart@0 {
>> > + ckil_clk: clkil {
>> > + compatible = "fixed-clock";
>> > + #frequency-cells = <1>;
>> > + clock-outputs = "clil";
>> > + clock-frequency = <32768>;
>> > + };
>> > +
>> > + ckih_clk: ckih {
>> > + compatible = "fixed-clock";
>> > + #frequency-cells = <1>;
>> > + clock-outputs = "ckih";
>> > + clock-frequency = <22579200>;
>> > + };
>> > +
>> > + osc_clk: soc {
>> > + compatible = "fixed-clock";
>> > + #frequency-cells = <1>;
>> > + clock-outputs = "osc";
>> > + clock-frequency = <24000000>;
>> > + };
>> > +
>> > + pll1_main_clk: pll1_main {
>> > + compatible = "clock";
>> > + reg = <0>;
>> > + clock-outputs = "pll1_main";
>> > + clock-source = <&osc_clk>;
>> > + };
>> > +
>> > + pll1_sw_clk: pll_switch@0 {
>> > + compatible = "clock";
>> > + reg = <0>;
>> > + clock-outputs = "pll1_sw";
>> > + clock-source = <&pll1_main_clk>;
>> > + };
>> > +
>> > + pll2_sw_clk: pll_switch@1 {
>> > + compatible = "clock";
>> > + reg = <1>;
>> > + clock-outputs = "pll2_sw";
>> > + clock-source = <&osc_clk>;
>> > + };
>> >
>>
>> It seems that you mis-used the reg property, it need fixed globally.
>>
> I guessed it out from Grant's comment on your babbage.dts as below.
I don't understand clearly. Can we have the this usage, grant? reg=<1>
in this case, it will be
decoded as clk->id finally.
pll2_sw_clk: pll_switch@1 {
>> > + compatible = "clock";
>> > + reg = <1>;
>> > + clock-outputs = "pll2_sw";
>> > + clock-source = <&osc_clk>;
>> > + };
I just want to raise the problems. According to ePAPR,
2.3.6 reg
Property: reg
Value type: <prop-encoded-array> encoded as arbitrary number of
(address,length) pairs.
Description:
The reg property describes the address and length of a device’s memory
mapped register
space within its parent’s address space. The value is a
<prop-encoded-array>, composed of
an arbitrary number of pairs of address and length, <address, length>.
The number of <u32> cells required to specify the address and length
are bus-specific and are
specified by the #address-cells and #size-cells properties in the
parent of the device node. If
the parent node specifies a value of 0 for #size-cells, the length
field in the value of reg shall
be omitted.
Example:
Suppose a device within a system-on-a-chip had two blocks of
registers—a 32-byte block at
offset 0x3000 in the SOC and a 256-byte block at offset 0xFE00. The
reg property would be
encoded as follows (assuming #address-cells and #size-cells values of 1):
reg = <0x3000 0x20 0xFE00 0x100>;
> --- quote end ---
>
> --
> Regards,
> Shawn
>
>
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
