Merge branch 'master' of git://git.denx.de/u-boot-arm

4 files changed, 203 insertions, 4 deletions

diff --git a/doc/README.nand b/doc/README.nand
index b91f1985d1..70cf768d23 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -190,6 +190,24 @@ Configuration Options:
 	This is used by SoC platforms which do not have built-in ELM
 	hardware engine required for BCH ECC correction.
 
+   CONFIG_SYS_NAND_BUSWIDTH_16BIT
+	Indicates that NAND device has 16-bit wide data-bus. In absence of this
+	config, bus-width of NAND device is assumed to be either 8-bit and later
+	determined by reading ONFI params.
+	Above config is useful when NAND device's bus-width information cannot
+	be determined from on-chip ONFI params, like in following scenarios:
+	- SPL boot does not support reading of ONFI parameters. This is done to
+	  keep SPL code foot-print small.
+	- In current U-Boot flow using nand_init(), driver initialization
+	  happens in board_nand_init() which is called before any device probe
+	  (nand_scan_ident + nand_scan_tail), thus device's ONFI parameters are
+	  not available while configuring controller. So a static CONFIG_NAND_xx
+	  is needed to know the device's bus-width in advance.
+	Some drivers using above config are:
+	drivers/mtd/nand/mxc_nand.c
+	drivers/mtd/nand/ndfc.c
+	drivers/mtd/nand/omap_gpmc.c
+
 
 Platform specific options
 =========================
@@ -231,6 +249,48 @@ Platform specific options
 		8-bit BCH code with
 		- ecc calculation using GPMC hardware engine,
 		- error detection using ELM hardware engine.
+	OMAP_ECC_BCH16_CODE_HW
+		16-bit BCH code with
+		- ecc calculation using GPMC hardware engine,
+		- error detection using ELM hardware engine.
+
+	How to select ECC scheme on OMAP and AMxx platforms ?
+	-----------------------------------------------------
+	Though higher ECC schemes have more capability to detect and correct
+	bit-flips, but still selection of ECC scheme is dependent on following
+	- hardware engines present in SoC.
+		Some legacy OMAP SoC do not have ELM h/w engine thus such
+		SoC cannot support BCHx_HW ECC schemes.
+	- size of OOB/Spare region
+		With higher ECC schemes, more OOB/Spare area is required to
+		store ECC. So choice of ECC scheme is limited by NAND oobsize.
+
+	In general following expression can help:
+		NAND_OOBSIZE >= 2 + (NAND_PAGESIZE / 512) * ECC_BYTES
+	where
+		NAND_OOBSIZE	= number of bytes available in
+				OOB/spare area per NAND page.
+		NAND_PAGESIZE	= bytes in main-area of NAND page.
+		ECC_BYTES	= number of ECC bytes generated to
+				protect 512 bytes of data, which is:
+				3 for HAM1_xx ecc schemes
+				7 for BCH4_xx ecc schemes
+				14 for BCH8_xx ecc schemes
+				26 for BCH16_xx ecc schemes
+
+		example to check for BCH16 on 2K page NAND
+		NAND_PAGESIZE = 2048
+		NAND_OOBSIZE = 64
+		2 + (2048 / 512) * 26 = 106 > NAND_OOBSIZE
+		Thus BCH16 cannot be supported on 2K page NAND.
+
+		However, for 4K pagesize NAND
+		NAND_PAGESIZE = 4096
+		NAND_OOBSIZE = 64
+		ECC_BYTES = 26
+		2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE
+		Thus BCH16 can be supported on 4K page NAND.
+
 
 NOTE:
 =====
diff --git a/doc/device-tree-bindings/exynos/dwmmc.txt b/doc/device-tree-bindings/exynos/dwmmc.txt
index 566da3b636..694d195916 100644
--- a/doc/device-tree-bindings/exynos/dwmmc.txt
+++ b/doc/device-tree-bindings/exynos/dwmmc.txt
@@ -1,18 +1,18 @@
-* Exynos 5250 DWC_mobile_storage
+* Exynos DWC_mobile_storage
 
-The Exynos 5250 provides DWC_mobile_storage interface which supports
+The Exynos provides DWC_mobile_storage interface which supports
 . Embedded Multimedia Cards (EMMC-version 4.5)
 . Secure Digital memory (SD mem-version 2.0)
 . Secure Digital I/O (SDIO-version 3.0)
 . Consumer Electronics Advanced Transport Architecture (CE-ATA-version 1.1)
 
-The Exynos 5250 DWC_mobile_storage provides four channels.
+The Exynos DWC_mobile_storage provides four channels.
 SOC specific and Board specific properties are channel specific.
 
 Required SoC Specific Properties:
 
 - compatible: should be
-	- samsung,exynos5250-dwmmc: for exynos5250 platforms
+	- samsung,exynos-dwmmc: for exynos platforms
 
 - reg: physical base address of the controller and length of memory mapped
 	region.
diff --git a/doc/device-tree-bindings/power/tps65090.txt b/doc/device-tree-bindings/power/tps65090.txt
new file mode 100644
index 0000000000..8e5e0d3910
--- /dev/null
+++ b/doc/device-tree-bindings/power/tps65090.txt
@@ -0,0 +1,17 @@
+TPS65090 Frontend PMU with Switchmode Charger
+
+Required Properties:
+-compatible: "ti,tps65090-charger"
+
+Optional Properties:
+-ti,enable-low-current-chrg: Enables charging when a low current is detected
+ while the default logic is to stop charging.
+
+This node is a subnode of the tps65090 PMIC.
+
+Example:
+
+	tps65090-charger {
+		compatible = "ti,tps65090-charger";
+		ti,enable-low-current-chrg;
+	};
diff --git a/doc/device-tree-bindings/regulator/tps65090.txt b/doc/device-tree-bindings/regulator/tps65090.txt
new file mode 100644
index 0000000000..313a60ba61
--- /dev/null
+++ b/doc/device-tree-bindings/regulator/tps65090.txt
@@ -0,0 +1,122 @@
+TPS65090 regulators
+
+Required properties:
+- compatible: "ti,tps65090"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  dcdc[1-3], fet[1-7] and ldo[1-2] respectively.
+- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively.
+- infet[1-7]-supply: The input supply for FET[1-7] respectively.
+- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.
+
+Optional properties:
+- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
+  If DCDCs are externally controlled then this property should be there.
+- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
+  If DCDCs are externally controlled and if it is from GPIO then GPIO
+  number should be provided. If it is externally controlled and no GPIO
+  entry then driver will just configure this rails as external control
+  and will not provide any enable/disable APIs.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+	tps65090@48 {
+		compatible = "ti,tps65090";
+		reg = <0x48>;
+		interrupts = <0 88 0x4>;
+
+		vsys1-supply = <&some_reg>;
+		vsys2-supply = <&some_reg>;
+		vsys3-supply = <&some_reg>;
+		infet1-supply = <&some_reg>;
+		infet2-supply = <&some_reg>;
+		infet3-supply = <&some_reg>;
+		infet4-supply = <&some_reg>;
+		infet5-supply = <&some_reg>;
+		infet6-supply = <&some_reg>;
+		infet7-supply = <&some_reg>;
+		vsys_l1-supply = <&some_reg>;
+		vsys_l2-supply = <&some_reg>;
+
+		regulators {
+			dcdc1 {
+				regulator-name = "dcdc1";
+				regulator-boot-on;
+				regulator-always-on;
+				ti,enable-ext-control;
+				dcdc-ext-control-gpios = <&gpio 10 0>;
+			};
+
+			dcdc2 {
+				regulator-name = "dcdc2";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			dcdc3 {
+				regulator-name = "dcdc3";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet1 {
+				regulator-name = "fet1";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet2 {
+				regulator-name = "fet2";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet3 {
+				regulator-name = "fet3";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet4 {
+				regulator-name = "fet4";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet5 {
+				regulator-name = "fet5";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet6 {
+				regulator-name = "fet6";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			fet7 {
+				regulator-name = "fet7";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo1 {
+				regulator-name = "ldo1";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo2 {
+				regulator-name = "ldo2";
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};