[PATCH] Add QE device tree definition

[Kumar Gala]

[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 at 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 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.
>
> 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 at 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 at 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 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