From 7d3ca0f89dfa4fc7bef738acdb95e632e284421d Mon Sep 17 00:00:00 2001 From: Jaehoon Chung Date: Fri, 16 May 2014 13:59:51 +0900 Subject: ARM: dts: exynos: rename from EXYNOS5_DWMMC to EXYNOS_DWMMC Exynos serise can be supported the dw-mmc controller. So, it's good that used the general prefix as "_EXYNOS_DWMMC". Signed-off-by: Jaehoon Chung Signed-off-by: Minkyu Kang --- doc/device-tree-bindings/exynos/dwmmc.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') 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. -- cgit v1.2.1 From ac1058fdb72b8a6dade7c81be31b22760099ee91 Mon Sep 17 00:00:00 2001 From: Tom Wai-Hong Tam Date: Tue, 20 May 2014 06:01:36 -0600 Subject: power: Add support for TPS65090 PMU chip. This adds driver support for the TPS65090 PMU. Support includes hooking into the pmic infrastructure so that the pmic commands can be used on the console. The TPS65090 supports the following functionality: - fet enable/disable/querying - getting and setting of charge state Even though it is connected to the pmic infrastructure it does not hook into the pmic charging charging infrastructure. The device tree binding is from Linux, but only a small subset of functionality is supported. Signed-off-by: Tom Wai-Hong Tam Signed-off-by: Hatim Ali Signed-off-by: Katie Roberts-Hoffman Signed-off-by: Rong Chang Signed-off-by: Sean Paul Signed-off-by: Vincent Palatin Signed-off-by: Aaron Durbin Signed-off-by: Simon Glass Signed-off-by: Minkyu Kang --- doc/device-tree-bindings/power/tps65090.txt | 17 ++++ doc/device-tree-bindings/regulator/tps65090.txt | 122 ++++++++++++++++++++++++ 2 files changed, 139 insertions(+) create mode 100644 doc/device-tree-bindings/power/tps65090.txt create mode 100644 doc/device-tree-bindings/regulator/tps65090.txt (limited to 'doc') 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; + }; + }; + }; -- cgit v1.2.1 From b80a66033856cc89c62886ae3e5ba54a7faf31ae Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Tue, 6 May 2014 00:46:19 +0530 Subject: mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization. Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working. This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals. Signed-off-by: Pekon Gupta --- doc/README.nand | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'doc') diff --git a/doc/README.nand b/doc/README.nand index b91f1985d1..2bc5b391f8 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 ========================= -- cgit v1.2.1 From 867f03040f771a95323925b569eaf3b911b9eb14 Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Mon, 2 Jun 2014 17:14:43 +0530 Subject: am335x: update README for BCH16 updates documentation with explanation on how to select ECC schemes. Signed-off-by: Pekon Gupta --- doc/README.nand | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'doc') diff --git a/doc/README.nand b/doc/README.nand index 2bc5b391f8..70cf768d23 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -249,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: ===== -- cgit v1.2.1