[PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[PATCH v4 3/6] 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>
---
 arch/arm/boot/dts/dra7-evm.dts | 117 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi    |  20 +++++++
 2 files changed, 137 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5f1f6da..ed4e974 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -108,6 +108,37 @@
 			0xbc (PIN_INPUT_PULLUP | MUX_MODE1)  /* gpmc_cs3.qspi1_cs1 */
 		>;
 	};
+
+	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 {
@@ -353,3 +384,89 @@
 		};
 	};
 };
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0 0x1000000>;
+	nand@0,0 {
+		reg = <0 0 0x380>;
+		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-on-read = "true";
+		gpmc,wait-on-write = "true";
+		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 37a0595..6af775a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -776,6 +776,26 @@
 			interrupts = <0 343 0x4>;
 			status = "disabled";
 		};
+
+		elm: elm@48078000 {
+			compatible = "ti,am3352-elm";
+			reg = <0x48078000 0x2000>;
+			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 0x2000>;
+			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 v4 4/6] 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>
---
 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 cf8bdf1..fd29930 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -360,7 +360,7 @@
 		};
 		partition@9 {
 			label = "NAND.file-system";
-			reg = <0x00800000 0x1F600000>;
+			reg = <0x00A00000 0x1F600000>;
 		};
 	};
 };
-- 
1.8.5.1.163.gd7aced9

[PATCH v4 5/6] ARM: dts: am43x-epos-evm: fix reg and range property of GPMC NAND node

[Pekon Gupta]

1) NAND device memory is not directly accessible to CPU, its indirectly accessed
   via registers. So the 'reg' property for GPMC NAND nodes should be limited to
   address range of internal GPMC registers only.
2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
   so 'range' property for GPMC NAND node should specify 16MB as its memory-size
3) On AM437x, address map of external memory accessible via GPMC starts from 0x0

Signed-off-by: Pekon Gupta <pekon@ti.com>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index fd29930..63a6a59 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -287,9 +287,9 @@
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&nand_flash_x8>;
-	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
+	ranges = <0 0 0 0x1000000>;	/* CS0: NAND */
 	nand@0,0 {
-		reg = <0 0 0>; /* CS0, offset 0 */
+		reg = <0 0 0x380>; /* CS0, offset=0, re-map size=0x380 */
 		ti,nand-ecc-opt = "bch8";
 		ti,elm-id = <&elm>;
 		nand-bus-width = <8>;
-- 
1.8.5.1.163.gd7aced9

[PATCH v4 6/6] ARM: dts: am335x-evm: fix reg and range property of GPMC NAND node

[Pekon Gupta]

1) NAND device memory is not directly accessible to CPU, its indirectly accessed
   via registers. So the 'reg' property for GPMC NAND nodes should be limited to
   address range of internal GPMC registers only.
2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
   so 'range' property for GPMC NAND node should specify 16MB as its memory-size
3) On AM437x, address map of external memory accessible via GPMC starts from 0x0

Signed-off-by: Pekon Gupta <pekon@ti.com>
---
 arch/arm/boot/dts/am335x-evm.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 33f7c57..bae7575 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -437,9 +437,9 @@
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&nandflash_pins_s0>;
-	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
+	ranges = <0 0 0 0x1000000>;	/* CS0: NAND */
 	nand@0,0 {
-		reg = <0 0 0>; /* CS0, offset 0 */
+		reg = <0 0 0x380>; /* CS0, offset=0, reg-map size=0x380 */
 		ti,nand-ecc-opt = "bch8";
 		ti,elm-id = <&elm>;
 		nand-bus-width = <8>;
-- 
1.8.5.1.163.gd7aced9

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

[Javier Martinez Canillas]

Hello Pekon,

On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
> MTD NAND partition for file-system should start at offset=0xA00000
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
>  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 cf8bdf1..fd29930 100644
> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
> @@ -360,7 +360,7 @@
>                 };
>                 partition@9 {
>                         label = "NAND.file-system";
> -                       reg = <0x00800000 0x1F600000>;
> +                       reg = <0x00A00000 0x1F600000>;
>                 };
>         };
>  };

While you are there, could you please change to lower case the hex
values to be consistent with the rest of the Device Trees?

Thanks a lot and best regards,
Javier

Re: [PATCH v4 6/6] ARM: dts: am335x-evm: fix reg and range property of GPMC NAND node

[Javier Martinez Canillas]

Hello Pekon,

On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
> 1) NAND device memory is not directly accessible to CPU, its indirectly accessed
>    via registers. So the 'reg' property for GPMC NAND nodes should be limited to
>    address range of internal GPMC registers only.
> 2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
>    so 'range' property for GPMC NAND node should specify 16MB as its memory-size

This is true for all SoC using the GPMC right? So we need to do the
same modification for all OMAP boards to avoid mapping a bigger
address space unnecessarily.

> 3) On AM437x, address map of external memory accessible via GPMC starts from 0x0
>

You are talking about AM437x here but changing an am335x board. Is this a typo?

Best regards,
Javier

> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
>  arch/arm/boot/dts/am335x-evm.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
> index 33f7c57..bae7575 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -437,9 +437,9 @@
>         status = "okay";
>         pinctrl-names = "default";
>         pinctrl-0 = <&nandflash_pins_s0>;
> -       ranges = <0 0 0x08000000 0x10000000>;   /* CS0: NAND */
> +       ranges = <0 0 0 0x1000000>;     /* CS0: NAND */
>         nand@0,0 {
> -               reg = <0 0 0>; /* CS0, offset 0 */
> +               reg = <0 0 0x380>; /* CS0, offset=0, reg-map size=0x380 */
>                 ti,nand-ecc-opt = "bch8";
>                 ti,elm-id = <&elm>;
>                 nand-bus-width = <8>;
> --
> 1.8.5.1.163.gd7aced9
>

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Javier Martinez Canillas]

Hello Pekon,

On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
> 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>
> ---
>  arch/arm/boot/dts/dra7-evm.dts | 117 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/dra7.dtsi    |  20 +++++++
>  2 files changed, 137 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 5f1f6da..ed4e974 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -108,6 +108,37 @@
>                         0xbc (PIN_INPUT_PULLUP | MUX_MODE1)  /* gpmc_cs3.qspi1_cs1 */
>                 >;
>         };
> +
> +       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 {
> @@ -353,3 +384,89 @@
>                 };
>         };
>  };
> +
> +&elm {
> +       status = "okay";
> +};
> +
> +&gpmc {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&nand_flash_x16>;
> +       ranges = <0 0 0 0x1000000>;
> +       nand@0,0 {
> +               reg = <0 0 0x380>;
> +               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-on-read = "true";
> +               gpmc,wait-on-write = "true";
> +               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 37a0595..6af775a 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -776,6 +776,26 @@
>                         interrupts = <0 343 0x4>;
>                         status = "disabled";
>                 };
> +
> +               elm: elm@48078000 {
> +                       compatible = "ti,am3352-elm";
> +                       reg = <0x48078000 0x2000>;

It is really necessary to map all this 8 KB address space for GPMC registers?

I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
that the GPMC module register address space size is 16 MB while in
practice the registers use less than 1 KB (0..0x02d0 to be exact) so
in arch/arm/boot/dts/omap3.dtsi we have:

gpmc: gpmc@6e000000 {
...
                        reg = <0x6e000000 0x02d0>;
...
};

Shouldn't this be similar (the same?) for DRA7 GPMC device node?

Thanks a lot and best regards,
Javier

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Gupta, Pekon]

Hello,

From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
>On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
>> From: Minal Shah <minalkshah@gmail.com>
[...]
>> +&gpmc {
>> +       status = "okay";
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&nand_flash_x16>;
>> +       ranges = <0 0 0 0x1000000>;
>> +       nand@0,0 {
>> +               reg = <0 0 0x380>;
[...]

>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 37a0595..6af775a 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -776,6 +776,26 @@
>>                         interrupts = <0 343 0x4>;
>>                         status = "disabled";
>>                 };
>> +
>> +               elm: elm@48078000 {
>> +                       compatible = "ti,am3352-elm";
>> +                       reg = <0x48078000 0x2000>;
>
>It is really necessary to map all this 8 KB address space for GPMC registers?
>
>I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
>that the GPMC module register address space size is 16 MB while in
>practice the registers use less than 1 KB (0..0x02d0 to be exact) so
>in arch/arm/boot/dts/omap3.dtsi we have:
>
These are not GPMC registers. Platforms from OMAP4 and beyond
(like AM335x, OMAP5) have another small hardware engine called ELM [1]
(Error Locater Module) in addition to GPMC, which is used for detecting
ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c

However, thanks for pointing out, this address-space for ELM is incorrect.
Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].

>gpmc: gpmc@6e000000 {
>...
>                        reg = <0x6e000000 0x02d0>;
>...
>};
>
>Shouldn't this be similar (the same?) for DRA7 GPMC device node?
>
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].


>Thanks a lot and best regards,
>Javier

[1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)

[2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
 it should be 0x378. I have raised documentation bug for it).


with regards, pekon

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Javier Martinez Canillas]

Hello Pekon,

On Mon, May 12, 2014 at 9:03 AM, Gupta, Pekon <pekon@ti.com> wrote:
> Hello,
>
> From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
>>On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
>>> From: Minal Shah <minalkshah@gmail.com>
> [...]
>>> +&gpmc {
>>> +       status = "okay";
>>> +       pinctrl-names = "default";
>>> +       pinctrl-0 = <&nand_flash_x16>;
>>> +       ranges = <0 0 0 0x1000000>;
>>> +       nand@0,0 {
>>> +               reg = <0 0 0x380>;
> [...]
>
>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>> index 37a0595..6af775a 100644
>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>> @@ -776,6 +776,26 @@
>>>                         interrupts = <0 343 0x4>;
>>>                         status = "disabled";
>>>                 };
>>> +
>>> +               elm: elm@48078000 {
>>> +                       compatible = "ti,am3352-elm";
>>> +                       reg = <0x48078000 0x2000>;
>>
>>It is really necessary to map all this 8 KB address space for GPMC registers?
>>
>>I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
>>that the GPMC module register address space size is 16 MB while in
>>practice the registers use less than 1 KB (0..0x02d0 to be exact) so
>>in arch/arm/boot/dts/omap3.dtsi we have:
>>
> These are not GPMC registers. Platforms from OMAP4 and beyond
> (like AM335x, OMAP5) have another small hardware engine called ELM [1]
> (Error Locater Module) in addition to GPMC, which is used for detecting
> ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c
>

Yes, I know what ELM is, I just made a mistake when adding my comments
inline. I actually meant the 8KB from the following device node:

> +               gpmc: gpmc@50000000 {
> +                       compatible = "ti,am3352-gpmc";
> +                       ti,hwmods = "gpmc";
> +                       reg = <0x50000000 0x2000>;
> +                       interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
> +                       gpmc,num-cs = <8>;
> +                       gpmc,num-waitpins = <2>;
> +                       #address-cells = <2>;
> +                       #size-cells = <1>;
> +                       status = "disabled";
> +               };

> However, thanks for pointing out, this address-space for ELM is incorrect.
> Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].
>

And yes, comments applies to ELM register address space as well.

>>gpmc: gpmc@6e000000 {
>>...
>>                        reg = <0x6e000000 0x02d0>;
>>...
>>};
>>
>>Shouldn't this be similar (the same?) for DRA7 GPMC device node?
>>
> Newer platforms have upgraded version of GPMC engine which supports
> BCH16 ECC scheme in hardware. Thus the GPMC address space was
> expanded to include some extra registers required for BCH16 ECC [2].
>
>

I see and did the GPMC register space became that big to need to map 8KB?

Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:

reg = <0x6e000000 0x02d0>;
reg = <0x6e000000 0x0400>;
reg = <0x6e000000 0x1000>;

in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.

>
> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>
> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
> (Though the AM335x address space mentions 0x368 as last address,
>  it should be 0x378. I have raised documentation bug for it).
>
>
> with regards, pekon

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Gupta, Pekon]

>From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
[...]

>> Newer platforms have upgraded version of GPMC engine which supports
>> BCH16 ECC scheme in hardware. Thus the GPMC address space was
>> expanded to include some extra registers required for BCH16 ECC [2].
>>
>>
>
>I see and did the GPMC register space became that big to need to map 8KB?
>
>Although the smallest unit for ioremap is PAGE_SIZE and using any of
>these reg sizes:
>
>reg = <0x6e000000 0x02d0>;
>reg = <0x6e000000 0x0400>;
>reg = <0x6e000000 0x1000>;
>
>in practice have the same effect, DTS should describe the hardware and
>not an implementation detail so I think that we should use only the
>register size that is defined in the TRM.
>
Yes, I agree with you.
I have fixed this in newer version of the patch and will be sending it soon.
But this series will only contain updates for new platforms with addition
of NAND node in DTS, so that this series is not stalled for any reason.
For fixing existing platform/boards DTS I'll send another series soon.

For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.

>>
>> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>>
>> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
>> (Though the AM335x address space mentions 0x368 as last address,
>>  it should be 0x378. I have raised documentation bug for it).
>>
>>
>> with regards, pekon
>
>Best regards,
>Javier
>
>[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Javier Martinez Canillas]

On Mon, May 12, 2014 at 11:05 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
> [...]
>
>>> Newer platforms have upgraded version of GPMC engine which supports
>>> BCH16 ECC scheme in hardware. Thus the GPMC address space was
>>> expanded to include some extra registers required for BCH16 ECC [2].
>>>
>>>
>>
>>I see and did the GPMC register space became that big to need to map 8KB?
>>
>>Although the smallest unit for ioremap is PAGE_SIZE and using any of
>>these reg sizes:
>>
>>reg = <0x6e000000 0x02d0>;
>>reg = <0x6e000000 0x0400>;
>>reg = <0x6e000000 0x1000>;
>>
>>in practice have the same effect, DTS should describe the hardware and
>>not an implementation detail so I think that we should use only the
>>register size that is defined in the TRM.
>>
> Yes, I agree with you.
> I have fixed this in newer version of the patch and will be sending it soon.
> But this series will only contain updates for new platforms with addition
> of NAND node in DTS, so that this series is not stalled for any reason.
> For fixing existing platform/boards DTS I'll send another series soon.
>

Yes, I agree that fixing existing platforms is a matter of a different
series, I just didn't want to introduce more :-)

> For now, I'll use GPMC address-space size = 0x380 as it matches with
> actual hardware and is working.
>

Perfect, thanks a lot!

>>>
>>> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>>>
>>> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
>>> (Though the AM335x address space mentions 0x368 as last address,
>>>  it should be 0x378. I have raised documentation bug for it).
>>>
>>>
>>> with regards, pekon
>>
>>Best regards,
>>Javier
>>
>>[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334

Best regards,
Javier

Re: [PATCH v4 6/6] ARM: dts: am335x-evm: fix reg and range property of GPMC NAND node

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140510 10:12]:
> Hello Pekon,
> 
> On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta <pekon@ti.com> wrote:
> > 1) NAND device memory is not directly accessible to CPU, its indirectly accessed
> >    via registers. So the 'reg' property for GPMC NAND nodes should be limited to
> >    address range of internal GPMC registers only.
> > 2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
> >    so 'range' property for GPMC NAND node should specify 16MB as its memory-size
> 
> This is true for all SoC using the GPMC right? So we need to do the
> same modification for all OMAP boards to avoid mapping a bigger
> address space unnecessarily.

Yes we should fix them all up. See also the commenting standard I suggested
in the parallel NAND series.

Regards,

Tony

Re: [PATCH v4 5/6] ARM: dts: am43x-epos-evm: fix reg and range property of GPMC NAND node

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140509 13:48]:
> 1) NAND device memory is not directly accessible to CPU, its indirectly accessed
>    via registers. So the 'reg' property for GPMC NAND nodes should be limited to
>    address range of internal GPMC registers only.
> 2) Also, minimum granularity of address space under a GPMC chip-select is 16MB
>    so 'range' property for GPMC NAND node should specify 16MB as its memory-size
> 3) On AM437x, address map of external memory accessible via GPMC starts from 0x0
> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
>  arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
> index fd29930..63a6a59 100644
> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
> @@ -287,9 +287,9 @@
>  	status = "okay";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&nand_flash_x8>;
> -	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
> +	ranges = <0 0 0 0x1000000>;	/* CS0: NAND */
>  	nand@0,0 {
> -		reg = <0 0 0>; /* CS0, offset 0 */
> +		reg = <0 0 0x380>; /* CS0, offset=0, re-map size=0x380 */
>  		ti,nand-ecc-opt = "bch8";
>  		ti,elm-id = <&elm>;
>  		nand-bus-width = <8>;
> 

Here too let's use the standard comments while fixing up the GPMC
ranges.

Tony

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Roger Quadros]

Hi Pekon,

On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
>> From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
> [...]
> 
>>> Newer platforms have upgraded version of GPMC engine which supports
>>> BCH16 ECC scheme in hardware. Thus the GPMC address space was
>>> expanded to include some extra registers required for BCH16 ECC [2].
>>>
>>>
>>
>> I see and did the GPMC register space became that big to need to map 8KB?
>>
>> Although the smallest unit for ioremap is PAGE_SIZE and using any of
>> these reg sizes:
>>
>> reg = <0x6e000000 0x02d0>;
>> reg = <0x6e000000 0x0400>;
>> reg = <0x6e000000 0x1000>;
>>
>> in practice have the same effect, DTS should describe the hardware and
>> not an implementation detail so I think that we should use only the
>> register size that is defined in the TRM.
>>
> Yes, I agree with you.
> I have fixed this in newer version of the patch and will be sending it soon.
> But this series will only contain updates for new platforms with addition
> of NAND node in DTS, so that this series is not stalled for any reason.
> For fixing existing platform/boards DTS I'll send another series soon.
> 
> For now, I'll use GPMC address-space size = 0x380 as it matches with
> actual hardware and is working.

How did you get 0x380?

From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)

For the ELM module it should be 4KB i.e. 0x1000

cheers,
-roger

>>>
>>> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>>>
>>> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
>>> (Though the AM335x address space mentions 0x368 as last address,
>>>  it should be 0x378. I have raised documentation bug for it).
>>>
>>>
>>> with regards, pekon
>>
>> Best regards,
>> Javier
>>
>> [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
> \x04�{.n�+�������+%��lzwm��b�맲��r��zX��\x1a&j���\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Gupta, Pekon]

Hi Roger,

>>
>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>> actual hardware and is working.
>
>How did you get 0x380?
>
>From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
>So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)
>
I think that is copy-paste error in documentation.
In the same TRM, you 'll find the correct address offsets for GPMC Registers in below
*Section: 15.4.7.1 GPMC Register Summary*
Register                                  Starting Offset                                       End Offset
GPMC_BCH_RESULT4_i    0x0000 0300 + (0x0000 0010 * i)     0x5000 0300 + (0x0000 0010 * i)
GPMC_BCH_RESULT5_i    0x0000 0304 + (0x0000 0010 * i)     0x5000 0304 + (0x0000 0010 * i)
GPMC_BCH_RESULT6_i    0x0000 0308 + (0x0000 0010 * i)     0x5000 0308 + (0x0000 0010 * i)
Where i = 0 to 7 .. 

So that makes last address 0x5000_0378 (for GPMC_BCH_RESULT6_7)
As the each register bank (i) is incrementing at 0x10, so last accessible address is 0x37F.

I have already raised documentation bug for AM335x TRM,
Need to raise the same for DRA7xx TRM.

>For the ELM module it should be 4KB i.e. 0x1000
>
Yes, that is correct. I have fixed that now.


>cheers,
>-roger
>
>>>>
>>>> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>>>>
>>>> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
>>>> (Though the AM335x address space mentions 0x368 as last address,
>>>>  it should be 0x378. I have raised documentation bug for it).


with regards, pekon

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Roger Quadros]

On 05/14/2014 11:25 AM, Roger Quadros wrote:
> Hi Pekon,
> 
> On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
>>> From: Javier Martinez Canillas [mailto:javier@dowhile0.org]
>> [...]
>>
>>>> Newer platforms have upgraded version of GPMC engine which supports
>>>> BCH16 ECC scheme in hardware. Thus the GPMC address space was
>>>> expanded to include some extra registers required for BCH16 ECC [2].
>>>>
>>>>
>>>
>>> I see and did the GPMC register space became that big to need to map 8KB?
>>>
>>> Although the smallest unit for ioremap is PAGE_SIZE and using any of
>>> these reg sizes:
>>>
>>> reg = <0x6e000000 0x02d0>;
>>> reg = <0x6e000000 0x0400>;
>>> reg = <0x6e000000 0x1000>;
>>>
>>> in practice have the same effect, DTS should describe the hardware and
>>> not an implementation detail so I think that we should use only the
>>> register size that is defined in the TRM.
>>>
>> Yes, I agree with you.
>> I have fixed this in newer version of the patch and will be sending it soon.
>> But this series will only contain updates for new platforms with addition
>> of NAND node in DTS, so that this series is not stalled for any reason.
>> For fixing existing platform/boards DTS I'll send another series soon.
>>
>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>> actual hardware and is working.
> 
> How did you get 0x380?
> 
> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)

Sorry for the noise.
Just figured out that the register space is not numerically arranged in the TRM.

The last register is P GPMC_BCH_RESULT6_i
	0x5000  0308  +  (0x0000   0010  *  i)
	i = 0 to 7

So size should be 0x37C.

cheers,
-roger
 
> 
> For the ELM module it should be 4KB i.e. 0x1000
> 
> cheers,
> -roger
> 
>>>>
>>>> [1] http://www.ti.com/lit/gpn/am3359    (Section 7.4 to 7.4.5)
>>>>
>>>> [2] http://www.ti.com/lit/gpn/am3359    (Section 7.1 to 7.1.5)
>>>> (Though the AM335x address space mentions 0x368 as last address,
>>>>  it should be 0x378. I have raised documentation bug for it).
>>>>
>>>>
>>>> with regards, pekon
>>>
>>> Best regards,
>>> Javier
>>>
>>> [0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
>> \x04�{.n�+�������+%��lzwm��b�맲��r��zX��\x1a&j���\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Gupta, Pekon]

>From: Quadros, Roger
[...]

>>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>>> actual hardware and is working.
>>
>> How did you get 0x380?
>>
>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)
>
>Sorry for the noise.
>Just figured out that the register space is not numerically arranged in the TRM.
>
>The last register is P GPMC_BCH_RESULT6_i
>	0x5000  0308  +  (0x0000   0010  *  i)
>	i = 0 to 7
>
>So size should be 0x37C.
>
Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
so I aligned the last address to 0x380 boundary. Hope leaving room for
extra 4 bytes (0x380 - 0x37C) will not matter much?

All platforms from OMAP4 onwards share the same version of GPMC engine.
So this remains consistent. Only OMAP3 has older version of GPMC engine
which has register-space till 0x2d0.

>cheers,
>-roger
>

with regards, pekon

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Roger Quadros]

On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
>> From: Quadros, Roger
> [...]
> 
>>>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>>>> actual hardware and is working.
>>>
>>> How did you get 0x380?
>>>
>>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
>>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)
>>
>> Sorry for the noise.
>> Just figured out that the register space is not numerically arranged in the TRM.
>>
>> The last register is P GPMC_BCH_RESULT6_i
>> 	0x5000  0308  +  (0x0000   0010  *  i)
>> 	i = 0 to 7
>>
>> So size should be 0x37C.
>>
> Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
> so I aligned the last address to 0x380 boundary. Hope leaving room for
> extra 4 bytes (0x380 - 0x37C) will not matter much?

Functionally it won't matter but it always good to describe the hardware as
accurately as possible and avoid confusion to future developers as to why
extra 4 bytes were used in the device tree.

cheers,
-roger

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

[Javier Martinez Canillas]

On Wed, May 14, 2014 at 11:17 AM, Roger Quadros <rogerq@ti.com> wrote:
> On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
>>> From: Quadros, Roger
>> [...]
>>
>>>>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>>>>> actual hardware and is working.
>>>>
>>>> How did you get 0x380?
>>>>
>>>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
>>>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)
>>>

arch/arm/boot/dts/omap3.dtsi is using reg = <0x6e000000 0x02d0> so
that should be fixed to 0x2d4 too.

>>> Sorry for the noise.
>>> Just figured out that the register space is not numerically arranged in the TRM.
>>>
>>> The last register is P GPMC_BCH_RESULT6_i
>>>      0x5000  0308  +  (0x0000   0010  *  i)
>>>      i = 0 to 7
>>>
>>> So size should be 0x37C.
>>>
>> Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
>> so I aligned the last address to 0x380 boundary. Hope leaving room for
>> extra 4 bytes (0x380 - 0x37C) will not matter much?
>
> Functionally it won't matter but it always good to describe the hardware as
> accurately as possible and avoid confusion to future developers as to why
> extra 4 bytes were used in the device tree.
>

I don't think that aligning makes too much sense since in practice
ioremap() will map a complete page anyways so if we are not using
0x1000 (e.g: PAGE_SIZE on ARM) is just because we want the DT to
strictly model what the hardware registers address size really is.

Best regards,
Javier