[PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS

[PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS

[Pekon Gupta]

This series adds DTS for following Beaglebone capes:

Memory Cape: http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
NAND Cape:   http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
NOR Cape:    http://elinux.org/Beagleboardtoys:BeagleBone_128Mb_16-Bit_NOR_Module
LCD4 Cape:   http://elinux.org/CircuitCo:BeagleBone_LCD4

Based on Tree: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.16/dt-v2

Acceptance of cape DTS in mainline is still under discussion [1], so multiple
'Tested-by' would be helpful.
Note: In order to avoid conflicts with existing DTS, device nodes added in these
patches have status="disabled", and need to be "enabled" via u-boot.
DT nodes can be selectively enabled | disabled via u-boot [2]

Example: Below sequence works for NAND cape patch.
---------------
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disable MMC2 node */
u-boot> fdt list /ocp/mmc@481d8000
u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot> fdt list /ocp/gpmc
u-boot> fdt set  /ocp/gpmc status \o\k\a\y
u-boot> fdt list /ocp/gpmc status
/* enable ELM node */
u-boot> fdt list /ocp/elm
u-boot> fdt set  /ocp/elm status \o\k\a\y
u-boot> fdt list /ocp/elm status
/* boot uImage */
tftp 0x82000000 uImage
bootm 0x82000000 - 0x81000000

Note: "fdt set" command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
"okay" == \o\k\a\y
"disabled" == \d\i\s\a\b\l\e\d"
---------------

[1] http://www.spinics.net/lists/linux-omap/msg108505.html 
[2] http://www.denx.de/wiki/view/DULG/UBootCmdFDT


Pekon Gupta (3):
  ARM: dts: am335x-bone: add support for beaglebone NAND cape
  ARM: dts: am335x-bone: add support for beaglebone NOR cape
  ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

 arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++
 arch/arm/boot/dts/am335x-bone-memory-cape.dts  | 249 +++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts              |   2 +
 arch/arm/boot/dts/am335x-boneblack.dts         |   2 +
 4 files changed, 357 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

-- 
1.8.5.1.163.gd7aced9

[PATCH v1 1/3] 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[ 1] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
   SW2[ 2] = ON   (SYSBOOT[ 1]==0:       -- do --          )
   SW2[ 3] = OFF  (SYSBOOT[ 2]==1:       -- do --          )
   SW2[ 4] = OFF  (SYSBOOT[ 3]==1:       -- do --          )
   SW2[ 5] = ON   (SYSBOOT[ 4]==0:       -- do --          )
   SW2[ 6] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
   SW2[ 7] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
   SW2[ 8] = ON   (SYSBOOT[10]==0: Non Muxed device )
   SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts             |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
 3 files changed, 129 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..6d8ebd8
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,127 @@
+/*
+ * 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-White and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+	bbcape_nand_flash_pins: bbcape_nand_flash_pins {
+		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_MODE0 | PIN_OUTPUT_PULLUP)	/* gpmc_wpn.gpmc_wpn */
+			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 {
+	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
+	nand@0,0 {
+		status = "disabled";
+		reg = <0 0 4>;		/* device IO registers */
+		pinctrl-names = "default";
+		pinctrl-0 = <&bbcape_nand_flash_pins>;
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		/* generic bindings */
+		nand-bus-width = <16>;
+		/* vendor specific bindings */
+		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 305975d..e6d7e54 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

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

[Ezequiel Garcia]

On 24 Jun 05:54 PM, Pekon Gupta wrote:
> +&gpmc {
> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> +	nand@0,0 {
> +		status = "disabled";
> +		reg = <0 0 4>;		/* device IO registers */
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
> +		ti,nand-ecc-opt = "bch8";
> +		ti,elm-id = <&elm>;

Don't you need something like this to turn on the elm device?

&elm {
	status = "okay";
};

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

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

[Gupta, Pekon]

>From: Ezequiel Garcia [mailto:ezequiel@vanguardiasur.com.ar]
>>On 24 Jun 05:54 PM, Pekon Gupta wrote:
>> +&gpmc {
>> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
>> +	nand@0,0 {
>> +		status = "disabled";
>> +		reg = <0 0 4>;		/* device IO registers */
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
>> +		ti,nand-ecc-opt = "bch8";
>> +		ti,elm-id = <&elm>;
>
>Don't you need something like this to turn on the elm device?
>
>&elm {
>	status = "okay";
>};
>
No, This was the intend of these patches to keep cape DTS as "disabled"
so that:
(1)These patches should not change the behavior of existing DTS
 (am335x-boneblack.dts or am335x-bone.dts), or conflict with
 any existing node or other cape DTS.
(2) In-case of share-pin mux where multiple capes use same pins
Cape DTS should not conflict each other.

Now, to enable the choice of cape without hacking any source file,
user can use u-boot commands (refer to example in cover-letter):
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disabled conflicting MMC2 (eMMC) */
u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
/* enable NAND cape*/
u-boot> fdt set  /ocp/elm status \o\k\a\y
u-boot> fdt set  /ocp/gpmc status \o\k\a\y
u-boot> fdt set  /ocp/gpmc/nand status \o\k\a\y

And then boot using this DTB loaded at 0x81000000
(you can put all these commands in uEnv as part of $bootcmd)


with regards, Pekon

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

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140624 05:26]:
> +
> +&gpmc {
> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> +	nand@0,0 {
> +		status = "disabled";
> +		reg = <0 0 4>;		/* device IO registers */

Hmm so what about other capes potentially also using GPMC CS0?

Can you please do a check with two .dtsi files trying to use
GPMC CS0 and see what the produced .dtb file looks like after
decompiling it with dtc?

I'd assume the 16MB GPMC partition will be just fine for many
devices and can be also be larger if NOR needs it so maybe it
can be handled for almost all the cases.

The names for devices must be unique though to avoid them
getting merged. And I don't know if gpmc.c skips disabled devices
properly.

Regards,

Tony

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

[Guido Martínez]

Hi Tony, Pekon

On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
> > +
> > +&gpmc {
> > +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> > +	nand@0,0 {
> > +		status = "disabled";
> > +		reg = <0 0 4>;		/* device IO registers */
> 
> Hmm so what about other capes potentially also using GPMC CS0?
> 
> Can you please do a check with two .dtsi files trying to use
> GPMC CS0 and see what the produced .dtb file looks like after
> decompiling it with dtc?
> 
> I'd assume the 16MB GPMC partition will be just fine for many
> devices and can be also be larger if NOR needs it so maybe it
> can be handled for almost all the cases.
> 
> The names for devices must be unique though to avoid them
> getting merged. And I don't know if gpmc.c skips disabled devices
> properly.
It doesn't. I've just sent a patch for it.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html

Regards,
Guido

> 
> Regards,
> 
> Tony
> --
> 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

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar

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

[Gupta, Pekon]

Hi Guido,

>From: Guido Martínez
>>On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
>> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
>> > +
>> > +&gpmc {
>> > +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
>> > +	nand@0,0 {
>> > +		status = "disabled";
>> > +		reg = <0 0 4>;		/* device IO registers */
>>
>> Hmm so what about other capes potentially also using GPMC CS0?
>>
>> Can you please do a check with two .dtsi files trying to use
>> GPMC CS0 and see what the produced .dtb file looks like after
>> decompiling it with dtc?
>>
>> I'd assume the 16MB GPMC partition will be just fine for many
>> devices and can be also be larger if NOR needs it so maybe it
>> can be handled for almost all the cases.
>>
>> The names for devices must be unique though to avoid them
>> getting merged. And I don't know if gpmc.c skips disabled devices
>> properly.
>It doesn't. I've just sent a patch for it.
>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>
I don't think we need above patch.
Helper macro "for_each_available_child_of_node" internally takes care
of skipping nodes with status="disabled".

$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
	     child = of_get_next_available_child(parent, child))

$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
	...
	if (!__of_device_is_available(next))
			continue;
	...


with regards, pekon

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

[Guido Martínez]

Hi Pekon,

On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
> >
> I don't think we need above patch.
> Helper macro "for_each_available_child_of_node" internally takes care
> of skipping nodes with status="disabled".
> 
> $KERNEL/include/linux/of.h
> #define for_each_available_child_of_node(parent, child) \
> 	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> 	     child = of_get_next_available_child(parent, child))
> 
> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
> 	...
> 	if (!__of_device_is_available(next))
> 			continue;
> 	...
Yes, that's why I suggest using that macro. It's not currently used
in gpmc.c and my patch changes the 'for_each_child_of_node' to a
'for_each_available_child_of_node'. Or am I missing something?

Regards,

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar

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

[Gupta, Pekon]

>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
>> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>> >
>> I don't think we need above patch.
>> Helper macro "for_each_available_child_of_node" internally takes care
>> of skipping nodes with status="disabled".
>>
>> $KERNEL/include/linux/of.h
>> #define for_each_available_child_of_node(parent, child) \
>> 	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
>> 	     child = of_get_next_available_child(parent, child))
>>
>> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
>> 	...
>> 	if (!__of_device_is_available(next))
>> 			continue;
>> 	...
>Yes, that's why I suggest using that macro. It's not currently used
>in gpmc.c and my patch changes the 'for_each_child_of_node' to a
>'for_each_available_child_of_node'. Or am I missing something?
>
Oops my bad. I was probably dreaming, I already had your patch in my tree
before reviewing the code. So please ignore my previous email.

with regards, pekon

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

[Guido Martínez]

Hi Pekon,

On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> 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[ 1] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
>    SW2[ 2] = ON   (SYSBOOT[ 1]==0:       -- do --          )
>    SW2[ 3] = OFF  (SYSBOOT[ 2]==1:       -- do --          )
>    SW2[ 4] = OFF  (SYSBOOT[ 3]==1:       -- do --          )
>    SW2[ 5] = ON   (SYSBOOT[ 4]==0:       -- do --          )
>    SW2[ 6] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
>    SW2[ 7] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
>    SW2[ 8] = ON   (SYSBOOT[10]==0: Non Muxed device )
>    SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts             |   1 +
>  arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
>  3 files changed, 129 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..6d8ebd8
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> @@ -0,0 +1,127 @@
> +/*
> + * 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-White and Beaglebone-Black.
> + */
> +
> +
> +&am33xx_pinmux {
> +	bbcape_nand_flash_pins: bbcape_nand_flash_pins {
> +		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_MODE0 | PIN_OUTPUT_PULLUP)	/* gpmc_wpn.gpmc_wpn */
> +			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 {
> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> +	nand@0,0 {
> +		status = "disabled";
> +		reg = <0 0 4>;		/* device IO registers */
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?

Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?

> +		ti,nand-ecc-opt = "bch8";
> +		ti,elm-id = <&elm>;
> +		/* generic bindings */
> +		nand-bus-width = <16>;
> +		/* vendor specific bindings */
> +		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 305975d..e6d7e54 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
> 
> --
> 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

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar

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

[Gupta, Pekon]

>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:

[...]

>> +&gpmc {
>> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
>> +	nand@0,0 {
>> +		status = "disabled";
>> +		reg = <0 0 4>;		/* device IO registers */
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
>This doesn't seem to work as pinctrl properties are not parsed for
>childs of the gpmc node. Did this work for you?
>Putting this in the gpmc node makes it work, but how will we control
>pins for the nand and nor independently? I believe there is currently no
>support for muxing individual gpmc devices. If we want to add both
>devices to the DT and enable them as needed we'd need to add support for
>this, right?
>
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.

Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
In addition to pin-mux you may also require following patch:
http://www.spinics.net/lists/linux-omap/msg107950.html

Also, I should have marked this series as RFC as its not fully tested.
My main intention was to get acknowledgement about cape DTS from
various users and Tony Lindgren <tony@atomide.com>.
Now as Tony has given some acceptance for these kind of cape DTS,
I'll clean-up and re-send these patches with better testing and GPMC fixes.


with regards, pekon


with regards, pekon

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

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> 
> [...]
> 
> >> +&gpmc {
> >> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> >> +	nand@0,0 {
> >> +		status = "disabled";
> >> +		reg = <0 0 4>;		/* device IO registers */
> >> +		pinctrl-names = "default";
> >> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
> >This doesn't seem to work as pinctrl properties are not parsed for
> >childs of the gpmc node. Did this work for you?
> >Putting this in the gpmc node makes it work, but how will we control
> >pins for the nand and nor independently? I believe there is currently no
> >support for muxing individual gpmc devices. If we want to add both
> >devices to the DT and enable them as needed we'd need to add support for
> >this, right?
> >
> Yes, And that should be the case, because different devices would be
> connected to different chip-selects, so there should be support of
> providing individual pin-mux for different GPMC devices.
> 
> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> capes will not work simultaneously. But I'm planning to modify NOR cape
> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> - NAND on GPMC_CS0
> - NOR on GPMC_CS1

Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?

In that case we should make sure we always set large enough GPMC
partition and that the pins are muxed for the connected GPMC
devices only.

Regards,

Tony

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

[Gupta, Pekon]

>From: Tony Lindgren [mailto:tony@atomide.com]
>>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
>> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>>
>> [...]
>>
>> >> +&gpmc {
>> >> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
>> >> +	nand@0,0 {
>> >> +		status = "disabled";
>> >> +		reg = <0 0 4>;		/* device IO registers */
>> >> +		pinctrl-names = "default";
>> >> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
>> >This doesn't seem to work as pinctrl properties are not parsed for
>> >childs of the gpmc node. Did this work for you?
>> >Putting this in the gpmc node makes it work, but how will we control
>> >pins for the nand and nor independently? I believe there is currently no
>> >support for muxing individual gpmc devices. If we want to add both
>> >devices to the DT and enable them as needed we'd need to add support for
>> >this, right?
>> >
>> Yes, And that should be the case, because different devices would be
>> connected to different chip-selects, so there should be support of
>> providing individual pin-mux for different GPMC devices.
>>
>> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
>> capes will not work simultaneously. But I'm planning to modify NOR cape
>> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
>> - NAND on GPMC_CS0
>> - NOR on GPMC_CS1
>
>Hmm but we should have these working with both using CS0 without
>any need to modify the hardware though?
>
Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
If you need both working simultaneously as 2 separate devices attached
to GPMC, then you need 2 separate chip-selects, which is what I'm trying
to test with [1].


>In that case we should make sure we always set large enough GPMC
>partition
Yes, this is taken care with introduction of NOR cape in
[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
 &gpmc {
-	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
+	ranges = <0 0 0x08000000 0x01000000>;	/* address offset=128MB, range=128Mb=16MB */
This GPMC partition suffices for both NAND and NOR requirements.

> and that the pins are muxed for the connected GPMC
>devices only.
>
Pin mux is something I need to re-work, because currently
I've tested either NAND or NOR individually, not together.

Also as mentioned above by Guido, pin-ctrl property is not parsed individually
for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.

Do you have any suggestions on how pin-ctrl should be set if we have
multiple devices connected to GPMC like;
All these devices will share:
- control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
- *some* data lines (gpmc_ad[])
- *some* address lines (gpmc_a[])
- but chip-selects will be different:
	gpmc_cs0: NAND
	gpmc_cs1: NOR
	gpmc_cs2: SMSC91xx
	gpmc_cs3: Camera


with regards, Pekon

>Regards,
>
>Tony

[1] http://www.spinics.net/lists/linux-omap/msg107950.html

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

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140701 02:09]:
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> >>
> >> [...]
> >>
> >> >> +&gpmc {
> >> >> +	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> >> >> +	nand@0,0 {
> >> >> +		status = "disabled";
> >> >> +		reg = <0 0 4>;		/* device IO registers */
> >> >> +		pinctrl-names = "default";
> >> >> +		pinctrl-0 = <&bbcape_nand_flash_pins>;
> >> >This doesn't seem to work as pinctrl properties are not parsed for
> >> >childs of the gpmc node. Did this work for you?
> >> >Putting this in the gpmc node makes it work, but how will we control
> >> >pins for the nand and nor independently? I believe there is currently no
> >> >support for muxing individual gpmc devices. If we want to add both
> >> >devices to the DT and enable them as needed we'd need to add support for
> >> >this, right?
> >> >
> >> Yes, And that should be the case, because different devices would be
> >> connected to different chip-selects, so there should be support of
> >> providing individual pin-mux for different GPMC devices.
> >>
> >> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> >> capes will not work simultaneously. But I'm planning to modify NOR cape
> >> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> >> - NAND on GPMC_CS0
> >> - NOR on GPMC_CS1
> >
> >Hmm but we should have these working with both using CS0 without
> >any need to modify the hardware though?
> >
> Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
> If you need both working simultaneously as 2 separate devices attached
> to GPMC, then you need 2 separate chip-selects, which is what I'm trying
> to test with [1].

Right only one enabled at a time, not both enabled at the same time :)
 
> >In that case we should make sure we always set large enough GPMC
> >partition
> Yes, this is taken care with introduction of NOR cape in
> [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
>  &gpmc {
> -	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
> +	ranges = <0 0 0x08000000 0x01000000>;	/* address offset=128MB, range=128Mb=16MB */
> This GPMC partition suffices for both NAND and NOR requirements.

OK
 
> > and that the pins are muxed for the connected GPMC
> >devices only.
> >
> Pin mux is something I need to re-work, because currently
> I've tested either NAND or NOR individually, not together.
> 
> Also as mentioned above by Guido, pin-ctrl property is not parsed individually
> for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.

Yes, drivers/base/pinctrl.c should already take care of that though?
 
> Do you have any suggestions on how pin-ctrl should be set if we have
> multiple devices connected to GPMC like;
> All these devices will share:
> - control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
> - *some* data lines (gpmc_ad[])
> - *some* address lines (gpmc_a[])
> - but chip-selects will be different:
> 	gpmc_cs0: NAND
> 	gpmc_cs1: NOR
> 	gpmc_cs2: SMSC91xx
> 	gpmc_cs3: Camera

Well the pinctrl settings should be done a the child driver level
when it probes so drivers/base/pinctrl.c does what it's supposed
to do.

Regards,

Tony

[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape

[Pekon Gupta]

This patch adds support for 'NOR cape' having '128Mb 16-Bit' device connected to
GPMC chip-select [1]. Due to shared nature of GPMC pins exposed on BeagleBone
connector this cape cannot be simulataneously used with 'NAND cape'.

[1] http://elinux.org/Beagleboardtoys:BeagleBone_128Mb_16-Bit_NOR_Module

Signed-off-by: Pekon Gupta <pekon@ti.com>
---
 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 124 +++++++++++++++++++++++++-
 1 file changed, 123 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
index 6d8ebd8..72131f6 100644
--- a/arch/arm/boot/dts/am335x-bone-memory-cape.dts
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -38,11 +38,47 @@
 			0x9c (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_be0n_cle.gpmc_be0n_cle */
 		>;
 	};
+
+	bbcape_nor_flash_pins: bbcape_nor_flash_pins {
+		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 */
+			0x40 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a0.gpmc_a0 */
+			0x44 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a1.gpmc_a1 */
+			0x48 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a2.gpmc_a2 */
+			0x4c (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a3.gpmc_a3 */
+			0x50 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a4.gpmc_a4 */
+			0x54 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a5.gpmc_a5 */
+			0x58 (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a6.gpmc_a6 */
+			0x5c (MUX_MODE0 | PIN_OUTPUT)	/* gpmc_a7.gpmc_a7 */
+			0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )	/* gpmc_wait0.gpmc_wait0 */
+		/*	0x74 (MUX_MODE0 | PIN_OUTPUT_PULLUP) */	/* gpmc_wpn (not connected) */
+			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 {
-	ranges = <0 0 0 0x01000000>;	/* address range = 16MB (minimum GPMC partition) */
+	ranges = <0 0 0x08000000 0x01000000>;	/* address offset=128MB, range=128Mb=16MB */
 	nand@0,0 {
 		status = "disabled";
 		reg = <0 0 4>;		/* device IO registers */
@@ -124,4 +160,90 @@
 			reg = <0x00a00000 0x1f600000>;
 		};
 	};
+
+	nor@0,0 {
+		status = "disabled";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bbcape_nor_flash_pins>;
+		compatible = "cfi-flash";
+		reg = <0 0 0x01000000>;		/* device memory map = actual device size = 16MB */
+		/* generic bindings */
+		linux,mtd-name = "Micron,M29W128G";
+		bank-width = <2>;
+		/* vendor specific bindings */
+		gpmc,device-width = <2>;
+		gpmc,mux-add-data = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <120>;
+		gpmc,cs-wr-off-ns = <120>;
+		gpmc,adv-on-ns = <10>;
+		gpmc,adv-rd-off-ns = <40>;
+		gpmc,adv-wr-off-ns = <40>;
+		gpmc,we-on-ns = <50>;
+		gpmc,we-off-ns = <120>;
+		gpmc,oe-on-ns = <50>;
+		gpmc,oe-off-ns = <120>;
+		gpmc,access-ns = <100>;
+		gpmc,rd-cycle-ns = <120>;
+		gpmc,wr-cycle-ns = <120>;
+		gpmc,page-burst-access-ns = <0>;
+		gpmc,cycle2cycle-samecsen;
+		/* gpmc,cycle2cycle-diffcsen; */
+		gpmc,num-waitpins = <4>;
+		/* gpmc,wait-pin = <0>; */
+		/* gpmc,wait-on-read; */
+		/* gpmc,wait-on-write; */
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <20>;
+		/* gpmc,clk-activation-ns = <0>; */
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <80>;
+		gpmc,wr-data-mux-bus-ns = <100>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0x00000000 {
+			label = "NOR.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@0x00040000 {
+			label = "NOR.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@0x00080000 {
+			label = "NOR.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@0x000c0000 {
+			label = "NOR.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@0x00100000 {
+			label = "NOR.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@0x00180000 {
+			label = "NOR.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@0x00280000 {
+			label = "NOR.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@0x002c0000 {
+			label = "NOR.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@0x00300000 {
+			label = "NOR.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@0x00a00000 {
+			label = "NOR.file-system";
+			reg = <0x00a00000 0x00600000>;
+		};
+	};
 };
-- 
1.8.5.1.163.gd7aced9

[PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Pekon Gupta]

This patch adds support for LCD4 cape as advertised on
  http://elinux.org/CircuitCo:BeagleBone_LCD4

This cape has:
* 480x272 TFT-LCD panel
 - LCD panel datasheet and timing information are sourced from [1]
 - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
   enabling backlight power-supply. So 'gpio-backlight' driver is used instead
   of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).

* 4-wire resistive Touchscreen

*Known constrains*
As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts

[1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
    www.newhavendisplay.com/app_notes/OTA5180A.pdf

Signed-off-by: Pekon Gupta <pekon@ti.com>
---
 arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts              |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
 3 files changed, 106 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts

diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts
new file mode 100644
index 0000000..f3b7cef
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
@@ -0,0 +1,104 @@
+/*
+ * 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 display capes using LCD interface for display
+ * and GPIO or PWM interface for backlight controls.
+ */
+
+
+&am33xx_pinmux {
+	bbcape_backlight_pins: bbcape_backlight_pins {
+		pinctrl-single,pins = <
+			0x48  (PIN_OUTPUT | MUX_MODE7)		/* gpmc_a[2].GPIO1[18] (backlight control) */
+		>;
+	};
+
+	bbcape_lcd_pins: bbcape_lcd_pins {
+		pinctrl-single,pins = <
+			0xa0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data0.lcd_data0 */
+			0xa4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data1.lcd_data1 */
+			0xa8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data2.lcd_data2 */
+			0xac (PIN_OUTPUT | MUX_MODE0)		/* lcd_data3.lcd_data3 */
+			0xb0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data4.lcd_data4 */
+			0xb4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data5.lcd_data5 */
+			0xb8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data6.lcd_data6 */
+			0xbc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data7.lcd_data7 */
+			0xc0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data8.lcd_data8 */
+			0xc4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data9.lcd_data9 */
+			0xc8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data10.lcd_data10 */
+			0xcc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data11.lcd_data11 */
+			0xd0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data12.lcd_data12 */
+			0xd4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data13.lcd_data13 */
+			0xd8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data14.lcd_data14 */
+			0xdc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data15.lcd_data15 */
+			0xe0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_vsync.lcd_vsync */
+			0xe4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_hsync.lcd_hsync */
+			0xe8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_pclk.lcd_pclk */
+			0xec (PIN_OUTPUT | MUX_MODE0)		/* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
+			0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* mcasp0_fsr.gpio3[19] (lcd_disen) */
+		>;
+	};
+
+	bbcape_touchscreen_pins: bbcape_touchscreen_pins {
+		pinctrl-single,pins = <
+			0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* uart1_txd.gpio0[15] (enter) */
+			0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a0.gpio1[16] (left) */
+			0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a1.gpio1[17] (right) */
+			0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a3.gpio1[19] (up) */
+			0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* mcasp0_axr0.gpio3[16] (down) */
+		>;
+	};
+};
+
+
+/ {
+	backlight {
+		status = "disabled";
+		compatible = "gpio-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bbcape_backlight_pins>;
+		gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+		default-on;
+	};
+
+	panel {
+		status = "disabled";
+		compatible = "ti,tilcdc,panel";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bbcape_lcd_pins>;
+		panel-info {
+			ac-bias           = <255>;
+			ac-bias-intrpt    = <0>;
+			dma-burst-sz      = <16>;
+			bpp               = <16>;
+			fdd               = <0x80>;
+			sync-edge         = <0>;
+			sync-ctrl         = <0>;
+			raster-order      = <0>;
+			fifo-th           = <0>;
+		};
+		display-timings {
+			native-mode = <&timing0>;
+			/* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
+			timing0: 480x272 {
+				clock-frequency = <30000000>;
+				hactive = <480>;
+				vactive = <272>;
+				hfront-porch = <8>;
+				hback-porch = <47>;
+				hsync-len = <41>;
+				vback-porch = <2>;
+				vfront-porch = <3>;
+				vsync-len = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index f16bfcf..41439dc 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,7 @@
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
 #include "am335x-bone-memory-cape.dts"
+#include "am335x-bone-display-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 e6d7e54..03232c7 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,7 @@
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
 #include "am335x-bone-memory-cape.dts"
+#include "am335x-bone-display-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
-- 
1.8.5.1.163.gd7aced9

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Ezequiel Garcia]

Hello Pekon,

On 24 Jun 05:54 PM, Pekon Gupta wrote:
> This patch adds support for LCD4 cape as advertised on
>   http://elinux.org/CircuitCo:BeagleBone_LCD4
> 
> This cape has:
> * 480x272 TFT-LCD panel
>  - LCD panel datasheet and timing information are sourced from [1]
>  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>    enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>    of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
> 

I'm confused about this, can you clarify why you are not using pwm-backlight?

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

RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Gupta, Pekon]

>From: Ezequiel Garcia
>>On 24 Jun 05:54 PM, Pekon Gupta wrote:
>> This patch adds support for LCD4 cape as advertised on
>>   http://elinux.org/CircuitCo:BeagleBone_LCD4
>>
>> This cape has:
>> * 480x272 TFT-LCD panel
>>  - LCD panel datasheet and timing information are sourced from [1]
>>  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>>    enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>>    of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
>>
>
>I'm confused about this, can you clarify why you are not using pwm-backlight?
>

As per the schematics of this LCD4 cape board, "EHRPWM1A" pin controls
enabling/disabling of the power to backlight LED. It does not control the
voltage levels (brightness levels) of the LED. Thus it wasn't making sense
to use pwm-backlight driver which more suitable in cases where you have
multiple levels of brightness.
Here, you have only 2 levels "backlight=off | on", so I used gpio-backlight driver.
Though you can use pwm-backlight driver also, but the backlight turns ON
only when you set the /sys/class/backlight/<backlight_device>/brighteness
to maximum level (as set in DT).


with regards, pekon

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Ezequiel Garcia]

On 25 Jun 04:38 AM, Gupta, Pekon wrote:
> >From: Ezequiel Garcia
> >>On 24 Jun 05:54 PM, Pekon Gupta wrote:
> >> This patch adds support for LCD4 cape as advertised on
> >>   http://elinux.org/CircuitCo:BeagleBone_LCD4
> >>
> >> This cape has:
> >> * 480x272 TFT-LCD panel
> >>  - LCD panel datasheet and timing information are sourced from [1]
> >>  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
> >>    enabling backlight power-supply. So 'gpio-backlight' driver is used instead
> >>    of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
> >>
> >
> >I'm confused about this, can you clarify why you are not using pwm-backlight?
> >
> 
> As per the schematics of this LCD4 cape board, "EHRPWM1A" pin controls
> enabling/disabling of the power to backlight LED. It does not control the
> voltage levels (brightness levels) of the LED. Thus it wasn't making sense
> to use pwm-backlight driver which more suitable in cases where you have
> multiple levels of brightness.
> Here, you have only 2 levels "backlight=off | on", so I used gpio-backlight driver.
> Though you can use pwm-backlight driver also, but the backlight turns ON
> only when you set the /sys/class/backlight/<backlight_device>/brighteness
> to maximum level (as set in DT).
> 

Hm, I didn't know that. Thanks for this information.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Jason Kridner]

On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> wrote:
> This patch adds support for LCD4 cape as advertised on
>   http://elinux.org/CircuitCo:BeagleBone_LCD4
>
> This cape has:
> * 480x272 TFT-LCD panel
>  - LCD panel datasheet and timing information are sourced from [1]
>  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>    enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>    of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
>
> * 4-wire resistive Touchscreen
>
> *Known constrains*
> As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
> NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
> using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
>
> [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
>     www.newhavendisplay.com/app_notes/OTA5180A.pdf
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
>  arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts              |   1 +
>  arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
>  3 files changed, 106 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
>
> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts

If this is mean to be included, why not use the .dtsi extension rather
than .dts. .dts implies it is a top-level file.

> new file mode 100644
> index 0000000..f3b7cef
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> @@ -0,0 +1,104 @@
> +/*
> + * 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 display capes using LCD interface for display
> + * and GPIO or PWM interface for backlight controls.
> + */
> +
> +
> +&am33xx_pinmux {
> +       bbcape_backlight_pins: bbcape_backlight_pins {
> +               pinctrl-single,pins = <
> +                       0x48  (PIN_OUTPUT | MUX_MODE7)          /* gpmc_a[2].GPIO1[18] (backlight control) */
> +               >;
> +       };
> +
> +       bbcape_lcd_pins: bbcape_lcd_pins {
> +               pinctrl-single,pins = <
> +                       0xa0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data0.lcd_data0 */
> +                       0xa4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data1.lcd_data1 */
> +                       0xa8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data2.lcd_data2 */
> +                       0xac (PIN_OUTPUT | MUX_MODE0)           /* lcd_data3.lcd_data3 */
> +                       0xb0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data4.lcd_data4 */
> +                       0xb4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data5.lcd_data5 */
> +                       0xb8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data6.lcd_data6 */
> +                       0xbc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data7.lcd_data7 */
> +                       0xc0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data8.lcd_data8 */
> +                       0xc4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data9.lcd_data9 */
> +                       0xc8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data10.lcd_data10 */
> +                       0xcc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data11.lcd_data11 */
> +                       0xd0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data12.lcd_data12 */
> +                       0xd4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data13.lcd_data13 */
> +                       0xd8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_data14.lcd_data14 */
> +                       0xdc (PIN_OUTPUT | MUX_MODE0)           /* lcd_data15.lcd_data15 */
> +                       0xe0 (PIN_OUTPUT | MUX_MODE0)           /* lcd_vsync.lcd_vsync */
> +                       0xe4 (PIN_OUTPUT | MUX_MODE0)           /* lcd_hsync.lcd_hsync */
> +                       0xe8 (PIN_OUTPUT | MUX_MODE0)           /* lcd_pclk.lcd_pclk */
> +                       0xec (PIN_OUTPUT | MUX_MODE0)           /* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
> +                       0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)   /* mcasp0_fsr.gpio3[19] (lcd_disen) */
> +               >;
> +       };
> +
> +       bbcape_touchscreen_pins: bbcape_touchscreen_pins {
> +               pinctrl-single,pins = <
> +                       0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* uart1_txd.gpio0[15] (enter) */
> +                       0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a0.gpio1[16] (left) */
> +                       0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a1.gpio1[17] (right) */
> +                       0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* gpmc_a3.gpio1[19] (up) */
> +                       0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)          /* mcasp0_axr0.gpio3[16] (down) */
> +               >;
> +       };
> +};
> +
> +
> +/ {
> +       backlight {
> +               status = "disabled";
> +               compatible = "gpio-backlight";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&bbcape_backlight_pins>;
> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> +               default-on;
> +       };
> +
> +       panel {
> +               status = "disabled";

Where are you expecting to enable this? I'm guessing through your
u-boot hacking? Certainly I can see editing the boot script to make
this work, but I don't see how this results in the average user simply
plugging in the cape and having it work without having to edit files.
Perhaps you can put some real logic into the bootloader that looks at
the cape EEPROMs?

Have you considered using tools like pinmux-helper as is done with the
cape-universal overlay?
https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-00A0.dts

I've been hacking with adding all of these pinmux helpers to the main
.dts. I think you are encouraging me to add it to include files to
make it a bit more granular.

http://paste.debian.net/106319/

> +               compatible = "ti,tilcdc,panel";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&bbcape_lcd_pins>;
> +               panel-info {
> +                       ac-bias           = <255>;
> +                       ac-bias-intrpt    = <0>;
> +                       dma-burst-sz      = <16>;
> +                       bpp               = <16>;
> +                       fdd               = <0x80>;
> +                       sync-edge         = <0>;
> +                       sync-ctrl         = <0>;
> +                       raster-order      = <0>;
> +                       fifo-th           = <0>;
> +               };
> +               display-timings {
> +                       native-mode = <&timing0>;
> +                       /* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
> +                       timing0: 480x272 {
> +                               clock-frequency = <30000000>;
> +                               hactive = <480>;
> +                               vactive = <272>;
> +                               hfront-porch = <8>;
> +                               hback-porch = <47>;
> +                               hsync-len = <41>;
> +                               vback-porch = <2>;
> +                               vfront-porch = <3>;
> +                               vsync-len = <10>;
> +                               hsync-active = <0>;
> +                               vsync-active = <0>;
> +                               de-active = <1>;
> +                               pixelclk-active = <0>;
> +                       };
> +               };
> +       };
> +};

I appreciate the enthusiasm to get this support into the mainline. If
it goes, I'll try to follow with a bunch of other outstanding changes
we have sitting in the vendor tree right now.

Have you looked at the features in the devicetree for this cape that
is currently pushed in the vendor tree?

https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-01-00A1.dts

> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index f16bfcf..41439dc 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-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 e6d7e54..03232c7 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>
>  &ldo3_reg {
>         regulator-min-microvolt = <1800000>;
> --
> 1.8.5.1.163.gd7aced9
>

RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Gupta, Pekon]

>From: Jason Kridner [mailto:jkridner@gmail.com]
>On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> wrote:
>> This patch adds support for LCD4 cape as advertised on
>>   http://elinux.org/CircuitCo:BeagleBone_LCD4
[...]

>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-
>display-cape.dts
>
>If this is mean to be included, why not use the .dtsi extension rather
>than .dts. .dts implies it is a top-level file.
>
I followed the ideology given in in below discussion
http://comments.gmane.org/gmane.linux.drivers.devicetree/13921

As I understood .dtsi file extension should be used for silicon DT data which
which remains common for all the boards using that silicon (like am33xx.dtsi).
And .dts is for board specific DT data.
However, anything works for me, as its just matter of file-name-extension.	
So should I rename all files to .dtsi ?

[...]

>> +/ {
>> +       backlight {
>> +               status = "disabled";
>> +               compatible = "gpio-backlight";
>> +               pinctrl-names = "default";
>> +               pinctrl-0 = <&bbcape_backlight_pins>;
>> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
>> +               default-on;
>> +       };
>> +
>> +       panel {
>> +               status = "disabled";
>
>Where are you expecting to enable this? I'm guessing through your
>u-boot hacking? Certainly I can see editing the boot script to make
>this work, but I don't see how this results in the average user simply
>plugging in the cape and having it work without having to edit files.
>
Yes, using u-boot commands, *without touching any source file*.
I'm planning to send patch for adding following helper commands  in u-boot
u-boot> fdt node enable <node-path>
u-boot> fdt node disable <node-path>
If that's accepted, enabling disabling capes will become very easy.
And, as you said user can put these commands in scripts (like Uenv.txt)
or environment variable, and execute them automatically at each boot.


>Perhaps you can put some real logic into the bootloader that looks at
>the cape EEPROMs?
>
No, I don't want to go the EEPROM way, because of reasons suggested
in earlier mail. It's not scalable, especially when you don't have control
over what type and how third-party is developing the capes.


>Have you considered using tools like pinmux-helper as is done with the
>cape-universal overlay?
>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
>00A0.dts
>
Yes, I have seen that. In pin-mux helper pins are configured not based on
their actual names but as they appear on P8 and P9 headers of Beaglebone.
- For shared pins, you have defined all possible functionality.
- For dedicated pins, there is single fragment.
Now there are two questions..
(1) Do we need to update this cape-universal-xx.dts everytime a new
Cape in market uses some dedicated pin for some muxed functionality ?
(2) I'm not sure but kernel does _not_ free the memory allocated to 
DT fragment. If so, this universal fragment which has pin-mux for all
P8 and P9 pins will block the memory forever. Would be good to know
the in-memory size required for this universal fragment ?


>I've been hacking with adding all of these pinmux helpers to the main
>.dts. I think you are encouraging me to add it to include files to
>make it a bit more granular.
>
>http://paste.debian.net/106319/
>
Yes, using include files would be good.
Also one minor feedback. Please use macros for Pin directions, Pulls, etc
instead of hex numbers, it make it more readable. And then you don't need
to specify that in comments.
-  0xa0 0x08	/* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
+ 0xa0	(OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)    /* lcd_data0.lcd_data0 */


>I appreciate the enthusiasm to get this support into the mainline. If
>it goes, I'll try to follow with a bunch of other outstanding changes
>we have sitting in the vendor tree right now.
>
Thanks. Waiting for Tony to at-least 'Ack' or say if this is acceptable approach.


>Have you looked at the features in the devicetree for this cape that
>is currently pushed in the vendor tree?
>
>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-
>01-00A1.dts
>
Yes, I have not added touchscreen support.
I developed this DTS independently while debugging some Display v/s NAND issue.
If these DTS patches are acceptable, then I'll refine them further.


with regards, pekon

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Jason Kridner]

On Wed, Jun 25, 2014 at 1:49 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Jason Kridner [mailto:jkridner@gmail.com]
>>On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta <pekon@ti.com> wrote:
>>> This patch adds support for LCD4 cape as advertised on
>>>   http://elinux.org/CircuitCo:BeagleBone_LCD4
> [...]
>
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-
>>display-cape.dts
>>
>>If this is mean to be included, why not use the .dtsi extension rather
>>than .dts. .dts implies it is a top-level file.
>>
> I followed the ideology given in in below discussion
> http://comments.gmane.org/gmane.linux.drivers.devicetree/13921
>
> As I understood .dtsi file extension should be used for silicon DT data which
> which remains common for all the boards using that silicon (like am33xx.dtsi).
> And .dts is for board specific DT data.
> However, anything works for me, as its just matter of file-name-extension.
> So should I rename all files to .dtsi ?

I believe the thread is not thinking of "board-level" as being add-on
boards. I don't think it disagrees that if it is an include file, it
should be called .dtsi. If it is called .dts, the assumption should be
that it results in a .dtb (or .dtbo if for an overlay --- not yet a
solution in mainline).

>
> [...]
>
>>> +/ {
>>> +       backlight {
>>> +               status = "disabled";
>>> +               compatible = "gpio-backlight";
>>> +               pinctrl-names = "default";
>>> +               pinctrl-0 = <&bbcape_backlight_pins>;
>>> +               gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
>>> +               default-on;
>>> +       };
>>> +
>>> +       panel {
>>> +               status = "disabled";
>>
>>Where are you expecting to enable this? I'm guessing through your
>>u-boot hacking? Certainly I can see editing the boot script to make
>>this work, but I don't see how this results in the average user simply
>>plugging in the cape and having it work without having to edit files.
>>
> Yes, using u-boot commands, *without touching any source file*.
> I'm planning to send patch for adding following helper commands  in u-boot
> u-boot> fdt node enable <node-path>
> u-boot> fdt node disable <node-path>
> If that's accepted, enabling disabling capes will become very easy.
> And, as you said user can put these commands in scripts (like Uenv.txt)
> or environment variable, and execute them automatically at each boot.
>
>
>>Perhaps you can put some real logic into the bootloader that looks at
>>the cape EEPROMs?
>>
> No, I don't want to go the EEPROM way, because of reasons suggested
> in earlier mail. It's not scalable, especially when you don't have control
> over what type and how third-party is developing the capes.

Well, I have no interest in needing to manually switch my uEnv.txt
file based on whatever cape I have installed. Your patches to put
by-default-disabled disabled support for various capes into the the
main .dtb feels useful to me. I'm just going to optimize my systems to
utilize the EEPROM (when provided) to trigger loading the
configuration for me.

>
>
>>Have you considered using tools like pinmux-helper as is done with the
>>cape-universal overlay?
>>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
>>00A0.dts
>>
> Yes, I have seen that. In pin-mux helper pins are configured not based on
> their actual names but as they appear on P8 and P9 headers of Beaglebone.
> - For shared pins, you have defined all possible functionality.
> - For dedicated pins, there is single fragment.
> Now there are two questions..
> (1) Do we need to update this cape-universal-xx.dts everytime a new
> Cape in market uses some dedicated pin for some muxed functionality ?

cape-universalXXX.dts needs to be moved into the main .dtb (via
.dtsi). Can you give an example of what you mean by shared pins and
dedicated pins here? It seems to me all the pins have multiple
fragments except ADC pins and perhaps the I2C port used for expansion
EEPROMs, but even that one CAN be muxed.

> (2) I'm not sure but kernel does _not_ free the memory allocated to
> DT fragment. If so, this universal fragment which has pin-mux for all
> P8 and P9 pins will block the memory forever. Would be good to know
> the in-memory size required for this universal fragment ?

How can I check easily? Obviously loading all of these drivers is
going to have an impact.

>
>
>>I've been hacking with adding all of these pinmux helpers to the main
>>.dts. I think you are encouraging me to add it to include files to
>>make it a bit more granular.
>>
>>http://paste.debian.net/106319/
>>
> Yes, using include files would be good.
> Also one minor feedback. Please use macros for Pin directions, Pulls, etc
> instead of hex numbers, it make it more readable. And then you don't need
> to specify that in comments.
> -  0xa0 0x08    /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> + 0xa0  (OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)    /* lcd_data0.lcd_data0 */

If those are supported in the syntax and exist in some headers, I will use them.

>
>
>>I appreciate the enthusiasm to get this support into the mainline. If
>>it goes, I'll try to follow with a bunch of other outstanding changes
>>we have sitting in the vendor tree right now.
>>
> Thanks. Waiting for Tony to at-least 'Ack' or say if this is acceptable approach.
>
>
>>Have you looked at the features in the devicetree for this cape that
>>is currently pushed in the vendor tree?
>>
>>https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-BONE-LCD4-
>>01-00A1.dts
>>
> Yes, I have not added touchscreen support.
> I developed this DTS independently while debugging some Display v/s NAND issue.
> If these DTS patches are acceptable, then I'll refine them further.
>
>
> with regards, pekon

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Guido Martínez]

Hi Pekon,

I had some issues with this patch. Booting linux-next on a BeagleBone
Black with this exact LCD left me with an unusable white screen. Please
see below for some details.

On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:
> This patch adds support for LCD4 cape as advertised on
>   http://elinux.org/CircuitCo:BeagleBone_LCD4
> 
> This cape has:
> * 480x272 TFT-LCD panel
>  - LCD panel datasheet and timing information are sourced from [1]
>  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>    enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>    of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
> 
> * 4-wire resistive Touchscreen
> 
> *Known constrains*
> As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
> NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
> using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
> 
> [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
>     www.newhavendisplay.com/app_notes/OTA5180A.pdf
> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
>  arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 +++++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts              |   1 +
>  arch/arm/boot/dts/am335x-boneblack.dts         |   1 +
>  3 files changed, 106 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> new file mode 100644
> index 0000000..f3b7cef
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
> @@ -0,0 +1,104 @@
> +/*
> + * 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 display capes using LCD interface for display
> + * and GPIO or PWM interface for backlight controls.
> + */
> +
> +
> +&am33xx_pinmux {
> +	bbcape_backlight_pins: bbcape_backlight_pins {
> +		pinctrl-single,pins = <
> +			0x48  (PIN_OUTPUT | MUX_MODE7)		/* gpmc_a[2].GPIO1[18] (backlight control) */
> +		>;
> +	};
> +
> +	bbcape_lcd_pins: bbcape_lcd_pins {
> +		pinctrl-single,pins = <
> +			0xa0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data0.lcd_data0 */
> +			0xa4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data1.lcd_data1 */
> +			0xa8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data2.lcd_data2 */
> +			0xac (PIN_OUTPUT | MUX_MODE0)		/* lcd_data3.lcd_data3 */
> +			0xb0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data4.lcd_data4 */
> +			0xb4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data5.lcd_data5 */
> +			0xb8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data6.lcd_data6 */
> +			0xbc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data7.lcd_data7 */
> +			0xc0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data8.lcd_data8 */
> +			0xc4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data9.lcd_data9 */
> +			0xc8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data10.lcd_data10 */
> +			0xcc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data11.lcd_data11 */
> +			0xd0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data12.lcd_data12 */
> +			0xd4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data13.lcd_data13 */
> +			0xd8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_data14.lcd_data14 */
> +			0xdc (PIN_OUTPUT | MUX_MODE0)		/* lcd_data15.lcd_data15 */
> +			0xe0 (PIN_OUTPUT | MUX_MODE0)		/* lcd_vsync.lcd_vsync */
> +			0xe4 (PIN_OUTPUT | MUX_MODE0)		/* lcd_hsync.lcd_hsync */
> +			0xe8 (PIN_OUTPUT | MUX_MODE0)		/* lcd_pclk.lcd_pclk */
> +			0xec (PIN_OUTPUT | MUX_MODE0)		/* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
> +			0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* mcasp0_fsr.gpio3[19] (lcd_disen) */
> +		>;
> +	};
> +
> +	bbcape_touchscreen_pins: bbcape_touchscreen_pins {
> +		pinctrl-single,pins = <
> +			0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* uart1_txd.gpio0[15] (enter) */
> +			0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a0.gpio1[16] (left) */
> +			0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a1.gpio1[17] (right) */
> +			0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* gpmc_a3.gpio1[19] (up) */
> +			0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)		/* mcasp0_axr0.gpio3[16] (down) */
> +		>;
> +	};
> +};
> +
> +
> +/ {
> +	backlight {
> +		status = "disabled";
> +		compatible = "gpio-backlight";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bbcape_backlight_pins>;
> +		gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> +		default-on;
> +	};
> +
> +	panel {
> +		status = "disabled";
> +		compatible = "ti,tilcdc,panel";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bbcape_lcd_pins>;
> +		panel-info {
> +			ac-bias           = <255>;
> +			ac-bias-intrpt    = <0>;
> +			dma-burst-sz      = <16>;
> +			bpp               = <16>;
> +			fdd               = <0x80>;
> +			sync-edge         = <0>;
> +			sync-ctrl         = <0>;
I had to set this to <1>. Does that make sense? 

> +			raster-order      = <0>;
> +			fifo-th           = <0>;
> +		};
> +		display-timings {
> +			native-mode = <&timing0>;
> +			/* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
> +			timing0: 480x272 {
> +				clock-frequency = <30000000>;
> +				hactive = <480>;
> +				vactive = <272>;
> +				hfront-porch = <8>;
> +				hback-porch = <47>;
> +				hsync-len = <41>;
> +				vback-porch = <2>;
> +				vfront-porch = <3>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
Are you sure these timings are ok? When enabling the sync control I get
an usable display, but it looks a bit funny. For example an all black
display looks very clear and has a dotted pattern.

I tried to take a picture of it but it doesn't show.

Also I'm just guessing about the timings, maybe it's something else?

> +			};
> +		};
> +	};
> +};
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index f16bfcf..41439dc 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-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 e6d7e54..03232c7 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -10,6 +10,7 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  #include "am335x-bone-memory-cape.dts"
> +#include "am335x-bone-display-cape.dts"
>  
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;
> -- 
> 1.8.5.1.163.gd7aced9
> 
> --
> 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

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Darren Etheridge]

Guido, Pekon,

On 06/26/2014 10:40 AM, Guido Martínez wrote:
> Hi Pekon,
>
> I had some issues with this patch. Booting linux-next on a BeagleBone
> Black with this exact LCD left me with an unusable white screen. Please
> see below for some details.
>
> On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:
>> This patch adds support for LCD4 cape as advertised on
>>    http://elinux.org/CircuitCo:BeagleBone_LCD4
>>
>> This cape has:
>> * 480x272 TFT-LCD panel
>>   - LCD panel datasheet and timing information are sourced from [1]
>>   - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>>     enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>>     of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
>>
>> * 4-wire resistive Touchscreen
>>
>> *Known constrains*
>> As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
>> NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
>> using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
>>
>> [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
>>      www.newhavendisplay.com/app_notes/OTA5180A.pdf
>>
>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>> ---

<snip>

>> +
>> +	panel {
>> +		status = "disabled";
>> +		compatible = "ti,tilcdc,panel";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&bbcape_lcd_pins>;
>> +		panel-info {
>> +			ac-bias           = <255>;
>> +			ac-bias-intrpt    = <0>;
>> +			dma-burst-sz      = <16>;
>> +			bpp               = <16>;
>> +			fdd               = <0x80>;
>> +			sync-edge         = <0>;
>> +			sync-ctrl         = <0>;
> I had to set this to <1>. Does that make sense?
>
>> +			raster-order      = <0>;
>> +			fifo-th           = <0>;
>> +		};
>> +		display-timings {
>> +			native-mode = <&timing0>;
>> +			/* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
>> +			timing0: 480x272 {
>> +				clock-frequency = <30000000>;
>> +				hactive = <480>;
>> +				vactive = <272>;
>> +				hfront-porch = <8>;
>> +				hback-porch = <47>;
>> +				hsync-len = <41>;
>> +				vback-porch = <2>;
>> +				vfront-porch = <3>;
>> +				vsync-len = <10>;
>> +				hsync-active = <0>;
>> +				vsync-active = <0>;
>> +				de-active = <1>;
>> +				pixelclk-active = <0>;
> Are you sure these timings are ok? When enabling the sync control I get
> an usable display, but it looks a bit funny. For example an all black
> display looks very clear and has a dotted pattern.
>
> I tried to take a picture of it but it doesn't show.

These timings look wrong to me, for instance this sets a clock frequency 
of 30MHz where as the linked app-note says 9MHz.  I think the LCD4 cape 
uses the same LCD panel as is used on the AM335x EVMSK.  Therefore the 
display timings from my DT patch for the EVMSK should work: 
https://patchwork.kernel.org/patch/4144801/

Darren

>
> Also I'm just guessing about the timings, maybe it's something else?
>
>> +			};
>> +		};
>> +	};
>> +};
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>> index f16bfcf..41439dc 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -10,6 +10,7 @@
>>   #include "am33xx.dtsi"
>>   #include "am335x-bone-common.dtsi"
>>   #include "am335x-bone-memory-cape.dts"
>> +#include "am335x-bone-display-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 e6d7e54..03232c7 100644
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -10,6 +10,7 @@
>>   #include "am33xx.dtsi"
>>   #include "am335x-bone-common.dtsi"
>>   #include "am335x-bone-memory-cape.dts"
>> +#include "am335x-bone-display-cape.dts"
>>
>>   &ldo3_reg {
>>   	regulator-min-microvolt = <1800000>;
>> --
>> 1.8.5.1.163.gd7aced9
>>
>> --
>> 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 v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Gupta, Pekon]

Hi Daren, Guido,

>From: Etheridge, Darren
>>On 06/26/2014 10:40 AM, Guido Martínez wrote:
>> I had some issues with this patch. Booting linux-next on a BeagleBone
>> Black with this exact LCD left me with an unusable white screen. Please
>> see below for some details.
>>
>>> On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:
>>> This patch adds support for LCD4 cape as advertised on
>>>    http://elinux.org/CircuitCo:BeagleBone_LCD4
>>>
>>> This cape has:
>>> * 480x272 TFT-LCD panel
>>>   - LCD panel datasheet and timing information are sourced from [1]
>>>   - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
>>>     enabling backlight power-supply. So 'gpio-backlight' driver is used instead
>>>     of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
>>>
>>> * 4-wire resistive Touchscreen
>>>
>>> *Known constrains*
>>> As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
>>> NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
>>> using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
>>>
>>> [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
>>>      www.newhavendisplay.com/app_notes/OTA5180A.pdf
>>>
>>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>>> ---
>
><snip>
>
>>> +
>>> +	panel {
>>> +		status = "disabled";
>>> +		compatible = "ti,tilcdc,panel";
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&bbcape_lcd_pins>;
>>> +		panel-info {
>>> +			ac-bias           = <255>;
>>> +			ac-bias-intrpt    = <0>;
>>> +			dma-burst-sz      = <16>;
>>> +			bpp               = <16>;
>>> +			fdd               = <0x80>;
>>> +			sync-edge         = <0>;
>>> +			sync-ctrl         = <0>;
>> I had to set this to <1>. Does that make sense?
>>
Yes, I'll check this one again at my end.

>>> +			raster-order      = <0>;
>>> +			fifo-th           = <0>;
>>> +		};
>>> +		display-timings {
>>> +			native-mode = <&timing0>;
>>> +			/* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
>>> +			timing0: 480x272 {
>>> +				clock-frequency = <30000000>;
>>> +				hactive = <480>;
>>> +				vactive = <272>;
>>> +				hfront-porch = <8>;
>>> +				hback-porch = <47>;
>>> +				hsync-len = <41>;
>>> +				vback-porch = <2>;
>>> +				vfront-porch = <3>;
>>> +				vsync-len = <10>;
>>> +				hsync-active = <0>;
>>> +				vsync-active = <0>;
>>> +				de-active = <1>;
>>> +				pixelclk-active = <0>;
>> Are you sure these timings are ok? When enabling the sync control I get
>> an usable display, but it looks a bit funny. For example an all black
>> display looks very clear and has a dotted pattern.
>>
>> I tried to take a picture of it but it doesn't show.
>>
I could run and test 'fbtest' and 'fbconsole' on this cape, using following configs
CONFIG_DRM=y
CONFIG_DRM_TILCDC=y
[...]
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FRAMEBUFFER_CONSOLE=y


>These timings look wrong to me, for instance this sets a clock frequency
>of 30MHz where as the linked app-note says 9MHz.  I think the LCD4 cape
>uses the same LCD panel as is used on the AM335x EVMSK.  Therefore the
>display timings from my DT patch for the EVMSK should work:
>https://patchwork.kernel.org/patch/4144801/
>
Yes, probably I got the pixel-clock timing wrong, I'll fix this.
It should be 9.2MHz as per
www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
Table: Electrical Characteristics
But as 'hsync' timings are relative to pixel-clock somehow it worked for me.

I got other vsync and hsync timings from following reference:
	www.newhavendisplay.com/app_notes/OTA5180A.pdf
	Table: 8.4.1 480XRGBX272 Vertical Timing
	Table: 8.4.2 480XRGBX272 Horizontal Timing
And I/O signal polarity for vsync-active and hsync-active from
	Table: 5. SIGNAL DESCRIPTIONS


with regards, pekon

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

[Pekon Gupta]

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


Pekon Gupta (3):
  ARM: dts: am335x-bone: add support for beaglebone NAND cape
  ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
  ARM: dts: am437x-gp-evm: add support for parallel NAND flash

 arch/arm/boot/dts/am335x-bone.dts      | 123 +++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-boneblack.dts | 120 ++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/am437x-gp-evm.dts    | 107 ++++++++++++++++++++++++++++
 3 files changed, 350 insertions(+)

-- 
1.8.5.1.163.gd7aced9

[PATCH v1 1/3] 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

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

 - 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>
---
 arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 123 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,36 @@
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
 
+&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 */
+		>;
+	};
+};
+
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
 	regulator-max-microvolt = <3300000>;
@@ -27,3 +57,96 @@
 &aes {
 	status = "okay";
 };
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ *      status = "disabled";
+ * };
+ * &elm {
+ *	status = "okay";
+ * };
+ * &gpmc {
+ *	status = "okay";
+ * };
+ */
+&gpmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
+	nand@0,0 {
+		reg = <0 0 0>; /* CS0, offset 0 */
+		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-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-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

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

[Nishanth Menon]

On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> 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
> 
>  - Selction of boot modes can be controlled via  DIP switch(SW2) present on
>    Memory Expander cape.
>    SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC-> SPI -> UART -> USB
>    SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)
>    So to flash NAND, first boot via MMC or other sources and then switch to
>    SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
> 
>  - 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>
> ---
>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 123 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..be2c572 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts

better to make a nand_cape dts which includes the am335x-bone.dts?

> @@ -10,6 +10,36 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  
> +&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 */
> +		>;
> +	};
> +};
> +
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;
>  	regulator-max-microvolt = <3300000>;
> @@ -27,3 +57,96 @@
>  &aes {
>  	status = "okay";
>  };
> +
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + *      status = "disabled";
> + * };
> + * &elm {
> + *	status = "okay";
> + * };
> + * &gpmc {
> + *	status = "okay";
> + * };
> + */
> +&gpmc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&nand_flash_x16>;
> +	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
> +	nand@0,0 {
> +		reg = <0 0 0>; /* CS0, offset 0 */
> +		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-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-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>;
> +		};
> +	};
> +};
> 


-- 
Regards,
Nishanth Menon

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

[Gupta, Pekon]

Hi,

>From: Menon, Nishanth
>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>> 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]
[...]
>> [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>
>> ---
>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 123 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>> index 94ee427..be2c572 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>
>better to make a nand_cape dts which includes the am335x-bone.dts?
>
Actually, I'm not in favor of having too many "xx_board_common.dts" files,
because it un-necessarily complexes things.

We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
Beaglebone-black in future. 
Example: some capes are not compatible to beaglebone-black [1], [2].

So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
unless there is a strong convincing reason otherwise.


[1] http://elinux.org/CircuitCo:BeagleBoardToys
[2] http://elinux.org/BeagleBone_Black_Capes

with regards, pekon

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

[Nishanth Menon]

On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> Hi,
>
>>From: Menon, Nishanth
>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>> 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]
> [...]
>>> [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>
>>> ---
>>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 123 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>> index 94ee427..be2c572 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>
>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>
> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> because it un-necessarily complexes things.
>
> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> Beaglebone-black in future.
> Example: some capes are not compatible to beaglebone-black [1], [2].
>
> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> unless there is a strong convincing reason otherwise.
>
>
> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> [2] http://elinux.org/BeagleBone_Black_Capes



Right, and adding NAND, GPMC nodes and asking folks to uncomment
sections into a generic board file (which by default has none) makes
more sense? I dont use NAND capes or might create my own cape. overo
has the same challenges as bone family has.I dont see asking folks to
uncomment entries to use the cape is a nicer alternative to having
more dts entries.

Regards,
Nishanth Menon

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

[Robert Nelson]

On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>> Hi,
>>
>>>From: Menon, Nishanth
>>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>> 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]
>> [...]
>>>> [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>
>>>> ---
>>>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 123 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 94ee427..be2c572 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>
>>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>>
>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>> because it un-necessarily complexes things.
>>
>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>> Beaglebone-black in future.
>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>
>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>> unless there is a strong convincing reason otherwise.
>>
>>
>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>> [2] http://elinux.org/BeagleBone_Black_Capes
>
>
>
> Right, and adding NAND, GPMC nodes and asking folks to uncomment
> sections into a generic board file (which by default has none) makes
> more sense? I dont use NAND capes or might create my own cape. overo
> has the same challenges as bone family has.I dont see asking folks to
> uncomment entries to use the cape is a nicer alternative to having
> more dts entries.

This is just going to get more messy with every cape addition. Should
we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
mainline kernel.org.

Then create a repo on github.com/beagleboard/ with every
<bone/black>-<first level cape>.dts option?

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[Tony Lindgren]

* Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> > On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> >> Hi,
> >>
> >>>From: Menon, Nishanth
> >>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> >>>> 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]
> >> [...]
> >>>> [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>
> >>>> ---
> >>>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
> >>>>  1 file changed, 123 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> >>>> index 94ee427..be2c572 100644
> >>>> --- a/arch/arm/boot/dts/am335x-bone.dts
> >>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >>>
> >>>better to make a nand_cape dts which includes the am335x-bone.dts?
> >>>
> >> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> >> because it un-necessarily complexes things.
> >>
> >> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> >> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> >> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> >> Beaglebone-black in future.
> >> Example: some capes are not compatible to beaglebone-black [1], [2].
> >>
> >> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> >> unless there is a strong convincing reason otherwise.
> >>
> >>
> >> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> >> [2] http://elinux.org/BeagleBone_Black_Capes
> >
> >
> >
> > Right, and adding NAND, GPMC nodes and asking folks to uncomment
> > sections into a generic board file (which by default has none) makes
> > more sense? I dont use NAND capes or might create my own cape. overo
> > has the same challenges as bone family has.I dont see asking folks to
> > uncomment entries to use the cape is a nicer alternative to having
> > more dts entries.
> 
> This is just going to get more messy with every cape addition. Should
> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
> mainline kernel.org.
> 
> Then create a repo on github.com/beagleboard/ with every
> <bone/black>-<first level cape>.dts option?

Or just include all devices on the most common capes but have their
status as disabled by default.

For the pinctrl, we need to make sure the pins for a device are not
muxed if it's set to disabled state.

Regards,

Tony

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

[Nishanth Menon]

On 03/12/2014 02:28 PM, Tony Lindgren wrote:
> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>> Hi,
>>>>
>>>>> From: Menon, Nishanth
>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>> 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]
>>>> [...]
>>>>>> [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>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 123 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>> index 94ee427..be2c572 100644
>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>
>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>
>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>> because it un-necessarily complexes things.
>>>>
>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>> Beaglebone-black in future.
>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>
>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>> unless there is a strong convincing reason otherwise.
>>>>
>>>>
>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>
>>>
>>>
>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>> sections into a generic board file (which by default has none) makes
>>> more sense? I dont use NAND capes or might create my own cape. overo
>>> has the same challenges as bone family has.I dont see asking folks to
>>> uncomment entries to use the cape is a nicer alternative to having
>>> more dts entries.
>>
>> This is just going to get more messy with every cape addition. Should
>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>> mainline kernel.org.
>>
>> Then create a repo on github.com/beagleboard/ with every
>> <bone/black>-<first level cape>.dts option?
> 
> Or just include all devices on the most common capes but have their
> status as disabled by default.
> 
> For the pinctrl, we need to make sure the pins for a device are not
> muxed if it's set to disabled state.

You do have a bunch of "if you want nand, disable mmc2" configuration
in the usage of cape configurations such as this patch, or in the case
of [1] (audio cape), different regulator usage etc. Maintaining out of
tree cape dts might be an option, but that is prone to maintenance
burden as device tree conversion goes on (yeah, all the dt as ABI
stuff aside).

Keeping aside the subjective nature of what entitles a cape being a
"common cape",even introducing nodes that belong to three or four
different first level capes will definitely have it's own sets of
problems.

The ideal solution would be some folks pitching in on what Matt
pointed in [2] - basically "upstream a resource manager on
top of the basic overlay support that's in progress" and introduce
capes as part of that overlay support once it is upstream.

Failing which, keeping the base bone dts to basic stuff that bare
board supports and having per "first level cape" dts which includes
relevant dts sounds to me the only rationale and easily usable (as in:
without much device tree knowledge) - again, I admit "easily" is
subjective here.


[1] https://lkml.org/lkml/2014/2/5/183
[2] https://lkml.org/lkml/2014/2/5/247

-- 
Regards,
Nishanth Menon

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

[Gupta, Pekon]

>-----Original Message-----
>From: Menon, Nishanth
>Sent: Thursday, March 13, 2014 2:21 AM
>To: Tony Lindgren; Robert Nelson
>Cc: Gupta, Pekon; bcousson@baylibre.com; linux-omap; linux-mtd
>Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>
>On 03/12/2014 02:28 PM, Tony Lindgren wrote:
>> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Menon, Nishanth
>>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>>> 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]
>>>>> [...]
>>>>>>> [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>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>>>  1 file changed, 123 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> index 94ee427..be2c572 100644
>>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>
>>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>>
>>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>>> because it un-necessarily complexes things.
>>>>>
>>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>>> Beaglebone-black in future.
>>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>>
>>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>>> unless there is a strong convincing reason otherwise.
>>>>>
>>>>>
>>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>>
>>>>
>>>>
>>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>>> sections into a generic board file (which by default has none) makes
>>>> more sense? I dont use NAND capes or might create my own cape. overo
>>>> has the same challenges as bone family has.I dont see asking folks to
>>>> uncomment entries to use the cape is a nicer alternative to having
>>>> more dts entries.

I think this is different discussion from previous one ..
"common DTS file" v/s "replicated DTS entries in individual board files"
because 'uncomment' issue will remain in both scenarios. (please read below)


>>>
>>> This is just going to get more messy with every cape addition. Should
>>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>>> mainline kernel.org.
>>>
>>> Then create a repo on github.com/beagleboard/ with every
>>> <bone/black>-<first level cape>.dts option?
>>
>> Or just include all devices on the most common capes but have their
>> status as disabled by default.
>>
>> For the pinctrl, we need to make sure the pins for a device are not
>> muxed if it's set to disabled state.

Yes, this is exactly what I intended. Therefore if you revisit the
"uncomment" section, then you would find that there is mmc2=disabled
because on beaglebone-black eMMC (MMC2) pinctrl conflicts with
NAND pin-ctrl.
------------------------
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + *      status = "disabled";
> + * };
> + * &elm {
> + *	status = "okay";
> + * };
> + * &gpmc {
> + *	status = "okay";
> + * };
------------------------
And I agree 'uncommenting' is not cleaner approach here, so if everyone
agrees, I can remove the above comment and just keep NAND DT node
"disabled" by default.


>
>You do have a bunch of "if you want nand, disable mmc2" configuration
>in the usage of cape configurations such as this patch, or in the case
>of [1] (audio cape), different regulator usage etc. Maintaining out of
>tree cape dts might be an option, but that is prone to maintenance
>burden as device tree conversion goes on (yeah, all the dt as ABI
>stuff aside).
>
>Keeping aside the subjective nature of what entitles a cape being a
>"common cape",even introducing nodes that belong to three or four
>different first level capes will definitely have it's own sets of
>problems.
>
>The ideal solution would be some folks pitching in on what Matt
>pointed in [2] - basically "upstream a resource manager on
>top of the basic overlay support that's in progress" and introduce
>capes as part of that overlay support once it is upstream.
>
I'm not sure how much "capemgr" or "DT overlay" is useful to larger
audience ? 

(1) *Usually* actual custom board going to production will have
all devices populated on the board. fixed. It's very rare that an end-user
may buy an extension board (like capes) and add to finished good.
Thus, 'DT overlay' and 'capemgr' are good for development platforms
where you give a generic basic board for people to play (at low cost)
And then give accessory boards (like capes) on top to choose and build
a conceptual solution.

(2) Also, 'capemgr' should be able to detect and identify all the capes
uniquely, and in correct sequence. For which you need some kind
of identification mechanism like EEPROM on each cape connected
to I2C. And I doubt all beaglebone capes have that as-of-today.
(also that makes cape slightly expensive).

So, I'll still prefer Tony's suggestion that,
add support for all Capes in DT, but keep the conflicting ones
"disabled" by default. And let the user choose which ones to enable.
This is simple and keeps maintenance overhead also low.


>Failing which, keeping the base bone dts to basic stuff that bare
>board supports and having per "first level cape" dts which includes
>relevant dts sounds to me the only rationale and easily usable (as in:
>without much device tree knowledge) - again, I admit "easily" is
>subjective here.
>
>
>[1] https://lkml.org/lkml/2014/2/5/183
>[2] https://lkml.org/lkml/2014/2/5/247
>
>--
>Regards,
>Nishanth Menon

with regards, pekon

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

[Nishanth Menon]

On 16:13-20140312, Gupta, Pekon wrote:
> I think this is different discussion from previous one ..
> "common DTS file" v/s "replicated DTS entries in individual board files"
> because 'uncomment' issue will remain in both scenarios. (please read below)

see below patch to highlight what I was mentioning: The build generates the dtb that can be used with
nand cape without any hand modification. the "easy" part I mentioned is
just knowing to select the right dtb corresponding to the cape. There is
no replication, just overriding the default board behavior.

>From b573d557aa09e34b1b587943dfea73bac480286d Mon Sep 17 00:00:00 2001
From: DUMMY AUTHOR <dummy@somewhere.com>
Date: Wed, 12 Mar 2014 16:47:15 -0500
Subject: [REFERENCE PATCH] ARM: dts: am335x-bone: add support for beaglebone NAND cape

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

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

 - 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
---
 arch/arm/boot/dts/Makefile                    |    1 +
 arch/arm/boot/dts/am335x-bone-memory-cape.dts |  123 +++++++++++++++++++++++++
 2 files changed, 124 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c5e9bfa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	am335x-evmsk.dtb \
 	am335x-bone.dtb \
 	am335x-boneblack.dtb \
+	am335x-bone-memory-cape.dtb\
 	am335x-nano.dtb \
 	am335x-base0033.dtb \
 	am3517-evm.dtb \
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..7ab088d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+#include "am335x-bone.dts"
+
+&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 */
+		>;
+	};
+};
+
+
+/* NAND cape cannot work with MMC2 */
+&mmc2 {
+	status = "disabled";
+};
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	pinctrl-names = "default";
+	status = "okay";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
+	nand@0,0 {
+		reg = <0 0 0>; /* CS0, offset 0 */
+		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-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-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.7.9.5


-- 
Regards,
Nishanth Menon

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

[Gupta, Pekon]

[...]
> arch/arm/boot/dts/Makefile                    |    1 +
> arch/arm/boot/dts/am335x-bone-memory-cape.dts |  123 +++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>index 0320303..c5e9bfa 100644
>--- a/arch/arm/boot/dts/Makefile
>+++ b/arch/arm/boot/dts/Makefile
>@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> 	am335x-evmsk.dtb \
> 	am335x-bone.dtb \
> 	am335x-boneblack.dtb \
>+	am335x-bone-memory-cape.dtb\
> 	am335x-nano.dtb \
> 	am335x-base0033.dtb \
> 	am3517-evm.dtb \
>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..7ab088d
>--- /dev/null
>+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>From discussions, option I could think are..

(a) NAND cape node added in both 'am335x-bone.dts' and
   'am335x-boneblack.dts' but "disabled" by default.

(b) NAND cape node in new '.dts' file (as mentioned above), and generate
   a separate blob individual for cape.

(c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
   by default. But there is no guarantee that future boards remain
   compatible and same 'common_xx.dtsi' can be reused later.

I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
ones who have to maintain all these. Tony ?

with regards, pekon

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

[Nishanth Menon]

On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
[..]
>> 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..7ab088d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>
> From discussions, option I could think are..
> 
> (a) NAND cape node added in both 'am335x-bone.dts' and
>    'am335x-boneblack.dts' but "disabled" by default.
> 
> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
>    a separate blob individual for cape.
> 
> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
>    by default. But there is no guarantee that future boards remain
>    compatible and same 'common_xx.dtsi' can be reused later.
> 
> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> ones who have to maintain all these. Tony ?
> 

Key for us is that we'd have to live with what ever we introduce in
the interest of backward dtb compatibility. both (a) and (c) requires
hand modification by user of nand cape - considering this might be the
strategy for "most common capes", we might end up with confusing
entries that in many cases will require additional documentation
example: option a, c: consider both audio cape (which needs hdmi
disabled) and nand cape (which needs mmc2 disabled) - how'd the user
know which entries to enable/disable for the user of the cape -
documentation needed and potentially user error prone implementation
as well.

There is as well a option (d) where we wait for FDT overlay to mature,
write up a resource manager and support all level capes.

-- 
Regards,
Nishanth Menon

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

[Robert Nelson]

On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> [..]
>>> 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..7ab088d
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>>
>> From discussions, option I could think are..
>>
>> (a) NAND cape node added in both 'am335x-bone.dts' and
>>    'am335x-boneblack.dts' but "disabled" by default.
>>
>> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
>>    a separate blob individual for cape.
>>
>> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
>>    by default. But there is no guarantee that future boards remain
>>    compatible and same 'common_xx.dtsi' can be reused later.
>>
>> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
>> ones who have to maintain all these. Tony ?
>>
>
> Key for us is that we'd have to live with what ever we introduce in
> the interest of backward dtb compatibility. both (a) and (c) requires
> hand modification by user of nand cape - considering this might be the
> strategy for "most common capes", we might end up with confusing
> entries that in many cases will require additional documentation
> example: option a, c: consider both audio cape (which needs hdmi
> disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> know which entries to enable/disable for the user of the cape -
> documentation needed and potentially user error prone implementation
> as well.
>
> There is as well a option (d) where we wait for FDT overlay to mature,
> write up a resource manager and support all level capes.

(b) is the direction i'm currently trying to transition the
beagleboard.org community till (d) actually shows any life/hope again.

example:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes

I really like Nishanth's simpler version he posted, so I'll be
converting mine to that style later today.

Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
we can actively check for the presence of <board>-<cape>.dtb and
safely fall back to <board>.dtb if it didn't actually exist.  The only
requirement is the end user specify the <cape> as a variable in
uEnv.txt

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[Tony Lindgren]

* Robert Nelson <robertcnelson@gmail.com> [140313 06:33]:
> On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> > On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> > [..]
> >>> 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..7ab088d
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> >>>
> >> From discussions, option I could think are..
> >>
> >> (a) NAND cape node added in both 'am335x-bone.dts' and
> >>    'am335x-boneblack.dts' but "disabled" by default.

The capes can live their own revision cycle from beaglebones,
so separate .dts files for each cape are probably better.

> >> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
> >>    a separate blob individual for cape.

(b.2) NAND cape node in new '.dts' file but devices set to disabled
      by default. Included into am335x-*bone*.dts files. The found
      and configured cape devices set back to enabled by u-boot by
      modifying the .dtb by using the existing ft_board_setup() and
      fdt_find_and_setprop() in u-boot.

> >> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
> >>    by default. But there is no guarantee that future boards remain
> >>    compatible and same 'common_xx.dtsi' can be reused later.

This also has an issue of different revision cycle between beaglebones
and the capes.

> >> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> >> ones who have to maintain all these. Tony ?
> >>
> >
> > Key for us is that we'd have to live with what ever we introduce in
> > the interest of backward dtb compatibility. both (a) and (c) requires
> > hand modification by user of nand cape - considering this might be the
> > strategy for "most common capes", we might end up with confusing
> > entries that in many cases will require additional documentation
> > example: option a, c: consider both audio cape (which needs hdmi
> > disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> > know which entries to enable/disable for the user of the cape -
> > documentation needed and potentially user error prone implementation
> > as well.
> >
> > There is as well a option (d) where we wait for FDT overlay to mature,
> > write up a resource manager and support all level capes.

Yeah option (d) and having the capes hotpluggable is probably the best
way to go in the long run.  Meanwhile, I'd suggest researching if
option (b.2) above is doable for enabling some capes.
 
> (b) is the direction i'm currently trying to transition the
> beagleboard.org community till (d) actually shows any life/hope again.
> 
> example:
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes
> 
> I really like Nishanth's simpler version he posted, so I'll be
> converting mine to that style later today.

Yeah except most of these capes should be included into the
am335x-*bone*.dts files as in (b.2) above. All the internal omap
devices are still there on the SoC even if not wired to the cape.
The GPMC devices may cause more of an issue as we cannot just override
the chip select wiring by modifying the .dtb. But for the internal
devices modifying the .dtb to enable some of them might be doable.
 
> Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
> we can actively check for the presence of <board>-<cape>.dtb and
> safely fall back to <board>.dtb if it didn't actually exist.  The only
> requirement is the end user specify the <cape> as a variable in
> uEnv.txt
> 
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76

That's great!

Regards,

Tony