[PATCH] Add QE device tree definition

Kumar Gala galak at kernel.crashing.org
Fri Jun 30 09:55:19 EST 2006


On Jun 29, 2006, at 7:53 AM, Li Yang-r58472 wrote:

> This is the device tree definition for QE SOC for Freescale CPUs.
>
> I have discussed with Vitaly.  We agreed on having CPM and QE  
> definition ultimately merged.  He will add in CPM specified  
> definition later.
>
> Signed-off-by: Jiang Bo <Tanya.jiang at freescale.com>
> Signed-off-by: Li Yang <leoli at freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips at freescale.com>
> Signed-off-by: Vitaly Bordug <vbordug at ru.mvista.com>
>
> ---
> Documentation/powerpc/booting-without-of.txt |  222 ++++++++++++++++ 
> ++++++++++
>  1 files changed, 222 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/ 
> Documentation/powerpc/booting-without-of.txt
> index 217e517..096063f 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1442,6 +1442,227 @@ platforms are moved over to use the flat
>         };
>
>
> +   h) Freescale QUICC Engine module (QE)
> +   This represents qe module that is installed on PowerQUICC II Pro.
> +   Hopefully it will merge backward compatibility with CPM/CPM2.
> +   Basically, it is a bus of devices, that could act more or less
> +   as a complete entity (UCC, USB etc ). All of them should be  
> siblings on
> +   the "root" qe node, using the common properties from there.
> +   The description below applies to the the qe of MPC8360 and
> +   more nodes and properties would be extended in the future.	
> +
> +   1) Root QE device
> +
> +   Required properties:
> +   - device_type : should be "qe";
> +   - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
> +   - reg : Offset and length of the register set for the device.
> +   - bus-frequency : the clock frequency for QUICC Engine.
> +
> +   Recommended properties
> +   - brg-frequency : the internal clock source frequency for baud- 
> rate
> +     generators in Hz.
> +
> +   Example:
> +	qe at e0100000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		#interrupt-cells = <2>;
> +		device_type = "qe";
> +		model = "QE";
> +		ranges = <0 e0100000 00100000>;
> +		reg = <e0100000 480>;
> +		brg-frequency = <0>;
> +		bus-frequency = <179A7B00>;
> +	}
> +
> +
> +   2) SPI (Serial Peripheral Interface)
> +
> +   Required properties:
> +   - device_type : should be "spi".
> +   - compatible : should be "fsl_spi".
> +   - mode : the spi operation mode, it can be "cpu" or "qe".

What does it mean for the spi to be in "qe" mode?

> +   - reg : offset to the register set and its length.
> +   - 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.
> +
> +   Example:
> +	spi at 4c0 {
> +		device_type = "spi";
> +		compatible = "fsl_spi";
> +		reg = <4c0 40>;
> +		interrupts = <82 0>;
> +		interrupt-parent = <700>;
> +		mode = "cpu";
> +	};
> +

How do we tell the difference between the various spi controllers.  I  
think we have four of them, three of which are probably pretty  
similar.  We have the 834x spi, and QE, CPM1, CPM2 SPI.

> +
> +   3) USB (Universal Serial Bus Controller)
> +
> +   Required properties:
> +   - device_type : should be "usb".
> +   - compatible : could be "qe_udc" or "fhci-hcd".
> +   - model : the could be "host" or "slave".

got a 'l' on mode, if we are slave should we provide more info about  
what kinda slave we are (ie, what gadget driver should apply).

> +   - reg : there will be two tuples of "address size".  The first  
> tuple is
> +     offset and length of the device registers respectively; the  
> second is
> +     offset and length of the device parameter RAM 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.
> +
> +   Example(slave):
> +	usb at 6c0 {
> +		device_type = "usb";
> +		compatible = "qe_udc";
> +		reg = <6c0 40 8B00 100>;
> +		interrupts = <8b 0>;
> +		interrupt-parent = <700>;
> +		mode = "slave";
> +	};
> +
> +
> +   4) UCC (Unified Communications Controllers)

Why dont you create a sub section for network, and in the future  
additional subsections can be added for the different device_types.

> +
> +   Required properties:
> +   - device_type : should be "network", "hldc", "uart", "transparent"
> +    "bisync" or "atm".
> +   - compatible : could be "ucc_geth" or "fsl_atm" and so on.
> +   - model : should be "UCC".
> +   - device-id : the ucc number(1-8), corresponding to UCCx in UM.
> +   - reg : there will be two tuples of "address size".  The first  
> tuple is
> +     offset and length of the device registers respectively; the  
> second is
> +     offset and length of the device parameter RAM 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.
> +   - pio-handle : The phandle for the Parallel I/O port  
> configuration.
> +
> +   Required properties for network device_type:
> +   - mac-address : list of bytes representing the ethernet address.
> +   - rx-clock : a string represents the UCC receive clock source.
> +     "brgx" : clock source is BRG1~BRG16 respectively;
> +     "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> +     others : clock source is disabled;
> +   - tx-clock: a string represents the UCC transmit clock source;
> +     "brgx" : clock source is BRG1~BRG16 respectively;
> +     "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> +     others : clock source is disabled;
> +   - phy-handle : The phandle for the PHY connected to this  
> controller.
> +
> +   Example:
> +	ucc at 2000 {
> +		device_type = "network";
> +		compatible = "ucc_geth";
> +		model = "UCC";
> +		device-id = <1>;
> +		reg = <2000 200 8400 100>;
> +		interrupts = <a0 0>;
> +		interrupt-parent = <700>;
> +		mac-address = [ 00 04 9f 00 23 23 ];
> +		rx-clock = "none";
> +		tx-clock = "clk9";
> +		phy-handle = <212000>;
> +		pio-handle = <140001>;
> +	};
> +
> +
> +   5) Parallel I/O Ports
> +
> +   This node configures Parallel I/O ports for CPUs with QE support.
> +   The node should reside in the "soc" node of the tree.  For each
> +   device that using parallel I/O ports, a child node should be  
> created.
> +   See the definition of the Pin configuration nodes below for more
> +   information.
> +
> +   Required properties:
> +   - device_type : should be "par_io".
> +   - reg : offset to the register set and its length.
> +
> +   Example:
> +	par_io at 1400 {
> +		reg = <1400 100>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;		
> +		device_type = "par_io";
> +		ucc_pin at 01 {
> +			......
> +		};
> +

Can you explain this further, I'm not getting the relationship  
between a par_io & ucc_pin.  An example maybe helpful.

> +
> +   6) Pin configuration nodes
> +
> +   Required properties:
> +   - linux,phandle : phandle of this node; likely referenced by a QE
> +     device.
> +   - pio-map : array of pin configurations.  Each pin is defined by 6
> +     integers.  The six numbers are respectively: port, pin, dir,
> +     open_drain, assignment, has_irq.
> +     - port : port number of the pin; 0-6 represent port A-G in UM.
> +     - pin : pin number in the port.
> +     - dir : direction of the pin, should encode as follows:
> +
> +	0 = The pin is disabled
> +	1 = The pin is an output
> +	2 = The pin is an input
> +	3 = The pin is I/O
> +
> +     - open_drain : indicates the pin is normal or wired-OR:
> +
> +	0 = The pin is actively driven as an output
> +	1 = The pin is an open-drain driver. As an output, the pin is
> +	    driven active-low, otherwise it is three-stated.
> +
> +     - assignment : function number of the pin according to the  
> Pin Assignment
> +       tables in User Manual.  Each pin can have up to 4 possible  
> functions in
> +       QE and two options for CPM.
> +     - has_irq : indicates if the pin is used as source of exteral
> +       interrupts.
> +
> +   Example:
> +	ucc_pin at 01 {
> +		linux,phandle = <140001>;
> +		pio-map = <
> +		/* port  pin  dir  open_drain  assignment  has_irq */
> +			0  3  1  0  1  0 	/* TxD0 */
> +			0  4  1  0  1  0 	/* TxD1 */
> +			0  5  1  0  1  0 	/* TxD2 */
> +			0  6  1  0  1  0 	/* TxD3 */
> +			1  6  1  0  3  0 	/* TxD4 */
> +			1  7  1  0  1  0 	/* TxD5 */
> +			1  9  1  0  2  0 	/* TxD6 */
> +			1  a  1  0  2  0 	/* TxD7 */
> +			0  9  2  0  1  0 	/* RxD0 */
> +			0  a  2  0  1  0 	/* RxD1 */
> +			0  b  2  0  1  0 	/* RxD2 */
> +			0  c  2  0  1  0 	/* RxD3 */
> +			0  d  2  0  1  0 	/* RxD4 */
> +			1  1  2  0  2  0 	/* RxD5 */
> +			1  0  2  0  2  0 	/* RxD6 */
> +			1  4  2  0  2  0 	/* RxD7 */
> +			0  7  1  0  1  0 	/* TX_EN */
> +			0  8  1  0  1  0 	/* TX_ER */
> +			0  f  2  0  1  0 	/* RX_DV */
> +			0  10 2  0  1  0 	/* RX_ER */
> +			0  0  2  0  1  0 	/* RX_CLK */
> +			2  9  1  0  3  0 	/* GTX_CLK - CLK10 */
> +			2  8  2  0  1  0>;	/* GTX125 - CLK9 */
> +	};
> +
> +
>     More devices will be defined as this spec matures.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev




More information about the Linuxppc-dev mailing list