[PATCH v6 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)

[PATCH v6 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)

[Pekon Gupta]

*changes v5 -> v6*
- removed explicit disabling of GPMC and ELM in am335x-bone-memorycape.dts
  as both modules are already disabled by default in am33xx.dtsi
- fixed comments for <range> and <reg> properties. keeping it consistent
  across platforms.
- fixed <reg size> property. Using 'exact' register space as in hardware.
- fixed DT properties for wait-pin monitoring. Added gpmc,wait-pin = <>
- using lower-case letter for hex digits
Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :omap-for-v3.16/dt


*changes v4 -> v5*
use lower-case hexadecimal numbers
add comments for using different memory sizes in <range> and <reg> properties
fix 'reg size' property for GPMC and ELM nodes in dra7.dtsi


*changes v3 -> v4*
fixed <reg> and <range> property for all GPMC DT nodes
added fix for am335x-evm and am437x-epos-evm
rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap +omap-for-v3.16/dt


*changes v2 -> v3*
rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master
merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series


*changes v1 -> v2*
[PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks
  http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon <nm@ti.com>'
  http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren <tony@atomide.com>'
[PATCH v2 2/2] <same as [PATCH v1 1/3]>


*original v1*
This patch-set adds parallel NAND support on following TI platforms
 - AM335x (am335x-bone LT, am335x-boneblack): <disabled by default>
 - AM43xx (am437x-gp-evm)


Minal Shah (1):
  ARM: dts: dra7: add support for parallel NAND flash

Pekon Gupta (3):
  ARM: dts: am335x-bone: add support for beaglebone NAND cape
  ARM: dts: am437x-gp-evm: add support for parallel NAND flash
  ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition

 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts             |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts           | 108 ++++++++++++++++++++++
 arch/arm/boot/dts/am43x-epos-evm.dts          |   2 +-
 arch/arm/boot/dts/dra7-evm.dts                | 118 ++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi                   |  20 +++++
 7 files changed, 372 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

-- 
1.8.5.1.163.gd7aced9

[PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Pekon Gupta]

Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]

* How to boot from NAND using Memory Expander + NAND Cape ? *
 - Important: As BOOTSEL values are sampled only at POR, so after changing any
   setting on SW2 (DIP switch), disconnect and reconnect all board power supply
   (including mini-USB console port) to POR the beaglebone.

 - Selection of ECC scheme
  for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
  for NAND cape(b), ROM code expects BCH16_HW ecc-scheme

 - Selection of boot modes can be controlled via  DIP switch(SW2) present on
   Memory Expander cape, so first boot via MMC or other sources to flash NAND
   device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
   SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC-> SPI -> UART -> USB
   SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)

 - For NAND boot following switch settings need to be followed
   SW2[ 0] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
   SW2[ 1] = ON   (SYSBOOT[ 1]==0:       -- do --          )
   SW2[ 2] = OFF  (SYSBOOT[ 2]==1:       -- do --          )
   SW2[ 3] = OFF  (SYSBOOT[ 3]==1:       -- do --          )
   SW2[ 4] = ON   (SYSBOOT[ 4]==0:       -- do --          )
   SW2[ 8] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
   SW2[ 9] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
   SW2[10] = ON   (SYSBOOT[10]==0: Non Muxed device )
   SW2[11] = ON   (SYSBOOT[11]==0:    -- do --      )

[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts             |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
 3 files changed, 125 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 0000000..f9940bc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+	nand_flash_x16: nand_flash_x16 {
+		pinctrl-single,pins = <
+			0x00 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad0.gpmc_ad0 */
+			0x04 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad1.gpmc_ad1 */
+			0x08 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad2.gpmc_ad2 */
+			0x0c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad3.gpmc_ad3 */
+			0x10 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad4.gpmc_ad4 */
+			0x14 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad5.gpmc_ad5 */
+			0x18 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad6.gpmc_ad6 */
+			0x1c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad7.gpmc_ad7 */
+			0x20 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad8.gpmc_ad8 */
+			0x24 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad9.gpmc_ad9 */
+			0x28 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad10.gpmc_ad10 */
+			0x2c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad11.gpmc_ad11 */
+			0x30 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad12.gpmc_ad12 */
+			0x34 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad13.gpmc_ad13 */
+			0x38 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad14.gpmc_ad14 */
+			0x3c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad15.gpmc_ad15 */
+			0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )	/* gpmc_wait0.gpmc_wait0 */
+			0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)	/* gpmc_wpn.gpio0_30 */
+			0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)	/* gpmc_csn0.gpmc_csn0  */
+			0x90 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_advn_ale.gpmc_advn_ale */
+			0x94 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_oen_ren.gpmc_oen_ren */
+			0x98 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_wen.gpmc_wen */
+			0x9c (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_be0n_cle.gpmc_be0n_cle */
+		>;
+	};
+};
+
+&gpmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 0x37c>;	/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <16>;
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <80>;
+		gpmc,cs-wr-off-ns = <80>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <80>;
+		gpmc,adv-wr-off-ns = <80>;
+		gpmc,we-on-ns = <20>;
+		gpmc,we-off-ns = <60>;
+		gpmc,oe-on-ns = <20>;
+		gpmc,oe-off-ns = <60>;
+		gpmc,access-ns = <40>;
+		gpmc,rd-cycle-ns = <80>;
+		gpmc,wr-cycle-ns = <80>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x1f600000>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..f16bfcf 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..c030b24 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@
 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
-- 
1.8.5.1.163.gd7aced9

[PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Pekon Gupta]

Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
    eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
    (a) By dynamically driving following GPIO pin from software
        SPI2_CS0(GPIO) == 0 NAND is selected (default)
        SPI2_CS0(GPIO) == 1 eMMC is selected
    (b) By statically using Jumper (J89) on the board

(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
    So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
    NAND boot.

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..97b71e6 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
 			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
 		>;
 	};
+
+	nand_flash_x8: nand_flash_x8 {
+		pinctrl-single,pins = <
+			0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* spi2_cs0.gpio/eMMCorNANDsel */
+			0x0  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0.gpmc_ad0 */
+			0x4  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1.gpmc_ad1 */
+			0x8  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2.gpmc_ad2 */
+			0xc  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3.gpmc_ad3 */
+			0x10 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4.gpmc_ad4 */
+			0x14 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5.gpmc_ad5 */
+			0x18 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6.gpmc_ad6 */
+			0x1c (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7.gpmc_ad7 */
+			0x70 (PIN_INPUT_PULLUP | MUX_MODE0)	/* gpmc_wait0.gpmc_wait0 */
+			0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* gpmc_wpn.gpmc_wpn */
+			0x7c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_csn0.gpmc_csn0  */
+			0x90 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_advn_ale.gpmc_advn_ale */
+			0x94 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_oen_ren.gpmc_oen_ren */
+			0x98 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_wen.gpmc_wen */
+			0x9c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_be0n_cle.gpmc_be0n_cle */
+		>;
+	};
 };
 
 &i2c0 {
@@ -246,3 +267,90 @@
 	phy_id = <&davinci_mdio>, <0>;
 	phy-mode = "rgmii";
 };
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x8>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 0x37c>;	/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <8>;
+		gpmc,device-width = <1>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <40>;
+		gpmc,cs-wr-off-ns = <40>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <25>;
+		gpmc,adv-wr-off-ns = <25>;
+		gpmc,we-on-ns = <0>;
+		gpmc,we-off-ns = <20>;
+		gpmc,oe-on-ns = <3>;
+		gpmc,oe-off-ns = <30>;
+		gpmc,access-ns = <30>;
+		gpmc,rd-cycle-ns = <40>;
+		gpmc,wr-cycle-ns = <40>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x1f600000>;
+		};
+	};
+};
-- 
1.8.5.1.163.gd7aced9

[PATCH v6 3/4] ARM: dts: dra7: add support for parallel NAND flash

[Pekon Gupta]

From: Minal Shah <minalkshah@gmail.com>

DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
	On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
	So following board settings are required for NAND device detection:
	SW5.9 (GPMC_WPN) = LOW
	SW5.1 (NAND_BOOTn) = HIGH

Signed-off-by: Minal Shah <minalkshah@gmail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/dra7-evm.dts | 118 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi    |  20 +++++++
 2 files changed, 138 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ec77907..e624c17 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -120,6 +120,37 @@
 			0x284 (PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
                 >;
         };
+
+	nand_flash_x16: nand_flash_x16 {
+		/* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+		 * So NAND flash requires following switch settings:
+		 * SW5.9 (GPMC_WPN) = LOW
+		 * SW5.1 (NAND_BOOTn) = HIGH */
+		pinctrl-single,pins = <
+			0x0 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0	*/
+			0x4 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1	*/
+			0x8 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2	*/
+			0xc 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3	*/
+			0x10	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4	*/
+			0x14	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5	*/
+			0x18	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6	*/
+			0x1c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7	*/
+			0x20	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad8	*/
+			0x24	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad9	*/
+			0x28	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad10	*/
+			0x2c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad11	*/
+			0x30	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad12	*/
+			0x34	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad13	*/
+			0x38	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad14	*/
+			0x3c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad15	*/
+			0xd8	(PIN_INPUT_PULLUP  | MUX_MODE0)	/* gpmc_wait0	*/
+			0xcc	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_wen	*/
+			0xb4	(PIN_OUTPUT_PULLUP | MUX_MODE0)	/* gpmc_csn0	*/
+			0xc4	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_advn_ale */
+			0xc8	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_oen_ren	 */
+			0xd0	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_be0n_cle */
+		>;
+	};
 };
 
 &i2c1 {
@@ -377,3 +408,90 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&usb2_pins>;
 };
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 0x37c>;	/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <16>;
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <40>;
+		gpmc,cs-wr-off-ns = <40>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <30>;
+		gpmc,adv-wr-off-ns = <30>;
+		gpmc,we-on-ns = <5>;
+		gpmc,we-off-ns = <25>;
+		gpmc,oe-on-ns = <2>;
+		gpmc,oe-off-ns = <20>;
+		gpmc,access-ns = <20>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,rd-cycle-ns = <40>;
+		gpmc,wr-cycle-ns = <40>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x000020000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00020000 0x00020000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00040000 0x00020000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x00060000 0x00020000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x000c0000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x001c0000 0x00020000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env";
+			reg = <0x001e0000 0x00020000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00200000 0x00800000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x0f600000>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 6af8b08..a8a0cee 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -964,6 +964,26 @@
 				dr_mode = "otg";
 			};
 		};
+
+		elm: elm@48078000 {
+			compatible = "ti,am3352-elm";
+			reg = <0x48078000 0xfc0>;      /* device IO registers */
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			ti,hwmods = "elm";
+			status = "disabled";
+		};
+
+		gpmc: gpmc@50000000 {
+			compatible = "ti,am3352-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x50000000 0x37c>;      /* device IO registers */
+			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+			gpmc,num-cs = <8>;
+			gpmc,num-waitpins = <2>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.5.1.163.gd7aced9

[PATCH v6 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition

[Pekon Gupta]

MTD NAND partition for file-system should start at offset=0xA00000

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 2a0fbbb..ad362c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -366,7 +366,7 @@
 		};
 		partition@9 {
 			label = "NAND.file-system";
-			reg = <0x00800000 0x1F600000>;
+			reg = <0x00a00000 0x1f600000>;
 		};
 	};
 };
-- 
1.8.5.1.163.gd7aced9

Re: [PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Ezequiel Garcia]

Hello Pekon,

On 16 May 04:33 PM, Pekon Gupta wrote:
[..]
> +		gpmc,wait-pin = <0>;
> +		gpmc,wait-on-read;
> +		gpmc,wait-on-write;

Thanks for adding the wait-pin property. I think the other boards also
needs this change. Javier, do you have a IGEP Aquila with NAND to try?

Pekon, have you noticed that there's no devicetree property to enable
ready/busy? In other words, the NAND driver dev_ready field will never
be true when probed from DT.

-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Roger Quadros]

Hi Pekon,

On 05/16/2014 02:03 PM, Pekon Gupta wrote:
> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> am437x-gp-evm board.
> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>     (a) By dynamically driving following GPIO pin from software
>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
>         SPI2_CS0(GPIO) == 1 eMMC is selected
>     (b) By statically using Jumper (J89) on the board
> 
> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
>     So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
>     NAND boot.
> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
>  arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 30ace1b..97b71e6 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -150,6 +150,27 @@
>  			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>  		>;
>  	};
> +
> +	nand_flash_x8: nand_flash_x8 {
> +		pinctrl-single,pins = <
> +			0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* spi2_cs0.gpio/eMMCorNANDsel */
> +			0x0  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0.gpmc_ad0 */
> +			0x4  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1.gpmc_ad1 */
> +			0x8  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2.gpmc_ad2 */
> +			0xc  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3.gpmc_ad3 */
> +			0x10 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4.gpmc_ad4 */
> +			0x14 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5.gpmc_ad5 */
> +			0x18 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6.gpmc_ad6 */
> +			0x1c (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7.gpmc_ad7 */
> +			0x70 (PIN_INPUT_PULLUP | MUX_MODE0)	/* gpmc_wait0.gpmc_wait0 */
> +			0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* gpmc_wpn.gpmc_wpn */
> +			0x7c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_csn0.gpmc_csn0  */
> +			0x90 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_advn_ale.gpmc_advn_ale */
> +			0x94 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_oen_ren.gpmc_oen_ren */
> +			0x98 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_wen.gpmc_wen */
> +			0x9c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_be0n_cle.gpmc_be0n_cle */
> +		>;
> +	};
>  };
>  
>  &i2c0 {
> @@ -246,3 +267,90 @@
>  	phy_id = <&davinci_mdio>, <0>;
>  	phy-mode = "rgmii";
>  };
> +
> +&elm {
> +	status = "okay";
> +};
> +
> +&gpmc {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&nand_flash_x8>;
> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
> +	nand@0,0 {
> +		reg = <0 0 0x37c>;	/* device IO registers */

This register space is used by the parent GPMC node as well as the NAND controller. So doing a request_and_ioremap() on this space will fail as it is already taken by the GPMC driver. 

Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)

We could have split the GPMC register space into GPMC part and NAND part but to add to the complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up. The way the NAND driver is currently written is that it expects the register addresses to come via platform data, primarily to get around this address interleaving issue. 

Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for I/O, and that is something that could be reflected here.

e.g.
		reg = <0 0 4>;		/* NAND I/O space */

But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still unclear to me how that can be done.

cheers,
-roger

> +		ti,nand-ecc-opt = "bch8";
> +		ti,elm-id = <&elm>;
> +		nand-bus-width = <8>;
> +		gpmc,device-width = <1>;
> +		gpmc,sync-clk-ps = <0>;
> +		gpmc,cs-on-ns = <0>;
> +		gpmc,cs-rd-off-ns = <40>;
> +		gpmc,cs-wr-off-ns = <40>;
> +		gpmc,adv-on-ns = <0>;
> +		gpmc,adv-rd-off-ns = <25>;
> +		gpmc,adv-wr-off-ns = <25>;
> +		gpmc,we-on-ns = <0>;
> +		gpmc,we-off-ns = <20>;
> +		gpmc,oe-on-ns = <3>;
> +		gpmc,oe-off-ns = <30>;
> +		gpmc,access-ns = <30>;
> +		gpmc,rd-cycle-ns = <40>;
> +		gpmc,wr-cycle-ns = <40>;
> +		gpmc,wait-pin = <0>;
> +		gpmc,wait-on-read;
> +		gpmc,wait-on-write;
> +		gpmc,bus-turnaround-ns = <0>;
> +		gpmc,cycle2cycle-delay-ns = <0>;
> +		gpmc,clk-activation-ns = <0>;
> +		gpmc,wait-monitoring-ns = <0>;
> +		gpmc,wr-access-ns = <40>;
> +		gpmc,wr-data-mux-bus-ns = <0>;
> +		/* MTD partition table */
> +		/* All SPL-* partitions are sized to minimal length
> +		 * which can be independently programmable. For
> +		 * NAND flash this is equal to size of erase-block */
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		partition@0 {
> +			label = "NAND.SPL";
> +			reg = <0x00000000 0x00040000>;
> +		};
> +		partition@1 {
> +			label = "NAND.SPL.backup1";
> +			reg = <0x00040000 0x00040000>;
> +		};
> +		partition@2 {
> +			label = "NAND.SPL.backup2";
> +			reg = <0x00080000 0x00040000>;
> +		};
> +		partition@3 {
> +			label = "NAND.SPL.backup3";
> +			reg = <0x000c0000 0x00040000>;
> +		};
> +		partition@4 {
> +			label = "NAND.u-boot-spl-os";
> +			reg = <0x00100000 0x00080000>;
> +		};
> +		partition@5 {
> +			label = "NAND.u-boot";
> +			reg = <0x00180000 0x00100000>;
> +		};
> +		partition@6 {
> +			label = "NAND.u-boot-env";
> +			reg = <0x00280000 0x00040000>;
> +		};
> +		partition@7 {
> +			label = "NAND.u-boot-env.backup1";
> +			reg = <0x002c0000 0x00040000>;
> +		};
> +		partition@8 {
> +			label = "NAND.kernel";
> +			reg = <0x00300000 0x00700000>;
> +		};
> +		partition@9 {
> +			label = "NAND.file-system";
> +			reg = <0x00a00000 0x1f600000>;
> +		};
> +	};
> +};
> 

RE: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Gupta, Pekon]

Hi Roger,

>From: Quadros, Roger
>
[...]
>> +&gpmc {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&nand_flash_x8>;
>> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>> +	nand@0,0 {
>> +		reg = <0 0 0x37c>;	/* device IO registers */
>
>This register space is used by the parent GPMC node as well as the NAND controller. So doing a
>request_and_ioremap() on this space will fail as it is already taken by the GPMC driver.
>
>Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select
>but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
>
>We could have split the GPMC register space into GPMC part and NAND part but to add to the
>complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up.
Sorry I din't get this part.
NAND is one of the devices supported by GPMC controller.
Hardware wise the it's the same engine is used for NAND, NOR and OneNAND
and even other parallel interfaces like Camera, Ethernet, etc..
So how can be NAND and GPMC registers space be splitted ?

I see gpmc.c as generic controller driver, which just does initializations
and registering the device. Then it's upto the individual protocol drivers
to probe the device and attach it to respective sub-system; like;
(a) drivers/mtd/nand/omap2.c  for NAND
(b) drivers/mtd/chips/cfi_probe.c  for NOR
...


> The way
>the NAND driver is currently written is that it expects the register addresses to come via platform data,
>primarily to get around this address interleaving issue.
>
Yes, that is right.
I don't know the historical reasons but that is correct also because,
(1) large set of GPMC register configurations are common across all
 types of devices (like NAND, NOR, OneNAND, Ethernet). These
 register configurations define the signal timings and physical attributes
 of device (like device width, etc).

(2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
 for transferring data, much of which is based on type of protocol.
 
So, large part of GPMC configurations remains static and can be
Shared across all types of devices, hence those are put in gpmc.c


>Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for I/O,
>and that is something that could be reflected here.
>
>e.g.
>		reg = <0 0 4>;		/* NAND I/O space */
>
>But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still
>unclear to me how that can be done.
>
Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
But where to map these 4 bytes ? and which 4-bytes to map.
So I have included complete GPMC register space-size.

Also since GPMC has a constrain that every chip-select must have
minimum of 16MB memory. So we specify it via  <range> property
to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..

If you have any better approach in mind for keeping consistent
memory mapping across different types of devices, then please suggest ..
I'll try to get this done in next set of patches, if not these.
Or
May be you can take over as part of GPMC transition.

>cheers,
>-roger
>

with regards, pekon

RE: [PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

Hi Ezequiel,

>From: Ezequiel Garcia [mailto:ezequiel@vanguardiasur.com.ar]
>
>Hello Pekon,
>
>On 16 May 04:33 PM, Pekon Gupta wrote:
>[..]
>> +		gpmc,wait-pin = <0>;
>> +		gpmc,wait-on-read;
>> +		gpmc,wait-on-write;
>
>Thanks for adding the wait-pin property. I think the other boards also
>needs this change. Javier, do you have a IGEP Aquila with NAND to try?
>
>Pekon, have you noticed that there's no devicetree property to enable
>ready/busy? In other words, the NAND driver dev_ready field will never
>be true when probed from DT.
>
Yes, that is know, therefore I din't reply to your earlier email.
I was just fixing your DT comments and have a small patch to set
dev_ready=true. I'll send it soon.

But still you need to consider that nand/omap2.c driver only supports
polling way of monitoring READY/BUSY pin. That is instead of polling
for status-bit | waiting for predefined delay, NAND driver now polls
for READY/BUSY pin.
However, actual benefit of wait-pin monitoring might be visible when
READY/BUSY pin is used with interrupt.


with regards, pekon

Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Roger Quadros]

On 05/16/2014 04:58 PM, Gupta, Pekon wrote:
> Hi Roger,
> 
>> From: Quadros, Roger
>>
> [...]
>>> +&gpmc {
>>> +	status = "okay";
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&nand_flash_x8>;
>>> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>>> +	nand@0,0 {
>>> +		reg = <0 0 0x37c>;	/* device IO registers */
>>
>> This register space is used by the parent GPMC node as well as the NAND controller. So doing a
>> request_and_ioremap() on this space will fail as it is already taken by the GPMC driver.
>>
>> Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select
>> but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
>>
>> We could have split the GPMC register space into GPMC part and NAND part but to add to the
>> complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up.
> Sorry I din't get this part.
> NAND is one of the devices supported by GPMC controller.
> Hardware wise the it's the same engine is used for NAND, NOR and OneNAND

But GPMC register space is only used for 2 things, Chip Select configuration and NAND driver.

GPMC registers are not used for NOR, OneNAND or other memory accessible devices. They don't need GPMC registers because their registers are mapped in the GPMC I/O space.

> and even other parallel interfaces like Camera, Ethernet, etc..
> So how can be NAND and GPMC registers space be splitted ?

- all Chip select configuration registers i.e. GPMC_CONFIG* should go to GPMC device
- all the GPMC_NAND_*, GPMC_ECC_, and GPMC_BCH_* registers go to NAND device

The tricky part is that all these registers are interleaved among each other and so the register map is fragmented.

> 
> I see gpmc.c as generic controller driver, which just does initializations
> and registering the device. Then it's upto the individual protocol drivers
> to probe the device and attach it to respective sub-system; like;
> (a) drivers/mtd/nand/omap2.c  for NAND
> (b) drivers/mtd/chips/cfi_probe.c  for NOR
> ...

omap2.c needs GPMC registers, but cfi_probe.c and others don't need them.

> 
> 
>> The way
>> the NAND driver is currently written is that it expects the register addresses to come via platform data,
>> primarily to get around this address interleaving issue.
>>
> Yes, that is right.
> I don't know the historical reasons but that is correct also because,
> (1) large set of GPMC register configurations are common across all
>  types of devices (like NAND, NOR, OneNAND, Ethernet). These
>  register configurations define the signal timings and physical attributes
>  of device (like device width, etc).
> 
> (2) Individual protocol drivers (a) and (b) only uses a sub-set of registers
>  for transferring data, much of which is based on type of protocol.
>  
> So, large part of GPMC configurations remains static and can be
> Shared across all types of devices, hence those are put in gpmc.c

Right, so just the GPMC configuration part needs to be with GPMC driver. The NAND controller bits don't need to be.

> 
> 
>> Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for I/O,
>> and that is something that could be reflected here.
>>
>> e.g.
>> 		reg = <0 0 4>;		/* NAND I/O space */
>>
>> But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still
>> unclear to me how that can be done.
>>
> Yes, NAND is not directly mapped. So only 4-bytes of I/O size will do.
> But where to map these 4 bytes ? and which 4-bytes to map.
> So I have included complete GPMC register space-size.

That is not the right solution. The mapping is done in the gpmc driver in gpmc_cs_request()/gpmc_cs_remap().
If a random address (meeting GPMC alignment needs) is specified within the GPMC 1GB space, the GPMC driver should configure the CS to map
to that address. If 0 is specified then the GPMC must map it automatically to a sane address and then update the reg property before instantiating the child node's platform device.

For the NAND controller, we don't even create a child device based on the OF node but instead legacy platform device, so this reg property isn't being even used.

> 
> Also since GPMC has a constrain that every chip-select must have
> minimum of 16MB memory. So we specify it via  <range> property
> to keep GPMC mapping consistent across all NAND, NOR, OneNAND, etc..
> 
> If you have any better approach in mind for keeping consistent
> memory mapping across different types of devices, then please suggest ..
> I'll try to get this done in next set of patches, if not these.
> Or
> May be you can take over as part of GPMC transition.

As the driver doesn't rely on the reg address portion (at least for the NAND driver), you can leave this option out for now.

cheers,
-roger

Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [140516 05:23]:
> On 05/16/2014 02:03 PM, Pekon Gupta wrote:
> > +&gpmc {
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&nand_flash_x8>;
> > +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
> > +	nand@0,0 {
> > +		reg = <0 0 0x37c>;	/* device IO registers */
> 
> This register space is used by the parent GPMC node as well as the NAND controller. So doing a request_and_ioremap() on this space will fail as it is already taken by the GPMC driver. 
> 
> Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
> 
> We could have split the GPMC register space into GPMC part and NAND part but to add to the complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up. The way the NAND driver is currently written is that it expects the register addresses to come via platform data, primarily to get around this address interleaving issue. 
> 
> Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for I/O, and that is something that could be reflected here.
> 
> e.g.
> 		reg = <0 0 4>;		/* NAND I/O space */

Guys, the reg size here is size of the IO region for the
NAND driver, it should not have anything to do with the GPMC
registers for the GPMC functions that the NAND driver may call.

So it sounds like 0x37c is wrong, and 4 is the right value if
the NAND chip has only one IO register.
 
> But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still unclear to me how that can be done.

If the offset for the NAND driver needs to be different from 0,
it can be in the offset. For example, the smsc,lan91c94 driver
wants the IO address space to be at offset 0x300 to avoid some
extra warnings during the boot. So for that, the reg entry is:

reg = <1 0x300 0xf>;

Where we have:

1 = chip select
0x300 = offset of smsc device register IO space from the start of
        16MB minimum GPMC partition
0xf = size of smsc device register IO space that the Ethernet
      driver ioremaps

Regards,

Tony

Re: [PATCH v6 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Javier Martinez Canillas]

Hello Ezequiel,

On Fri, May 16, 2014 at 1:57 PM, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> Hello Pekon,
>
> On 16 May 04:33 PM, Pekon Gupta wrote:
> [..]
>> +             gpmc,wait-pin = <0>;
>> +             gpmc,wait-on-read;
>> +             gpmc,wait-on-write;
>
> Thanks for adding the wait-pin property. I think the other boards also
> needs this change. Javier, do you have a IGEP Aquila with NAND to try?
>

I do have an IGEP aquila with NAND so I can give it a try. I won't be
able to do this until Monday though. Hopefully by then Pekon would
have already sent his patch to set dev_ready=true.

Do you have any specific thing you want me to test? or just a nandtest run?

> Pekon, have you noticed that there's no devicetree property to enable
> ready/busy? In other words, the NAND driver dev_ready field will never
> be true when probed from DT.
>
> --
> Ezequiel Garcia, VanguardiaSur
> www.vanguardiasur.com.ar

Best regards,
Javier

RE: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Gupta, Pekon]

Hi Tony, Roger,

>From: Tony Lindgren [mailto:tony@atomide.com]
>
>* Roger Quadros <rogerq@ti.com> [140516 05:23]:
>> On 05/16/2014 02:03 PM, Pekon Gupta wrote:
>> > +&gpmc {
>> > +	status = "okay";
>> > +	pinctrl-names = "default";
>> > +	pinctrl-0 = <&nand_flash_x8>;
>> > +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>> > +	nand@0,0 {
>> > +		reg = <0 0 0x37c>;	/* device IO registers */
>>
>> This register space is used by the parent GPMC node as well as the NAND controller. So doing a
>request_and_ioremap() on this space will fail as it is already taken by the GPMC driver.
>>
>> Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select
>but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
>>
>> We could have split the GPMC register space into GPMC part and NAND part but to add to the
>complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up. The way
>the NAND driver is currently written is that it expects the register addresses to come via platform data,
>primarily to get around this address interleaving issue.
>>
>> Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for
>I/O, and that is something that could be reflected here.
>>
>> e.g.
>> 		reg = <0 0 4>;		/* NAND I/O space */
>
>Guys, the reg size here is size of the IO region for the
>NAND driver, it should not have anything to do with the GPMC
>registers for the GPMC functions that the NAND driver may call.
>
>So it sounds like 0x37c is wrong, and 4 is the right value if
>the NAND chip has only one IO register.
>
Yes, Roger and myself both agree on the actual size of 4.
But what I'm not sure is what should be offset for a io-remapped region.

Apologies for my ignorance here, as I'm not good in this memory mapping concept..
-  I understand that for 'memory mapped' device <offset> is with respect to
   base-address of chip-select.
- But for indirectly mapped device (like NAND) how is  <offset> calculated?

Example: For CS0 in GPMC ..
GPMC_NAND_COMMAND_0 = 0x007c
GPMC_NAND_ADDRESS_0 = 0x0080
GPMC_NAND_DATA_0 = 0x0084

(1) Now, should the 'offset' for <reg> property used for NAND node
   connected at CS=0.  reg = <0 ??  4>
   (a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
   OR
   (b) There is no relation between 'GPMC register' and 'NAND partition' offset?

(2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
   or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?

This is why I used the size of complete GPMC register space for NAND region also.


>> But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still
>unclear to me how that can be done.
>
>If the offset for the NAND driver needs to be different from 0,
>it can be in the offset. For example, the smsc,lan91c94 driver
>wants the IO address space to be at offset 0x300 to avoid some
>extra warnings during the boot. So for that, the reg entry is:
>
>reg = <1 0x300 0xf>;
>
>Where we have:
>
>1 = chip select
>0x300 = offset of smsc device register IO space from the start of
>        16MB minimum GPMC partition

This is where my confusion lies, where is the 0x300 coming from?
Is this the offset of I/O register in given Ethernet IP register space?

>0xf = size of smsc device register IO space that the Ethernet
>      driver ioremaps
>


with regards, pekon

Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Roger Quadros]

Pekon,

On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
> Hi Tony, Roger,
> 
>> From: Tony Lindgren [mailto:tony@atomide.com]
>>
>> * Roger Quadros <rogerq@ti.com> [140516 05:23]:
>>> On 05/16/2014 02:03 PM, Pekon Gupta wrote:
>>>> +&gpmc {
>>>> +	status = "okay";
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&nand_flash_x8>;
>>>> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>>>> +	nand@0,0 {
>>>> +		reg = <0 0 0x37c>;	/* device IO registers */
>>>
>>> This register space is used by the parent GPMC node as well as the NAND controller. So doing a
>> request_and_ioremap() on this space will fail as it is already taken by the GPMC driver.
>>>
>>> Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select
>> but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
>>>
>>> We could have split the GPMC register space into GPMC part and NAND part but to add to the
>> complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up. The way
>> the NAND driver is currently written is that it expects the register addresses to come via platform data,
>> primarily to get around this address interleaving issue.
>>>
>>> Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for
>> I/O, and that is something that could be reflected here.
>>>
>>> e.g.
>>> 		reg = <0 0 4>;		/* NAND I/O space */
>>
>> Guys, the reg size here is size of the IO region for the
>> NAND driver, it should not have anything to do with the GPMC
>> registers for the GPMC functions that the NAND driver may call.
>>
>> So it sounds like 0x37c is wrong, and 4 is the right value if
>> the NAND chip has only one IO register.
>>
> Yes, Roger and myself both agree on the actual size of 4.
> But what I'm not sure is what should be offset for a io-remapped region.
> 
> Apologies for my ignorance here, as I'm not good in this memory mapping concept..
> -  I understand that for 'memory mapped' device <offset> is with respect to
>    base-address of chip-select.
> - But for indirectly mapped device (like NAND) how is  <offset> calculated?

This would depend on what the NAND driver expects. In the current OMAP nand driver it expects only the memory mapped NAND I/O resource. > 
> Example: For CS0 in GPMC ..
> GPMC_NAND_COMMAND_0 = 0x007c
> GPMC_NAND_ADDRESS_0 = 0x0080
> GPMC_NAND_DATA_0 = 0x0084

OK, let's say that we want to update that NAND driver to accept a second memory resource which would be the GPMC registers starting from GPMC_NAND_COMMAND_0 (phy.addr 0x6e00 007c), then we need to define a new address in the ranges property of the gpmc node. 

Something like so

	ranges = <0 0 0x00000000 0x01000000	/* GPMC external map */
		  1 0 0x6e000000 0x0000037c>;	/* GPMC register map */
	nand@0,0 {
		reg = <0 0 4		/* NAND I/O space */
		       1 0x7c 3> 	/* NAND controller registers */

Since range 1 started from 0x6e000000 we specify offset as 0x7c.

But at the moment the NAND driver doesn't directly access the GPMC register map so it should be sufficient to just specify the I/O space.

> 
> (1) Now, should the 'offset' for <reg> property used for NAND node
>    connected at CS=0.  reg = <0 ??  4>
>    (a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
>    OR
>    (b) There is no relation between 'GPMC register' and 'NAND partition' offset?
> 
> (2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
>    or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
> 
> This is why I used the size of complete GPMC register space for NAND region also.
> 
> 
>>> But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still
>> unclear to me how that can be done.
>>
>> If the offset for the NAND driver needs to be different from 0,
>> it can be in the offset. For example, the smsc,lan91c94 driver
>> wants the IO address space to be at offset 0x300 to avoid some
>> extra warnings during the boot. So for that, the reg entry is:
>>
>> reg = <1 0x300 0xf>;
>>
>> Where we have:
>>
>> 1 = chip select
>> 0x300 = offset of smsc device register IO space from the start of
>>        16MB minimum GPMC partition
> 
> This is where my confusion lies, where is the 0x300 coming from?
> Is this the offset of I/O register in given Ethernet IP register space?

I'm not sure about 0x300 but this is my guess.
The smsc register addresses start at 0x300. In theory this could be aligned to the CS start address and we could have worked with 0 offset. But because of the 16MB min. granularity requirement for the GPMC CS start address, A23:A0 have to be 0. As CS start address can never be aligned to 0x300 we can't have 0 offset.

cheers,
-roger

Re: [PATCH v6 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [140516 13:30]:
> Pekon,
> 
> On 05/16/2014 09:52 PM, Gupta, Pekon wrote:
> > Hi Tony, Roger,
> > 
> >> From: Tony Lindgren [mailto:tony@atomide.com]
> >>
> >> * Roger Quadros <rogerq@ti.com> [140516 05:23]:
> >>> On 05/16/2014 02:03 PM, Pekon Gupta wrote:
> >>>> +&gpmc {
> >>>> +	status = "okay";
> >>>> +	pinctrl-names = "default";
> >>>> +	pinctrl-0 = <&nand_flash_x8>;
> >>>> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
> >>>> +	nand@0,0 {
> >>>> +		reg = <0 0 0x37c>;	/* device IO registers */
> >>>
> >>> This register space is used by the parent GPMC node as well as the NAND controller. So doing a
> >> request_and_ioremap() on this space will fail as it is already taken by the GPMC driver.
> >>>
> >>> Further, the GPMC register space doesn't map to the GPMC memory map created by this Chip select
> >> but it is mapped to L3_IO space. i.e. (physical address 0x6e00 0000)
> >>>
> >>> We could have split the GPMC register space into GPMC part and NAND part but to add to the
> >> complexity, the register spaces for GPMC vs NAND are interleaved so it can't be easily split up. The way
> >> the NAND driver is currently written is that it expects the register addresses to come via platform data,
> >> primarily to get around this address interleaving issue.
> >>>
> >>> Apart from the GPMC register space, the NAND controller uses 4 bytes of GPMC memory map for
> >> I/O, and that is something that could be reflected here.
> >>>
> >>> e.g.
> >>> 		reg = <0 0 4>;		/* NAND I/O space */
> >>
> >> Guys, the reg size here is size of the IO region for the
> >> NAND driver, it should not have anything to do with the GPMC
> >> registers for the GPMC functions that the NAND driver may call.
> >>
> >> So it sounds like 0x37c is wrong, and 4 is the right value if
> >> the NAND chip has only one IO register.
> >>
> > Yes, Roger and myself both agree on the actual size of 4.
> > But what I'm not sure is what should be offset for a io-remapped region.
> > 
> > Apologies for my ignorance here, as I'm not good in this memory mapping concept..
> > -  I understand that for 'memory mapped' device <offset> is with respect to
> >    base-address of chip-select.
> > - But for indirectly mapped device (like NAND) how is  <offset> calculated?
> 
> This would depend on what the NAND driver expects. In the current OMAP nand driver it expects only the memory mapped NAND I/O resource. > 
> > Example: For CS0 in GPMC ..
> > GPMC_NAND_COMMAND_0 = 0x007c
> > GPMC_NAND_ADDRESS_0 = 0x0080
> > GPMC_NAND_DATA_0 = 0x0084
> 
> OK, let's say that we want to update that NAND driver to accept a second memory resource which would be the GPMC registers starting from GPMC_NAND_COMMAND_0 (phy.addr 0x6e00 007c), then we need to define a new address in the ranges property of the gpmc node. 
> 
> Something like so
> 
> 	ranges = <0 0 0x00000000 0x01000000	/* GPMC external map */
> 		  1 0 0x6e000000 0x0000037c>;	/* GPMC register map */
> 	nand@0,0 {
> 		reg = <0 0 4		/* NAND I/O space */
> 		       1 0x7c 3> 	/* NAND controller registers */
> 
> Since range 1 started from 0x6e000000 we specify offset as 0x7c.
> 
> But at the moment the NAND driver doesn't directly access the GPMC register map so it should be sufficient to just specify the I/O space.
> 
> > 
> > (1) Now, should the 'offset' for <reg> property used for NAND node
> >    connected at CS=0.  reg = <0 ??  4>
> >    (a) Should it be equal to 'GPMC_NAND_ADDRESS_0'?
> >    OR
> >    (b) There is no relation between 'GPMC register' and 'NAND partition' offset?
> > 
> > (2) If considering (a) then should size consider only GPMC_NAND_ADDRESS_0
> >    or also include GPMC_NAND_COMMAND_0 and GPMC_NAND_DATA_0?
> > 
> > This is why I used the size of complete GPMC register space for NAND region also.

The NAND driver should only ioremap the NAND register(s). The
GPMC driver has the GPMC registers ioremapped, and should allow
the NAND driver to use those registers via some functions in the
GPMC code. Those functions should be ideally made available to
the NAND driver by some Linux generic framework rather than
custom exported functions.

> >>> But still, the start address can't be 0 and has to be assigned when this CS region is mapped. It is still
> >> unclear to me how that can be done.
> >>
> >> If the offset for the NAND driver needs to be different from 0,
> >> it can be in the offset. For example, the smsc,lan91c94 driver
> >> wants the IO address space to be at offset 0x300 to avoid some
> >> extra warnings during the boot. So for that, the reg entry is:
> >>
> >> reg = <1 0x300 0xf>;
> >>
> >> Where we have:
> >>
> >> 1 = chip select
> >> 0x300 = offset of smsc device register IO space from the start of
> >>        16MB minimum GPMC partition
> > 
> > This is where my confusion lies, where is the 0x300 coming from?
> > Is this the offset of I/O register in given Ethernet IP register space?
> 
> I'm not sure about 0x300 but this is my guess.
> The smsc register addresses start at 0x300. In theory this could be aligned to the CS start address and we could have worked with 0 offset. But because of the 16MB min. granularity requirement for the GPMC CS start address, A23:A0 have to be 0. As CS start address can never be aligned to 0x300 we can't have 0 offset.

The 0x300 is just a legacy requirement by the smc91x.c
driver where it does some checking of the addresses. It
still works just fine if 0x300 is set to 0, but will warn
about the address space.

Regards,

Tony