Merge branch 'spear/13xx' into next/soc2

  weblink : http://www.st.com/spear

  The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are

  supported by the 'spear' platform of ARM Linux. Currently SPEAr300,

  SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX

  series is in progress.

  supported by the 'spear' platform of ARM Linux. Currently SPEAr1310,

  SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported.

  Hierarchy in SPEAr is as follows:

  SPEAr (Platform)

	- SPEAr3XX (3XX SOC series, based on ARM9)

		- SPEAr300 (SOC)

			- SPEAr300_EVB (Evaluation Board)

			- SPEAr300 Evaluation Board

		- SPEAr310 (SOC)

			- SPEAr310_EVB (Evaluation Board)

			- SPEAr310 Evaluation Board

		- SPEAr320 (SOC)

			- SPEAr320_EVB (Evaluation Board)

			- SPEAr320 Evaluation Board

	- SPEAr6XX (6XX SOC series, based on ARM9)

		- SPEAr600 (SOC)

			- SPEAr600_EVB (Evaluation Board)

			- SPEAr600 Evaluation Board

	- SPEAr13XX (13XX SOC series, based on ARM CORTEXA9)

		- SPEAr1300 (SOC)

		- SPEAr1310 (SOC)

			- SPEAr1310 Evaluation Board

		- SPEAr1340 (SOC)

			- SPEAr1340 Evaluation Board

  Configuration

  -------------

  A generic configuration is provided for each machine, and can be used as the

  default by

	make spear600_defconfig

	make spear300_defconfig

	make spear310_defconfig

	make spear320_defconfig

	make spear13xx_defconfig

	make spear3xx_defconfig

	make spear6xx_defconfig

  Layout

  ------

  The common files for multiple machine families (SPEAr3XX, SPEAr6XX and

  SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear

  The common files for multiple machine families (SPEAr3xx, SPEAr6xx and

  SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear

  with headers in plat/.

  Each machine series have a directory with name arch/arm/mach-spear followed by

  series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx.

  Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for

  spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine

  specific files, like spear300.c, spear310.c, spear320.c and spear600.c.

  mach-spear* also contains board specific files for each machine type.

  Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for

  spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is

  mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific

  files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and

  spear600.c.  mach-spear* doesn't contains board specific files as they fully

  support Flattened Device Tree.

  Document Author

  ---------------

  Viresh Kumar, (c) 2010 ST Microelectronics

  Viresh Kumar <viresh.kumar@st.com>, (c) 2010-2012 ST Microelectronics

* SPEAr ARM Timer

** Timer node required properties:

- compatible : Should be:

	"st,spear-timer"

- reg: Address range of the timer registers

- interrupt-parent: Should be the phandle for the interrupt controller

  that services interrupts for this device

- interrupt: Should contain the timer interrupt number

Example:

	timer@f0000000 {

		compatible = "st,spear-timer";

		reg = <0xf0000000 0x400>;

		interrupts = <2>;

	};

---------------------------------------

Boards with the ST SPEAr600 SoC shall have the following properties:

Required root node property:

compatible = "st,spear600";

Boards with the ST SPEAr300 SoC shall have the following properties:

Required root node property:

compatible = "st,spear300";

compatible = "st,spear600";

Boards with the ST SPEAr310 SoC shall have the following properties:

Required root node property:

compatible = "st,spear310";

Boards with the ST SPEAr320 SoC shall have the following properties:

Required root node property:

compatible = "st,spear320";

Boards with the ST SPEAr1310 SoC shall have the following properties:

Required root node property:

compatible = "st,spear1310";

Boards with the ST SPEAr1340 SoC shall have the following properties:

Required root node property:

compatible = "st,spear1340";

* Freescale IOMUX Controller (IOMUXC) for i.MX

The IOMUX Controller (IOMUXC), together with the IOMUX, enables the IC

to share one PAD to several functional blocks. The sharing is done by

multiplexing the PAD input/output signals. For each PAD there are up to

8 muxing options (called ALT modes). Since different modules require

different PAD settings (like pull up, keeper, etc) the IOMUXC controls

also the PAD settings parameters.

Please refer to pinctrl-bindings.txt in this directory for details of the

common pinctrl bindings used by client devices, including the meaning of the

phrase "pin configuration node".

Freescale IMX pin configuration node is a node of a group of pins which can be

used for a specific device or function. This node represents both mux and config

of the pins in that group. The 'mux' selects the function mode(also named mux

mode) this pin can work on and the 'config' configures various pad settings

such as pull-up, open drain, drive strength, etc.

Required properties for iomux controller:

- compatible: "fsl,<soc>-iomuxc"

  Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.

Required properties for pin configuration node:

- fsl,pins: two integers array, represents a group of pins mux and config

  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a

  pin working on a specific function, CONFIG is the pad setting value like

  pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid

  pins and functions of each SoC.

Bits used for CONFIG:

NO_PAD_CTL(1 << 31): indicate this pin does not need config.

SION(1 << 30): Software Input On Field.

Force the selected mux mode input path no matter of MUX_MODE functionality.

By default the input path is determined by functionality of the selected

mux mode (regular).

Other bits are used for PAD setting.

Please refer to each fsl,<soc>-pinctrl,txt binding doc for SoC specific part

of bits definitions.

NOTE:

Some requirements for using fsl,imx-pinctrl binding:

1. We have pin function node defined under iomux controller node to represent

   what pinmux functions this SoC supports.

2. The pin configuration node intends to work on a specific function should

   to be defined under that specific function node.

   The function node's name should represent well about what function

   this group of pins in this pin configuration node are working on.

3. The driver can use the function node's name and pin configuration node's

   name describe the pin function and group hierarchy.

   For example, Linux IMX pinctrl driver takes the function node's name

   as the function name and pin configuration node's name as group name to

   create the map table.

4. Each pin configuration node should have a phandle, devices can set pins

   configurations by referring to the phandle of that pin configuration node.

Examples:

usdhc@0219c000 { /* uSDHC4 */

	fsl,card-wired;

	vmmc-supply = <&reg_3p3v>;

	status = "okay";

	pinctrl-names = "default";

	pinctrl-0 = <&pinctrl_usdhc4_1>;

};

iomuxc@020e0000 {

	compatible = "fsl,imx6q-iomuxc";

	reg = <0x020e0000 0x4000>;

	/* shared pinctrl settings */

	usdhc4 {

		pinctrl_usdhc4_1: usdhc4grp-1 {

			fsl,pins = <1386 0x17059	/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */

				    1392 0x10059	/* MX6Q_PAD_SD4_CLK__USDHC4_CLK	*/

				    1462 0x17059	/* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */

				    1470 0x17059	/* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */

				    1478 0x17059	/* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */

				    1486 0x17059	/* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */

				    1493 0x17059	/* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */

				    1501 0x17059	/* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */

				    1509 0x17059	/* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */

				    1517 0x17059>;	/* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */

		};

	};

	....

};

Refer to the IOMUXC controller chapter in imx6q datasheet,

0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed,

80Ohm driver strength and Fast Slew Rate.

User should refer to each SoC spec to set the correct value.

TODO: when dtc macro support is available, we can change above raw data

to dt macro which can get better readability in dts file.