* [PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson, 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-24 12:24 ` Pekon Gupta
-1 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-24 12:24 ` Pekon Gupta
-1 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-24 12:24 ` Pekon Gupta
-1 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 50+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, 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
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-24 15:03 ` Ezequiel Garcia
-1 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-24 15:03 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, Robert Nelson, linux-omap,
linux-mtd, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-24 15:03 ` Ezequiel Garcia
0 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-24 15:03 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-24 15:24 ` Jason Kridner
-1 siblings, 0 replies; 50+ messages in thread
From: Jason Kridner @ 2014-06-24 15:24 UTC (permalink / raw)
To: Pekon Gupta; +Cc: Tony Lindgren, linux-omap, linux-mtd, Robert Nelson
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
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-24 15:24 ` Jason Kridner
0 siblings, 0 replies; 50+ messages in thread
From: Jason Kridner @ 2014-06-24 15:24 UTC (permalink / raw)
To: Pekon Gupta; +Cc: Tony Lindgren, Robert Nelson, linux-omap, linux-mtd
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
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 15:03 ` Ezequiel Garcia
@ 2014-06-25 4:38 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-25 4:38 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, Jason Kridner, Robert Nelson, linux-omap,
linux-mtd, Guido Martínez
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-25 4:38 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-25 4:38 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 15:24 ` Jason Kridner
@ 2014-06-25 5:49 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-25 5:49 UTC (permalink / raw)
To: Jason Kridner, Tony Lindgren; +Cc: linux-omap, linux-mtd, Robert Nelson
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-25 5:49 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-25 5:49 UTC (permalink / raw)
To: Jason Kridner, Tony Lindgren; +Cc: Robert Nelson, linux-omap, linux-mtd
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-25 4:38 ` Gupta, Pekon
@ 2014-06-25 14:59 ` Ezequiel Garcia
-1 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 14:59 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Jason Kridner, Robert Nelson, linux-omap,
linux-mtd, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-25 14:59 ` Ezequiel Garcia
0 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 14:59 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-25 15:27 ` Ezequiel Garcia
-1 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 15:27 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner,
Robert Nelson, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-25 15:27 ` Ezequiel Garcia
0 siblings, 0 replies; 50+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 15:27 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-25 5:49 ` Gupta, Pekon
@ 2014-06-26 4:30 ` Jason Kridner
-1 siblings, 0 replies; 50+ messages in thread
From: Jason Kridner @ 2014-06-26 4:30 UTC (permalink / raw)
To: Gupta, Pekon; +Cc: Tony Lindgren, linux-omap, linux-mtd, Robert Nelson
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-26 4:30 ` Jason Kridner
0 siblings, 0 replies; 50+ messages in thread
From: Jason Kridner @ 2014-06-26 4:30 UTC (permalink / raw)
To: Gupta, Pekon; +Cc: Tony Lindgren, Robert Nelson, linux-omap, linux-mtd
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-25 15:27 ` Ezequiel Garcia
@ 2014-06-26 5:43 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-26 5:43 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner,
Robert Nelson, Guido Martínez
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 5:43 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-26 5:43 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-26 10:40 ` Tony Lindgren
-1 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-06-26 10:40 UTC (permalink / raw)
To: Pekon Gupta; +Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 10:40 ` Tony Lindgren
0 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-06-26 10:40 UTC (permalink / raw)
To: Pekon Gupta; +Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
* 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 10:40 ` Tony Lindgren
@ 2014-06-26 15:06 ` Guido Martínez
-1 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 15:06 UTC (permalink / raw)
To: Tony Lindgren, Pekon Gupta
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 15:06 ` Guido Martínez
0 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 15:06 UTC (permalink / raw)
To: Tony Lindgren, Pekon Gupta
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-26 15:40 ` Guido Martínez
-1 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 15:40 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-26 15:40 ` Guido Martínez
0 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 15:40 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-26 15:40 ` Guido Martínez
@ 2014-06-26 18:35 ` Darren Etheridge
-1 siblings, 0 replies; 50+ messages in thread
From: Darren Etheridge @ 2014-06-26 18:35 UTC (permalink / raw)
To: Guido Martínez, Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
>
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-26 18:35 ` Darren Etheridge
0 siblings, 0 replies; 50+ messages in thread
From: Darren Etheridge @ 2014-06-26 18:35 UTC (permalink / raw)
To: Guido Martínez, Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
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
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-26 19:48 ` Guido Martínez
-1 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 19:48 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 19:48 ` Guido Martínez
0 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-06-26 19:48 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
2014-06-26 18:35 ` Darren Etheridge
@ 2014-06-27 11:38 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-27 11:38 UTC (permalink / raw)
To: Etheridge, Darren, Guido Martínez
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
@ 2014-06-27 11:38 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-27 11:38 UTC (permalink / raw)
To: Etheridge, Darren, Guido Martínez
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 19:48 ` Guido Martínez
@ 2014-06-27 21:06 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-27 21:06 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-27 21:06 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-06-27 21:06 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 15:06 ` Guido Martínez
@ 2014-07-01 7:01 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-01 7:01 UTC (permalink / raw)
To: Guido Martínez, Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 7:01 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-01 7:01 UTC (permalink / raw)
To: Guido Martínez, Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-27 21:06 ` Gupta, Pekon
@ 2014-07-01 8:47 ` Tony Lindgren
-1 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-07-01 8:47 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Guido Martínez, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* 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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 8:47 ` Tony Lindgren
0 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-07-01 8:47 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, Guido Martínez
* 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 8:47 ` Tony Lindgren
@ 2014-07-01 9:07 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-01 9:07 UTC (permalink / raw)
To: Tony Lindgren, Guido Martínez
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 9:07 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-01 9:07 UTC (permalink / raw)
To: Tony Lindgren, Guido Martínez
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 9:07 ` Gupta, Pekon
@ 2014-07-01 13:28 ` Tony Lindgren
-1 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-07-01 13:28 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Guido Martínez, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* 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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 13:28 ` Tony Lindgren
0 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2014-07-01 13:28 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, Guido Martínez
* 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 7:01 ` Gupta, Pekon
@ 2014-07-01 23:42 ` Guido Martínez
-1 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-07-01 23:42 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 23:42 ` Guido Martínez
0 siblings, 0 replies; 50+ messages in thread
From: Guido Martínez @ 2014-07-01 23:42 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 23:42 ` Guido Martínez
@ 2014-07-02 5:29 ` Gupta, Pekon
-1 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-02 5:29 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>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
--
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-02 5:29 ` Gupta, Pekon
0 siblings, 0 replies; 50+ messages in thread
From: Gupta, Pekon @ 2014-07-02 5:29 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
>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
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2014-07-02 5:29 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-24 12:24 [PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS Pekon Gupta
2014-06-24 12:24 ` Pekon Gupta
2014-06-24 12:24 ` [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape Pekon Gupta
2014-06-24 12:24 ` Pekon Gupta
2014-06-25 15:27 ` Ezequiel Garcia
2014-06-25 15:27 ` Ezequiel Garcia
2014-06-26 5:43 ` Gupta, Pekon
2014-06-26 5:43 ` Gupta, Pekon
2014-06-26 10:40 ` Tony Lindgren
2014-06-26 10:40 ` Tony Lindgren
2014-06-26 15:06 ` Guido Martínez
2014-06-26 15:06 ` Guido Martínez
2014-07-01 7:01 ` Gupta, Pekon
2014-07-01 7:01 ` Gupta, Pekon
2014-07-01 23:42 ` Guido Martínez
2014-07-01 23:42 ` Guido Martínez
2014-07-02 5:29 ` Gupta, Pekon
2014-07-02 5:29 ` Gupta, Pekon
2014-06-26 19:48 ` Guido Martínez
2014-06-26 19:48 ` Guido Martínez
2014-06-27 21:06 ` Gupta, Pekon
2014-06-27 21:06 ` Gupta, Pekon
2014-07-01 8:47 ` Tony Lindgren
2014-07-01 8:47 ` Tony Lindgren
2014-07-01 9:07 ` Gupta, Pekon
2014-07-01 9:07 ` Gupta, Pekon
2014-07-01 13:28 ` Tony Lindgren
2014-07-01 13:28 ` Tony Lindgren
2014-06-24 12:24 ` [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape Pekon Gupta
2014-06-24 12:24 ` Pekon Gupta
2014-06-24 12:24 ` [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape Pekon Gupta
2014-06-24 12:24 ` Pekon Gupta
2014-06-24 15:03 ` Ezequiel Garcia
2014-06-24 15:03 ` Ezequiel Garcia
2014-06-25 4:38 ` Gupta, Pekon
2014-06-25 4:38 ` Gupta, Pekon
2014-06-25 14:59 ` Ezequiel Garcia
2014-06-25 14:59 ` Ezequiel Garcia
2014-06-24 15:24 ` Jason Kridner
2014-06-24 15:24 ` Jason Kridner
2014-06-25 5:49 ` Gupta, Pekon
2014-06-25 5:49 ` Gupta, Pekon
2014-06-26 4:30 ` Jason Kridner
2014-06-26 4:30 ` Jason Kridner
2014-06-26 15:40 ` Guido Martínez
2014-06-26 15:40 ` Guido Martínez
2014-06-26 18:35 ` Darren Etheridge
2014-06-26 18:35 ` Darren Etheridge
2014-06-27 11:38 ` Gupta, Pekon
2014-06-27 11:38 ` Gupta, Pekon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.