[PATCH] powerpc: Add FSL CPM2 device tree node documentation

[PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

Updated the documentation to include the initial description of the CPM2
device that are used on PQII and PQIII families. Only initial sub-devices
described so far, but that should be sufficient to move the respective
boards to powerpc, with a reasonable minimum supporteddevice set.

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---

 Documentation/powerpc/booting-without-of.txt |  149 ++++++++++++++++++++++++++
 1 files changed, 149 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee551c6..d44980c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1436,6 +1436,155 @@ platforms are moved over to use the flat
                descriptor-types-mask = <073f1127>;
        };
 
+   h) Freescale SOC communication processor module (CPM)
+	This represents cpm module that is installed on PQ (PowerQUICC)
+	series,1-st, 2-nd and 3-rd generation. Basically, is is a bus of devices,
+	both those that are inalienable cpm parts (BRGs, etc.), and those that could act
+	more or less as a complete entity (FCC, SCC). All af them should be
+	siblings on the "root" cpm node, using the common properties from
+	there. The description below applies to the CPM2 (2-nd rev. found on
+	PQ2 and PQ3) but I beleive could be extended to the PQ CPM1 as well
+	later.
+
+	1) Root cpm2 device
+	  Required properties:
+
+	    - device_type : Should be "cpm"
+	    - model : Model of the device.  Should be "CPM1" or "CPM2"
+    	    - reg : Offset and length of the register set for the device
+	    - command-proc : Offset to the CPM command processor
+
+	2) Baud-rate generators (BRG)
+          The CPM contains eight independent, identical baud-rate generators (BRGs) that can be
+          used with the FCCs, SCCs, and SMCs. The clocks produced by the BRGs are sent to the
+          bank-of-clocks selection logic, where they can be routed to the controllers. In addition, the
+          output of a BRG can be routed to a pin to be used externally.
+
+	  Required properties:
+
+	   - device_type : Should be "brg"
+	   - model : should be "BRGx", x relative to the BRG number (usually
+			   from 1 to 8)
+	   - reg : Offset to the configuration register (from cpm reg)
+	   - linux,phandle : phandle for this node; likely referenced by the CPM
+		   devices (SCC, FCC, SMC, etc.)
+
+	  Recommended properties:
+
+	   - clock-divider : 12-bit integer (internal counter that is decremented at the DIV16 output rate)
+	   - div16 : Either <0> or <1> the 1/16 prescalar before reaching the clock divider
+	   - ext-clock : Either <0> or phandle of the external clock source
+
+	3) CPM multiplexor
+	  CPM supports special NMSI mode of operation for its devices. In short,
+	  each serial device could be connected to the set of dedicated pins,
+	  and this pseudo-device controls such behavior. They are different for
+	  each device set, and could be recognised using "compatible" field.
+
+	  Required properties:
+
+	  - device_type : Should be "cpmux"
+	  - reg : offset to the configuration register
+	  - compatible : "fcc", "scc", or "smc"
+
+	4) SCCs (Serial Communications Controllers)
+
+	  Required properties:
+
+	  - device_type : "serial" or "network"
+	  - model : "SCCx", x is typically a small number depending on the
+	  devices amount
+	  - compatible : Either "fs_enet" or "cpm_uart"
+	  - reg : offset to the register set and its length
+	  - reg-pram : offset to the device parameter RAM
+	  - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values define
+	  multiplexor clock routing and clock mask respectively
+	  - interrupts : <a b> where a is the interrupt number and b is a
+		field that represents an encoding of the sense and level
+		information for the interrupt.  This should be encoded based on
+		the information in section 2) depending on the type of interrupt
+		controller you have.
+	  - interrupt-parent : the phandle for the interrupt controller that
+		services interrupts for this device.
+
+	5) FCCs (Fast Communications Controllers)
+
+	  Required properties:
+
+	  - device_type : should be "network"
+	  - model : "FCCx", x is typically a small number depending on the
+	  devices amount
+	  - compatible : should be "fs_enet"
+	  - address : List of bytes representing the ethernet address of
+		this controller
+	  - reg : offset to the register set and its length
+	  - reg-pram : offset to the device parameter RAM
+	  - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values define
+	  multiplexor clock routing and clock mask respectively
+	  - interrupts : <a b> where a is the interrupt number and b is a
+		field that represents an encoding of the sense and level
+		information for the interrupt.  This should be encoded based on
+		the information in section 2) depending on the type of interrupt
+		controller you have.
+	  - interrupt-parent : the phandle for the interrupt controller that
+		services interrupts for this device.
+	  - phy-handle : The phandle for the PHY connected to this ethernet
+		controller.
+   Example:
+ 	/*8272ADS*/
+	cpm@f0000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		#interrupt-cells = <2>;
+		device_type = "cpm";
+		model = "CPM2";
+		ranges = <0 f0000000 00100000>;
+		reg = <f0000000 000101a8>;
+		command-proc = <119c0>
+
+		brg@119f0 {
+			device_type = "brg";
+			model = "BRG1";
+			reg = <119f0>;
+			linux,phandle = <775>;
+		};
+
+		cpmux@11b04 {
+			device_type = "cpmux";
+			compatible = "fcc";
+			reg = <11b04>;
+		};
+
+		cpmux@11b08 {
+			device_type = "cpmux";
+			compatible = "scc";
+			reg = <11b08>;
+		};
+
+		scc@11a20 {
+			device_type = "serial";
+			compatible = "cpm_uart";
+			model = "SCC1";
+			reg = <11a20 100>;
+			reg_pram = <8000 ff>;
+			clock_setup = <0x00ffffff 0>;
+			interrupts = <28 3>;
+			interrupt-parent = <700>;
+			brg_phandle = <775>;
+		};
+
+		fcc@11300 {
+			device_type = "network";
+			compatible = "fs_enet";
+			model = "FCC1";
+			reg = <11300 1f>;
+			reg_pram = <8400 ff>;
+			address = [00 00 00 00 00 00];
+			interrupts = <20 3>;
+			interrupt-parent = <700>;
+			phy_handle = <2452000>;
+		};
+	};
 
    More devices will be defined as this spec matures.
 

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Kumar Gala]

Paul,

Please dont accept this patch right away.  I think we should let this  
have some discussion on the list before it goes in.  I believe this  
is the first time any of the 8xx maintainers have seen this (Dan or  
Marcelo) so getting their feedback would be good.

Nothing against your patch Vitaly :)

- kumar

On Mar 28, 2006, at 10:14 AM, Vitaly Bordug wrote:

>
> Updated the documentation to include the initial description of the  
> CPM2
> device that are used on PQII and PQIII families. Only initial sub- 
> devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
>
>  Documentation/powerpc/booting-without-of.txt |  149 +++++++++++++++ 
> +++++++++++
>  1 files changed, 149 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/ 
> Documentation/powerpc/booting-without-of.txt
> index ee551c6..d44980c 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1436,6 +1436,155 @@ platforms are moved over to use the flat
>                 descriptor-types-mask = <073f1127>;
>         };
>
> +   h) Freescale SOC communication processor module (CPM)
> +	This represents cpm module that is installed on PQ (PowerQUICC)
> +	series,1-st, 2-nd and 3-rd generation. Basically, is is a bus of  
> devices,
> +	both those that are inalienable cpm parts (BRGs, etc.), and those  
> that could act
> +	more or less as a complete entity (FCC, SCC). All af them should be
> +	siblings on the "root" cpm node, using the common properties from
> +	there. The description below applies to the CPM2 (2-nd rev. found on
> +	PQ2 and PQ3) but I beleive could be extended to the PQ CPM1 as well
> +	later.
> +
> +	1) Root cpm2 device
> +	  Required properties:
> +
> +	    - device_type : Should be "cpm"
> +	    - model : Model of the device.  Should be "CPM1" or "CPM2"
> +    	    - reg : Offset and length of the register set for the device
> +	    - command-proc : Offset to the CPM command processor
> +
> +	2) Baud-rate generators (BRG)
> +          The CPM contains eight independent, identical baud-rate  
> generators (BRGs) that can be
> +          used with the FCCs, SCCs, and SMCs. The clocks produced  
> by the BRGs are sent to the
> +          bank-of-clocks selection logic, where they can be routed  
> to the controllers. In addition, the
> +          output of a BRG can be routed to a pin to be used  
> externally.
> +
> +	  Required properties:
> +
> +	   - device_type : Should be "brg"
> +	   - model : should be "BRGx", x relative to the BRG number (usually
> +			   from 1 to 8)
> +	   - reg : Offset to the configuration register (from cpm reg)
> +	   - linux,phandle : phandle for this node; likely referenced by  
> the CPM
> +		   devices (SCC, FCC, SMC, etc.)
> +
> +	  Recommended properties:
> +
> +	   - clock-divider : 12-bit integer (internal counter that is  
> decremented at the DIV16 output rate)
> +	   - div16 : Either <0> or <1> the 1/16 prescalar before reaching  
> the clock divider
> +	   - ext-clock : Either <0> or phandle of the external clock source
> +
> +	3) CPM multiplexor
> +	  CPM supports special NMSI mode of operation for its devices. In  
> short,
> +	  each serial device could be connected to the set of dedicated  
> pins,
> +	  and this pseudo-device controls such behavior. They are  
> different for
> +	  each device set, and could be recognised using "compatible" field.
> +
> +	  Required properties:
> +
> +	  - device_type : Should be "cpmux"
> +	  - reg : offset to the configuration register
> +	  - compatible : "fcc", "scc", or "smc"
> +
> +	4) SCCs (Serial Communications Controllers)
> +
> +	  Required properties:
> +
> +	  - device_type : "serial" or "network"
> +	  - model : "SCCx", x is typically a small number depending on the
> +	  devices amount
> +	  - compatible : Either "fs_enet" or "cpm_uart"
> +	  - reg : offset to the register set and its length
> +	  - reg-pram : offset to the device parameter RAM
> +	  - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values  
> define
> +	  multiplexor clock routing and clock mask respectively
> +	  - interrupts : <a b> where a is the interrupt number and b is a
> +		field that represents an encoding of the sense and level
> +		information for the interrupt.  This should be encoded based on
> +		the information in section 2) depending on the type of interrupt
> +		controller you have.
> +	  - interrupt-parent : the phandle for the interrupt controller that
> +		services interrupts for this device.
> +
> +	5) FCCs (Fast Communications Controllers)
> +
> +	  Required properties:
> +
> +	  - device_type : should be "network"
> +	  - model : "FCCx", x is typically a small number depending on the
> +	  devices amount
> +	  - compatible : should be "fs_enet"
> +	  - address : List of bytes representing the ethernet address of
> +		this controller
> +	  - reg : offset to the register set and its length
> +	  - reg-pram : offset to the device parameter RAM
> +	  - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values  
> define
> +	  multiplexor clock routing and clock mask respectively
> +	  - interrupts : <a b> where a is the interrupt number and b is a
> +		field that represents an encoding of the sense and level
> +		information for the interrupt.  This should be encoded based on
> +		the information in section 2) depending on the type of interrupt
> +		controller you have.
> +	  - interrupt-parent : the phandle for the interrupt controller that
> +		services interrupts for this device.
> +	  - phy-handle : The phandle for the PHY connected to this ethernet
> +		controller.
> +   Example:
> + 	/*8272ADS*/
> +	cpm@f0000000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		#interrupt-cells = <2>;
> +		device_type = "cpm";
> +		model = "CPM2";
> +		ranges = <0 f0000000 00100000>;
> +		reg = <f0000000 000101a8>;
> +		command-proc = <119c0>
> +
> +		brg@119f0 {
> +			device_type = "brg";
> +			model = "BRG1";
> +			reg = <119f0>;
> +			linux,phandle = <775>;
> +		};
> +
> +		cpmux@11b04 {
> +			device_type = "cpmux";
> +			compatible = "fcc";
> +			reg = <11b04>;
> +		};
> +
> +		cpmux@11b08 {
> +			device_type = "cpmux";
> +			compatible = "scc";
> +			reg = <11b08>;
> +		};
> +
> +		scc@11a20 {
> +			device_type = "serial";
> +			compatible = "cpm_uart";
> +			model = "SCC1";
> +			reg = <11a20 100>;
> +			reg_pram = <8000 ff>;
> +			clock_setup = <0x00ffffff 0>;
> +			interrupts = <28 3>;
> +			interrupt-parent = <700>;
> +			brg_phandle = <775>;
> +		};
> +
> +		fcc@11300 {
> +			device_type = "network";
> +			compatible = "fs_enet";
> +			model = "FCC1";
> +			reg = <11300 1f>;
> +			reg_pram = <8400 ff>;
> +			address = [00 00 00 00 00 00];
> +			interrupts = <20 3>;
> +			interrupt-parent = <700>;
> +			phy_handle = <2452000>;
> +		};
> +	};
>
>     More devices will be defined as this spec matures.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Tue, 28 Mar 2006 10:37:02 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> Paul,
> 
> Please dont accept this patch right away.  I think we should let this  
> have some discussion on the list before it goes in.  I believe this  
> is the first time any of the 8xx maintainers have seen this (Dan or  
> Marcelo) so getting their feedback would be good.
> 
That was implied... This is definitely RFC, I forgot to add that to the subject :)

> Nothing against your patch Vitaly :)
> 
> - kumar
> -- 
Sincerely, 
Vitaly

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Paul Nasrat]

On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:
> Updated the documentation to include the initial description of the CPM2
> device that are used on PQII and PQIII families. Only initial sub-devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
> 

> +	5) FCCs (Fast Communications Controllers)
> +
> +	  Required properties:
> +
> +	  - device_type : should be "network"
> +	  - model : "FCCx", x is typically a small number depending on the
> +	  devices amount
> +	  - compatible : should be "fs_enet"
> +	  - address : List of bytes representing the ethernet address of
> +		this controller

Umm should we not use local-mac-address and mac-address (and
address-bits) as in section 3.7.4 in 1275-1994?

Paul

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Andy Fleming]

On Mar 28, 2006, at 10:55, Paul Nasrat wrote:

> On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:
>> Updated the documentation to include the initial description of  
>> the CPM2
>> device that are used on PQII and PQIII families. Only initial sub- 
>> devices
>> described so far, but that should be sufficient to move the  
>> respective
>> boards to powerpc, with a reasonable minimum supporteddevice set.
>>
>
>> +	5) FCCs (Fast Communications Controllers)
>> +
>> +	  Required properties:
>> +
>> +	  - device_type : should be "network"
>> +	  - model : "FCCx", x is typically a small number depending on the
>> +	  devices amount
>> +	  - compatible : should be "fs_enet"
>> +	  - address : List of bytes representing the ethernet address of
>> +		this controller
>
> Umm should we not use local-mac-address and mac-address (and
> address-bits) as in section 3.7.4 in 1275-1994?


So no one chimed in on this.  Clearly, 1275 states that it's supposed  
to be local-mac-address or mac-address.  We use "address".  But I'm  
pretty sure we copied our ethernet node from somewhere else, so which  
one should it be?

Andy Fleming

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Paul Nasrat]

On Wed, 2006-04-12 at 18:19 -0500, Andy Fleming wrote:
> On Mar 28, 2006, at 10:55, Paul Nasrat wrote:
> 
> > On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:

> >> +	  - address : List of bytes representing the ethernet address of
> >> +		this controller
> >
> > Umm should we not use local-mac-address and mac-address (and
> > address-bits) as in section 3.7.4 in 1275-1994?
> 
> 
> So no one chimed in on this.  Clearly, 1275 states that it's supposed  
> to be local-mac-address or mac-address.  We use "address".  But I'm  
> pretty sure we copied our ethernet node from somewhere else, so which  
> one should it be?

Well I'm biased and say we shouldn't reinvent the wheel with dtc if we
don't need to.  I've sent Jon a patch to start validating this for dtc
and am waiting feedback before I add additional device_types. So we
should have local-mac-address be preassiged hwaddr and mac-address last
used. For some setups this would be the same persistently, but I can
envisage some non OF setups populating mac-address from the card. 

Paul

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Jon Loeliger]

So, like, the other day Paul Nasrat mumbled:
> 
> Well I'm biased and say we shouldn't reinvent the wheel with dtc if we
> don't need to.  I've sent Jon a patch to start validating this for dtc
> and am waiting feedback before I add additional device_types.

What other device_types do you want to check? 

> So we
> should have local-mac-address be preassiged hwaddr and mac-address last
> used. For some setups this would be the same persistently, but I can
> envisage some non OF setups populating mac-address from the card. 

I'm sitting at a conference right now.  I'll slate 
some time for looking into it early next week.

jdl

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Paul Mackerras]

Andy Fleming writes:

> So no one chimed in on this.  Clearly, 1275 states that it's supposed  
> to be local-mac-address or mac-address.  We use "address".  But I'm  
> pretty sure we copied our ethernet node from somewhere else, so which  
> one should it be?

It shouldn't be "address".  That would normally be the physical
address of the device's registers, if anything.

Paul.

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Dan Malek]

On Mar 28, 2006, at 11:14 AM, Vitaly Bordug wrote:

> Updated the documentation to include the initial description of the 
> CPM2
> device that are used on PQII and PQIII families.

I haven't followed the device tree development in detail, but when
looking at this the only question that comes to mind is wondering
what this really does to help me.  None of the information provided
here is variable nor configurable .... except I guess for the internal
register base address (IMMR), which for some reason has turned
into a variable which hasn't changed since I did the first kernel port.
About the only thing that is variable, which is the two different bank
addresses of the CPM memory that affects the configuration of
the FCCs in Ethernet mode, isn't reflected here in any way.

> +		brg@119f0 {
> +			device_type = "brg";
> +			model = "BRG1";
> +			reg = <119f0>;
> +			linux,phandle = <775>;
> +		};

Why?  We already know it's at this address offset.

> +
> +		cpmux@11b04 {
> +			device_type = "cpmux";
> +			compatible = "fcc";
> +			reg = <11b04>;
> +		};
> +
> +		cpmux@11b08 {
> +			device_type = "cpmux";
> +			compatible = "scc";
> +			reg = <11b08>;
> +		};

I don't understand the value of these either.

> +
> +		scc@11a20 {
> +			device_type = "serial";
> +			compatible = "cpm_uart";
> +			model = "SCC1";
> +			reg = <11a20 100>;
> +			reg_pram = <8000 ff>;
> +			clock_setup = <0x00ffffff 0>;
> +			interrupts = <28 3>;

None of this is variable.  If you know you are using scc1,
you must use certain configuration bits in the cmxscr (the
thing you are calling cpmux).  Why would you want to make
this variable and prone to error?  The driver knows, and
there are no options.  Same for the interrupts that are used.

> +		fcc@11300 {
> +			device_type = "network";
> +			compatible = "fs_enet";
> +			model = "FCC1";
> +			reg = <11300 1f>;
> +			reg_pram = <8400 ff>;
> +			address = [00 00 00 00 00 00];

I'm assuming this is the MAC address, and is probably
the only thing I see of value here.

>     More devices will be defined as this spec matures.

I just don't understand the value of this.  Will you explain
it for me?

Thanks.


	-- Dan

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Paul Mackerras]

Dan Malek writes:

> I haven't followed the device tree development in detail, but when
> looking at this the only question that comes to mind is wondering
> what this really does to help me.  None of the information provided
> here is variable nor configurable .... except I guess for the internal
> register base address (IMMR), which for some reason has turned
> into a variable which hasn't changed since I did the first kernel port.
> About the only thing that is variable, which is the two different bank
> addresses of the CPM memory that affects the configuration of
> the FCCs in Ethernet mode, isn't reflected here in any way.

I don't know much about the CPM or CPM2, so I don't know precisely why
these bits have been put in.  If the CPM2 is completely unique and is
identical across all possible past and future implementations, then
indeed there isn't a lot of value in putting details about it in the
device tree.  Having details in the device tree becomes useful if:

* there are variants that have different collections of subdevices, or
  subdevices at different offsets, or

* there are common subdevices between CPM and CPM2 (or future CPM*
  devices), potentially with subtle variations in offset, method of
  enabling, etc., or

* there are subdevices in CPM/CPM2 which match some common device
  (e.g. a 16550 uart) for which a generic driver can be used with some
  appropriate configuration.

As I say, I don't know if these points apply to CPM/CPM2 specifically.

Paul.

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Thu, 30 Mar 2006 17:10:48 +1100
Paul Mackerras <paulus@samba.org> wrote:

> Dan Malek writes:
> 
> > I haven't followed the device tree development in detail, but when
> > looking at this the only question that comes to mind is wondering
> > what this really does to help me.  None of the information provided
> > here is variable nor configurable .... except I guess for the internal
> > register base address (IMMR), which for some reason has turned
> > into a variable which hasn't changed since I did the first kernel port.
> > About the only thing that is variable, which is the two different bank
> > addresses of the CPM memory that affects the configuration of
> > the FCCs in Ethernet mode, isn't reflected here in any way.
> 
> I don't know much about the CPM or CPM2, so I don't know precisely why
> these bits have been put in.  If the CPM2 is completely unique and is
> identical across all possible past and future implementations, then
> indeed there isn't a lot of value in putting details about it in the
> device tree.  Having details in the device tree becomes useful if:
> 
> * there are variants that have different collections of subdevices, or
>   subdevices at different offsets, or
> 
Yes. Offsets differ across the different PQ families. Collections may differ even on the same reference design, 885 for instance could have all the scc's/smc's utilized as UARTs, while on classic SMC1+SMC2, only, SCC may be used as 10M network.

> * there are common subdevices between CPM and CPM2 (or future CPM*
>   devices), potentially with subtle variations in offset, method of
>   enabling, etc., or
> 
Yes, but this is similar with the first point... Well even cpm and cpm2 differ (different immap.h ), and we have CPM future heading for QE. 
> * there are subdevices in CPM/CPM2 which match some common device
>   (e.g. a 16550 uart) for which a generic driver can be used with some
>   appropriate configuration.
Yep - cpm_uart and fs_enet are live examples. Both are intended to deal with serial and Ethernet stuff from the different variations of CPM. Right now they are not ideal, because they still have to remap the whole immr (say to access cpm command register) ,and such parts are still board-specific which is not good...
> 
> As I say, I don't know if these points apply to CPM/CPM2 specifically.
> 
> Paul.
> 
> 
Thank you for your comments - now I'm sure all this following the right way...

-- 
Sincerely, 
Vitaly

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Thu, 30 Mar 2006 00:05:38 -0500
Dan Malek <dan@embeddededge.com> wrote:

> 
> On Mar 28, 2006, at 11:14 AM, Vitaly Bordug wrote:
> 
> > Updated the documentation to include the initial description of the 
> > CPM2
> > device that are used on PQII and PQIII families.
> 
> I haven't followed the device tree development in detail, but when
> looking at this the only question that comes to mind is wondering
> what this really does to help me.  None of the information provided
> here is variable nor configurable .... except I guess for the internal
> register base address (IMMR), which for some reason has turned
> into a variable which hasn't changed since I did the first kernel port.
> About the only thing that is variable, which is the two different bank
> addresses of the CPM memory that affects the configuration of
> the FCCs in Ethernet mode, isn't reflected here in any way.

Why do you think/guess the values below _should_ be variable? Well they could, but the target is to have the auto-config only in places it makes sense. (I currently see only PCI stuff in this relation). The dts will be compiled together with the firmware, and provide the correct information to the kernel. The dts is a board-specific thing, it is intended to present all the necessary devices to live happily without all the immr structure. In other words, what it should present, is the same logical construction uniting all the legacy (CPM on 8xx), up-to-date (CPM2 on PQ2 and PQ3) and future (QuiccEngine on 8360) boards in an easy to maintain and extensible  way.

I'll elaborate of course if needed - note I am not the theoretical fanatic of this idea, but it 
-	makes sense, 
- 	the new way, all that will not follow it will be obsoleted sooner or later


> 
> > +		brg@119f0 {
> > +			device_type = "brg";
> > +			model = "BRG1";
> > +			reg = <119f0>;
> > +			linux,phandle = <775>;
> > +		};
> 
> Why?  We already know it's at this address offset.
Hmm? The same offset for 8xx, 82xx PQII and new QE? don't think so...
> 
> > +
> > +		cpmux@11b04 {
> > +			device_type = "cpmux";
> > +			compatible = "fcc";
> > +			reg = <11b04>;
> > +		};
> > +
> > +		cpmux@11b08 {
> > +			device_type = "cpmux";
> > +			compatible = "scc";
> > +			reg = <11b08>;
> > +		};
> 
> I don't understand the value of these either.

As far as I got the idea, on startup I'll have _only_ devicetree, in order to configure the stuff, and insert the devices properly. Hereby, I need the offsets to configure things. And I don't really want to hide those into *.h - or we'll return to #ifdef hell there. These offsets are *not* constant if we look over different PQ generations. 

> 
> > +
> > +		scc@11a20 {
> > +			device_type = "serial";
> > +			compatible = "cpm_uart";
> > +			model = "SCC1";
> > +			reg = <11a20 100>;
> > +			reg_pram = <8000 ff>;
> > +			clock_setup = <0x00ffffff 0>;
> > +			interrupts = <28 3>;
> 
> None of this is variable.  If you know you are using scc1,
> you must use certain configuration bits in the cmxscr (the
> thing you are calling cpmux).  Why would you want to make
> this variable and prone to error?  The driver knows, and
> there are no options.  Same for the interrupts that are used.
> 

Just compared in CPM, CPM2 and QE reference manuals - found no equal values. The aim is to move all that specific offsets over to BSP land in devicetree source. The logic is common, but the numbers/offsets are different, and features as well, for instance, QE UCC is much more flexible than SCC/FCC, differing technically but is really common logically.

> > +		fcc@11300 {
> > +			device_type = "network";
> > +			compatible = "fs_enet";
> > +			model = "FCC1";
> > +			reg = <11300 1f>;
> > +			reg_pram = <8400 ff>;
> > +			address = [00 00 00 00 00 00];
> 
> I'm assuming this is the MAC address, and is probably
> the only thing I see of value here.
> 
> >     More devices will be defined as this spec matures.
> 
> I just don't understand the value of this.  Will you explain
> it for me?
> 
I am not a good "explainer", but AFAIR, the powerpc land is generic-code-prone. All the bsp stuff should be either dealt in the firmware, of passed as a flattened devtree and unpacked/used in one function. 

Even conflicting IOPs in 8xx I am going to be configured completely within u-boot, using env or something like that. I know, the kernel should be able to deal with tuning like the upper dependless of the firmware, but there are no much such designs remaining (that are targeting to the new-generation kernel),
and all of them (I know about) are using u-boot.
 
> Thanks.
>
Thanks for attention to this :) 
> 
> 	-- Dan
> 
> 


-- 
Sincerely, 
Vitaly

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Dan Malek]

On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:

> - 	the new way, all that will not follow it will be obsoleted sooner 
> or later

The problem I see is the "new way" is done for the sake of doing 
something
new, without adding any value.  If you want to make the drivers 
dynamically
configurable, which I'll continue to argue is silly in an embedded 
environment
of the type with CPMs, all you need to know is personality of the 
device.
The reason it's silly is the wiring on the particular board dictates 
how a
CPM peripheral will be used.  The SCC1 can't be a serial uart one
moment and an Ethernet the next time you boot up.  Since you have 
already
done a "board port", you may as well wire this as part of the 
configuration
and eliminate potential mistakes.  If you insist on making this dynamic
(and as a port maintainer I would reject such patches), the only thing
you need to describe is the device type.  For example, the SCC1 can be
an Ethernet or uart.  We only support FCCs as Ethernets, and unless
someone submits some other kind of driver, like ATM/UTOPIA, there
isn't anything variable to configure.

All of the truly configurable options, like NMSI vs. TSA, are so complex
the device tree would not be helpful, as that would be built into the
custom driver to configure as necessary.

The offsets into the internal register maps are not so variable that 
adding
the information into the device tree is useful.  There is CPM1 and CPM2,
some common code shared between them that already solves the
problems, and the real difference between the two different CPM2 maps
on 82xx isn't reflected here (but again is already solved in the 
existing
software).  As I said in the past message, this seems more likely to 
cause
errors than be helpful.  To me it just seems new for the sake of being
new, rather than providing any real value.

I'd rather we spend our time adding the xmon and kgdb over serial port
features back into the driver that were lost during the "great driver 
clean up"
than pursing stuff like this.

Thanks.

	-- Dan

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Kumar Gala]

On Mar 30, 2006, at 7:09 AM, Dan Malek wrote:

>
> On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:
>
>> - 	the new way, all that will not follow it will be obsoleted sooner
>> or later
>
> The problem I see is the "new way" is done for the sake of doing
> something
> new, without adding any value.  If you want to make the drivers
> dynamically
> configurable, which I'll continue to argue is silly in an embedded
> environment
> of the type with CPMs, all you need to know is personality of the
> device.
> The reason it's silly is the wiring on the particular board dictates
> how a
> CPM peripheral will be used.  The SCC1 can't be a serial uart one
> moment and an Ethernet the next time you boot up.  Since you have
> already
> done a "board port", you may as well wire this as part of the
> configuration
> and eliminate potential mistakes.  If you insist on making this  
> dynamic
> (and as a port maintainer I would reject such patches), the only thing
> you need to describe is the device type.  For example, the SCC1 can be
> an Ethernet or uart.  We only support FCCs as Ethernets, and unless
> someone submits some other kind of driver, like ATM/UTOPIA, there
> isn't anything variable to configure.
>
> All of the truly configurable options, like NMSI vs. TSA, are so  
> complex
> the device tree would not be helpful, as that would be built into the
> custom driver to configure as necessary.
>
> The offsets into the internal register maps are not so variable that
> adding
> the information into the device tree is useful.  There is CPM1 and  
> CPM2,
> some common code shared between them that already solves the
> problems, and the real difference between the two different CPM2 maps
> on 82xx isn't reflected here (but again is already solved in the
> existing
> software).  As I said in the past message, this seems more likely to
> cause
> errors than be helpful.  To me it just seems new for the sake of being
> new, rather than providing any real value.
>
> I'd rather we spend our time adding the xmon and kgdb over serial port
> features back into the driver that were lost during the "great driver
> clean up"
> than pursing stuff like this.

Maybe we should look at this from a different point of view.  What  
are the things that change can change between boards for the same CPU?

* What a give channel (SCC, FCC, UCC, SMC?) is used for serial,  
ethernet, ATM, etc.
* How a channel is wired? [pin muxing]  (I really hate having drivers  
have board specific ifdefs for this)
* which (if any) BRG a channel is using?
* ...? [I feel like I'm missing some but haven't worked on a CPM  
driver in a while :)]

The other question is what changes between CPUs?

* Number/Mix of channels
* some PRAM offset (8272 FCC comes to mind)
* channel differences for same channel type? (what's an example of  
this?)
* ...?

I think we should attempt to answer my two questions first (which Dan  
took an initial swag at) and use those answers to drive how/what we  
need in the description of a CPM node.

- kumar

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Dan Malek]

On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:

> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> ethernet, ATM, etc.

You need to view this from the other direction.  As I've always
said, we don't have an "SCC driver", we have a uart driver for
SCCs.  So, you configure from that perspective.  The uart driver
is configured to use certain SCCs.

> * How a channel is wired? [pin muxing]  (I really hate having drivers
> have board specific ifdefs for this)

I've got a solution for IO pin multiplexing that I have to get pushed
in using the "feature_call" method like a pmac.  The other thing
to realize here is there is often hardware beyond just "pin muxing"
that is unique to a board and requires configuration.  Statically
describing what pins set/clear is a small, and already understood
part, of more complex set up that needs to be done with code
unique to a board.

> * which (if any) BRG a channel is using?

These are already a dynamically allocated resource.  Drivers
don't care which one is assigned, you should be allocating
one and using the handle provided to the support functions.

> * ...? [I feel like I'm missing some but haven't worked on a CPM
> driver in a while :)]

I can't think of any, and I use the CPM all of the time.  :-)

> The other question is what changes between CPUs?

Almost nothing, except the PRAM offset you mention below
and I've mentioned in past messages as memory bank differences.

> * Number/Mix of channels
> * some PRAM offset (8272 FCC comes to mind)
> * channel differences for same channel type? (what's an example of
> this?)
> * ...?

Don't be creating problems to solve because we seem to have
a solution for _something_.  Yes, this would be a cute piece of code
to write and interesting driver updates, but in the end all we have
is change for the sake of change, without adding any new features.

The thing to remember is the few public Linux drivers we have
take little advantage of the CPM features.  We just configure a few
fixed standard modes (like serial and Ethernet).  The CPM is far
more powerful and flexible than this, so it seems silly to create some
complex method of describing our trivial fixed modes that has no
hope of actually being useful for "real" CPM usage.  Then, when
someone does write a more complex driver, we have all of this
"framework" that just gets in the way instead of being useful.

Thanks.


	-- Dan

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Thu, 30 Mar 2006 10:14:18 -0500
Dan Malek <dan@embeddedalley.com> wrote:

> 
> On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
> 
> > * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> > ethernet, ATM, etc.
> 
> You need to view this from the other direction.  As I've always
> said, we don't have an "SCC driver", we have a uart driver for
> SCCs.  So, you configure from that perspective.  The uart driver
> is configured to use certain SCCs.
> 
Well, I am going to move the board-specific code to the BSP place, and make the driver use the callback when it needs to configure the HW tp use SCC/SMC (that includes pin setup as well - the way it is in fs_enet). Actually, it can use any (or even all the SXCs) simultaneously, and that strict configuration can be obsoleted (I mean - nothing required in .config to mention which soc device has the uart, as gianfar does not require what TSEC to utilize) - people often misconfigure things, and to be right there should be ifdef hell in the driver which is _odd_.

> > * How a channel is wired? [pin muxing]  (I really hate having drivers
> > have board specific ifdefs for this)
> 
> I've got a solution for IO pin multiplexing that I have to get pushed
> in using the "feature_call" method like a pmac.  The other thing
> to realize here is there is often hardware beyond just "pin muxing"
> that is unique to a board and requires configuration.  Statically
> describing what pins set/clear is a small, and already understood
> part, of more complex set up that needs to be done with code
> unique to a board.

well, ... :D
> 
> > * which (if any) BRG a channel is using?
> 
> These are already a dynamically allocated resource.  Drivers
> don't care which one is assigned, you should be allocating
> one and using the handle provided to the support functions.
> 

Nobody is arguing. But we need offsets to deal with BRGs (at least repeat that behavior in powerpc), CMX, CP - and there are 2 options to have them  -  yet another foo_immap.h or that "static" nodes in the flattened device tree. 

We already have mature implementation of the first approach - and I just want to give the second one a try and to see if it will be more flexible/effective that what we have in ppc right now. 


> > * ...? [I feel like I'm missing some but haven't worked on a CPM
> > driver in a while :)]
> 
> I can't think of any, and I use the CPM all of the time.  :-)
That is great :)
> 
> > The other question is what changes between CPUs?
> 
> Almost nothing, except the PRAM offset you mention below
> and I've mentioned in past messages as memory bank differences.
> 
> > * Number/Mix of channels
> > * some PRAM offset (8272 FCC comes to mind)
> > * channel differences for same channel type? (what's an example of
> > this?)
> > * ...?
> 
> Don't be creating problems to solve because we seem to have
> a solution for _something_.  Yes, this would be a cute piece of code
> to write and interesting driver updates, but in the end all we have
> is change for the sake of change, without adding any new features.

Let me disagree. Each big change is "a change for change, for design" usually at start. Or, why don't we still use 2.4 - I'm pretty sure there was some period of "redesign" when the new architecture tries to re-implement features yet-existing in mature-stable branch... Or am I missing something?

> 
> The thing to remember is the few public Linux drivers we have
> take little advantage of the CPM features.  We just configure a few
> fixed standard modes (like serial and Ethernet).  The CPM is far
> more powerful and flexible than this, so it seems silly to create some
> complex method of describing our trivial fixed modes that has no
> hope of actually being useful for "real" CPM usage.  Then, when
> someone does write a more complex driver, we have all of this
> "framework" that just gets in the way instead of being useful.
> 
Currently we'll be stale on that small fixed functionality with the implementation we have in ppc. Yes, feature_call could help, but will not save the world, so drivers will have that ifdeffed code inside, direct immr dereference, etc.  Well, it's really hard to make use of CPM flexibility the way it is now.  I don't believe that devicetree approach will save the world either, but it is promising enough at least to try that way.


-- 
Sincerely, 
Vitaly

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Kumar Gala]

On Mar 30, 2006, at 9:14 AM, Dan Malek wrote:

>
> On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
>
>> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
>> ethernet, ATM, etc.
>
> You need to view this from the other direction.  As I've always
> said, we don't have an "SCC driver", we have a uart driver for
> SCCs.  So, you configure from that perspective.  The uart driver
> is configured to use certain SCCs.

Oh, I agree with you.  This becomes more obvious with QE where  
everything is a UCC channel.

>> * How a channel is wired? [pin muxing]  (I really hate having drivers
>> have board specific ifdefs for this)
>
> I've got a solution for IO pin multiplexing that I have to get pushed
> in using the "feature_call" method like a pmac.  The other thing
> to realize here is there is often hardware beyond just "pin muxing"
> that is unique to a board and requires configuration.  Statically
> describing what pins set/clear is a small, and already understood
> part, of more complex set up that needs to be done with code
> unique to a board.

still waiting :)

>> * which (if any) BRG a channel is using?
>
> These are already a dynamically allocated resource.  Drivers
> don't care which one is assigned, you should be allocating
> one and using the handle provided to the support functions.

Ok, good.

>> * ...? [I feel like I'm missing some but haven't worked on a CPM
>> driver in a while :)]
>
> I can't think of any, and I use the CPM all of the time.  :-)
>
>> The other question is what changes between CPUs?
>
> Almost nothing, except the PRAM offset you mention below
> and I've mentioned in past messages as memory bank differences.
>
>> * Number/Mix of channels
>> * some PRAM offset (8272 FCC comes to mind)
>> * channel differences for same channel type? (what's an example of
>> this?)
>> * ...?
>
> Don't be creating problems to solve because we seem to have
> a solution for _something_.  Yes, this would be a cute piece of code
> to write and interesting driver updates, but in the end all we have
> is change for the sake of change, without adding any new features.

I'm hopefully not suggesting that or at least not something I see as  
this extensive.

> The thing to remember is the few public Linux drivers we have
> take little advantage of the CPM features.  We just configure a few
> fixed standard modes (like serial and Ethernet).  The CPM is far
> more powerful and flexible than this, so it seems silly to create some
> complex method of describing our trivial fixed modes that has no
> hope of actually being useful for "real" CPM usage.  Then, when
> someone does write a more complex driver, we have all of this
> "framework" that just gets in the way instead of being useful.

I know.

I guess what I'd suggest is something that makes letting the kernel  
know about serial & enet usage on the CPM is the extent to take this  
to start with.  If in time we have more drivers for more things  
great, then extend it then.  I dont see any reason we can't leverage  
the flat-dev-tree to have a single way to describe the serial & enet  
configs for a board.

I see how you can see this as duplication of a solved problem.   
However, we need some place to describe some basic config info that  
we have in arch/ppc for arch/powerpc and flat-dev/.dts is that  
mechanism.  While we are moving it out of the kernel proper, I think  
the idea is that over time using the flat-dev tree will allow the  
information we have to be described in one place and shared between  
kernel & firmware.

(and if Vitaly finishes this off we can beat him up to add kgdb  
support back to cpm_uart :)

- kumar

Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation

[Vitaly Bordug]

On Thu, 30 Mar 2006 09:43:38 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Mar 30, 2006, at 9:14 AM, Dan Malek wrote:
> 
> >
> > On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
> >
> >> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> >> ethernet, ATM, etc.
> >
> > You need to view this from the other direction.  As I've always
> > said, we don't have an "SCC driver", we have a uart driver for
> > SCCs.  So, you configure from that perspective.  The uart driver
> > is configured to use certain SCCs.
> 
> Oh, I agree with you.  This becomes more obvious with QE where  
> everything is a UCC channel.
> 
> >> * How a channel is wired? [pin muxing]  (I really hate having drivers
> >> have board specific ifdefs for this)
> >
> > I've got a solution for IO pin multiplexing that I have to get pushed
> > in using the "feature_call" method like a pmac.  The other thing
> > to realize here is there is often hardware beyond just "pin muxing"
> > that is unique to a board and requires configuration.  Statically
> > describing what pins set/clear is a small, and already understood
> > part, of more complex set up that needs to be done with code
> > unique to a board.
> 
> still waiting :)
> 
> >> * which (if any) BRG a channel is using?
> >
> > These are already a dynamically allocated resource.  Drivers
> > don't care which one is assigned, you should be allocating
> > one and using the handle provided to the support functions.
> 
> Ok, good.
> 
> >> * ...? [I feel like I'm missing some but haven't worked on a CPM
> >> driver in a while :)]
> >
> > I can't think of any, and I use the CPM all of the time.  :-)
> >
> >> The other question is what changes between CPUs?
> >
> > Almost nothing, except the PRAM offset you mention below
> > and I've mentioned in past messages as memory bank differences.
> >
> >> * Number/Mix of channels
> >> * some PRAM offset (8272 FCC comes to mind)
> >> * channel differences for same channel type? (what's an example of
> >> this?)
> >> * ...?
> >
> > Don't be creating problems to solve because we seem to have
> > a solution for _something_.  Yes, this would be a cute piece of code
> > to write and interesting driver updates, but in the end all we have
> > is change for the sake of change, without adding any new features.
> 
> I'm hopefully not suggesting that or at least not something I see as  
> this extensive.
> 
> > The thing to remember is the few public Linux drivers we have
> > take little advantage of the CPM features.  We just configure a few
> > fixed standard modes (like serial and Ethernet).  The CPM is far
> > more powerful and flexible than this, so it seems silly to create some
> > complex method of describing our trivial fixed modes that has no
> > hope of actually being useful for "real" CPM usage.  Then, when
> > someone does write a more complex driver, we have all of this
> > "framework" that just gets in the way instead of being useful.
> 
> I know.
> 
> I guess what I'd suggest is something that makes letting the kernel  
> know about serial & enet usage on the CPM is the extent to take this  
> to start with.  If in time we have more drivers for more things  
> great, then extend it then.  I dont see any reason we can't leverage  
> the flat-dev-tree to have a single way to describe the serial & enet  
> configs for a board.
> 
Yes, that's definitely what it is intended to be...

> I see how you can see this as duplication of a solved problem.   
> However, we need some place to describe some basic config info that  
> we have in arch/ppc for arch/powerpc and flat-dev/.dts is that  
> mechanism.  While we are moving it out of the kernel proper, I think  
> the idea is that over time using the flat-dev tree will allow the  
> information we have to be described in one place and shared between  
> kernel & firmware.
> 

And the results we have now for 85xx family look very nice using this approach.
> (and if Vitaly finishes this off we can beat him up to add kgdb  
> support back to cpm_uart :)

Hrm, I've added that to kgdb already... I even have the KGDB stuff implemented in the platform-device-reworked cpm_uart driver :)

-- 
Sincerely, 
Vitaly