* [PATCH] Add QE device tree definition
@ 2006-06-29 12:53 Li Yang-r58472
2006-06-29 23:55 ` Kumar Gala
0 siblings, 1 reply; 11+ messages in thread
From: Li Yang-r58472 @ 2006-06-29 12:53 UTC (permalink / raw)
To: linuxppc-dev
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@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Vitaly Bordug <vbordug@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@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".
+ - 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@4c0 {
+ device_type = "spi";
+ compatible = "fsl_spi";
+ reg = <4c0 40>;
+ interrupts = <82 0>;
+ interrupt-parent = <700>;
+ mode = "cpu";
+ };
+
+
+ 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".
+ - 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@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)
+
+ 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@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@1400 {
+ reg = <1400 100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "par_io";
+ ucc_pin@01 {
+ ......
+ };
+
+
+ 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@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.
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] Add QE device tree definition
2006-06-29 12:53 Li Yang-r58472
@ 2006-06-29 23:55 ` Kumar Gala
0 siblings, 0 replies; 11+ messages in thread
From: Kumar Gala @ 2006-06-29 23:55 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
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@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Vitaly Bordug <vbordug@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@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@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@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@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@1400 {
> + reg = <1400 100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "par_io";
> + ucc_pin@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@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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] Add QE device tree definition
@ 2006-06-30 3:36 Li Yang-r58472
2006-06-30 4:10 ` Kumar Gala
2006-06-30 17:54 ` Andy Fleming
0 siblings, 2 replies; 11+ messages in thread
From: Li Yang-r58472 @ 2006-06-30 3:36 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 7:55 AM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> 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@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > Signed-off-by: Vitaly Bordug <vbordug@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@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?
That means:
The SPI can operate in QE mode or in CPU mode. In QE mode SPI is compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU mode, the SPI is controlled wholly by the CPU without any QE RISC intervention.
>
> > + - 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@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@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@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@1400 {
> > + reg = <1400 100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "par_io";
> > + ucc_pin@01 {
> > + ......
> > + };
> > +
>
> Can you explain this further, I'm not getting the relationship
> between a par_io & ucc_pin. An example maybe helpful.
Each QE device needs to configure Parallel I/O Ports pin configuration in order to work, for example the configuration for ucc1 is ucc_pin@01. par_io is a container for all these configurations and gives the base for parallel io port register. I will paste dts file for 8360 to give an example.
>
> > +
> > + 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@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@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add QE device tree definition
2006-06-30 3:36 Li Yang-r58472
@ 2006-06-30 4:10 ` Kumar Gala
2006-06-30 17:54 ` Andy Fleming
1 sibling, 0 replies; 11+ messages in thread
From: Kumar Gala @ 2006-06-30 4:10 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
[snip]
>>> + 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?
> That means:
> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> mode, the SPI is controlled wholly by the CPU without any QE RISC
> intervention.
In QE mode does software get involved at all?
>>> + - 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@4c0 {
>>> + device_type = "spi";
>>> + compatible = "fsl_spi";
>>> + reg = <4c0 40>;
>>> + interrupts = <82 0>;
>>> + interrupt-parent = <700>;
>>> + mode = "cpu";
>>> + };
>>> +
[snip]
>>> + 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@1400 {
>>> + reg = <1400 100>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "par_io";
>>> + ucc_pin@01 {
>>> + ......
>>> + };
>>> +
>>
>> Can you explain this further, I'm not getting the relationship
>> between a par_io & ucc_pin. An example maybe helpful.
>
> Each QE device needs to configure Parallel I/O Ports pin
> configuration in order to work, for example the configuration for
> ucc1 is ucc_pin@01. par_io is a container for all these
> configurations and gives the base for parallel io port register. I
> will paste dts file for 8360 to give an example.
Maybe its the name that's confusing me, ucc_pin@01 describes what
exactly? A single pin? or all the pin configs for ucc 1?
>>> +
>>> + 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@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@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] Add QE device tree definition
@ 2006-06-30 4:52 Li Yang-r58472
2006-06-30 5:09 ` Kumar Gala
0 siblings, 1 reply; 11+ messages in thread
From: Li Yang-r58472 @ 2006-06-30 4:52 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 12:11 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
> [snip]
>
> >>> + 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?
> > That means:
> > The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> > compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> > mode, the SPI is controlled wholly by the CPU without any QE RISC
> > intervention.
>
> In QE mode does software get involved at all?
Yes, of course. The driver needs to do initialization, and deal with the BDs.
>
> >>> + - 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@4c0 {
> >>> + device_type = "spi";
> >>> + compatible = "fsl_spi";
> >>> + reg = <4c0 40>;
> >>> + interrupts = <82 0>;
> >>> + interrupt-parent = <700>;
> >>> + mode = "cpu";
> >>> + };
> >>> +
>
> [snip]
>
> >>> + 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@1400 {
> >>> + reg = <1400 100>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + device_type = "par_io";
> >>> + ucc_pin@01 {
> >>> + ......
> >>> + };
> >>> +
> >>
> >> Can you explain this further, I'm not getting the relationship
> >> between a par_io & ucc_pin. An example maybe helpful.
> >
> > Each QE device needs to configure Parallel I/O Ports pin
> > configuration in order to work, for example the configuration for
> > ucc1 is ucc_pin@01. par_io is a container for all these
> > configurations and gives the base for parallel io port register. I
> > will paste dts file for 8360 to give an example.
>
> Maybe its the name that's confusing me, ucc_pin@01 describes what
> exactly? A single pin? or all the pin configs for ucc 1?
All pin configs to ucc1.
Could you suggest a more proper name?
>
> >>> +
> >>> + 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@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@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add QE device tree definition
2006-06-30 4:52 [PATCH] Add QE device tree definition Li Yang-r58472
@ 2006-06-30 5:09 ` Kumar Gala
0 siblings, 0 replies; 11+ messages in thread
From: Kumar Gala @ 2006-06-30 5:09 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
On Jun 29, 2006, at 11:52 PM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, June 30, 2006 12:11 PM
>> To: Li Yang-r58472
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Add QE device tree definition
>>
>> [snip]
>>
>>>>> + 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?
>>> That means:
>>> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
>>> compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
>>> mode, the SPI is controlled wholly by the CPU without any QE RISC
>>> intervention.
>>
>> In QE mode does software get involved at all?
>
> Yes, of course. The driver needs to do initialization, and deal
> with the BDs.
So what exactly does the QE do in this 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@4c0 {
>>>>> + device_type = "spi";
>>>>> + compatible = "fsl_spi";
>>>>> + reg = <4c0 40>;
>>>>> + interrupts = <82 0>;
>>>>> + interrupt-parent = <700>;
>>>>> + mode = "cpu";
>>>>> + };
>>>>> +
>>
>> [snip]
>>
>>>>> + 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@1400 {
>>>>> + reg = <1400 100>;
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> + device_type = "par_io";
>>>>> + ucc_pin@01 {
>>>>> + ......
>>>>> + };
>>>>> +
>>>>
>>>> Can you explain this further, I'm not getting the relationship
>>>> between a par_io & ucc_pin. An example maybe helpful.
>>>
>>> Each QE device needs to configure Parallel I/O Ports pin
>>> configuration in order to work, for example the configuration for
>>> ucc1 is ucc_pin@01. par_io is a container for all these
>>> configurations and gives the base for parallel io port register. I
>>> will paste dts file for 8360 to give an example.
>>
>> Maybe its the name that's confusing me, ucc_pin@01 describes what
>> exactly? A single pin? or all the pin configs for ucc 1?
>
> All pin configs to ucc1.
> Could you suggest a more proper name?
Let me think on this now that I understand what's going on.
- k
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] Add QE device tree definition
@ 2006-06-30 5:28 Li Yang-r58472
2006-06-30 5:37 ` Kumar Gala
0 siblings, 1 reply; 11+ messages in thread
From: Li Yang-r58472 @ 2006-06-30 5:28 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 1:10 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> On Jun 29, 2006, at 11:52 PM, Li Yang-r58472 wrote:
>
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Friday, June 30, 2006 12:11 PM
> >> To: Li Yang-r58472
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Add QE device tree definition
> >>
> >> [snip]
> >>
> >>>>> + 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?
> >>> That means:
> >>> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> >>> compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> >>> mode, the SPI is controlled wholly by the CPU without any QE RISC
> >>> intervention.
> >>
> >> In QE mode does software get involved at all?
> >
> > Yes, of course. The driver needs to do initialization, and deal
> > with the BDs.
>
> So what exactly does the QE do in this mode?
Just like CPM. Driver only deal with buffer and buffer descriptor. And QE will take care of the other things.
While in CPU mode, it is up to the CPU to pack and unpack the receive/transmit frames. And tx/rx through data registers.
>
> >>>>> + - 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@4c0 {
> >>>>> + device_type = "spi";
> >>>>> + compatible = "fsl_spi";
> >>>>> + reg = <4c0 40>;
> >>>>> + interrupts = <82 0>;
> >>>>> + interrupt-parent = <700>;
> >>>>> + mode = "cpu";
> >>>>> + };
> >>>>> +
> >>
> >> [snip]
> >>
> >>>>> + 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@1400 {
> >>>>> + reg = <1400 100>;
> >>>>> + #address-cells = <1>;
> >>>>> + #size-cells = <0>;
> >>>>> + device_type = "par_io";
> >>>>> + ucc_pin@01 {
> >>>>> + ......
> >>>>> + };
> >>>>> +
> >>>>
> >>>> Can you explain this further, I'm not getting the relationship
> >>>> between a par_io & ucc_pin. An example maybe helpful.
> >>>
> >>> Each QE device needs to configure Parallel I/O Ports pin
> >>> configuration in order to work, for example the configuration for
> >>> ucc1 is ucc_pin@01. par_io is a container for all these
> >>> configurations and gives the base for parallel io port register. I
> >>> will paste dts file for 8360 to give an example.
> >>
> >> Maybe its the name that's confusing me, ucc_pin@01 describes what
> >> exactly? A single pin? or all the pin configs for ucc 1?
> >
> > All pin configs to ucc1.
> > Could you suggest a more proper name?
>
> Let me think on this now that I understand what's going on.
>
> - k
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add QE device tree definition
2006-06-30 5:28 Li Yang-r58472
@ 2006-06-30 5:37 ` Kumar Gala
0 siblings, 0 replies; 11+ messages in thread
From: Kumar Gala @ 2006-06-30 5:37 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
>>>>
>>>>>>> + 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?
>>>>> That means:
>>>>> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
>>>>> compatible to the MPC826x SPI, and is controlled by QE RISC. In
>>>>> CPU
>>>>> mode, the SPI is controlled wholly by the CPU without any QE RISC
>>>>> intervention.
>>>>
>>>> In QE mode does software get involved at all?
>>>
>>> Yes, of course. The driver needs to do initialization, and deal
>>> with the BDs.
>>
>> So what exactly does the QE do in this mode?
>
> Just like CPM. Driver only deal with buffer and buffer
> descriptor. And QE will take care of the other things.
> While in CPU mode, it is up to the CPU to pack and unpack the
> receive/transmit frames. And tx/rx through data registers.
Ohh, so CPU mode matches the 834x then, and QE mode matches 82xx/CPM.
Has anyone looked at extending the 834x driver that is in the tree
now for using descriptors for QE/82xx?
- k
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add QE device tree definition
2006-06-30 3:36 Li Yang-r58472
2006-06-30 4:10 ` Kumar Gala
@ 2006-06-30 17:54 ` Andy Fleming
1 sibling, 0 replies; 11+ messages in thread
From: Andy Fleming @ 2006-06-30 17:54 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
On Jun 29, 2006, at 22:36, Li Yang-r58472 wrote:
>>> +
>>> +
>>> + 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?
> That means:
> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> mode, the SPI is controlled wholly by the CPU without any QE RISC
> intervention.
Doesn't that mean the "cpu" SPI isn't part of the QE device? I kind
of feel like it shouldn't be part of the QE node, then. Or is it
actually one device that can act in two different modes?
>
>>
>>> + - 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@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@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@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@1400 {
>>> + reg = <1400 100>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "par_io";
>>> + ucc_pin@01 {
>>> + ......
>>> + };
>>> +
>>
>> Can you explain this further, I'm not getting the relationship
>> between a par_io & ucc_pin. An example maybe helpful.
>
> Each QE device needs to configure Parallel I/O Ports pin
> configuration in order to work, for example the configuration for
> ucc1 is ucc_pin@01. par_io is a container for all these
> configurations and gives the base for parallel io port register. I
> will paste dts file for 8360 to give an example.
>>
>>> +
>>> + 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@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@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] Add QE device tree definition
@ 2006-07-03 6:17 Li Yang-r58472
0 siblings, 0 replies; 11+ messages in thread
From: Li Yang-r58472 @ 2006-07-03 6:17 UTC (permalink / raw)
To: Fleming Andy-afleming; +Cc: linuxppc-dev
> -----Original Message-----
> From: Fleming Andy-afleming
> Sent: Saturday, July 01, 2006 1:55 AM
> To: Li Yang-r58472
> Cc: 'Kumar Gala'; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> On Jun 29, 2006, at 22:36, Li Yang-r58472 wrote:
>
> >>> +
> >>> +
> >>> + 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?
> > That means:
> > The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> > compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> > mode, the SPI is controlled wholly by the CPU without any QE RISC
> > intervention.
>
>
> Doesn't that mean the "cpu" SPI isn't part of the QE device? I kind
> of feel like it shouldn't be part of the QE node, then. Or is it
> actually one device that can act in two different modes?
Yes, it is actually one device with two modes, sharing the same set of registers within QE memory map region. So it best lives in QE node.
>
>
> >
> >>
> >>> + - 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@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@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@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@1400 {
> >>> + reg = <1400 100>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + device_type = "par_io";
> >>> + ucc_pin@01 {
> >>> + ......
> >>> + };
> >>> +
> >>
> >> Can you explain this further, I'm not getting the relationship
> >> between a par_io & ucc_pin. An example maybe helpful.
> >
> > Each QE device needs to configure Parallel I/O Ports pin
> > configuration in order to work, for example the configuration for
> > ucc1 is ucc_pin@01. par_io is a container for all these
> > configurations and gives the base for parallel io port register. I
> > will paste dts file for 8360 to give an example.
> >>
> >>> +
> >>> + 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@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@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] Add QE device tree definition
@ 2006-07-04 4:57 Li Yang-r58472
0 siblings, 0 replies; 11+ messages in thread
From: Li Yang-r58472 @ 2006-07-04 4:57 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> > + 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).
In current implementation of gadget, gadget driver is selected in kernel config and module loading. Different gadget drivers can't be loaded at the same time for now. Thus, having it in device tree will have no actual use.
>
> > + - 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-07-04 4:57 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-30 4:52 [PATCH] Add QE device tree definition Li Yang-r58472
2006-06-30 5:09 ` Kumar Gala
-- strict thread matches above, loose matches on Subject: below --
2006-07-04 4:57 Li Yang-r58472
2006-07-03 6:17 Li Yang-r58472
2006-06-30 5:28 Li Yang-r58472
2006-06-30 5:37 ` Kumar Gala
2006-06-30 3:36 Li Yang-r58472
2006-06-30 4:10 ` Kumar Gala
2006-06-30 17:54 ` Andy Fleming
2006-06-29 12:53 Li Yang-r58472
2006-06-29 23:55 ` Kumar Gala
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).