* [PATCH 0/4] Device tree related changes to boot dm816x
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel
Hi,
Here are the device tree related changes to boot dm816x
boards as tested on a dm8168-evm.
Note that these depend on the other related patches I've
posted today. To make it easier to figure out what all is
needed, i've also posted a temporary test branch with all
the necessary patches applied to a tmp-testing-dm81xx branch
at:
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=tmp-testing-dm81xx
Regards,
Tony
Tony Lindgren (4):
ARM: OMAP2+: Add board-generic.c entry for ti81xx
ARM: dts: Add basic dm816x device tree configuration
ARM: dts: Add basic clocks for dm816x
ARM: dts: Add minimal support for dm8168-evm
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dm8168-evm.dts | 105 ++++++++++
arch/arm/boot/dts/dm816x-clocks.dtsi | 250 +++++++++++++++++++++++
arch/arm/boot/dts/dm816x.dtsi | 375 +++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 34 ++++
5 files changed, 765 insertions(+)
create mode 100644 arch/arm/boot/dts/dm8168-evm.dts
create mode 100644 arch/arm/boot/dts/dm816x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/dm816x.dtsi
--
2.1.4
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 0/4] Device tree related changes to boot dm816x
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here are the device tree related changes to boot dm816x
boards as tested on a dm8168-evm.
Note that these depend on the other related patches I've
posted today. To make it easier to figure out what all is
needed, i've also posted a temporary test branch with all
the necessary patches applied to a tmp-testing-dm81xx branch
at:
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=tmp-testing-dm81xx
Regards,
Tony
Tony Lindgren (4):
ARM: OMAP2+: Add board-generic.c entry for ti81xx
ARM: dts: Add basic dm816x device tree configuration
ARM: dts: Add basic clocks for dm816x
ARM: dts: Add minimal support for dm8168-evm
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dm8168-evm.dts | 105 ++++++++++
arch/arm/boot/dts/dm816x-clocks.dtsi | 250 +++++++++++++++++++++++
arch/arm/boot/dts/dm816x.dtsi | 375 +++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 34 ++++
5 files changed, 765 insertions(+)
create mode 100644 arch/arm/boot/dts/dm8168-evm.dts
create mode 100644 arch/arm/boot/dts/dm816x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/dm816x.dtsi
--
2.1.4
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-13 23:37 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
This allows booting ti81xx boards with with when a .dts
file is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-generic.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 608079a..e95b8f7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -142,6 +142,40 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
.dt_compat = am3517_boards_compat,
.restart = omap3xxx_restart,
MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
This allows booting ti81xx boards with with when a .dts
file is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-generic.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 608079a..e95b8f7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -142,6 +142,40 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
.dt_compat = am3517_boards_compat,
.restart = omap3xxx_restart,
MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-13 23:37 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dm816x.dtsi | 374 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 374 insertions(+)
create mode 100644 arch/arm/boot/dts/dm816x.dtsi
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
new file mode 100644
index 0000000..7d575ac
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,374 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm@48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm@48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon@44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma@49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm@48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio@48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio@4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c@48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c@4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller@48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox@480c8000 {
+ compatible = "ti,omap3-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <8>;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+ };
+
+ mdio: mdio@4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet@4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet@4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi@48030000 {
+ compatible = "ti,omap3-mcspi";
+ reg = <0x48030000 0x2000>;
+ interrupts = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc@48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer@4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer@4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart@48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart@48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart@48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs@47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb@47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb@47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer@480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dm816x.dtsi | 374 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 374 insertions(+)
create mode 100644 arch/arm/boot/dts/dm816x.dtsi
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
new file mode 100644
index 0000000..7d575ac
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,374 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm at 48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm at 48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon at 44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma at 49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm at 48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio at 48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio at 4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c at 48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c at 4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller at 48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox at 480c8000 {
+ compatible = "ti,omap3-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <8>;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = <0 0 0>;
+ ti,mbox-rx = <0 0 3>;
+ };
+ };
+
+ mdio: mdio at 4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy at 0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy at 1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet at 4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet at 4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi at 48030000 {
+ compatible = "ti,omap3-mcspi";
+ reg = <0x48030000 0x2000>;
+ interrupts = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc at 48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer at 4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer at 48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer at 4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart at 48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart at 48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart at 48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs at 47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb at 47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb at 47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer at 480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 3/4] ARM: dts: Add basic clocks for dm816x
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-13 23:37 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson, Paul Walmsley, Tero Kristo
The clocks on dm816x are a bit different from the other omap
variants. The clocks are sourced from a FAPLL (Flying Adder PLL)
unlike on other omaps. Other than that, it's a similar setup
to am33xx with extra muxes and dividers that can be defined
as existing component clocks.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dm816x-clocks.dtsi | 250 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/dm816x.dtsi | 1 +
2 files changed, 251 insertions(+)
create mode 100644 arch/arm/boot/dts/dm816x-clocks.dtsi
diff --git a/arch/arm/boot/dts/dm816x-clocks.dtsi b/arch/arm/boot/dts/dm816x-clocks.dtsi
new file mode 100644
index 0000000..50d9d33
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x-clocks.dtsi
@@ -0,0 +1,250 @@
+/*
+ * 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.
+ */
+
+&scrm {
+ main_fapll: main_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x400 0x40>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>, <5>,
+ <6>, <7>;
+ clock-output-names = "main_pll_clk1",
+ "main_pll_clk2",
+ "main_pll_clk3",
+ "main_pll_clk4",
+ "main_pll_clk5",
+ "main_pll_clk6",
+ "main_pll_clk7";
+ };
+
+ ddr_fapll: ddr_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x440 0x30>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>;
+ clock-output-names = "ddr_pll_clk1",
+ "ddr_pll_clk2",
+ "ddr_pll_clk3",
+ "ddr_pll_clk4";
+ };
+
+ video_fapll: video_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x470 0x30>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>;
+ clock-output-names = "video_pll_clk1",
+ "video_pll_clk2",
+ "video_pll_clk3";
+ };
+
+ audio_fapll: audio_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x4a0 0x30>;
+ clocks = <&main_fapll 7>, < &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>, <5>;
+ clock-output-names = "audio_pll_clk1",
+ "audio_pll_clk2",
+ "audio_pll_clk3",
+ "audio_pll_clk4",
+ "audio_pll_clk5";
+ };
+};
+
+&scrm_clocks {
+ secure_32k_ck: secure_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ sys_32k_ck: sys_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ tclkin_ck: tclkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ sys_clkin_ck: sys_clkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <27000000>;
+ };
+};
+
+/* 0x48180000 */
+&prcm_clocks {
+ clkout_pre_ck: clkout_pre_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&main_fapll 5 &ddr_fapll 1 &video_fapll 1
+ &audio_fapll 1>;
+ reg = <0x100>;
+ };
+
+ clkout_div_ck: clkout_div_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&clkout_pre_ck>;
+ ti,bit-shift = <3>;
+ ti,max-div = <8>;
+ reg = <0x100>;
+ };
+
+ clkout_ck: clkout_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&clkout_div_ck>;
+ ti,bit-shift = <7>;
+ reg = <0x100>;
+ };
+
+ /* CM_DPLL clocks p1795 */
+ sysclk1_ck: sysclk1_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 1>;
+ ti,max-div = <7>;
+ reg = <0x0300>;
+ };
+
+ sysclk2_ck: sysclk2_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 2>;
+ ti,max-div = <7>;
+ reg = <0x0304>;
+ };
+
+ sysclk3_ck: sysclk3_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 3>;
+ ti,max-div = <7>;
+ reg = <0x0308>;
+ };
+
+ sysclk4_ck: sysclk4_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 4>;
+ ti,max-div = <1>;
+ reg = <0x030c>;
+ };
+
+ sysclk5_ck: sysclk5_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&sysclk4_ck>;
+ ti,max-div = <1>;
+ reg = <0x0310>;
+ };
+
+ sysclk6_ck: sysclk6_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 4>;
+ ti,dividers = <2>, <4>;
+ reg = <0x0314>;
+ };
+
+ sysclk10_ck: sysclk10_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&ddr_fapll 2>;
+ ti,max-div = <7>;
+ reg = <0x0324>;
+ };
+
+ sysclk24_ck: sysclk24_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 5>;
+ ti,max-div = <7>;
+ reg = <0x03b4>;
+ };
+
+ mpu_ck: mpu_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sysclk2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x15dc>;
+ };
+
+ audio_pll_a_ck: audio_pll_a_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&audio_fapll 1>;
+ ti,max-div = <7>;
+ reg = <0x035c>;
+ };
+
+ sysclk18_ck: sysclk18_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&sys_32k_ck>, <&audio_pll_a_ck>;
+ reg = <0x0378>;
+ };
+
+ timer1_fck: timer1_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0390>;
+ };
+
+ timer2_fck: timer2_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0394>;
+ };
+
+ timer3_fck: timer3_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0398>;
+ };
+
+ timer4_fck: timer4_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x039c>;
+ };
+
+ timer5_fck: timer5_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a0>;
+ };
+
+ timer6_fck: timer6_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a4>;
+ };
+
+ timer7_fck: timer7_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a8>;
+ };
+};
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 7d575ac..c1029db 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -372,3 +372,4 @@
};
};
+#include "dm816x-clocks.dtsi"
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 3/4] ARM: dts: Add basic clocks for dm816x
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
The clocks on dm816x are a bit different from the other omap
variants. The clocks are sourced from a FAPLL (Flying Adder PLL)
unlike on other omaps. Other than that, it's a similar setup
to am33xx with extra muxes and dividers that can be defined
as existing component clocks.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/dm816x-clocks.dtsi | 250 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/dm816x.dtsi | 1 +
2 files changed, 251 insertions(+)
create mode 100644 arch/arm/boot/dts/dm816x-clocks.dtsi
diff --git a/arch/arm/boot/dts/dm816x-clocks.dtsi b/arch/arm/boot/dts/dm816x-clocks.dtsi
new file mode 100644
index 0000000..50d9d33
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x-clocks.dtsi
@@ -0,0 +1,250 @@
+/*
+ * 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.
+ */
+
+&scrm {
+ main_fapll: main_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x400 0x40>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>, <5>,
+ <6>, <7>;
+ clock-output-names = "main_pll_clk1",
+ "main_pll_clk2",
+ "main_pll_clk3",
+ "main_pll_clk4",
+ "main_pll_clk5",
+ "main_pll_clk6",
+ "main_pll_clk7";
+ };
+
+ ddr_fapll: ddr_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x440 0x30>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>;
+ clock-output-names = "ddr_pll_clk1",
+ "ddr_pll_clk2",
+ "ddr_pll_clk3",
+ "ddr_pll_clk4";
+ };
+
+ video_fapll: video_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x470 0x30>;
+ clocks = <&sys_clkin_ck &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>;
+ clock-output-names = "video_pll_clk1",
+ "video_pll_clk2",
+ "video_pll_clk3";
+ };
+
+ audio_fapll: audio_fapll {
+ #clock-cells = <1>;
+ compatible = "ti,dm816-fapll-clock";
+ reg = <0x4a0 0x30>;
+ clocks = <&main_fapll 7>, < &sys_clkin_ck>;
+ clock-indices = <1>, <2>, <3>, <4>, <5>;
+ clock-output-names = "audio_pll_clk1",
+ "audio_pll_clk2",
+ "audio_pll_clk3",
+ "audio_pll_clk4",
+ "audio_pll_clk5";
+ };
+};
+
+&scrm_clocks {
+ secure_32k_ck: secure_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ sys_32k_ck: sys_32k_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ tclkin_ck: tclkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ sys_clkin_ck: sys_clkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <27000000>;
+ };
+};
+
+/* 0x48180000 */
+&prcm_clocks {
+ clkout_pre_ck: clkout_pre_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&main_fapll 5 &ddr_fapll 1 &video_fapll 1
+ &audio_fapll 1>;
+ reg = <0x100>;
+ };
+
+ clkout_div_ck: clkout_div_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&clkout_pre_ck>;
+ ti,bit-shift = <3>;
+ ti,max-div = <8>;
+ reg = <0x100>;
+ };
+
+ clkout_ck: clkout_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&clkout_div_ck>;
+ ti,bit-shift = <7>;
+ reg = <0x100>;
+ };
+
+ /* CM_DPLL clocks p1795 */
+ sysclk1_ck: sysclk1_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 1>;
+ ti,max-div = <7>;
+ reg = <0x0300>;
+ };
+
+ sysclk2_ck: sysclk2_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 2>;
+ ti,max-div = <7>;
+ reg = <0x0304>;
+ };
+
+ sysclk3_ck: sysclk3_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 3>;
+ ti,max-div = <7>;
+ reg = <0x0308>;
+ };
+
+ sysclk4_ck: sysclk4_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 4>;
+ ti,max-div = <1>;
+ reg = <0x030c>;
+ };
+
+ sysclk5_ck: sysclk5_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&sysclk4_ck>;
+ ti,max-div = <1>;
+ reg = <0x0310>;
+ };
+
+ sysclk6_ck: sysclk6_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 4>;
+ ti,dividers = <2>, <4>;
+ reg = <0x0314>;
+ };
+
+ sysclk10_ck: sysclk10_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&ddr_fapll 2>;
+ ti,max-div = <7>;
+ reg = <0x0324>;
+ };
+
+ sysclk24_ck: sysclk24_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&main_fapll 5>;
+ ti,max-div = <7>;
+ reg = <0x03b4>;
+ };
+
+ mpu_ck: mpu_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sysclk2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x15dc>;
+ };
+
+ audio_pll_a_ck: audio_pll_a_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&audio_fapll 1>;
+ ti,max-div = <7>;
+ reg = <0x035c>;
+ };
+
+ sysclk18_ck: sysclk18_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&sys_32k_ck>, <&audio_pll_a_ck>;
+ reg = <0x0378>;
+ };
+
+ timer1_fck: timer1_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0390>;
+ };
+
+ timer2_fck: timer2_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0394>;
+ };
+
+ timer3_fck: timer3_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x0398>;
+ };
+
+ timer4_fck: timer4_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x039c>;
+ };
+
+ timer5_fck: timer5_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a0>;
+ };
+
+ timer6_fck: timer6_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a4>;
+ };
+
+ timer7_fck: timer7_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&tclkin_ck>, <&sysclk18_ck>, <&sys_clkin_ck>;
+ reg = <0x03a8>;
+ };
+};
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 7d575ac..c1029db 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -372,3 +372,4 @@
};
};
+#include "dm816x-clocks.dtsi"
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-13 23:37 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dm8168-evm.dts | 105 +++++++++++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/dm8168-evm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..fe15c7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 0000000..9acd4ff
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,105 @@
+/*
+ * 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.
+ */
+/dts-v1/;
+
+#include "dm816x.dtsi"
+
+/ {
+ model = "DM8168 EVM";
+ compatible = "ti,dm8168-evm", "ti,dm8168";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000 /* 1 GB */
+ 0xc0000000 0x40000000>; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&i2c1 {
+ extgpio0: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&i2c2 {
+ extgpio1: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x04000000 0x01000000>; /* CS0: 16MB for NAND */
+
+ nand@0,0 {
+ linux,mtd-name= "micron,mt29f2g16aadwp";
+ reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,nand-ecc-opt = "bch8";
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ partition@0 {
+ label = "X-Loader";
+ reg = <0 0x80000>;
+ };
+ partition@0x80000 {
+ label = "U-Boot";
+ reg = <0x80000 0x1c0000>;
+ };
+ partition@0x1c0000 {
+ label = "Environment";
+ reg = <0x240000 0x40000>;
+ };
+ partition@0x280000 {
+ label = "Kernel";
+ reg = <0x280000 0x500000>;
+ };
+ partition@0x780000 {
+ label = "Filesystem";
+ reg = <0x780000 0xf880000>;
+ };
+ };
+};
+
+&mmc1 {
+ vmmc-supply = <&vmmcsd_fixed>;
+};
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-13 23:37 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dm8168-evm.dts | 105 +++++++++++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/dm8168-evm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..fe15c7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 0000000..9acd4ff
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,105 @@
+/*
+ * 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.
+ */
+/dts-v1/;
+
+#include "dm816x.dtsi"
+
+/ {
+ model = "DM8168 EVM";
+ compatible = "ti,dm8168-evm", "ti,dm8168";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000 /* 1 GB */
+ 0xc0000000 0x40000000>; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&i2c1 {
+ extgpio0: pcf8575 at 20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&i2c2 {
+ extgpio1: pcf8575 at 20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x04000000 0x01000000>; /* CS0: 16MB for NAND */
+
+ nand at 0,0 {
+ linux,mtd-name= "micron,mt29f2g16aadwp";
+ reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,nand-ecc-opt = "bch8";
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ partition at 0 {
+ label = "X-Loader";
+ reg = <0 0x80000>;
+ };
+ partition at 0x80000 {
+ label = "U-Boot";
+ reg = <0x80000 0x1c0000>;
+ };
+ partition at 0x1c0000 {
+ label = "Environment";
+ reg = <0x240000 0x40000>;
+ };
+ partition at 0x280000 {
+ label = "Kernel";
+ reg = <0x280000 0x500000>;
+ };
+ partition at 0x780000 {
+ label = "Filesystem";
+ reg = <0x780000 0xf880000>;
+ };
+ };
+};
+
+&mmc1 {
+ vmmc-supply = <&vmmcsd_fixed>;
+};
--
2.1.4
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-14 13:51 ` Sergei Shtylyov
-1 siblings, 0 replies; 66+ messages in thread
From: Sergei Shtylyov @ 2015-01-14 13:51 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: Brian Hutchinson, linux-arm-kernel
Hello.
On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> This allows booting ti81xx boards with with when a .dts
So, with, with or when? :-)
> file is in place.
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
WBR, Sergei
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-14 13:51 ` Sergei Shtylyov
0 siblings, 0 replies; 66+ messages in thread
From: Sergei Shtylyov @ 2015-01-14 13:51 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> This allows booting ti81xx boards with with when a .dts
So, with, with or when? :-)
> file is in place.
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
WBR, Sergei
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-14 13:51 ` Sergei Shtylyov
@ 2015-01-15 0:07 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-15 0:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-omap, Brian Hutchinson, linux-arm-kernel
* Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> Hello.
>
> On 1/14/2015 2:37 AM, Tony Lindgren wrote:
>
> >This allows booting ti81xx boards with with when a .dts
>
> So, with, with or when? :-)
Heh thanks will updated to:
This allows booting ti81xx boards when a .dts file
is in place.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-15 0:07 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-15 0:07 UTC (permalink / raw)
To: linux-arm-kernel
* Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> Hello.
>
> On 1/14/2015 2:37 AM, Tony Lindgren wrote:
>
> >This allows booting ti81xx boards with with when a .dts
>
> So, with, with or when? :-)
Heh thanks will updated to:
This allows booting ti81xx boards when a .dts file
is in place.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-15 21:23 ` Suman Anna
-1 siblings, 0 replies; 66+ messages in thread
From: Suman Anna @ 2015-01-15 21:23 UTC (permalink / raw)
To: Tony Lindgren, linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
Hi Tony,
On 01/13/2015 05:37 PM, Tony Lindgren wrote:
> Similar to other omap variants, let's add dm816x support.
>
> Note that this is based on generated data from the
> TI81XX-LINUX-PSP-04.04.00.02 patches published at:
>
> http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
>
> I've verified the basic functionality, but have not been
> able to test all the devices on dm8168-evm.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/dm816x.dtsi | 374 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 374 insertions(+)
> create mode 100644 arch/arm/boot/dts/dm816x.dtsi
>
> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
> new file mode 100644
> index 0000000..7d575ac
> --- /dev/null
> +++ b/arch/arm/boot/dts/dm816x.dtsi
> @@ -0,0 +1,374 @@
> +/*
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "ti,dm816";
> + interrupt-parent = <&intc>;
> +
> + aliases {
> + i2c0 = &i2c1;
> + i2c1 = &i2c2;
> + serial0 = &uart1;
> + serial1 = &uart2;
> + serial2 = &uart3;
> + ethernet0 = ð0;
> + ethernet1 = ð1;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "arm,cortex-a8";
> + device_type = "cpu";
> + reg = <0>;
> + };
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a8-pmu";
> + interrupts = <3>;
> + };
> +
> + /*
> + * The soc node represents the soc top level view. It is used for IPs
> + * that are not memory mapped in the MPU view or for the MPU itself.
> + */
> + soc {
> + compatible = "ti,omap-infra";
> + mpu {
> + compatible = "ti,omap3-mpu";
> + ti,hwmods = "mpu";
> + };
> + };
> +
> + /*
> + * XXX: Use a flat representation of the dm816x interconnect.
> + * The real dm816x interconnect network is quite complex. Since
> + * it will not bring real advantage to represent that in DT
> + * for the moment, just use a fake OCP bus entry to represent
> + * the whole bus hierarchy.
> + */
> + ocp {
> + compatible = "ti,omap3-l3-smx", "simple-bus";
> + reg = <0x44000000 0x10000>;
> + interrupts = <9 10>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + ti,hwmods = "l3_main";
> +
> + prcm: prcm@48180000 {
> + compatible = "ti,dm816-prcm";
> + reg = <0x48180000 0x4000>;
> +
> + prcm_clocks: clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + prcm_clockdomains: clockdomains {
> + };
> + };
> +
> + scrm: scrm@48140000 {
> + compatible = "ti,dm816-scrm";
> + reg = <0x48140000 0x21000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x48140000 0x21000>;
> +
> + scrm_clocks: clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + scrm_clockdomains: clockdomains {
> + };
> + };
> +
> + cm: syscon@44e10000 {
> + compatible = "ti,am33xx-controlmodule", "syscon";
> + reg = <0x44e10000 0x800>;
> + };
> +
> + edma: edma@49000000 {
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
> + reg = <0x49000000 0x10000>,
> + <0x44e10f90 0x40>;
> + interrupts = <12 13 14>;
> + #dma-cells = <1>;
> + };
> +
> + elm: elm@48080000 {
> + compatible = "ti,816-elm";
> + ti,hwmods = "elm";
> + reg = <0x48080000 0x2000>;
> + interrupts = <4>;
> + };
> +
> + gpio1: gpio@48032000 {
> + compatible = "ti,omap3-gpio";
> + ti,hwmods = "gpio1";
> + reg = <0x48032000 0x1000>;
> + interrupts = <97>;
> + };
> +
> + gpio2: gpio@4804c000 {
> + compatible = "ti,omap3-gpio";
> + ti,hwmods = "gpio2";
> + reg = <0x4804c000 0x1000>;
> + interrupts = <99>;
> + };
> +
> + gpmc: gpmc@50000000 {
> + compatible = "ti,am3352-gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x2000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <100>;
> + gpmc,num-cs = <6>;
> + gpmc,num-waitpins = <2>;
> + };
> +
> + i2c1: i2c@48028000 {
> + compatible = "ti,omap4-i2c";
> + ti,hwmods = "i2c1";
> + reg = <0x48028000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <70>;
> + dmas = <&edma 58 &edma 59>;
> + dma-names = "tx", "rx";
> + };
> +
> + i2c2: i2c@4802a000 {
> + compatible = "ti,omap4-i2c";
> + ti,hwmods = "i2c2";
> + reg = <0x4802a000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <71>;
> + dmas = <&edma 60 &edma 61>;
> + dma-names = "tx", "rx";
> + };
> +
> + intc: interrupt-controller@48200000 {
> + compatible = "ti,dm816-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x48200000 0x1000>;
> + };
> +
> + mailbox: mailbox@480c8000 {
> + compatible = "ti,omap3-mailbox";
The Mailbox IP is actually more like that of OMAP4, so the correct one
would be "ti,omap4-mailbox"
> + reg = <0x480c8000 0x2000>;
> + interrupts = <77>;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <4>;
> + ti,mbox-num-fifos = <8>;
This should be 12
> + mbox_wkupm3: wkup_m3 {
> + ti,mbox-tx = <0 0 0>;
> + ti,mbox-rx = <0 0 3>;
> + };
This may have been copied from AM335, so is incorrect. You are better
off starting with one for DSP instead of above, below are taken from the
corresponding SysLink release associated with above PSP release
mbox_dsp: mbox_dsp {
ti,mbox-tx = <3 0 0>;
ti,mbox-rx = <0 0 0>;
};
regards
Suman
> + };
> +
> + mdio: mdio@4a100800 {
> + compatible = "ti,davinci_mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4a100800 0x100>;
> + ti,hwmods = "davinci_mdio";
> + bus_freq = <1000000>;
> + phy0: ethernet-phy@0 {
> + reg = <1>;
> + };
> + phy1: ethernet-phy@1 {
> + reg = <2>;
> + };
> + };
> +
> + eth0: ethernet@4a100000 {
> + compatible = "ti,dm816-emac";
> + ti,hwmods = "emac0";
> + reg = <0x4a100000 0x800
> + 0x4a100900 0x3700>;
> + clocks = <&sysclk24_ck>;
> + ti,davinci-ctrl-reg-offset = <0>;
> + ti,davinci-ctrl-mod-reg-offset = <0x900>;
> + ti,davinci-ctrl-ram-offset = <0x2000>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + interrupts = <40 41 42 43>;
> + phy-handle = <&phy0>;
> + };
> +
> + eth1: ethernet@4a120000 {
> + compatible = "ti,dm816-emac";
> + ti,hwmods = "emac1";
> + reg = <0x4a120000 0x4000>;
> + clocks = <&sysclk24_ck>;
> + ti,davinci-ctrl-reg-offset = <0>;
> + ti,davinci-ctrl-mod-reg-offset = <0x900>;
> + ti,davinci-ctrl-ram-offset = <0x2000>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + interrupts = <44 45 46 47>;
> + phy-handle = <&phy1>;
> + };
> +
> + mcspi1: spi@48030000 {
> + compatible = "ti,omap3-mcspi";
> + reg = <0x48030000 0x2000>;
> + interrupts = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "mcspi1";
> + dmas = <&edma 16 &edma 17
> + &edma 18 &edma 19>;
> + dma-names = "tx0", "rx0", "tx1", "rx1";
> + };
> +
> + mmc1: mmc@48060000 {
> + compatible = "ti,omap4-hsmmc";
> + reg = <0x48060000 0x11000>;
> + ti,hwmods = "mmc1";
> + interrupts = <64>;
> + dmas = <&edma 24 &edma 25>;
> + dma-names = "tx", "rx";
> + };
> +
> + timer1: timer@4802e000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x4802e000 0x2000>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@48040000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48040000 0x2000>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer@48042000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48042000 0x2000>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer@48044000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48044000 0x2000>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer@48046000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48046000 0x2000>;
> + interrupts = <93>;
> + ti,hwmods = "timer5";
> + };
> +
> + timer6: timer@48048000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48048000 0x2000>;
> + interrupts = <94>;
> + ti,hwmods = "timer6";
> + };
> +
> + timer7: timer@4804a000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x4804a000 0x2000>;
> + interrupts = <95>;
> + ti,hwmods = "timer7";
> + };
> +
> + uart1: uart@48020000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart1";
> + reg = <0x48020000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <72>;
> + dmas = <&edma 26 &edma 27>;
> + dma-names = "tx", "rx";
> + };
> +
> + uart2: uart@48022000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart2";
> + reg = <0x48022000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <73>;
> + dmas = <&edma 28 &edma 29>;
> + dma-names = "tx", "rx";
> + };
> +
> + uart3: uart@48024000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart3";
> + reg = <0x48024000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <74>;
> + dmas = <&edma 30 &edma 31>;
> + dma-names = "tx", "rx";
> + };
> +
> + /* NOTE: USB needs a transceiver driver for phys to work */
> + usb: usb_otg_hs@47401000 {
> + compatible = "ti,am33xx-usb";
> + reg = <0x47401000 0x400000>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ti,hwmods = "usb_otg_hs";
> +
> + usb0: usb@47401000 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x47401400 0x400
> + 0x47401000 0x200>;
> + reg-names = "mc", "control";
> + interrupts = <18>;
> + interrupt-names = "mc";
> + dr_mode = "otg";
> + mentor,multipoint = <1>;
> + mentor,num-eps = <16>;
> + mentor,ram-bits = <12>;
> + mentor,power = <500>;
> + };
> +
> + usb1: usb@47401800 {
> + compatible = "ti,musb-am33xx";
> + status = "disabled";
> + reg = <0x47401c00 0x400
> + 0x47401800 0x200>;
> + reg-names = "mc", "control";
> + interrupts = <19>;
> + interrupt-names = "mc";
> + dr_mode = "otg";
> + mentor,multipoint = <1>;
> + mentor,num-eps = <16>;
> + mentor,ram-bits = <12>;
> + mentor,power = <500>;
> + };
> + };
> +
> + wd_timer2: wd_timer@480c2000 {
> + compatible = "ti,omap3-wdt";
> + ti,hwmods = "wd_timer";
> + reg = <0x480c2000 0x1000>;
> + interrupts = <0>;
> + };
> + };
> +};
> +
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
@ 2015-01-15 21:23 ` Suman Anna
0 siblings, 0 replies; 66+ messages in thread
From: Suman Anna @ 2015-01-15 21:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
On 01/13/2015 05:37 PM, Tony Lindgren wrote:
> Similar to other omap variants, let's add dm816x support.
>
> Note that this is based on generated data from the
> TI81XX-LINUX-PSP-04.04.00.02 patches published at:
>
> http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
>
> I've verified the basic functionality, but have not been
> able to test all the devices on dm8168-evm.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/dm816x.dtsi | 374 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 374 insertions(+)
> create mode 100644 arch/arm/boot/dts/dm816x.dtsi
>
> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
> new file mode 100644
> index 0000000..7d575ac
> --- /dev/null
> +++ b/arch/arm/boot/dts/dm816x.dtsi
> @@ -0,0 +1,374 @@
> +/*
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "ti,dm816";
> + interrupt-parent = <&intc>;
> +
> + aliases {
> + i2c0 = &i2c1;
> + i2c1 = &i2c2;
> + serial0 = &uart1;
> + serial1 = &uart2;
> + serial2 = &uart3;
> + ethernet0 = ð0;
> + ethernet1 = ð1;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu at 0 {
> + compatible = "arm,cortex-a8";
> + device_type = "cpu";
> + reg = <0>;
> + };
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a8-pmu";
> + interrupts = <3>;
> + };
> +
> + /*
> + * The soc node represents the soc top level view. It is used for IPs
> + * that are not memory mapped in the MPU view or for the MPU itself.
> + */
> + soc {
> + compatible = "ti,omap-infra";
> + mpu {
> + compatible = "ti,omap3-mpu";
> + ti,hwmods = "mpu";
> + };
> + };
> +
> + /*
> + * XXX: Use a flat representation of the dm816x interconnect.
> + * The real dm816x interconnect network is quite complex. Since
> + * it will not bring real advantage to represent that in DT
> + * for the moment, just use a fake OCP bus entry to represent
> + * the whole bus hierarchy.
> + */
> + ocp {
> + compatible = "ti,omap3-l3-smx", "simple-bus";
> + reg = <0x44000000 0x10000>;
> + interrupts = <9 10>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + ti,hwmods = "l3_main";
> +
> + prcm: prcm at 48180000 {
> + compatible = "ti,dm816-prcm";
> + reg = <0x48180000 0x4000>;
> +
> + prcm_clocks: clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + prcm_clockdomains: clockdomains {
> + };
> + };
> +
> + scrm: scrm at 48140000 {
> + compatible = "ti,dm816-scrm";
> + reg = <0x48140000 0x21000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x48140000 0x21000>;
> +
> + scrm_clocks: clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + scrm_clockdomains: clockdomains {
> + };
> + };
> +
> + cm: syscon at 44e10000 {
> + compatible = "ti,am33xx-controlmodule", "syscon";
> + reg = <0x44e10000 0x800>;
> + };
> +
> + edma: edma at 49000000 {
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
> + reg = <0x49000000 0x10000>,
> + <0x44e10f90 0x40>;
> + interrupts = <12 13 14>;
> + #dma-cells = <1>;
> + };
> +
> + elm: elm at 48080000 {
> + compatible = "ti,816-elm";
> + ti,hwmods = "elm";
> + reg = <0x48080000 0x2000>;
> + interrupts = <4>;
> + };
> +
> + gpio1: gpio at 48032000 {
> + compatible = "ti,omap3-gpio";
> + ti,hwmods = "gpio1";
> + reg = <0x48032000 0x1000>;
> + interrupts = <97>;
> + };
> +
> + gpio2: gpio at 4804c000 {
> + compatible = "ti,omap3-gpio";
> + ti,hwmods = "gpio2";
> + reg = <0x4804c000 0x1000>;
> + interrupts = <99>;
> + };
> +
> + gpmc: gpmc at 50000000 {
> + compatible = "ti,am3352-gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x2000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <100>;
> + gpmc,num-cs = <6>;
> + gpmc,num-waitpins = <2>;
> + };
> +
> + i2c1: i2c at 48028000 {
> + compatible = "ti,omap4-i2c";
> + ti,hwmods = "i2c1";
> + reg = <0x48028000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <70>;
> + dmas = <&edma 58 &edma 59>;
> + dma-names = "tx", "rx";
> + };
> +
> + i2c2: i2c at 4802a000 {
> + compatible = "ti,omap4-i2c";
> + ti,hwmods = "i2c2";
> + reg = <0x4802a000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <71>;
> + dmas = <&edma 60 &edma 61>;
> + dma-names = "tx", "rx";
> + };
> +
> + intc: interrupt-controller at 48200000 {
> + compatible = "ti,dm816-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x48200000 0x1000>;
> + };
> +
> + mailbox: mailbox at 480c8000 {
> + compatible = "ti,omap3-mailbox";
The Mailbox IP is actually more like that of OMAP4, so the correct one
would be "ti,omap4-mailbox"
> + reg = <0x480c8000 0x2000>;
> + interrupts = <77>;
> + ti,hwmods = "mailbox";
> + ti,mbox-num-users = <4>;
> + ti,mbox-num-fifos = <8>;
This should be 12
> + mbox_wkupm3: wkup_m3 {
> + ti,mbox-tx = <0 0 0>;
> + ti,mbox-rx = <0 0 3>;
> + };
This may have been copied from AM335, so is incorrect. You are better
off starting with one for DSP instead of above, below are taken from the
corresponding SysLink release associated with above PSP release
mbox_dsp: mbox_dsp {
ti,mbox-tx = <3 0 0>;
ti,mbox-rx = <0 0 0>;
};
regards
Suman
> + };
> +
> + mdio: mdio at 4a100800 {
> + compatible = "ti,davinci_mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4a100800 0x100>;
> + ti,hwmods = "davinci_mdio";
> + bus_freq = <1000000>;
> + phy0: ethernet-phy at 0 {
> + reg = <1>;
> + };
> + phy1: ethernet-phy at 1 {
> + reg = <2>;
> + };
> + };
> +
> + eth0: ethernet at 4a100000 {
> + compatible = "ti,dm816-emac";
> + ti,hwmods = "emac0";
> + reg = <0x4a100000 0x800
> + 0x4a100900 0x3700>;
> + clocks = <&sysclk24_ck>;
> + ti,davinci-ctrl-reg-offset = <0>;
> + ti,davinci-ctrl-mod-reg-offset = <0x900>;
> + ti,davinci-ctrl-ram-offset = <0x2000>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + interrupts = <40 41 42 43>;
> + phy-handle = <&phy0>;
> + };
> +
> + eth1: ethernet at 4a120000 {
> + compatible = "ti,dm816-emac";
> + ti,hwmods = "emac1";
> + reg = <0x4a120000 0x4000>;
> + clocks = <&sysclk24_ck>;
> + ti,davinci-ctrl-reg-offset = <0>;
> + ti,davinci-ctrl-mod-reg-offset = <0x900>;
> + ti,davinci-ctrl-ram-offset = <0x2000>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + interrupts = <44 45 46 47>;
> + phy-handle = <&phy1>;
> + };
> +
> + mcspi1: spi at 48030000 {
> + compatible = "ti,omap3-mcspi";
> + reg = <0x48030000 0x2000>;
> + interrupts = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "mcspi1";
> + dmas = <&edma 16 &edma 17
> + &edma 18 &edma 19>;
> + dma-names = "tx0", "rx0", "tx1", "rx1";
> + };
> +
> + mmc1: mmc at 48060000 {
> + compatible = "ti,omap4-hsmmc";
> + reg = <0x48060000 0x11000>;
> + ti,hwmods = "mmc1";
> + interrupts = <64>;
> + dmas = <&edma 24 &edma 25>;
> + dma-names = "tx", "rx";
> + };
> +
> + timer1: timer at 4802e000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x4802e000 0x2000>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 48040000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48040000 0x2000>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48042000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48042000 0x2000>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 48044000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48044000 0x2000>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 48046000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48046000 0x2000>;
> + interrupts = <93>;
> + ti,hwmods = "timer5";
> + };
> +
> + timer6: timer at 48048000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x48048000 0x2000>;
> + interrupts = <94>;
> + ti,hwmods = "timer6";
> + };
> +
> + timer7: timer at 4804a000 {
> + compatible = "ti,dm816-timer";
> + reg = <0x4804a000 0x2000>;
> + interrupts = <95>;
> + ti,hwmods = "timer7";
> + };
> +
> + uart1: uart at 48020000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart1";
> + reg = <0x48020000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <72>;
> + dmas = <&edma 26 &edma 27>;
> + dma-names = "tx", "rx";
> + };
> +
> + uart2: uart at 48022000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart2";
> + reg = <0x48022000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <73>;
> + dmas = <&edma 28 &edma 29>;
> + dma-names = "tx", "rx";
> + };
> +
> + uart3: uart at 48024000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart3";
> + reg = <0x48024000 0x2000>;
> + clock-frequency = <48000000>;
> + interrupts = <74>;
> + dmas = <&edma 30 &edma 31>;
> + dma-names = "tx", "rx";
> + };
> +
> + /* NOTE: USB needs a transceiver driver for phys to work */
> + usb: usb_otg_hs at 47401000 {
> + compatible = "ti,am33xx-usb";
> + reg = <0x47401000 0x400000>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ti,hwmods = "usb_otg_hs";
> +
> + usb0: usb at 47401000 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x47401400 0x400
> + 0x47401000 0x200>;
> + reg-names = "mc", "control";
> + interrupts = <18>;
> + interrupt-names = "mc";
> + dr_mode = "otg";
> + mentor,multipoint = <1>;
> + mentor,num-eps = <16>;
> + mentor,ram-bits = <12>;
> + mentor,power = <500>;
> + };
> +
> + usb1: usb at 47401800 {
> + compatible = "ti,musb-am33xx";
> + status = "disabled";
> + reg = <0x47401c00 0x400
> + 0x47401800 0x200>;
> + reg-names = "mc", "control";
> + interrupts = <19>;
> + interrupt-names = "mc";
> + dr_mode = "otg";
> + mentor,multipoint = <1>;
> + mentor,num-eps = <16>;
> + mentor,ram-bits = <12>;
> + mentor,power = <500>;
> + };
> + };
> +
> + wd_timer2: wd_timer at 480c2000 {
> + compatible = "ti,omap3-wdt";
> + ti,hwmods = "wd_timer";
> + reg = <0x480c2000 0x1000>;
> + interrupts = <0>;
> + };
> + };
> +};
> +
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
2015-01-15 21:23 ` Suman Anna
@ 2015-01-15 22:59 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-15 22:59 UTC (permalink / raw)
To: Suman Anna; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Suman Anna <s-anna@ti.com> [150115 13:26]:
> On 01/13/2015 05:37 PM, Tony Lindgren wrote:
> > +
> > + mailbox: mailbox@480c8000 {
> > + compatible = "ti,omap3-mailbox";
>
> The Mailbox IP is actually more like that of OMAP4, so the correct one
> would be "ti,omap4-mailbox"
>
> > + reg = <0x480c8000 0x2000>;
> > + interrupts = <77>;
> > + ti,hwmods = "mailbox";
> > + ti,mbox-num-users = <4>;
> > + ti,mbox-num-fifos = <8>;
> This should be 12
>
> > + mbox_wkupm3: wkup_m3 {
> > + ti,mbox-tx = <0 0 0>;
> > + ti,mbox-rx = <0 0 3>;
> > + };
>
> This may have been copied from AM335, so is incorrect. You are better
> off starting with one for DSP instead of above, below are taken from the
> corresponding SysLink release associated with above PSP release
> mbox_dsp: mbox_dsp {
> ti,mbox-tx = <3 0 0>;
> ti,mbox-rx = <0 0 0>;
> };
Thanks for checking it! Yes I just copied the entry from am33xx.dtsi
and forgot to even check it.
The IO ranges, interrupts and dma channels I generated with printk
from a booted PSP kernel so those should be mostly correct. But
everything else is prone to cut and paste type errors.
For reference, the devices I've confirmed to work so far are:
- intc
- timers
- gpmc
- i2c
- ethernet and mdio
- mmc
- edma
- uart
Updated patch below with the mailbox fixed.
Regards,
Tony
8< ----------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add basic dm816x device tree configuration
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,374 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm@48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm@48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon@44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma@49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm@48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio@48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio@4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c@48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c@4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller@48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox@480c8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <12>;
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <0 0 0>;
+ };
+ };
+
+ mdio: mdio@4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet@4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet@4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi@48030000 {
+ compatible = "ti,omap3-mcspi";
+ reg = <0x48030000 0x2000>;
+ interrupts = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc@48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer@4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer@4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart@48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart@48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart@48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs@47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb@47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb@47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer@480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
@ 2015-01-15 22:59 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-15 22:59 UTC (permalink / raw)
To: linux-arm-kernel
* Suman Anna <s-anna@ti.com> [150115 13:26]:
> On 01/13/2015 05:37 PM, Tony Lindgren wrote:
> > +
> > + mailbox: mailbox at 480c8000 {
> > + compatible = "ti,omap3-mailbox";
>
> The Mailbox IP is actually more like that of OMAP4, so the correct one
> would be "ti,omap4-mailbox"
>
> > + reg = <0x480c8000 0x2000>;
> > + interrupts = <77>;
> > + ti,hwmods = "mailbox";
> > + ti,mbox-num-users = <4>;
> > + ti,mbox-num-fifos = <8>;
> This should be 12
>
> > + mbox_wkupm3: wkup_m3 {
> > + ti,mbox-tx = <0 0 0>;
> > + ti,mbox-rx = <0 0 3>;
> > + };
>
> This may have been copied from AM335, so is incorrect. You are better
> off starting with one for DSP instead of above, below are taken from the
> corresponding SysLink release associated with above PSP release
> mbox_dsp: mbox_dsp {
> ti,mbox-tx = <3 0 0>;
> ti,mbox-rx = <0 0 0>;
> };
Thanks for checking it! Yes I just copied the entry from am33xx.dtsi
and forgot to even check it.
The IO ranges, interrupts and dma channels I generated with printk
from a booted PSP kernel so those should be mostly correct. But
everything else is prone to cut and paste type errors.
For reference, the devices I've confirmed to work so far are:
- intc
- timers
- gpmc
- i2c
- ethernet and mdio
- mmc
- edma
- uart
Updated patch below with the mailbox fixed.
Regards,
Tony
8< ----------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add basic dm816x device tree configuration
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,374 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm at 48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm at 48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon at 44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma at 49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm at 48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio at 48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio at 4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c at 48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c at 4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller at 48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox at 480c8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <12>;
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <0 0 0>;
+ };
+ };
+
+ mdio: mdio at 4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy at 0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy at 1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet at 4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet at 4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi at 48030000 {
+ compatible = "ti,omap3-mcspi";
+ reg = <0x48030000 0x2000>;
+ interrupts = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc at 48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer at 4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer at 48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer at 4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart at 48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart at 48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart at 48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs at 47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb at 47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb at 47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer at 480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
2015-01-15 22:59 ` Tony Lindgren
@ 2015-01-17 16:41 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 16:41 UTC (permalink / raw)
To: Suman Anna; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Tony Lindgren <tony@atomide.com> [150115 15:05]:
>
> For reference, the devices I've confirmed to work so far are:
>
> - intc
> - timers
> - gpmc
> - i2c
> - ethernet and mdio
> - mmc
> - edma
> - uart
>
> Updated patch below with the mailbox fixed.
Got the spi working too. The it needs to be compatible with
ti,omap4-mcspi with four chip selects. Updated patch below.
Also added the pinctrl-single entry.
Regards,
Tony
8< ------------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add basic dm816x device tree configuration
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,386 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/omap.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ dm816x_pinmux: pinmux@44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x48140800 0x50a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0xf>;
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm@48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm@48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon@44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma@49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm@48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio@48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio@4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c@48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c@4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller@48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox@480c8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <12>;
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <0 0 0>;
+ };
+ };
+
+ mdio: mdio@4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet@4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet@4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi@48030000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x48030000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <65>;
+ ti,spi-num-cs = <4>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc@48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer@4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer@4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart@48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart@48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart@48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs@47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb@47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb@47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer@480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
@ 2015-01-17 16:41 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 16:41 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150115 15:05]:
>
> For reference, the devices I've confirmed to work so far are:
>
> - intc
> - timers
> - gpmc
> - i2c
> - ethernet and mdio
> - mmc
> - edma
> - uart
>
> Updated patch below with the mailbox fixed.
Got the spi working too. The it needs to be compatible with
ti,omap4-mcspi with four chip selects. Updated patch below.
Also added the pinctrl-single entry.
Regards,
Tony
8< ------------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add basic dm816x device tree configuration
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,386 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/omap.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+ * The soc node represents the soc top level view. It is used for IPs
+ * that are not memory mapped in the MPU view or for the MPU itself.
+ */
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ dm816x_pinmux: pinmux at 44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x48140800 0x50a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0xf>;
+ };
+
+ /*
+ * XXX: Use a flat representation of the dm816x interconnect.
+ * The real dm816x interconnect network is quite complex. Since
+ * it will not bring real advantage to represent that in DT
+ * for the moment, just use a fake OCP bus entry to represent
+ * the whole bus hierarchy.
+ */
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x44000000 0x10000>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm at 48180000 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x48180000 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm at 48140000 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x48140000 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x48140000 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon at 44e10000 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e10000 0x800>;
+ };
+
+ edma: edma at 49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm at 48080000 {
+ compatible = "ti,816-elm";
+ ti,hwmods = "elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+ };
+
+ gpio1: gpio at 48032000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio1";
+ reg = <0x48032000 0x1000>;
+ interrupts = <97>;
+ };
+
+ gpio2: gpio at 4804c000 {
+ compatible = "ti,omap3-gpio";
+ ti,hwmods = "gpio2";
+ reg = <0x4804c000 0x1000>;
+ interrupts = <99>;
+ };
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <100>;
+ gpmc,num-cs = <6>;
+ gpmc,num-waitpins = <2>;
+ };
+
+ i2c1: i2c at 48028000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c1";
+ reg = <0x48028000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <70>;
+ dmas = <&edma 58 &edma 59>;
+ dma-names = "tx", "rx";
+ };
+
+ i2c2: i2c at 4802a000 {
+ compatible = "ti,omap4-i2c";
+ ti,hwmods = "i2c2";
+ reg = <0x4802a000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <71>;
+ dmas = <&edma 60 &edma 61>;
+ dma-names = "tx", "rx";
+ };
+
+ intc: interrupt-controller at 48200000 {
+ compatible = "ti,dm816-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x48200000 0x1000>;
+ };
+
+ mailbox: mailbox at 480c8000 {
+ compatible = "ti,omap4-mailbox";
+ reg = <0x480c8000 0x2000>;
+ interrupts = <77>;
+ ti,hwmods = "mailbox";
+ ti,mbox-num-users = <4>;
+ ti,mbox-num-fifos = <12>;
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = <3 0 0>;
+ ti,mbox-rx = <0 0 0>;
+ };
+ };
+
+ mdio: mdio at 4a100800 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a100800 0x100>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ phy0: ethernet-phy at 0 {
+ reg = <1>;
+ };
+ phy1: ethernet-phy at 1 {
+ reg = <2>;
+ };
+ };
+
+ eth0: ethernet at 4a100000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac0";
+ reg = <0x4a100000 0x800
+ 0x4a100900 0x3700>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <40 41 42 43>;
+ phy-handle = <&phy0>;
+ };
+
+ eth1: ethernet at 4a120000 {
+ compatible = "ti,dm816-emac";
+ ti,hwmods = "emac1";
+ reg = <0x4a120000 0x4000>;
+ clocks = <&sysclk24_ck>;
+ ti,davinci-ctrl-reg-offset = <0>;
+ ti,davinci-ctrl-mod-reg-offset = <0x900>;
+ ti,davinci-ctrl-ram-offset = <0x2000>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ interrupts = <44 45 46 47>;
+ phy-handle = <&phy1>;
+ };
+
+ mcspi1: spi at 48030000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x48030000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <65>;
+ ti,spi-num-cs = <4>;
+ ti,hwmods = "mcspi1";
+ dmas = <&edma 16 &edma 17
+ &edma 18 &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ };
+
+ mmc1: mmc at 48060000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x48060000 0x11000>;
+ ti,hwmods = "mmc1";
+ interrupts = <64>;
+ dmas = <&edma 24 &edma 25>;
+ dma-names = "tx", "rx";
+ };
+
+ timer1: timer at 4802e000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4802e000 0x2000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48040000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48040000 0x2000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48042000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48042000 0x2000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48044000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48044000 0x2000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 48046000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48046000 0x2000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer at 48048000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x48048000 0x2000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ };
+
+ timer7: timer at 4804a000 {
+ compatible = "ti,dm816-timer";
+ reg = <0x4804a000 0x2000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ };
+
+ uart1: uart at 48020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ reg = <0x48020000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <72>;
+ dmas = <&edma 26 &edma 27>;
+ dma-names = "tx", "rx";
+ };
+
+ uart2: uart at 48022000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ reg = <0x48022000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <73>;
+ dmas = <&edma 28 &edma 29>;
+ dma-names = "tx", "rx";
+ };
+
+ uart3: uart at 48024000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ reg = <0x48024000 0x2000>;
+ clock-frequency = <48000000>;
+ interrupts = <74>;
+ dmas = <&edma 30 &edma 31>;
+ dma-names = "tx", "rx";
+ };
+
+ /* NOTE: USB needs a transceiver driver for phys to work */
+ usb: usb_otg_hs at 47401000 {
+ compatible = "ti,am33xx-usb";
+ reg = <0x47401000 0x400000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,hwmods = "usb_otg_hs";
+
+ usb0: usb at 47401000 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x47401400 0x400
+ 0x47401000 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <18>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+
+ usb1: usb at 47401800 {
+ compatible = "ti,musb-am33xx";
+ status = "disabled";
+ reg = <0x47401c00 0x400
+ 0x47401800 0x200>;
+ reg-names = "mc", "control";
+ interrupts = <19>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ mentor,multipoint = <1>;
+ mentor,num-eps = <16>;
+ mentor,ram-bits = <12>;
+ mentor,power = <500>;
+ };
+ };
+
+ wd_timer2: wd_timer at 480c2000 {
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer";
+ reg = <0x480c2000 0x1000>;
+ interrupts = <0>;
+ };
+ };
+};
+
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-13 23:37 ` Tony Lindgren
@ 2015-01-17 16:47 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 16:47 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
* Tony Lindgren <tony@atomide.com> [150113 15:44]:
> This allows booting the device with basic functionality.
>
> Note that at least on my revision c board the DDR3 does
> not seem to work properly and only some of the memory
> can be reliably used.
>
> Also, the mainline u-boot does not seem to properly
> initialize the ethernet, so I've been using the old TI
> u-boot at:
>
> http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Here's this one updated with spi-nor detected and a minimal
pinctrl-single configuration. No partition info yet configured
though. Also looks like the PULL_ENA bit is inverted on dm816x
like on am33xx so at some point we probably want to have
a arch/arm/boot/dts/include/dt-bindings/pinctrl/dm816x.h.
Regards,
Tony
8< -------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add minimal support for dm8168-evm
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 0000000..857d028
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,129 @@
+/*
+ * 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.
+ */
+/dts-v1/;
+
+#include "dm816x.dtsi"
+
+/ {
+ model = "DM8168 EVM";
+ compatible = "ti,dm8168-evm", "ti,dm8168";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000 /* 1 GB */
+ 0xc0000000 0x40000000>; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&dm816x_pinmux {
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins = <
+ DM816X_IOPAD(0x0a94, PIN_INPUT | MUX_MODE0) /* SPI_SCLK */
+ DM816X_IOPAD(0x0a98, PIN_OUTPUT | MUX_MODE0) /* SPI_SCS0 */
+ DM816X_IOPAD(0x0aa8, PIN_INPUT | MUX_MODE0) /* SPI_D0 */
+ DM816X_IOPAD(0x0aac, PIN_INPUT | MUX_MODE0) /* SPI_D1 */
+ >;
+ };
+};
+
+&i2c1 {
+ extgpio0: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&i2c2 {
+ extgpio1: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x04000000 0x01000000>; /* CS0: 16MB for NAND */
+
+ nand@0,0 {
+ linux,mtd-name= "micron,mt29f2g16aadwp";
+ reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,nand-ecc-opt = "bch8";
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ partition@0 {
+ label = "X-Loader";
+ reg = <0 0x80000>;
+ };
+ partition@0x80000 {
+ label = "U-Boot";
+ reg = <0x80000 0x1c0000>;
+ };
+ partition@0x1c0000 {
+ label = "Environment";
+ reg = <0x240000 0x40000>;
+ };
+ partition@0x280000 {
+ label = "Kernel";
+ reg = <0x280000 0x500000>;
+ };
+ partition@0x780000 {
+ label = "Filesystem";
+ reg = <0x780000 0xf880000>;
+ };
+ };
+};
+
+&mcspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi1_pins>;
+
+ m25p80@0 {
+ compatible = "w25x32";
+ spi-max-frequency = <48000000>;
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&mmc1 {
+ vmmc-supply = <&vmmcsd_fixed>;
+};
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -61,6 +61,7 @@
#define OMAP3430_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25d8) (val)
#define OMAP3630_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25a0) (val)
#define OMAP3_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2a00) (val)
+#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define DRA7XX_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x3400) (val)
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-17 16:47 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150113 15:44]:
> This allows booting the device with basic functionality.
>
> Note that at least on my revision c board the DDR3 does
> not seem to work properly and only some of the memory
> can be reliably used.
>
> Also, the mainline u-boot does not seem to properly
> initialize the ethernet, so I've been using the old TI
> u-boot at:
>
> http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Here's this one updated with spi-nor detected and a minimal
pinctrl-single configuration. No partition info yet configured
though. Also looks like the PULL_ENA bit is inverted on dm816x
like on am33xx so at some point we probably want to have
a arch/arm/boot/dts/include/dt-bindings/pinctrl/dm816x.h.
Regards,
Tony
8< -------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add minimal support for dm8168-evm
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 0000000..857d028
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,129 @@
+/*
+ * 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.
+ */
+/dts-v1/;
+
+#include "dm816x.dtsi"
+
+/ {
+ model = "DM8168 EVM";
+ compatible = "ti,dm8168-evm", "ti,dm8168";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000 /* 1 GB */
+ 0xc0000000 0x40000000>; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&dm816x_pinmux {
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins = <
+ DM816X_IOPAD(0x0a94, PIN_INPUT | MUX_MODE0) /* SPI_SCLK */
+ DM816X_IOPAD(0x0a98, PIN_OUTPUT | MUX_MODE0) /* SPI_SCS0 */
+ DM816X_IOPAD(0x0aa8, PIN_INPUT | MUX_MODE0) /* SPI_D0 */
+ DM816X_IOPAD(0x0aac, PIN_INPUT | MUX_MODE0) /* SPI_D1 */
+ >;
+ };
+};
+
+&i2c1 {
+ extgpio0: pcf8575 at 20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&i2c2 {
+ extgpio1: pcf8575 at 20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x04000000 0x01000000>; /* CS0: 16MB for NAND */
+
+ nand at 0,0 {
+ linux,mtd-name= "micron,mt29f2g16aadwp";
+ reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,nand-ecc-opt = "bch8";
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ partition at 0 {
+ label = "X-Loader";
+ reg = <0 0x80000>;
+ };
+ partition at 0x80000 {
+ label = "U-Boot";
+ reg = <0x80000 0x1c0000>;
+ };
+ partition at 0x1c0000 {
+ label = "Environment";
+ reg = <0x240000 0x40000>;
+ };
+ partition at 0x280000 {
+ label = "Kernel";
+ reg = <0x280000 0x500000>;
+ };
+ partition at 0x780000 {
+ label = "Filesystem";
+ reg = <0x780000 0xf880000>;
+ };
+ };
+};
+
+&mcspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi1_pins>;
+
+ m25p80 at 0 {
+ compatible = "w25x32";
+ spi-max-frequency = <48000000>;
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&mmc1 {
+ vmmc-supply = <&vmmcsd_fixed>;
+};
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -61,6 +61,7 @@
#define OMAP3430_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25d8) (val)
#define OMAP3630_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25a0) (val)
#define OMAP3_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2a00) (val)
+#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
#define DRA7XX_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x3400) (val)
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-17 16:47 ` Tony Lindgren
@ 2015-01-17 17:51 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-17 17:51 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
On 17 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
Yes, ditto on dm814x but there things get even more interesting:
It has the same four config bits as am335x but moved them to bits
16-19, while bits 0-7 contains 1 << mode. The benefit is that you can
also select no mode at all (high-Z or just the pull if enabled) and
this is in fact the default, though I'm curious what would happen if
multiple bits are set (though not curious enough to risk my hardware
:P ).
It also means you can change mode with a byte-write to avoid touching
the upper bits, which is nice especially since slew is preconfigured
per pin to match I/O timings and you're supposed to never change it
(after fixing the ones ROM messed up due to bugs). Also on rev 2.x
silicon you're not allowed to disable the receiver if using 3.3V I/O.
> +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
The overall control module layout is actually compatible across the
whole happy family; basically any register they have in common is at
the same offset (with notable exception of ADC and eCAP event muxes on
am335x versus c6a811x/dra62x, but the latter is a semi-mythical device
anyway, not even a product brief in circulation). They often even have
the same semantics, though padconf shows this isn't always true
unfortunately.
A similar thing is true for the overall device memory map actually:
https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-17 17:51 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-17 17:51 UTC (permalink / raw)
To: linux-arm-kernel
On 17 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
Yes, ditto on dm814x but there things get even more interesting:
It has the same four config bits as am335x but moved them to bits
16-19, while bits 0-7 contains 1 << mode. The benefit is that you can
also select no mode@all (high-Z or just the pull if enabled) and
this is in fact the default, though I'm curious what would happen if
multiple bits are set (though not curious enough to risk my hardware
:P ).
It also means you can change mode with a byte-write to avoid touching
the upper bits, which is nice especially since slew is preconfigured
per pin to match I/O timings and you're supposed to never change it
(after fixing the ones ROM messed up due to bugs). Also on rev 2.x
silicon you're not allowed to disable the receiver if using 3.3V I/O.
> +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
The overall control module layout is actually compatible across the
whole happy family; basically any register they have in common is at
the same offset (with notable exception of ADC and eCAP event muxes on
am335x versus c6a811x/dra62x, but the latter is a semi-mythical device
anyway, not even a product brief in circulation). They often even have
the same semantics, though padconf shows this isn't always true
unfortunately.
A similar thing is true for the overall device memory map actually:
https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-17 17:51 ` Matthijs van Duin
@ 2015-01-17 18:14 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 18:14 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 09:54]:
> On 17 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> > Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
>
> Yes, ditto on dm814x but there things get even more interesting:
>
> It has the same four config bits as am335x but moved them to bits
> 16-19, while bits 0-7 contains 1 << mode. The benefit is that you can
> also select no mode at all (high-Z or just the pull if enabled) and
> this is in fact the default, though I'm curious what would happen if
> multiple bits are set (though not curious enough to risk my hardware
> :P ).
Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
> It also means you can change mode with a byte-write to avoid touching
> the upper bits, which is nice especially since slew is preconfigured
> per pin to match I/O timings and you're supposed to never change it
> (after fixing the ones ROM messed up due to bugs). Also on rev 2.x
> silicon you're not allowed to disable the receiver if using 3.3V I/O.
Maybe that's why some bits got shifted :)
> > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>
> The overall control module layout is actually compatible across the
> whole happy family; basically any register they have in common is at
> the same offset (with notable exception of ADC and eCAP event muxes on
> am335x versus c6a811x/dra62x, but the latter is a semi-mythical device
> anyway, not even a product brief in circulation). They often even have
> the same semantics, though padconf shows this isn't always true
> unfortunately.
Got any generic naming in mind for the helper macro we could use?
> A similar thing is true for the overall device memory map actually:
> https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view
Cool, that certainly helps. To me it looks dm814x needs it's own
clock driver for the source clocks, but after that the dividers
are similar to dm816x and am33xx. Have not looked at the am814x
beyond that though.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-17 18:14 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-17 18:14 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 09:54]:
> On 17 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> > Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
>
> Yes, ditto on dm814x but there things get even more interesting:
>
> It has the same four config bits as am335x but moved them to bits
> 16-19, while bits 0-7 contains 1 << mode. The benefit is that you can
> also select no mode at all (high-Z or just the pull if enabled) and
> this is in fact the default, though I'm curious what would happen if
> multiple bits are set (though not curious enough to risk my hardware
> :P ).
Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
> It also means you can change mode with a byte-write to avoid touching
> the upper bits, which is nice especially since slew is preconfigured
> per pin to match I/O timings and you're supposed to never change it
> (after fixing the ones ROM messed up due to bugs). Also on rev 2.x
> silicon you're not allowed to disable the receiver if using 3.3V I/O.
Maybe that's why some bits got shifted :)
> > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>
> The overall control module layout is actually compatible across the
> whole happy family; basically any register they have in common is at
> the same offset (with notable exception of ADC and eCAP event muxes on
> am335x versus c6a811x/dra62x, but the latter is a semi-mythical device
> anyway, not even a product brief in circulation). They often even have
> the same semantics, though padconf shows this isn't always true
> unfortunately.
Got any generic naming in mind for the helper macro we could use?
> A similar thing is true for the overall device memory map actually:
> https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view
Cool, that certainly helps. To me it looks dm814x needs it's own
clock driver for the source clocks, but after that the dividers
are similar to dm816x and am33xx. Have not looked at the am814x
beyond that though.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-17 18:14 ` Tony Lindgren
@ 2015-01-17 22:37 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-17 22:37 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Brian Hutchinson
On 17 January 2015 at 19:14, Tony Lindgren <tony@atomide.com> wrote:
> Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
> bits for MUXMODE instead of just bits [2:0]?
However, the datasheet's table of possible mux modes per pin has as
column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80. (mode 0,
called "safe mode" is mentioned separately)
For compatibility sake I'm personally more inclined to consider them
modes 0-7 with "safe mode" being -1.
Oh, and I just remembered: while 811x is mostly compatible with 814x,
it has up to 12 mux modes per pin. So replace "byte-write" by
"u16-write" in my previous post ;-)
>> It also means you can change mode with a u16-write to avoid touching
>> the upper bits
>
> Maybe that's why some bits got shifted :)
Yes, in general bitfields seem to be grouped into separate bytes in
quite a few places where it may be convenient to take advantage of the
fact that both PRCM and the Control module are byte-addressable to
avoid having to do a read-modify-update. (For example the omap4/5
standard layout for CLKCTRL puts modulemode in byte 0, optional fclks
in byte 1, and any mux/div config the module may have in the upper
bytes. Only the am335x violates this rule.)
>> The overall control module layout is actually compatible across the
>> whole happy family
>
> Got any generic naming in mind for the helper macro we could use?
I've already been pondering what to call this family, since
architecturally they do very clearly form a fairly close family
related to, but also clearly distinct from, the omap4/5 line.
As you may notice from my spreadsheet I already generally prefer to
use their names (Netra, Centaurus, Subarctic, Aegis), both because
names are rather more memorable and distinguishable for humans than
4-digit numbers and because each actually has a flurry of wildly
different part codes depending on which subsystems happen to fail the
factory test and get disabled (which may of course be a big deal
featurewise but is rather irrelevant to the kernel).
Still leaves four names to unify... I may be biased but I'm leaning
towards "Centauroid": Centaurus (814x) seems to have a fairly central
position, being memory-map compatible with the there other members
(i.e. no subsystem/peripheral of Centaurus overlaps a different one of
another device), while the same is not true between Netra (816x) and
subarctic (335x). I suspect this may be because Centaurus and Netra
form a single product line (DM81xx) iin one market segment (video)
while Centaurus and Subarctic form a single product line (DRA6xx) in
another market segment (automotive).
> Cool, that certainly helps. To me it looks dm814x needs it's own
> clock driver for the source clocks, but after that the dividers
> are similar to dm816x and am33xx. Have not looked at the am814x
> beyond that though.
dm814x you mean... the downfeatured Sitara version got called am387x,
naturally. ;-)
The biggest architectural differences between three chips are indeed
in PRCM, where each member has its own peculiarities:
Netra and Centaurus both have the simple but clean omap4-subset PRCM.
No fancy auto-management by hardware but at least a clean
well-organised interface, with the biggest blemish being the
register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in
contrast, being organized by "sort -R", incompatibility with the
omap4/5 register layouts, and a seemingly endless supply of novel ways
of being inconsistent.)
Netra however has the FAPLL experiment, which apparently wasn't a
success so while Centaurus retained much of the clock tree it reverted
to using normal PLLs by replacing the FAPLLs with its PLL subsystem
containing additional clock muxes to sort of glue it onto the existing
clock tree, making the clock tree a bit messier. (Especially older
versions of the TRM were very confusing to those unfamiliar with this
Netra-heritage since FAPLL names were still all over the place.) In
line with the "fully software managed" tradition, it seems to wire
*all* control/status signals of the PLLs directly into registers. They
can be slightly fickle (and mucking up the MPU PLL can leave you
pretty screwed, especially since the watchdog reset doesn't reset the
PLLs).
Also important: Centaurus has very similar Ethernet subsystem to that
of subarctic, though some components are a slightly older minor
revision. In violation of what a "minor revision" normally means, they
are however software-incompatible thanks to moving blocks of registers
around to different offsets, and some per-port settings became global
or vice versa. This however seems to be a tradition for the 3-port
gigabit switch subsystem: out of curiosity I examined the ones in
other TI SoCs, and it turns out that literally *all* of them have
different, incompatible register layouts (sometimes also extending to
the switch table entries and/or DMA descriptors).
Other than this, the subsystems and peripherals are mostly familiar
omap4-generation stuff, but with a standard C674x DSP instead of
omap4's weird custom "Tesla" DSP (although some Tesla documentation
accidentally got copy-pasted into Netra's TRM). An overview of the
video situation on Centaurus (afaik, I'm not deeply into the video
stuff) can be found in this post, where I was also cheerleading your
efforts towards mainline dm81xx support:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681
There's also an interesting Security Subsystem, which houses the
crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
irq routing, and an elaborate L3 firewall instance covering both
external and internal access. It is about as well-documented as the
crypto accelerators on the am335x are :P Still, it's not hard to get
it operational, and allows e.g. sequencing of composite crypto
operations combined with DMA without the kernel having to micro-manage
it, along with secure local key storage.
Once the basics work there's definitely some neat gear on these chips
to play with
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-17 22:37 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-17 22:37 UTC (permalink / raw)
To: linux-arm-kernel
On 17 January 2015 at 19:14, Tony Lindgren <tony@atomide.com> wrote:
> Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
> bits for MUXMODE instead of just bits [2:0]?
However, the datasheet's table of possible mux modes per pin has as
column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80. (mode 0,
called "safe mode" is mentioned separately)
For compatibility sake I'm personally more inclined to consider them
modes 0-7 with "safe mode" being -1.
Oh, and I just remembered: while 811x is mostly compatible with 814x,
it has up to 12 mux modes per pin. So replace "byte-write" by
"u16-write" in my previous post ;-)
>> It also means you can change mode with a u16-write to avoid touching
>> the upper bits
>
> Maybe that's why some bits got shifted :)
Yes, in general bitfields seem to be grouped into separate bytes in
quite a few places where it may be convenient to take advantage of the
fact that both PRCM and the Control module are byte-addressable to
avoid having to do a read-modify-update. (For example the omap4/5
standard layout for CLKCTRL puts modulemode in byte 0, optional fclks
in byte 1, and any mux/div config the module may have in the upper
bytes. Only the am335x violates this rule.)
>> The overall control module layout is actually compatible across the
>> whole happy family
>
> Got any generic naming in mind for the helper macro we could use?
I've already been pondering what to call this family, since
architecturally they do very clearly form a fairly close family
related to, but also clearly distinct from, the omap4/5 line.
As you may notice from my spreadsheet I already generally prefer to
use their names (Netra, Centaurus, Subarctic, Aegis), both because
names are rather more memorable and distinguishable for humans than
4-digit numbers and because each actually has a flurry of wildly
different part codes depending on which subsystems happen to fail the
factory test and get disabled (which may of course be a big deal
featurewise but is rather irrelevant to the kernel).
Still leaves four names to unify... I may be biased but I'm leaning
towards "Centauroid": Centaurus (814x) seems to have a fairly central
position, being memory-map compatible with the there other members
(i.e. no subsystem/peripheral of Centaurus overlaps a different one of
another device), while the same is not true between Netra (816x) and
subarctic (335x). I suspect this may be because Centaurus and Netra
form a single product line (DM81xx) iin one market segment (video)
while Centaurus and Subarctic form a single product line (DRA6xx) in
another market segment (automotive).
> Cool, that certainly helps. To me it looks dm814x needs it's own
> clock driver for the source clocks, but after that the dividers
> are similar to dm816x and am33xx. Have not looked at the am814x
> beyond that though.
dm814x you mean... the downfeatured Sitara version got called am387x,
naturally. ;-)
The biggest architectural differences between three chips are indeed
in PRCM, where each member has its own peculiarities:
Netra and Centaurus both have the simple but clean omap4-subset PRCM.
No fancy auto-management by hardware but at least a clean
well-organised interface, with the biggest blemish being the
register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in
contrast, being organized by "sort -R", incompatibility with the
omap4/5 register layouts, and a seemingly endless supply of novel ways
of being inconsistent.)
Netra however has the FAPLL experiment, which apparently wasn't a
success so while Centaurus retained much of the clock tree it reverted
to using normal PLLs by replacing the FAPLLs with its PLL subsystem
containing additional clock muxes to sort of glue it onto the existing
clock tree, making the clock tree a bit messier. (Especially older
versions of the TRM were very confusing to those unfamiliar with this
Netra-heritage since FAPLL names were still all over the place.) In
line with the "fully software managed" tradition, it seems to wire
*all* control/status signals of the PLLs directly into registers. They
can be slightly fickle (and mucking up the MPU PLL can leave you
pretty screwed, especially since the watchdog reset doesn't reset the
PLLs).
Also important: Centaurus has very similar Ethernet subsystem to that
of subarctic, though some components are a slightly older minor
revision. In violation of what a "minor revision" normally means, they
are however software-incompatible thanks to moving blocks of registers
around to different offsets, and some per-port settings became global
or vice versa. This however seems to be a tradition for the 3-port
gigabit switch subsystem: out of curiosity I examined the ones in
other TI SoCs, and it turns out that literally *all* of them have
different, incompatible register layouts (sometimes also extending to
the switch table entries and/or DMA descriptors).
Other than this, the subsystems and peripherals are mostly familiar
omap4-generation stuff, but with a standard C674x DSP instead of
omap4's weird custom "Tesla" DSP (although some Tesla documentation
accidentally got copy-pasted into Netra's TRM). An overview of the
video situation on Centaurus (afaik, I'm not deeply into the video
stuff) can be found in this post, where I was also cheerleading your
efforts towards mainline dm81xx support:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681
There's also an interesting Security Subsystem, which houses the
crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
irq routing, and an elaborate L3 firewall instance covering both
external and internal access. It is about as well-documented as the
crypto accelerators on the am335x are :P Still, it's not hard to get
it operational, and allows e.g. sequencing of composite crypto
operations combined with DMA without the kernel having to micro-manage
it, along with secure local key storage.
Once the basics work there's definitely some neat gear on these chips
to play with
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-17 22:37 ` Matthijs van Duin
@ 2015-01-19 17:29 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 17:29 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 14:41]:
> On 17 January 2015 at 19:14, Tony Lindgren <tony@atomide.com> wrote:
> > Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
> > bits for MUXMODE instead of just bits [2:0]?
>
> However, the datasheet's table of possible mux modes per pin has as
> column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80. (mode 0,
> called "safe mode" is mentioned separately)
>
> For compatibility sake I'm personally more inclined to consider them
> modes 0-7 with "safe mode" being -1.
>
> Oh, and I just remembered: while 811x is mostly compatible with 814x,
> it has up to 12 mux modes per pin. So replace "byte-write" by
> "u16-write" in my previous post ;-)
Luckily those can be defined which ever way in pinctrl single just
by changing the pinctrl-single,register-width entry.
> > Got any generic naming in mind for the helper macro we could use?
>
> I've already been pondering what to call this family, since
> architecturally they do very clearly form a fairly close family
> related to, but also clearly distinct from, the omap4/5 line.
>
> As you may notice from my spreadsheet I already generally prefer to
> use their names (Netra, Centaurus, Subarctic, Aegis), both because
> names are rather more memorable and distinguishable for humans than
> 4-digit numbers and because each actually has a flurry of wildly
> different part codes depending on which subsystems happen to fail the
> factory test and get disabled (which may of course be a big deal
> featurewise but is rather irrelevant to the kernel).
>
> Still leaves four names to unify... I may be biased but I'm leaning
> towards "Centauroid": Centaurus (814x) seems to have a fairly central
> position, being memory-map compatible with the there other members
> (i.e. no subsystem/peripheral of Centaurus overlaps a different one of
> another device), while the same is not true between Netra (816x) and
> subarctic (335x). I suspect this may be because Centaurus and Netra
> form a single product line (DM81xx) iin one market segment (video)
> while Centaurus and Subarctic form a single product line (DRA6xx) in
> another market segment (automotive).
Well sounds like no need to start messing with the existing ti81xx
defines excemt maybe rename cpu_is_ti81xx to soc_is_dm81xx and so
on. There are only very few places referencing that now.
> > Cool, that certainly helps. To me it looks dm814x needs it's own
> > clock driver for the source clocks, but after that the dividers
> > are similar to dm816x and am33xx. Have not looked at the am814x
> > beyond that though.
>
> dm814x you mean... the downfeatured Sitara version got called am387x,
> naturally. ;-)
Yes I mean dm814x sorry :)
> The biggest architectural differences between three chips are indeed
> in PRCM, where each member has its own peculiarities:
>
> Netra and Centaurus both have the simple but clean omap4-subset PRCM.
> No fancy auto-management by hardware but at least a clean
> well-organised interface, with the biggest blemish being the
> register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in
> contrast, being organized by "sort -R", incompatibility with the
> omap4/5 register layouts, and a seemingly endless supply of novel ways
> of being inconsistent.)
Uhh yeah.
> Netra however has the FAPLL experiment, which apparently wasn't a
> success so while Centaurus retained much of the clock tree it reverted
> to using normal PLLs by replacing the FAPLLs with its PLL subsystem
> containing additional clock muxes to sort of glue it onto the existing
> clock tree, making the clock tree a bit messier. (Especially older
> versions of the TRM were very confusing to those unfamiliar with this
> Netra-heritage since FAPLL names were still all over the place.) In
> line with the "fully software managed" tradition, it seems to wire
> *all* control/status signals of the PLLs directly into registers. They
> can be slightly fickle (and mucking up the MPU PLL can leave you
> pretty screwed, especially since the watchdog reset doesn't reset the
> PLLs).
Hmm I sort of got the idea that dm814x and dm816x were done about
the same time. Are you saying dm814x was actually done after dm816x?
> Also important: Centaurus has very similar Ethernet subsystem to that
> of subarctic, though some components are a slightly older minor
> revision. In violation of what a "minor revision" normally means, they
> are however software-incompatible thanks to moving blocks of registers
> around to different offsets, and some per-port settings became global
> or vice versa. This however seems to be a tradition for the 3-port
> gigabit switch subsystem: out of curiosity I examined the ones in
> other TI SoCs, and it turns out that literally *all* of them have
> different, incompatible register layouts (sometimes also extending to
> the switch table entries and/or DMA descriptors).
Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
the registers are different.
> Other than this, the subsystems and peripherals are mostly familiar
> omap4-generation stuff, but with a standard C674x DSP instead of
> omap4's weird custom "Tesla" DSP (although some Tesla documentation
> accidentally got copy-pasted into Netra's TRM). An overview of the
> video situation on Centaurus (afaik, I'm not deeply into the video
> stuff) can be found in this post, where I was also cheerleading your
> efforts towards mainline dm81xx support:
> http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681
Yeah all the add on devices are a whole different project.. But if
we get the basics working then at least somebody can work on that
if they want to.
> There's also an interesting Security Subsystem, which houses the
> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
> irq routing, and an elaborate L3 firewall instance covering both
> external and internal access. It is about as well-documented as the
> crypto accelerators on the am335x are :P Still, it's not hard to get
> it operational, and allows e.g. sequencing of composite crypto
> operations combined with DMA without the kernel having to micro-manage
> it, along with secure local key storage.
Hmm that's a lot of accelerators..
> Once the basics work there's definitely some neat gear on these chips
> to play with
Yup :)
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-19 17:29 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 17:29 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 14:41]:
> On 17 January 2015 at 19:14, Tony Lindgren <tony@atomide.com> wrote:
> > Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
> > bits for MUXMODE instead of just bits [2:0]?
>
> However, the datasheet's table of possible mux modes per pin has as
> column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80. (mode 0,
> called "safe mode" is mentioned separately)
>
> For compatibility sake I'm personally more inclined to consider them
> modes 0-7 with "safe mode" being -1.
>
> Oh, and I just remembered: while 811x is mostly compatible with 814x,
> it has up to 12 mux modes per pin. So replace "byte-write" by
> "u16-write" in my previous post ;-)
Luckily those can be defined which ever way in pinctrl single just
by changing the pinctrl-single,register-width entry.
> > Got any generic naming in mind for the helper macro we could use?
>
> I've already been pondering what to call this family, since
> architecturally they do very clearly form a fairly close family
> related to, but also clearly distinct from, the omap4/5 line.
>
> As you may notice from my spreadsheet I already generally prefer to
> use their names (Netra, Centaurus, Subarctic, Aegis), both because
> names are rather more memorable and distinguishable for humans than
> 4-digit numbers and because each actually has a flurry of wildly
> different part codes depending on which subsystems happen to fail the
> factory test and get disabled (which may of course be a big deal
> featurewise but is rather irrelevant to the kernel).
>
> Still leaves four names to unify... I may be biased but I'm leaning
> towards "Centauroid": Centaurus (814x) seems to have a fairly central
> position, being memory-map compatible with the there other members
> (i.e. no subsystem/peripheral of Centaurus overlaps a different one of
> another device), while the same is not true between Netra (816x) and
> subarctic (335x). I suspect this may be because Centaurus and Netra
> form a single product line (DM81xx) iin one market segment (video)
> while Centaurus and Subarctic form a single product line (DRA6xx) in
> another market segment (automotive).
Well sounds like no need to start messing with the existing ti81xx
defines excemt maybe rename cpu_is_ti81xx to soc_is_dm81xx and so
on. There are only very few places referencing that now.
> > Cool, that certainly helps. To me it looks dm814x needs it's own
> > clock driver for the source clocks, but after that the dividers
> > are similar to dm816x and am33xx. Have not looked at the am814x
> > beyond that though.
>
> dm814x you mean... the downfeatured Sitara version got called am387x,
> naturally. ;-)
Yes I mean dm814x sorry :)
> The biggest architectural differences between three chips are indeed
> in PRCM, where each member has its own peculiarities:
>
> Netra and Centaurus both have the simple but clean omap4-subset PRCM.
> No fancy auto-management by hardware but at least a clean
> well-organised interface, with the biggest blemish being the
> register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in
> contrast, being organized by "sort -R", incompatibility with the
> omap4/5 register layouts, and a seemingly endless supply of novel ways
> of being inconsistent.)
Uhh yeah.
> Netra however has the FAPLL experiment, which apparently wasn't a
> success so while Centaurus retained much of the clock tree it reverted
> to using normal PLLs by replacing the FAPLLs with its PLL subsystem
> containing additional clock muxes to sort of glue it onto the existing
> clock tree, making the clock tree a bit messier. (Especially older
> versions of the TRM were very confusing to those unfamiliar with this
> Netra-heritage since FAPLL names were still all over the place.) In
> line with the "fully software managed" tradition, it seems to wire
> *all* control/status signals of the PLLs directly into registers. They
> can be slightly fickle (and mucking up the MPU PLL can leave you
> pretty screwed, especially since the watchdog reset doesn't reset the
> PLLs).
Hmm I sort of got the idea that dm814x and dm816x were done about
the same time. Are you saying dm814x was actually done after dm816x?
> Also important: Centaurus has very similar Ethernet subsystem to that
> of subarctic, though some components are a slightly older minor
> revision. In violation of what a "minor revision" normally means, they
> are however software-incompatible thanks to moving blocks of registers
> around to different offsets, and some per-port settings became global
> or vice versa. This however seems to be a tradition for the 3-port
> gigabit switch subsystem: out of curiosity I examined the ones in
> other TI SoCs, and it turns out that literally *all* of them have
> different, incompatible register layouts (sometimes also extending to
> the switch table entries and/or DMA descriptors).
Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
the registers are different.
> Other than this, the subsystems and peripherals are mostly familiar
> omap4-generation stuff, but with a standard C674x DSP instead of
> omap4's weird custom "Tesla" DSP (although some Tesla documentation
> accidentally got copy-pasted into Netra's TRM). An overview of the
> video situation on Centaurus (afaik, I'm not deeply into the video
> stuff) can be found in this post, where I was also cheerleading your
> efforts towards mainline dm81xx support:
> http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681
Yeah all the add on devices are a whole different project.. But if
we get the basics working then at least somebody can work on that
if they want to.
> There's also an interesting Security Subsystem, which houses the
> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
> irq routing, and an elaborate L3 firewall instance covering both
> external and internal access. It is about as well-documented as the
> crypto accelerators on the am335x are :P Still, it's not hard to get
> it operational, and allows e.g. sequencing of composite crypto
> operations combined with DMA without the kernel having to micro-manage
> it, along with secure local key storage.
Hmm that's a lot of accelerators..
> Once the basics work there's definitely some neat gear on these chips
> to play with
Yup :)
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-15 0:07 ` Tony Lindgren
@ 2015-01-19 19:18 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 19:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-omap, Brian Hutchinson, linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150114 16:14]:
> * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > Hello.
> >
> > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> >
> > >This allows booting ti81xx boards with with when a .dts
> >
> > So, with, with or when? :-)
>
> Heh thanks will updated to:
>
> This allows booting ti81xx boards when a .dts file
> is in place.
This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
to avoid make randconfig build errors. Updated patch below.
Regards,
Tony
8< -----------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
This allows booting ti81xx boards when a .dts file
is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
.dt_compat = am3517_boards_compat,
.restart = omap3xxx_restart,
MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+#endif
+
+#ifdef CONFIG_SOC_TI81XX
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-19 19:18 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 19:18 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150114 16:14]:
> * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > Hello.
> >
> > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> >
> > >This allows booting ti81xx boards with with when a .dts
> >
> > So, with, with or when? :-)
>
> Heh thanks will updated to:
>
> This allows booting ti81xx boards when a .dts file
> is in place.
This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
to avoid make randconfig build errors. Updated patch below.
Regards,
Tony
8< -----------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
This allows booting ti81xx boards when a .dts file
is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
.dt_compat = am3517_boards_compat,
.restart = omap3xxx_restart,
MACHINE_END
+
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+#endif
+
+#ifdef CONFIG_SOC_TI81XX
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-19 19:18 ` Tony Lindgren
@ 2015-01-19 20:42 ` Felipe Balbi
-1 siblings, 0 replies; 66+ messages in thread
From: Felipe Balbi @ 2015-01-19 20:42 UTC (permalink / raw)
To: Tony Lindgren
Cc: Sergei Shtylyov, linux-omap, Brian Hutchinson, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > Hello.
> > >
> > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > >
> > > >This allows booting ti81xx boards with with when a .dts
> > >
> > > So, with, with or when? :-)
> >
> > Heh thanks will updated to:
> >
> > This allows booting ti81xx boards when a .dts file
> > is in place.
>
> This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> to avoid make randconfig build errors. Updated patch below.
>
> Regards,
>
> Tony
>
> 8< -----------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 19 Jan 2015 10:38:07 -0800
> Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
>
> This allows booting ti81xx boards when a .dts file
> is in place.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> .dt_compat = am3517_boards_compat,
> .restart = omap3xxx_restart,
> MACHINE_END
> +
> +static const char *const ti814x_boards_compat[] __initconst = {
should this definition be within that ifdef too ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-19 20:42 ` Felipe Balbi
0 siblings, 0 replies; 66+ messages in thread
From: Felipe Balbi @ 2015-01-19 20:42 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > Hello.
> > >
> > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > >
> > > >This allows booting ti81xx boards with with when a .dts
> > >
> > > So, with, with or when? :-)
> >
> > Heh thanks will updated to:
> >
> > This allows booting ti81xx boards when a .dts file
> > is in place.
>
> This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> to avoid make randconfig build errors. Updated patch below.
>
> Regards,
>
> Tony
>
> 8< -----------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 19 Jan 2015 10:38:07 -0800
> Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
>
> This allows booting ti81xx boards when a .dts file
> is in place.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> .dt_compat = am3517_boards_compat,
> .restart = omap3xxx_restart,
> MACHINE_END
> +
> +static const char *const ti814x_boards_compat[] __initconst = {
should this definition be within that ifdef too ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150119/6dad440b/attachment.sig>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-19 20:42 ` Felipe Balbi
@ 2015-01-19 21:05 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 21:05 UTC (permalink / raw)
To: Felipe Balbi
Cc: Sergei Shtylyov, linux-omap, Brian Hutchinson, linux-arm-kernel
* Felipe Balbi <balbi@ti.com> [150119 12:46]:
> On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > > Hello.
> > > >
> > > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > > >
> > > > >This allows booting ti81xx boards with with when a .dts
> > > >
> > > > So, with, with or when? :-)
> > >
> > > Heh thanks will updated to:
> > >
> > > This allows booting ti81xx boards when a .dts file
> > > is in place.
> >
> > This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> > to avoid make randconfig build errors. Updated patch below.
> >
> > Regards,
> >
> > Tony
> >
> > 8< -----------------
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Mon, 19 Jan 2015 10:38:07 -0800
> > Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
> >
> > This allows booting ti81xx boards when a .dts file
> > is in place.
> >
> > Cc: Brian Hutchinson <b.hutchman@gmail.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> > .dt_compat = am3517_boards_compat,
> > .restart = omap3xxx_restart,
> > MACHINE_END
> > +
> > +static const char *const ti814x_boards_compat[] __initconst = {
>
> should this definition be within that ifdef too ?
Oops yes totally thanks for catching that. Updated patch below.
Regards,
Tony
8< -----------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
This allows booting ti81xx boards when a .dts file
is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -144,6 +144,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
MACHINE_END
#endif
+#ifdef CONFIG_SOC_TI81XX
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+#endif
+
#ifdef CONFIG_SOC_AM33XX
static const char *const am33xx_boards_compat[] __initconst = {
"ti,am33xx",
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-19 21:05 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-19 21:05 UTC (permalink / raw)
To: linux-arm-kernel
* Felipe Balbi <balbi@ti.com> [150119 12:46]:
> On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > > Hello.
> > > >
> > > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > > >
> > > > >This allows booting ti81xx boards with with when a .dts
> > > >
> > > > So, with, with or when? :-)
> > >
> > > Heh thanks will updated to:
> > >
> > > This allows booting ti81xx boards when a .dts file
> > > is in place.
> >
> > This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> > to avoid make randconfig build errors. Updated patch below.
> >
> > Regards,
> >
> > Tony
> >
> > 8< -----------------
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Mon, 19 Jan 2015 10:38:07 -0800
> > Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
> >
> > This allows booting ti81xx boards when a .dts file
> > is in place.
> >
> > Cc: Brian Hutchinson <b.hutchman@gmail.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> > .dt_compat = am3517_boards_compat,
> > .restart = omap3xxx_restart,
> > MACHINE_END
> > +
> > +static const char *const ti814x_boards_compat[] __initconst = {
>
> should this definition be within that ifdef too ?
Oops yes totally thanks for catching that. Updated patch below.
Regards,
Tony
8< -----------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Jan 2015 10:38:07 -0800
Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
This allows booting ti81xx boards when a .dts file
is in place.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -144,6 +144,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
MACHINE_END
#endif
+#ifdef CONFIG_SOC_TI81XX
+static const char *const ti814x_boards_compat[] __initconst = {
+ "ti,dm8148",
+ "ti,dm814",
+ NULL,
+};
+
+DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti814x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti814x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+
+static const char *const ti816x_boards_compat[] __initconst = {
+ "ti,dm8168",
+ "ti,dm816",
+ NULL,
+};
+
+DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = ti81xx_map_io,
+ .init_early = ti816x_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = ti81xx_init_late,
+ .init_time = omap3_gptimer_timer_init,
+ .dt_compat = ti816x_boards_compat,
+ .restart = ti81xx_restart,
+MACHINE_END
+#endif
+
#ifdef CONFIG_SOC_AM33XX
static const char *const am33xx_boards_compat[] __initconst = {
"ti,am33xx",
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
2015-01-19 21:05 ` Tony Lindgren
@ 2015-01-19 21:10 ` Felipe Balbi
-1 siblings, 0 replies; 66+ messages in thread
From: Felipe Balbi @ 2015-01-19 21:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: Felipe Balbi, Sergei Shtylyov, linux-omap, Brian Hutchinson,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]
On Mon, Jan 19, 2015 at 01:05:45PM -0800, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [150119 12:46]:
> > On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > > > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > > > Hello.
> > > > >
> > > > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > > > >
> > > > > >This allows booting ti81xx boards with with when a .dts
> > > > >
> > > > > So, with, with or when? :-)
> > > >
> > > > Heh thanks will updated to:
> > > >
> > > > This allows booting ti81xx boards when a .dts file
> > > > is in place.
> > >
> > > This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> > > to avoid make randconfig build errors. Updated patch below.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > 8< -----------------
> > > From: Tony Lindgren <tony@atomide.com>
> > > Date: Mon, 19 Jan 2015 10:38:07 -0800
> > > Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
> > >
> > > This allows booting ti81xx boards when a .dts file
> > > is in place.
> > >
> > > Cc: Brian Hutchinson <b.hutchman@gmail.com>
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >
> > > --- a/arch/arm/mach-omap2/board-generic.c
> > > +++ b/arch/arm/mach-omap2/board-generic.c
> > > @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> > > .dt_compat = am3517_boards_compat,
> > > .restart = omap3xxx_restart,
> > > MACHINE_END
> > > +
> > > +static const char *const ti814x_boards_compat[] __initconst = {
> >
> > should this definition be within that ifdef too ?
>
> Oops yes totally thanks for catching that. Updated patch below.
>
> Regards,
>
> Tony
>
> 8< -----------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 19 Jan 2015 10:38:07 -0800
> Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
>
> This allows booting ti81xx boards when a .dts file
> is in place.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -144,6 +144,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> MACHINE_END
> #endif
>
> +#ifdef CONFIG_SOC_TI81XX
> +static const char *const ti814x_boards_compat[] __initconst = {
> + "ti,dm8148",
> + "ti,dm814",
> + NULL,
> +};
> +
> +DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = ti81xx_map_io,
> + .init_early = ti814x_init_early,
> + .init_machine = omap_generic_init,
> + .init_late = ti81xx_init_late,
> + .init_time = omap3_gptimer_timer_init,
> + .dt_compat = ti814x_boards_compat,
> + .restart = ti81xx_restart,
> +MACHINE_END
> +
> +static const char *const ti816x_boards_compat[] __initconst = {
> + "ti,dm8168",
> + "ti,dm816",
> + NULL,
> +};
> +
> +DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = ti81xx_map_io,
> + .init_early = ti816x_init_early,
> + .init_machine = omap_generic_init,
> + .init_late = ti81xx_init_late,
> + .init_time = omap3_gptimer_timer_init,
> + .dt_compat = ti816x_boards_compat,
> + .restart = ti81xx_restart,
> +MACHINE_END
> +#endif
> +
> #ifdef CONFIG_SOC_AM33XX
> static const char *const am33xx_boards_compat[] __initconst = {
> "ti,am33xx",
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx
@ 2015-01-19 21:10 ` Felipe Balbi
0 siblings, 0 replies; 66+ messages in thread
From: Felipe Balbi @ 2015-01-19 21:10 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 19, 2015 at 01:05:45PM -0800, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [150119 12:46]:
> > On Mon, Jan 19, 2015 at 11:18:34AM -0800, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [150114 16:14]:
> > > > * Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [150114 05:54]:
> > > > > Hello.
> > > > >
> > > > > On 1/14/2015 2:37 AM, Tony Lindgren wrote:
> > > > >
> > > > > >This allows booting ti81xx boards with with when a .dts
> > > > >
> > > > > So, with, with or when? :-)
> > > >
> > > > Heh thanks will updated to:
> > > >
> > > > This allows booting ti81xx boards when a .dts file
> > > > is in place.
> > >
> > > This too needs to be in a separate ifdef CONFIG_SOC_TI81XX block
> > > to avoid make randconfig build errors. Updated patch below.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> > > 8< -----------------
> > > From: Tony Lindgren <tony@atomide.com>
> > > Date: Mon, 19 Jan 2015 10:38:07 -0800
> > > Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
> > >
> > > This allows booting ti81xx boards when a .dts file
> > > is in place.
> > >
> > > Cc: Brian Hutchinson <b.hutchman@gmail.com>
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >
> > > --- a/arch/arm/mach-omap2/board-generic.c
> > > +++ b/arch/arm/mach-omap2/board-generic.c
> > > @@ -142,6 +142,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> > > .dt_compat = am3517_boards_compat,
> > > .restart = omap3xxx_restart,
> > > MACHINE_END
> > > +
> > > +static const char *const ti814x_boards_compat[] __initconst = {
> >
> > should this definition be within that ifdef too ?
>
> Oops yes totally thanks for catching that. Updated patch below.
>
> Regards,
>
> Tony
>
> 8< -----------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 19 Jan 2015 10:38:07 -0800
> Subject: [PATCH] ARM: OMAP2+: Add board-generic.c entry for ti81xx
>
> This allows booting ti81xx boards when a .dts file
> is in place.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -144,6 +144,42 @@ DT_MACHINE_START(AM3517_DT, "Generic AM3517 (Flattened Device Tree)")
> MACHINE_END
> #endif
>
> +#ifdef CONFIG_SOC_TI81XX
> +static const char *const ti814x_boards_compat[] __initconst = {
> + "ti,dm8148",
> + "ti,dm814",
> + NULL,
> +};
> +
> +DT_MACHINE_START(TI81XX_DT, "Generic ti814x (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = ti81xx_map_io,
> + .init_early = ti814x_init_early,
> + .init_machine = omap_generic_init,
> + .init_late = ti81xx_init_late,
> + .init_time = omap3_gptimer_timer_init,
> + .dt_compat = ti814x_boards_compat,
> + .restart = ti81xx_restart,
> +MACHINE_END
> +
> +static const char *const ti816x_boards_compat[] __initconst = {
> + "ti,dm8168",
> + "ti,dm816",
> + NULL,
> +};
> +
> +DT_MACHINE_START(TI816X_DT, "Generic ti816x (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = ti81xx_map_io,
> + .init_early = ti816x_init_early,
> + .init_machine = omap_generic_init,
> + .init_late = ti81xx_init_late,
> + .init_time = omap3_gptimer_timer_init,
> + .dt_compat = ti816x_boards_compat,
> + .restart = ti81xx_restart,
> +MACHINE_END
> +#endif
> +
> #ifdef CONFIG_SOC_AM33XX
> static const char *const am33xx_boards_compat[] __initconst = {
> "ti,am33xx",
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150119/3d1c8a18/attachment.sig>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-19 17:29 ` Tony Lindgren
@ 2015-01-22 3:17 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-22 3:17 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
On 19 January 2015 at 18:29, Tony Lindgren <tony@atomide.com> wrote:
> Hmm I sort of got the idea that dm814x and dm816x were done about
> the same time. Are you saying dm814x was actually done after dm816x?
Well, it's hard to come up with an alternate explanation of netra's
FAPLLs showing up in the terminology of centaurus' clock tree (though
the amount of references to them in the TRM decreased over time)
without the FAPLLs being there themselves.
Of course a radical new design will have much more distance between
initial development and public release than a derivative design. An
interesting timeline is given by looking at JTAG partcodes, since
those obviously have to be assigned somewhere during development,
before the first silicon is produced (omap3/4/5 and centauroids
listed):
b6d6 - omap34xx 1.0
b7ae - omap34xx/35xx 2.x/3.x
b81e - netra
b852 - omap4430 1.0
b868 - am35xx
b891 - omap36xx / dm/am37xx
b8f2 - centaurus
b942 - omap5430
b944 - subarctic
b94e - omap4460
b95c - omap4430 2.x
b96b - centaurus eve (dmva3/4 / dm38x)
b975 - omap4470
b98c - aegis
b990 - vayu
b998 - omap5432
(The distance between the two omap543x variants suggests to me the ID
is assigned early in the development, with the 5432-variant added late
in the design, but that's just a guess.)
> Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
> the registers are different.
BTW, if you spot any piece of the documentation making it sound like
port 2 is special somehow, it means port 0 instead. (The host port was
port 2 in CPSW in some earlier devices, and iirc a reference to this
was still somewhere in the current docs)
>> There's also an interesting Security Subsystem, which houses the
>> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
>> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
>> irq routing, and an elaborate L3 firewall instance covering both
>> external and internal access.
>
> Hmm that's a lot of accelerators..
And there are gaps in the memory map suggesting maybe there were more
submodules in earlier versions. I know it differs from Netra's
security subsystem since one module offset is different... hmm, now
I'm curious. I'll see if I can find a moment to brush the dust off the
evm816x here and make a quick inventory.
The DES module and second AES module in subarctic's memory map (and
PRCM) appear to be ghost modules, but I'd suspect this means they are
present on Aegis. Makes sense in combo with its magstripe card reader.
BTW, someone found genuine documentation of the AES/DES/Hash accelerators:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868
[random thought] There's another interesting application of the SecSS
cortex-M3: on GP devices it is (afaict) the only processor with
MReqDomain=1, while this is zero for all others. This 3-bit identifier
is used for security partitioning, and is something you can test on in
all firewalls. It is also the "connID" for EDMA's integrated memory
protection and proxied by EDMA transfers. The processor is also
located in the ALWON power domain.
This puts the secM3 in a unique position to act as "device hypervisor"
and prevent processors and DMA engines from meddling with hardware
resources they aren't supposed to meddle with. Even if security isn't
a concern, this would be a good idea for the same reason memory
protection is useful to separate processes. With so many initiators
around, if one accidently does a bogus write and clobbers someone
else's state, the resulting failure is obviously rather hard to debug.
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-22 3:17 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-22 3:17 UTC (permalink / raw)
To: linux-arm-kernel
On 19 January 2015 at 18:29, Tony Lindgren <tony@atomide.com> wrote:
> Hmm I sort of got the idea that dm814x and dm816x were done about
> the same time. Are you saying dm814x was actually done after dm816x?
Well, it's hard to come up with an alternate explanation of netra's
FAPLLs showing up in the terminology of centaurus' clock tree (though
the amount of references to them in the TRM decreased over time)
without the FAPLLs being there themselves.
Of course a radical new design will have much more distance between
initial development and public release than a derivative design. An
interesting timeline is given by looking at JTAG partcodes, since
those obviously have to be assigned somewhere during development,
before the first silicon is produced (omap3/4/5 and centauroids
listed):
b6d6 - omap34xx 1.0
b7ae - omap34xx/35xx 2.x/3.x
b81e - netra
b852 - omap4430 1.0
b868 - am35xx
b891 - omap36xx / dm/am37xx
b8f2 - centaurus
b942 - omap5430
b944 - subarctic
b94e - omap4460
b95c - omap4430 2.x
b96b - centaurus eve (dmva3/4 / dm38x)
b975 - omap4470
b98c - aegis
b990 - vayu
b998 - omap5432
(The distance between the two omap543x variants suggests to me the ID
is assigned early in the development, with the 5432-variant added late
in the design, but that's just a guess.)
> Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
> the registers are different.
BTW, if you spot any piece of the documentation making it sound like
port 2 is special somehow, it means port 0 instead. (The host port was
port 2 in CPSW in some earlier devices, and iirc a reference to this
was still somewhere in the current docs)
>> There's also an interesting Security Subsystem, which houses the
>> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
>> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
>> irq routing, and an elaborate L3 firewall instance covering both
>> external and internal access.
>
> Hmm that's a lot of accelerators..
And there are gaps in the memory map suggesting maybe there were more
submodules in earlier versions. I know it differs from Netra's
security subsystem since one module offset is different... hmm, now
I'm curious. I'll see if I can find a moment to brush the dust off the
evm816x here and make a quick inventory.
The DES module and second AES module in subarctic's memory map (and
PRCM) appear to be ghost modules, but I'd suspect this means they are
present on Aegis. Makes sense in combo with its magstripe card reader.
BTW, someone found genuine documentation of the AES/DES/Hash accelerators:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868
[random thought] There's another interesting application of the SecSS
cortex-M3: on GP devices it is (afaict) the only processor with
MReqDomain=1, while this is zero for all others. This 3-bit identifier
is used for security partitioning, and is something you can test on in
all firewalls. It is also the "connID" for EDMA's integrated memory
protection and proxied by EDMA transfers. The processor is also
located in the ALWON power domain.
This puts the secM3 in a unique position to act as "device hypervisor"
and prevent processors and DMA engines from meddling with hardware
resources they aren't supposed to meddle with. Even if security isn't
a concern, this would be a good idea for the same reason memory
protection is useful to separate processes. With so many initiators
around, if one accidently does a bogus write and clobbers someone
else's state, the resulting failure is obviously rather hard to debug.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-22 3:17 ` Matthijs van Duin
@ 2015-01-23 16:47 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-23 16:47 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150121 19:20]:
> On 19 January 2015 at 18:29, Tony Lindgren <tony@atomide.com> wrote:
> > Hmm I sort of got the idea that dm814x and dm816x were done about
> > the same time. Are you saying dm814x was actually done after dm816x?
>
> Well, it's hard to come up with an alternate explanation of netra's
> FAPLLs showing up in the terminology of centaurus' clock tree (though
> the amount of references to them in the TRM decreased over time)
> without the FAPLLs being there themselves.
>
> Of course a radical new design will have much more distance between
> initial development and public release than a derivative design. An
> interesting timeline is given by looking at JTAG partcodes, since
> those obviously have to be assigned somewhere during development,
> before the first silicon is produced (omap3/4/5 and centauroids
> listed):
>
> b6d6 - omap34xx 1.0
> b7ae - omap34xx/35xx 2.x/3.x
> b81e - netra
> b852 - omap4430 1.0
> b868 - am35xx
> b891 - omap36xx / dm/am37xx
> b8f2 - centaurus
> b942 - omap5430
> b944 - subarctic
> b94e - omap4460
> b95c - omap4430 2.x
> b96b - centaurus eve (dmva3/4 / dm38x)
> b975 - omap4470
> b98c - aegis
> b990 - vayu
> b998 - omap5432
>
> (The distance between the two omap543x variants suggests to me the ID
> is assigned early in the development, with the 5432-variant added late
> in the design, but that's just a guess.)
That's interesting info thanks :) Yeah it seems dm814x was done after
dm816x and that clears at least some of the clockdomain confusion
that I though was TRM copy-paste issue.
> > Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
> > the registers are different.
>
> BTW, if you spot any piece of the documentation making it sound like
> port 2 is special somehow, it means port 0 instead. (The host port was
> port 2 in CPSW in some earlier devices, and iirc a reference to this
> was still somewhere in the current docs)
>
>
> >> There's also an interesting Security Subsystem, which houses the
> >> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
> >> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
> >> irq routing, and an elaborate L3 firewall instance covering both
> >> external and internal access.
> >
> > Hmm that's a lot of accelerators..
>
> And there are gaps in the memory map suggesting maybe there were more
> submodules in earlier versions. I know it differs from Netra's
> security subsystem since one module offset is different... hmm, now
> I'm curious. I'll see if I can find a moment to brush the dust off the
> evm816x here and make a quick inventory.
Should be usable for NFSroot with all the patches I've sent using the
ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
Linux next though, I'll push a current testing branch at some point
today. The mainline u-boot was at least missing the davinci_emac
support the last time I tried.
> The DES module and second AES module in subarctic's memory map (and
> PRCM) appear to be ghost modules, but I'd suspect this means they are
> present on Aegis. Makes sense in combo with its magstripe card reader.
>
> BTW, someone found genuine documentation of the AES/DES/Hash accelerators:
> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868
Oh OK.
> [random thought] There's another interesting application of the SecSS
> cortex-M3: on GP devices it is (afaict) the only processor with
> MReqDomain=1, while this is zero for all others. This 3-bit identifier
> is used for security partitioning, and is something you can test on in
> all firewalls. It is also the "connID" for EDMA's integrated memory
> protection and proxied by EDMA transfers. The processor is also
> located in the ALWON power domain.
>
> This puts the secM3 in a unique position to act as "device hypervisor"
> and prevent processors and DMA engines from meddling with hardware
> resources they aren't supposed to meddle with. Even if security isn't
> a concern, this would be a good idea for the same reason memory
> protection is useful to separate processes. With so many initiators
> around, if one accidently does a bogus write and clobbers someone
> else's state, the resulting failure is obviously rather hard to debug.
Yeah could be handy :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-23 16:47 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-23 16:47 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150121 19:20]:
> On 19 January 2015 at 18:29, Tony Lindgren <tony@atomide.com> wrote:
> > Hmm I sort of got the idea that dm814x and dm816x were done about
> > the same time. Are you saying dm814x was actually done after dm816x?
>
> Well, it's hard to come up with an alternate explanation of netra's
> FAPLLs showing up in the terminology of centaurus' clock tree (though
> the amount of references to them in the TRM decreased over time)
> without the FAPLLs being there themselves.
>
> Of course a radical new design will have much more distance between
> initial development and public release than a derivative design. An
> interesting timeline is given by looking at JTAG partcodes, since
> those obviously have to be assigned somewhere during development,
> before the first silicon is produced (omap3/4/5 and centauroids
> listed):
>
> b6d6 - omap34xx 1.0
> b7ae - omap34xx/35xx 2.x/3.x
> b81e - netra
> b852 - omap4430 1.0
> b868 - am35xx
> b891 - omap36xx / dm/am37xx
> b8f2 - centaurus
> b942 - omap5430
> b944 - subarctic
> b94e - omap4460
> b95c - omap4430 2.x
> b96b - centaurus eve (dmva3/4 / dm38x)
> b975 - omap4470
> b98c - aegis
> b990 - vayu
> b998 - omap5432
>
> (The distance between the two omap543x variants suggests to me the ID
> is assigned early in the development, with the 5432-variant added late
> in the design, but that's just a guess.)
That's interesting info thanks :) Yeah it seems dm814x was done after
dm816x and that clears at least some of the clockdomain confusion
that I though was TRM copy-paste issue.
> > Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
> > the registers are different.
>
> BTW, if you spot any piece of the documentation making it sound like
> port 2 is special somehow, it means port 0 instead. (The host port was
> port 2 in CPSW in some earlier devices, and iirc a reference to this
> was still somewhere in the current docs)
>
>
> >> There's also an interesting Security Subsystem, which houses the
> >> crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine,
> >> 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit,
> >> irq routing, and an elaborate L3 firewall instance covering both
> >> external and internal access.
> >
> > Hmm that's a lot of accelerators..
>
> And there are gaps in the memory map suggesting maybe there were more
> submodules in earlier versions. I know it differs from Netra's
> security subsystem since one module offset is different... hmm, now
> I'm curious. I'll see if I can find a moment to brush the dust off the
> evm816x here and make a quick inventory.
Should be usable for NFSroot with all the patches I've sent using the
ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
Linux next though, I'll push a current testing branch at some point
today. The mainline u-boot was at least missing the davinci_emac
support the last time I tried.
> The DES module and second AES module in subarctic's memory map (and
> PRCM) appear to be ghost modules, but I'd suspect this means they are
> present on Aegis. Makes sense in combo with its magstripe card reader.
>
> BTW, someone found genuine documentation of the AES/DES/Hash accelerators:
> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868
Oh OK.
> [random thought] There's another interesting application of the SecSS
> cortex-M3: on GP devices it is (afaict) the only processor with
> MReqDomain=1, while this is zero for all others. This 3-bit identifier
> is used for security partitioning, and is something you can test on in
> all firewalls. It is also the "connID" for EDMA's integrated memory
> protection and proxied by EDMA transfers. The processor is also
> located in the ALWON power domain.
>
> This puts the secM3 in a unique position to act as "device hypervisor"
> and prevent processors and DMA engines from meddling with hardware
> resources they aren't supposed to meddle with. Even if security isn't
> a concern, this would be a good idea for the same reason memory
> protection is useful to separate processes. With so many initiators
> around, if one accidently does a bogus write and clobbers someone
> else's state, the resulting failure is obviously rather hard to debug.
Yeah could be handy :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-23 16:47 ` Tony Lindgren
@ 2015-01-25 8:34 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-25 8:34 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
On 23 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> That's interesting info thanks :) Yeah it seems dm814x was done after
> dm816x and that clears at least some of the clockdomain confusion
> that I though was TRM copy-paste issue.
Well it is in some sense still a copy-paste issue when e.g.
CM_SYSCLK18_CLKSEL refers to the "Audio PLL generated 32 Khz Clock"
when there is none (it means the "Audio PLL A divider" output, which
itself is in fact fed by the rtcdivider).
Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP
interrupt controller, whose list of interrupts is from Freon/Primus
(omap-L13x) which is not even remotely similar to the actual list in
section 1.7.3. Which reminds me, I also have a centaurus irqs
spreadsheet which may be more convenient than the lists in the PDF and
includes some that were censored from public docs:
https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view
(note however that I consistently use 0-based indexing, regardless of
the TRM which tends to vary on that)
> > And there are gaps in the memory map suggesting maybe there were more
> > submodules in earlier versions. I know it differs from Netra's
> > security subsystem since one module offset is different... hmm, now
> > I'm curious. I'll see if I can find a moment to brush the dust off the
> > evm816x here and make a quick inventory.
>
> Should be usable for NFSroot with all the patches I've sent using the
> ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> Linux next though
With "make a quick inventory" I meant peeking and poking around in the
subsystem using JTAG, which is generally better done without any OS
running on the target :-) I don't actually have any real motivation
to run linux on the evm816x; we selected the DM814x for our target
(before it became clear support for it had basically dropped like a
brick), though it may still take a bit before I have time to see how
far I can get with booting Linux on it.
The inventory of SecSS on Netra yielded exactly the same list of
accelerators and other peripherals as on Centaurus btw. The only
changes seem to be in subsystem control stuff. I was not succesful in
attaching to the secM3 via JTAG though, but this may have been an
issue with the target config since Code Composer was being more
annoying than usual about it.
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-25 8:34 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-25 8:34 UTC (permalink / raw)
To: linux-arm-kernel
On 23 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> That's interesting info thanks :) Yeah it seems dm814x was done after
> dm816x and that clears at least some of the clockdomain confusion
> that I though was TRM copy-paste issue.
Well it is in some sense still a copy-paste issue when e.g.
CM_SYSCLK18_CLKSEL refers to the "Audio PLL generated 32 Khz Clock"
when there is none (it means the "Audio PLL A divider" output, which
itself is in fact fed by the rtcdivider).
Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP
interrupt controller, whose list of interrupts is from Freon/Primus
(omap-L13x) which is not even remotely similar to the actual list in
section 1.7.3. Which reminds me, I also have a centaurus irqs
spreadsheet which may be more convenient than the lists in the PDF and
includes some that were censored from public docs:
https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view
(note however that I consistently use 0-based indexing, regardless of
the TRM which tends to vary on that)
> > And there are gaps in the memory map suggesting maybe there were more
> > submodules in earlier versions. I know it differs from Netra's
> > security subsystem since one module offset is different... hmm, now
> > I'm curious. I'll see if I can find a moment to brush the dust off the
> > evm816x here and make a quick inventory.
>
> Should be usable for NFSroot with all the patches I've sent using the
> ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> Linux next though
With "make a quick inventory" I meant peeking and poking around in the
subsystem using JTAG, which is generally better done without any OS
running on the target :-) I don't actually have any real motivation
to run linux on the evm816x; we selected the DM814x for our target
(before it became clear support for it had basically dropped like a
brick), though it may still take a bit before I have time to see how
far I can get with booting Linux on it.
The inventory of SecSS on Netra yielded exactly the same list of
accelerators and other peripherals as on Centaurus btw. The only
changes seem to be in subsystem control stuff. I was not succesful in
attaching to the secM3 via JTAG though, but this may have been an
issue with the target config since Code Composer was being more
annoying than usual about it.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-25 8:34 ` Matthijs van Duin
@ 2015-01-26 15:58 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-26 15:58 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150125 00:37]:
> On 23 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> > That's interesting info thanks :) Yeah it seems dm814x was done after
> > dm816x and that clears at least some of the clockdomain confusion
> > that I though was TRM copy-paste issue.
>
> Well it is in some sense still a copy-paste issue when e.g.
> CM_SYSCLK18_CLKSEL refers to the "Audio PLL generated 32 Khz Clock"
> when there is none (it means the "Audio PLL A divider" output, which
> itself is in fact fed by the rtcdivider).
Sounds like that's a copy paste issue from dm816x to dm814x then :)
See earlier I was assuming copy paste issues from dm814x to dm816x
before you confirmed dm816x was done before dm814x. On the dm816x
I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it with a scope on the clkout pin.
> Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP
> interrupt controller, whose list of interrupts is from Freon/Primus
> (omap-L13x) which is not even remotely similar to the actual list in
> section 1.7.3. Which reminds me, I also have a centaurus irqs
> spreadsheet which may be more convenient than the lists in the PDF and
> includes some that were censored from public docs:
> https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view
> (note however that I consistently use 0-based indexing, regardless of
> the TRM which tends to vary on that)
Heheh that should be also helpful.
> > > And there are gaps in the memory map suggesting maybe there were more
> > > submodules in earlier versions. I know it differs from Netra's
> > > security subsystem since one module offset is different... hmm, now
> > > I'm curious. I'll see if I can find a moment to brush the dust off the
> > > evm816x here and make a quick inventory.
> >
> > Should be usable for NFSroot with all the patches I've sent using the
> > ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> > Linux next though
>
> With "make a quick inventory" I meant peeking and poking around in the
> subsystem using JTAG, which is generally better done without any OS
> running on the target :-) I don't actually have any real motivation
> to run linux on the evm816x; we selected the DM814x for our target
> (before it became clear support for it had basically dropped like a
> brick), though it may still take a bit before I have time to see how
> far I can get with booting Linux on it.
Oh OK. Yeah it sounds like you could generate the required dm814x .dts
entries with a few macros from your spreadsheets :)
> The inventory of SecSS on Netra yielded exactly the same list of
> accelerators and other peripherals as on Centaurus btw. The only
> changes seem to be in subsystem control stuff. I was not succesful in
> attaching to the secM3 via JTAG though, but this may have been an
> issue with the target config since Code Composer was being more
> annoying than usual about it.
What are you using to identify the devices? The device revision
register? Or are there actually some populated interconnect data
available with device info that could be used for a real scannable
bus?
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-26 15:58 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-26 15:58 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150125 00:37]:
> On 23 January 2015 at 17:47, Tony Lindgren <tony@atomide.com> wrote:
> > That's interesting info thanks :) Yeah it seems dm814x was done after
> > dm816x and that clears at least some of the clockdomain confusion
> > that I though was TRM copy-paste issue.
>
> Well it is in some sense still a copy-paste issue when e.g.
> CM_SYSCLK18_CLKSEL refers to the "Audio PLL generated 32 Khz Clock"
> when there is none (it means the "Audio PLL A divider" output, which
> itself is in fact fed by the rtcdivider).
Sounds like that's a copy paste issue from dm816x to dm814x then :)
See earlier I was assuming copy paste issues from dm814x to dm816x
before you confirmed dm816x was done before dm814x. On the dm816x
I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it with a scope on the clkout pin.
> Probably the sillyest copy-paste error is section 1.3.2.2.1 on the DSP
> interrupt controller, whose list of interrupts is from Freon/Primus
> (omap-L13x) which is not even remotely similar to the actual list in
> section 1.7.3. Which reminds me, I also have a centaurus irqs
> spreadsheet which may be more convenient than the lists in the PDF and
> includes some that were censored from public docs:
> https://docs.google.com/spreadsheets/d/1O3IFMdAfLMWVBQ8rzLPexMbi4LDD5ECfpVYGF6HMv_0/view
> (note however that I consistently use 0-based indexing, regardless of
> the TRM which tends to vary on that)
Heheh that should be also helpful.
> > > And there are gaps in the memory map suggesting maybe there were more
> > > submodules in earlier versions. I know it differs from Netra's
> > > security subsystem since one module offset is different... hmm, now
> > > I'm curious. I'll see if I can find a moment to brush the dust off the
> > > evm816x here and make a quick inventory.
> >
> > Should be usable for NFSroot with all the patches I've sent using the
> > ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> > Linux next though
>
> With "make a quick inventory" I meant peeking and poking around in the
> subsystem using JTAG, which is generally better done without any OS
> running on the target :-) I don't actually have any real motivation
> to run linux on the evm816x; we selected the DM814x for our target
> (before it became clear support for it had basically dropped like a
> brick), though it may still take a bit before I have time to see how
> far I can get with booting Linux on it.
Oh OK. Yeah it sounds like you could generate the required dm814x .dts
entries with a few macros from your spreadsheets :)
> The inventory of SecSS on Netra yielded exactly the same list of
> accelerators and other peripherals as on Centaurus btw. The only
> changes seem to be in subsystem control stuff. I was not succesful in
> attaching to the secM3 via JTAG though, but this may have been an
> issue with the target config since Code Composer was being more
> annoying than usual about it.
What are you using to identify the devices? The device revision
register? Or are there actually some populated interconnect data
available with device info that could be used for a real scannable
bus?
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-23 16:47 ` Tony Lindgren
@ 2015-01-28 17:04 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-28 17:04 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, Brian Hutchinson, linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150123 08:54]:
>
> Should be usable for NFSroot with all the patches I've sent using the
> ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> Linux next though, I'll push a current testing branch at some point
> today. The mainline u-boot was at least missing the davinci_emac
> support the last time I tried.
Seems to be all in today's Linux next and I just verified that
3.19.0-rc6-next-20150128-06478-g30720bbe is booting on 8168-evm.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-28 17:04 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-01-28 17:04 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150123 08:54]:
>
> Should be usable for NFSroot with all the patches I've sent using the
> ti u-boot and and appended DTB uImage. Sorry not all of it is yet in
> Linux next though, I'll push a current testing branch at some point
> today. The mainline u-boot was at least missing the davinci_emac
> support the last time I tried.
Seems to be all in today's Linux next and I just verified that
3.19.0-rc6-next-20150128-06478-g30720bbe is booting on 8168-evm.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-26 15:58 ` Tony Lindgren
@ 2015-01-28 21:43 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-28 21:43 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, Brian Hutchinson, linux-arm-kernel
On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
> See earlier I was assuming copy paste issues from dm814x to dm816x
Ahh, you thought the 816x was 814x-derived... yes I can imagine that
will have led to some confusion.
> I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
> to 32KiHz by looking at it with a scope on the clkout pin.
Yeah it comes straight from the "rtcdivider" so it'll produce
0.0016384 * devosc.
The global clock structure overview in the TRM (figure 2-6) actually
correctly marks the former-audio-fapll clocks (except audio5 := osc0,
yielding sysclk22 after divider) but you already need to know what the
hell is going on to recognize that.
Oh, on the topic of PRCM, a word of caution: while the cold reset
default of PM_DEFAULT_PWRSTCTRL is 0, performing _any_ write to it
(regardless of value) sets it to 3 (force power-on) until next cold
reset. An unfortunately side-effect I stumbled over is that a
particular bus lockup that can occur in ducati (dual cortex-m3
subsystem) then becomes warm-reset-insensitive.
The statement I got from TI support about the strange behaviour of
this power control register was.. vague:
In DM814x, complete functionality of PRCM was not used and that
resulted into such requirements.
This recommendations was made based on DV test cases with POWERONSTATE
== ON/0x3.
We didn’t do any negative testing to see the behaviour in case
POWERONSTATE != ON/0x3.
So I can recommend you to test your system without this requirement
and see if you will have any issues. I think this requirement is not
needed (POWERONSTATE == ON/0x3), as the DM814x EZSDK (u-boot, linux
kernel) is working fine without it.
> > The inventory of SecSS on Netra yielded exactly the same list of
> > accelerators and other peripherals as on Centaurus btw. The only
> > changes seem to be in subsystem control stuff.
>
> What are you using to identify the devices? The device revision
> register? Or are there actually some populated interconnect data
> available with device info that could be used for a real scannable
> bus?
You mean the modules? SecSS unfortunately doesn't have an integrated
memory map like the one present in the Sonics S3220 interconnects, so
I just probed it manually while making use of the knowledge I already
had of SecSS on Centaurus. It helps that I already did quite a bit of
exploration of SecSS on Centaurus, and it turns out to barely differ
from the original one* on Netra. The differences seem to be
permissions-related: the subsystem control module was split into two
separate parts and there was a tiny bit of rearrangement for the
benefit of being able to cover multiple modules with a single firewall
region.
I've updated the SecSS sheet of my memory-map spreadsheet to highlight
the differences.
It's not totally clear what the intentions are of the various default
firewall regions. Region 0 will undoubtedly be highly restricted on
all but GP devices. On centaurus region 5 looks like it'll be
exclusively for the cortex-m3 on devices where it automatically boots
stand-alone from ROM (EMU/HS) instead of waiting to boot into
user-supplied code on request (Test/GP/EMUL/HSL).
*TI's linux driver calls it "NSS" (Netra Security Subsystem) on both
chips, so presumably Netra was the first to have this kind of
subsystem.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-01-28 21:43 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-01-28 21:43 UTC (permalink / raw)
To: linux-arm-kernel
On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
> See earlier I was assuming copy paste issues from dm814x to dm816x
Ahh, you thought the 816x was 814x-derived... yes I can imagine that
will have led to some confusion.
> I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
> to 32KiHz by looking at it with a scope on the clkout pin.
Yeah it comes straight from the "rtcdivider" so it'll produce
0.0016384 * devosc.
The global clock structure overview in the TRM (figure 2-6) actually
correctly marks the former-audio-fapll clocks (except audio5 := osc0,
yielding sysclk22 after divider) but you already need to know what the
hell is going on to recognize that.
Oh, on the topic of PRCM, a word of caution: while the cold reset
default of PM_DEFAULT_PWRSTCTRL is 0, performing _any_ write to it
(regardless of value) sets it to 3 (force power-on) until next cold
reset. An unfortunately side-effect I stumbled over is that a
particular bus lockup that can occur in ducati (dual cortex-m3
subsystem) then becomes warm-reset-insensitive.
The statement I got from TI support about the strange behaviour of
this power control register was.. vague:
In DM814x, complete functionality of PRCM was not used and that
resulted into such requirements.
This recommendations was made based on DV test cases with POWERONSTATE
== ON/0x3.
We didn?t do any negative testing to see the behaviour in case
POWERONSTATE != ON/0x3.
So I can recommend you to test your system without this requirement
and see if you will have any issues. I think this requirement is not
needed (POWERONSTATE == ON/0x3), as the DM814x EZSDK (u-boot, linux
kernel) is working fine without it.
> > The inventory of SecSS on Netra yielded exactly the same list of
> > accelerators and other peripherals as on Centaurus btw. The only
> > changes seem to be in subsystem control stuff.
>
> What are you using to identify the devices? The device revision
> register? Or are there actually some populated interconnect data
> available with device info that could be used for a real scannable
> bus?
You mean the modules? SecSS unfortunately doesn't have an integrated
memory map like the one present in the Sonics S3220 interconnects, so
I just probed it manually while making use of the knowledge I already
had of SecSS on Centaurus. It helps that I already did quite a bit of
exploration of SecSS on Centaurus, and it turns out to barely differ
from the original one* on Netra. The differences seem to be
permissions-related: the subsystem control module was split into two
separate parts and there was a tiny bit of rearrangement for the
benefit of being able to cover multiple modules with a single firewall
region.
I've updated the SecSS sheet of my memory-map spreadsheet to highlight
the differences.
It's not totally clear what the intentions are of the various default
firewall regions. Region 0 will undoubtedly be highly restricted on
all but GP devices. On centaurus region 5 looks like it'll be
exclusively for the cortex-m3 on devices where it automatically boots
stand-alone from ROM (EMU/HS) instead of waiting to boot into
user-supplied code on request (Test/GP/EMUL/HSL).
*TI's linux driver calls it "NSS" (Netra Security Subsystem) on both
chips, so presumably Netra was the first to have this kind of
subsystem.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-17 16:47 ` Tony Lindgren
@ 2015-02-01 1:51 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-02-01 1:51 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
I just noticed the dm816x.dtsi says:
ocp {
compatible = "ti,omap3-l3-smx", "simple-bus";
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
omap4-generation)
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-02-01 1:51 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-02-01 1:51 UTC (permalink / raw)
To: linux-arm-kernel
I just noticed the dm816x.dtsi says:
ocp {
compatible = "ti,omap3-l3-smx", "simple-bus";
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
omap4-generation)
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-02-01 1:51 ` Matthijs van Duin
@ 2015-02-02 16:09 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-02-02 16:09 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150131 17:54]:
> I just noticed the dm816x.dtsi says:
>
> ocp {
> compatible = "ti,omap3-l3-smx", "simple-bus";
>
> This is incorrect: the DM81xx (and siblings like the AM335x) use
> Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
> SonicsMX. (In general everything on the DM81xx seems to be
> omap4-generation)
Good catch, yes it seems it's mostly omap4. Looks like we
should also add it for am33xx.dtsi while at it.
I'll also check the devices one more time if I have some as
compatible with omap3 instead of omap4.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-02-02 16:09 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-02-02 16:09 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150131 17:54]:
> I just noticed the dm816x.dtsi says:
>
> ocp {
> compatible = "ti,omap3-l3-smx", "simple-bus";
>
> This is incorrect: the DM81xx (and siblings like the AM335x) use
> Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
> SonicsMX. (In general everything on the DM81xx seems to be
> omap4-generation)
Good catch, yes it seems it's mostly omap4. Looks like we
should also add it for am33xx.dtsi while at it.
I'll also check the devices one more time if I have some as
compatible with omap3 instead of omap4.
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-01-28 21:43 ` Matthijs van Duin
@ 2015-02-02 17:44 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-02-02 17:44 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
* Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]:
> On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
> > See earlier I was assuming copy paste issues from dm814x to dm816x
>
> Ahh, you thought the 816x was 814x-derived... yes I can imagine that
> will have led to some confusion.
>
> > I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
> > to 32KiHz by looking at it with a scope on the clkout pin.
>
> Yeah it comes straight from the "rtcdivider" so it'll produce
> 0.0016384 * devosc.
Not much about "rtcdivider" in the dm816x TRM..
> The global clock structure overview in the TRM (figure 2-6) actually
> correctly marks the former-audio-fapll clocks (except audio5 := osc0,
> yielding sysclk22 after divider) but you already need to know what the
> hell is going on to recognize that.
That seems to be in the dm814x TRM. OK so it looks like in
mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded
value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref
multiplied 0.0016384 instead of 32768.
And we probably should add what you're explaining to the comments
also to make some sense out of it :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-02-02 17:44 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-02-02 17:44 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]:
> On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
> > See earlier I was assuming copy paste issues from dm814x to dm816x
>
> Ahh, you thought the 816x was 814x-derived... yes I can imagine that
> will have led to some confusion.
>
> > I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
> > to 32KiHz by looking at it with a scope on the clkout pin.
>
> Yeah it comes straight from the "rtcdivider" so it'll produce
> 0.0016384 * devosc.
Not much about "rtcdivider" in the dm816x TRM..
> The global clock structure overview in the TRM (figure 2-6) actually
> correctly marks the former-audio-fapll clocks (except audio5 := osc0,
> yielding sysclk22 after divider) but you already need to know what the
> hell is going on to recognize that.
That seems to be in the dm814x TRM. OK so it looks like in
mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded
value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref
multiplied 0.0016384 instead of 32768.
And we probably should add what you're explaining to the comments
also to make some sense out of it :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-02-02 17:44 ` Tony Lindgren
@ 2015-02-03 5:51 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-02-03 5:51 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Brian Hutchinson
On 2 February 2015 at 18:44, Tony Lindgren <tony@atomide.com> wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]:
>> On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
>> > I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
>> > to 32KiHz by looking at it with a scope on the clkout pin.
>>
>> Yeah it comes straight from the "rtcdivider" so it'll produce
>> 0.0016384 * devosc.
>
> Not much about "rtcdivider" in the dm816x TRM..
> [..]
> That seems to be in the dm814x TRM. OK so it looks like in
> mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded
> value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref
> multiplied 0.0016384 instead of 32768.
Ah sorry, yes, for some reason I thought you meant the dm814x one...
(which makes no sense in retrospect)
It seems however the situation is actually similar on the dm816x since
the diagram of the audio FAPLL also shows clock 1 deriving directly
from devosc, and the associated audio frequency/divider 1 registers
read as zero. Presumably it was produced by the audio PLL in some
early design but replaced by a fixed synthesizer later on, later named
"rtcdivider" in the dm814x. Note that the multiplier 0.0016384 = 32768
/ 20e6 is for the dm814x, it'll be 32768 / 27e6 on the dm816x.
I think "audio 1" should be kept out of the fapll code entirely given
that it doesn't seem to be related to the audio FAPLL anymore in any
way other than in name.
I've also been looking at the rest of Netra's 32KiHz clock tree, but
the TRM is a real mess there, often contradicting both itself and the
TI kernel. As far as I can tell they agree on:
audio_1 = devosc * (32768 / 27e6);
audio_a = audio_1 / (CM_DPLL_APA_CLKSEL + 1);
rtc_fck = { clkin32, audio_a }[CM_DPLL_SYSCLK18_CLKSEL];
but the TRM seems to suggest the mux output is the "sec_clk32k"
specifically for the RTC while the signal I called "audio_a" here is
sysclk18 provided for debouncing and as timer option. In contrast the
TI kernel considers the mux the only user of audio_a and its output
sysclk18. It does also define a secure 32k but without parent or any
apparent users.
(The audio FAPLL description (1.10.3.1.4) also claims mux option 0
selects the synthesized 32k clock, but that contradicts all other
evidence so I will ignore that.)
I'm leaning more towards believing the TI kernel since on Centaurus
(all flavors) sysclk18 definitely comes from the mux. It adds a twist
however: PRCM's clkin32 doesn't come straight from the pin but PLLSS
inserts another mux which by default *also* feeds it the synthesized
32k:
rtcdivider = devosc * (32768 / 20e6); // former audio 1
prcm_clkin32 = { rtcdivider, clkin32 }[PLLSS_SYSCLK18_CLKSRC];
sysclk18_a = rtcdivider / (CM_DPLL_RTCDIVA_CLKSEL + 1);
sysclk18 = { prcm_clkin32, sysclk18_a }[CM_DPLL_SYSCLK18_CLKSEL];
I confirmed the above on our board where clkin32 is not connected, so
I could "manually" toggle it using the internal pull up/down. This
also revealed that mux in PLLSS, unlike the PRCM one, is not
glitch-free but takes immediate effect. It also revealed the TRM's
statement that "If newly selected clock is idle, a switchover never
occurs (previously selected clock continues to pass through the mux)"
is false. Switching sysclk18 to the idle clkin32 stopped timers fed by
it (including the "synctimer32k") and switching back also proved
impossible without toggling clkin32 or having PLLSS feed it the
rtcdivider clock. This may be the reason this (otherwise redundant)
mux exists in the first place.
Finally, Centaurus also has an internal ~32kHz RC osc as option for
the watchdog and on the 811x (also known as Jacinto 5 Eco) the clkin32
is upgraded from clock input to oscillator.
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-02-03 5:51 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-02-03 5:51 UTC (permalink / raw)
To: linux-arm-kernel
On 2 February 2015 at 18:44, Tony Lindgren <tony@atomide.com> wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150128 13:46]:
>> On 26 January 2015 at 16:58, Tony Lindgren <tony@atomide.com> wrote:
>> > I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
>> > to 32KiHz by looking at it with a scope on the clkout pin.
>>
>> Yeah it comes straight from the "rtcdivider" so it'll produce
>> 0.0016384 * devosc.
>
> Not much about "rtcdivider" in the dm816x TRM..
> [..]
> That seems to be in the dm814x TRM. OK so it looks like in
> mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded
> value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref
> multiplied 0.0016384 instead of 32768.
Ah sorry, yes, for some reason I thought you meant the dm814x one...
(which makes no sense in retrospect)
It seems however the situation is actually similar on the dm816x since
the diagram of the audio FAPLL also shows clock 1 deriving directly
from devosc, and the associated audio frequency/divider 1 registers
read as zero. Presumably it was produced by the audio PLL in some
early design but replaced by a fixed synthesizer later on, later named
"rtcdivider" in the dm814x. Note that the multiplier 0.0016384 = 32768
/ 20e6 is for the dm814x, it'll be 32768 / 27e6 on the dm816x.
I think "audio 1" should be kept out of the fapll code entirely given
that it doesn't seem to be related to the audio FAPLL anymore in any
way other than in name.
I've also been looking at the rest of Netra's 32KiHz clock tree, but
the TRM is a real mess there, often contradicting both itself and the
TI kernel. As far as I can tell they agree on:
audio_1 = devosc * (32768 / 27e6);
audio_a = audio_1 / (CM_DPLL_APA_CLKSEL + 1);
rtc_fck = { clkin32, audio_a }[CM_DPLL_SYSCLK18_CLKSEL];
but the TRM seems to suggest the mux output is the "sec_clk32k"
specifically for the RTC while the signal I called "audio_a" here is
sysclk18 provided for debouncing and as timer option. In contrast the
TI kernel considers the mux the only user of audio_a and its output
sysclk18. It does also define a secure 32k but without parent or any
apparent users.
(The audio FAPLL description (1.10.3.1.4) also claims mux option 0
selects the synthesized 32k clock, but that contradicts all other
evidence so I will ignore that.)
I'm leaning more towards believing the TI kernel since on Centaurus
(all flavors) sysclk18 definitely comes from the mux. It adds a twist
however: PRCM's clkin32 doesn't come straight from the pin but PLLSS
inserts another mux which by default *also* feeds it the synthesized
32k:
rtcdivider = devosc * (32768 / 20e6); // former audio 1
prcm_clkin32 = { rtcdivider, clkin32 }[PLLSS_SYSCLK18_CLKSRC];
sysclk18_a = rtcdivider / (CM_DPLL_RTCDIVA_CLKSEL + 1);
sysclk18 = { prcm_clkin32, sysclk18_a }[CM_DPLL_SYSCLK18_CLKSEL];
I confirmed the above on our board where clkin32 is not connected, so
I could "manually" toggle it using the internal pull up/down. This
also revealed that mux in PLLSS, unlike the PRCM one, is not
glitch-free but takes immediate effect. It also revealed the TRM's
statement that "If newly selected clock is idle, a switchover never
occurs (previously selected clock continues to pass through the mux)"
is false. Switching sysclk18 to the idle clkin32 stopped timers fed by
it (including the "synctimer32k") and switching back also proved
impossible without toggling clkin32 or having PLLSS feed it the
rtcdivider clock. This may be the reason this (otherwise redundant)
mux exists in the first place.
Finally, Centaurus also has an internal ~32kHz RC osc as option for
the watchdog and on the 811x (also known as Jacinto 5 Eco) the clkin32
is upgraded from clock input to oscillator.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-02-02 16:09 ` Tony Lindgren
@ 2015-03-18 0:06 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-03-18 0:06 UTC (permalink / raw)
To: Matthijs van Duin
Cc: linux-omap, linux-arm-kernel, Brian Hutchinson, Felipe Balbi
* Tony Lindgren <tony@atomide.com> [150202 08:15]:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150131 17:54]:
> > I just noticed the dm816x.dtsi says:
> >
> > ocp {
> > compatible = "ti,omap3-l3-smx", "simple-bus";
> >
> > This is incorrect: the DM81xx (and siblings like the AM335x) use
> > Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
> > SonicsMX. (In general everything on the DM81xx seems to be
> > omap4-generation)
>
> Good catch, yes it seems it's mostly omap4. Looks like we
> should also add it for am33xx.dtsi while at it.
>
> I'll also check the devices one more time if I have some as
> compatible with omap3 instead of omap4.
Hmm this is also broken on am33xx, and the following patch is needed.
And we also need to populate the tables along the lines of 27b7d5f3cc49
("bus: omap_l3_noc: Add AM4372 interconnect error data").
Do the below ranges match your JTAG results? I scanned them in u-boot
using md for the ranges where I found some related data.
That got me wondering if we can actually scan that data based
on the ranges below as target is 00130001 and flagmux 00370001.
We would be missing the names, but that would be still less data
to pile up in the kernel :) If some module is disabled, then it
should never produce errors so it seems safe to scan the data..
Can we dig even more info based on the RX port address at offset
0x10? That's the L3_TARG_STDHOSTHDR_NTTPADDR_0.
Or got any good ideas for populating the names?
Regards,
Tony
8< ------------------------------
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -105,7 +105,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = "simple-bus";
+ compatible = "ti,am335-l3-noc", "simple-bus";
+ reg = <0x44000000 0x1200
+ 0x44800000 0x1000>;
+ interrupts = <9 10>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -58,8 +58,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = "ti,omap4-l3-noc", "simple-bus";
- reg = <0x44000000 0x10000>;
+ compatible = "ti,dm816-l3-noc", "simple-bus";
+ reg = <0x44000000 0x1200
+ 0x44400000 0x1200
+ 0x44800000 0x1000>;
interrupts = <9 10>;
#address-cells = <1>;
#size-cells = <1>;
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-03-18 0:06 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-03-18 0:06 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [150202 08:15]:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150131 17:54]:
> > I just noticed the dm816x.dtsi says:
> >
> > ocp {
> > compatible = "ti,omap3-l3-smx", "simple-bus";
> >
> > This is incorrect: the DM81xx (and siblings like the AM335x) use
> > Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
> > SonicsMX. (In general everything on the DM81xx seems to be
> > omap4-generation)
>
> Good catch, yes it seems it's mostly omap4. Looks like we
> should also add it for am33xx.dtsi while at it.
>
> I'll also check the devices one more time if I have some as
> compatible with omap3 instead of omap4.
Hmm this is also broken on am33xx, and the following patch is needed.
And we also need to populate the tables along the lines of 27b7d5f3cc49
("bus: omap_l3_noc: Add AM4372 interconnect error data").
Do the below ranges match your JTAG results? I scanned them in u-boot
using md for the ranges where I found some related data.
That got me wondering if we can actually scan that data based
on the ranges below as target is 00130001 and flagmux 00370001.
We would be missing the names, but that would be still less data
to pile up in the kernel :) If some module is disabled, then it
should never produce errors so it seems safe to scan the data..
Can we dig even more info based on the RX port address at offset
0x10? That's the L3_TARG_STDHOSTHDR_NTTPADDR_0.
Or got any good ideas for populating the names?
Regards,
Tony
8< ------------------------------
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -105,7 +105,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = "simple-bus";
+ compatible = "ti,am335-l3-noc", "simple-bus";
+ reg = <0x44000000 0x1200
+ 0x44800000 0x1000>;
+ interrupts = <9 10>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -58,8 +58,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = "ti,omap4-l3-noc", "simple-bus";
- reg = <0x44000000 0x10000>;
+ compatible = "ti,dm816-l3-noc", "simple-bus";
+ reg = <0x44000000 0x1200
+ 0x44400000 0x1200
+ 0x44800000 0x1000>;
interrupts = <9 10>;
#address-cells = <1>;
#size-cells = <1>;
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-03-18 0:06 ` Tony Lindgren
@ 2015-03-18 8:32 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-03-18 8:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm-kernel, Brian Hutchinson, Felipe Balbi
> And we also need to populate the tables along the lines of 27b7d5f3cc49
> ("bus: omap_l3_noc: Add AM4372 interconnect error data").
I think intercon data should be in DT rather than some hardcoded table.
> Do the below ranges match your JTAG results?
Yup. Based a memory dump I had done earlier, combined with the high
degree of similarity with centaurus and filling in the remaining
blanks with my best guess yields:
44000000 host L3F
44000100 target 01 dmm port 0
44000200 target 02 dmm port 1
44000300 target 03 iva 0 sl2 ?
44000400 target 04 iva 1 sl2 ?
44000500 target 05 dsp sdma
44000600 target 06 expansion port
44000700 target 07 edma tc 0
44000800 target 08 edma tc 1
44000900 target 09 edma tc 2
44000a00 target 0a edma tc 3
44000b00 target 0b edma cc
44000c00 target 23 system mmu
44000d00 target 25 iva 2 sl2 ?
44000e00 flagmux l3f
44000f00 flagmux top
44001000 statcoll
44001400 statcoll
44001800 statcoll
44001c00 bw-regulator
44001d00 bw-regulator
44001e00 bw-regulator
44001f00 bw-regulator
44002000 bw-regulator
44002100 bw-regulator
44002200 bw-regulator
44002300 bw-regulator
44002400 bw-regulator
44400000 host L3M
44400100 target 0d ducati
44400200 target 0e sgx
44400300 target 0f pcie
44400400 target 10 ocmc ram
44400500 target 11 vcp
44400600 target 12 iva config
44400700 target 13 iss
44400800 target 14 tppss
44400900 target 15 l4hs port 0
44400a00 target 16 secss
44400b00 target 24 l4hs port 1
44400c00 target 26 mmc 2
44400d00 target 1f l3_instr
44400e00 flagmux L3M
44401000 statcoll
44800000 host L3S
44800100 target 18 vlynq ?
44800200 target 19 mcbsp
44800300 target 1a hdmi
44800400 target 1b l4fw
44800500 target 1c l4ls port 0
44800600 target 1d l4ls port 1
44800700 target 1e gpmc
44800800 target 20 mcasp 0
44800900 target 21 mcasp 1
44800a00 target 22 mcasp 2
44800b00 target 27 usb
44800c00 flagmux L3S
Note BTW that centaurus (in contrast with netra and subarctic)
actually has a pretty good interconnect chapter with full register
maps (except for the L3 firewals).
> That got me wondering if we can actually scan that data based
> on the ranges below as target is 00130001 and flagmux 00370001.
> We would be missing the names, but that would be still less data
> to pile up in the kernel :) If some module is disabled, then it
> should never produce errors so it seems safe to scan the data..
Note that reading invalid addresses while scanning does yield bus
errors you'd need to trap. There can be gaps, and some modules can be
larger than 0x100 (e.g. statcoll is variable in size), but other than
that it's just a matter of reading words in increments of 0x100 and
match with one of the known types:
// 13'0001 target
// 1a'0001 host
// 2c'0001 bw_limiter
// 2d'0001 rate_adapter
// 31'0001 bw_regulator
// 37'0001 flagmux
// 38'0001 pwr_discon
// 3a'0001 statcoll
The statcoll content should read as zeros after reset, so no risk in
accidently detecting a module inside it.
> Can we dig even more info?
Much can be auto-detected indeed, although it may be preferred to use
auto-detection to generate the data, assign missing names, and then
have other users use that data file.
If you know where the FlexNOC L3 intercon registers themselves are
located (called the "service network" in Vayu), then you can scan the
L3 with the following steps:
1. Detect all FlexNOC components as mentioned above. The components we
care about for now are Target NIUs and Flagmuxes, and optionally the
Host to decode errors while scanning the service network itself. In
this step you learn the association Target NIU regbase <-> Target NIU
ID since this is indicated in one of the regs. Make sure error
logging is enabled for all targets.
2. Disable all L3 Target NIUs. You will temporarily lose access to all
peripherals, OCMC ram, and on subarctic also DDR memory (I think on
devices with a DMM you'd retain access to DDR memory). Note that the
service network itself isn't considered an L3 target.
3. Probe the whole address space with reads or writes, while trapping
data aborts (or use posted writes, those won't generate a data abort
but only signal the L3 error irq). The smallest L3 ranges I've seen
so far were 64 KB, so scanning the whole address space would require
2^16 accesses. Shouldn't take too long. Ranges which are not routed to
L3 targets (e.g. the service networks themselves, or MPUSS-local
peripherals) should be manually excluded.
4. For each access, examine the Flagmux modules and Target NIU error
logs. (Then clear the error log for the next access) You should now
learn:
a. which target was reached at that address
b. to which target-local address it was mapped
c. which bit of which flagmux is used for errors from this target
d. to which bit of the top flagmux this flagmux connects
Note that usually a Target NIU will have its regs in the service
network of the L3 it belongs to, and report errors to the associated
Flagmux. Centaurus is a counter-example since for some odd reason its
DMM Target NIUs regs moved to the L3M service network, even though
they attach to the L3F and report errors to the L3F flagmux.
Distinguishing the top flagmux from the others, or even more general
flagmux topologies, can also be deduced programmatically but I'm not
sure that's worth the effort.
The target which seems to be reachable at many many address ranges,
none of which documented as containing any peripheral, is your "error
target" where unroutable packets are sent to to generate an error
reply.
5. Reenable all target NIUs.
6. Identify the L3 targets. This will be semi-automatic at best, since
there's no generally reliable way to do this. Not all peripherals have
a highlander-style revision register, and even the ones that do
sometimes have it at a non-zero offset or failed to pick a unique
function code to identify the module. (Or split it into two 16-bit
halves in consecutive 32-bit registers... nicely done, omap-i2c)
One interesting option is keeping a database of L3 targets across
multiple devices and taking advantage of design reuse: if you find a
target whose NIU ID and mapped memory ranges match those of a specific
target in another device, then there's a good chance they are in fact
the same. This is highly visible in centaurus vs subarctic for
example.
7. Some targets will be other interconnects; proceed with inspecting
those. (Fortunately the L4 intercons are easier to scan).
Matthijs
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-03-18 8:32 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-03-18 8:32 UTC (permalink / raw)
To: linux-arm-kernel
> And we also need to populate the tables along the lines of 27b7d5f3cc49
> ("bus: omap_l3_noc: Add AM4372 interconnect error data").
I think intercon data should be in DT rather than some hardcoded table.
> Do the below ranges match your JTAG results?
Yup. Based a memory dump I had done earlier, combined with the high
degree of similarity with centaurus and filling in the remaining
blanks with my best guess yields:
44000000 host L3F
44000100 target 01 dmm port 0
44000200 target 02 dmm port 1
44000300 target 03 iva 0 sl2 ?
44000400 target 04 iva 1 sl2 ?
44000500 target 05 dsp sdma
44000600 target 06 expansion port
44000700 target 07 edma tc 0
44000800 target 08 edma tc 1
44000900 target 09 edma tc 2
44000a00 target 0a edma tc 3
44000b00 target 0b edma cc
44000c00 target 23 system mmu
44000d00 target 25 iva 2 sl2 ?
44000e00 flagmux l3f
44000f00 flagmux top
44001000 statcoll
44001400 statcoll
44001800 statcoll
44001c00 bw-regulator
44001d00 bw-regulator
44001e00 bw-regulator
44001f00 bw-regulator
44002000 bw-regulator
44002100 bw-regulator
44002200 bw-regulator
44002300 bw-regulator
44002400 bw-regulator
44400000 host L3M
44400100 target 0d ducati
44400200 target 0e sgx
44400300 target 0f pcie
44400400 target 10 ocmc ram
44400500 target 11 vcp
44400600 target 12 iva config
44400700 target 13 iss
44400800 target 14 tppss
44400900 target 15 l4hs port 0
44400a00 target 16 secss
44400b00 target 24 l4hs port 1
44400c00 target 26 mmc 2
44400d00 target 1f l3_instr
44400e00 flagmux L3M
44401000 statcoll
44800000 host L3S
44800100 target 18 vlynq ?
44800200 target 19 mcbsp
44800300 target 1a hdmi
44800400 target 1b l4fw
44800500 target 1c l4ls port 0
44800600 target 1d l4ls port 1
44800700 target 1e gpmc
44800800 target 20 mcasp 0
44800900 target 21 mcasp 1
44800a00 target 22 mcasp 2
44800b00 target 27 usb
44800c00 flagmux L3S
Note BTW that centaurus (in contrast with netra and subarctic)
actually has a pretty good interconnect chapter with full register
maps (except for the L3 firewals).
> That got me wondering if we can actually scan that data based
> on the ranges below as target is 00130001 and flagmux 00370001.
> We would be missing the names, but that would be still less data
> to pile up in the kernel :) If some module is disabled, then it
> should never produce errors so it seems safe to scan the data..
Note that reading invalid addresses while scanning does yield bus
errors you'd need to trap. There can be gaps, and some modules can be
larger than 0x100 (e.g. statcoll is variable in size), but other than
that it's just a matter of reading words in increments of 0x100 and
match with one of the known types:
// 13'0001 target
// 1a'0001 host
// 2c'0001 bw_limiter
// 2d'0001 rate_adapter
// 31'0001 bw_regulator
// 37'0001 flagmux
// 38'0001 pwr_discon
// 3a'0001 statcoll
The statcoll content should read as zeros after reset, so no risk in
accidently detecting a module inside it.
> Can we dig even more info?
Much can be auto-detected indeed, although it may be preferred to use
auto-detection to generate the data, assign missing names, and then
have other users use that data file.
If you know where the FlexNOC L3 intercon registers themselves are
located (called the "service network" in Vayu), then you can scan the
L3 with the following steps:
1. Detect all FlexNOC components as mentioned above. The components we
care about for now are Target NIUs and Flagmuxes, and optionally the
Host to decode errors while scanning the service network itself. In
this step you learn the association Target NIU regbase <-> Target NIU
ID since this is indicated in one of the regs. Make sure error
logging is enabled for all targets.
2. Disable all L3 Target NIUs. You will temporarily lose access to all
peripherals, OCMC ram, and on subarctic also DDR memory (I think on
devices with a DMM you'd retain access to DDR memory). Note that the
service network itself isn't considered an L3 target.
3. Probe the whole address space with reads or writes, while trapping
data aborts (or use posted writes, those won't generate a data abort
but only signal the L3 error irq). The smallest L3 ranges I've seen
so far were 64 KB, so scanning the whole address space would require
2^16 accesses. Shouldn't take too long. Ranges which are not routed to
L3 targets (e.g. the service networks themselves, or MPUSS-local
peripherals) should be manually excluded.
4. For each access, examine the Flagmux modules and Target NIU error
logs. (Then clear the error log for the next access) You should now
learn:
a. which target was reached at that address
b. to which target-local address it was mapped
c. which bit of which flagmux is used for errors from this target
d. to which bit of the top flagmux this flagmux connects
Note that usually a Target NIU will have its regs in the service
network of the L3 it belongs to, and report errors to the associated
Flagmux. Centaurus is a counter-example since for some odd reason its
DMM Target NIUs regs moved to the L3M service network, even though
they attach to the L3F and report errors to the L3F flagmux.
Distinguishing the top flagmux from the others, or even more general
flagmux topologies, can also be deduced programmatically but I'm not
sure that's worth the effort.
The target which seems to be reachable at many many address ranges,
none of which documented as containing any peripheral, is your "error
target" where unroutable packets are sent to to generate an error
reply.
5. Reenable all target NIUs.
6. Identify the L3 targets. This will be semi-automatic at best, since
there's no generally reliable way to do this. Not all peripherals have
a highlander-style revision register, and even the ones that do
sometimes have it at a non-zero offset or failed to pick a unique
function code to identify the module. (Or split it into two 16-bit
halves in consecutive 32-bit registers... nicely done, omap-i2c)
One interesting option is keeping a database of L3 targets across
multiple devices and taking advantage of design reuse: if you find a
target whose NIU ID and mapped memory ranges match those of a specific
target in another device, then there's a good chance they are in fact
the same. This is highly visible in centaurus vs subarctic for
example.
7. Some targets will be other interconnects; proceed with inspecting
those. (Fortunately the L4 intercons are easier to scan).
Matthijs
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-03-18 8:32 ` Matthijs van Duin
@ 2015-03-18 16:54 ` Tony Lindgren
-1 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-03-18 16:54 UTC (permalink / raw)
To: Matthijs van Duin
Cc: linux-omap, linux-arm-kernel, Brian Hutchinson, Felipe Balbi
* Matthijs van Duin <matthijsvanduin@gmail.com> [150318 01:33]:
> > And we also need to populate the tables along the lines of 27b7d5f3cc49
> > ("bus: omap_l3_noc: Add AM4372 interconnect error data").
>
> I think intercon data should be in DT rather than some hardcoded table.
Yeah so it seems.
> > Do the below ranges match your JTAG results?
>
> Yup. Based a memory dump I had done earlier, combined with the high
> degree of similarity with centaurus and filling in the remaining
> blanks with my best guess yields:
>
> 44000000 host L3F
> 44000100 target 01 dmm port 0
> 44000200 target 02 dmm port 1
> 44000300 target 03 iva 0 sl2 ?
> 44000400 target 04 iva 1 sl2 ?
> 44000500 target 05 dsp sdma
> 44000600 target 06 expansion port
> 44000700 target 07 edma tc 0
> 44000800 target 08 edma tc 1
> 44000900 target 09 edma tc 2
> 44000a00 target 0a edma tc 3
> 44000b00 target 0b edma cc
> 44000c00 target 23 system mmu
> 44000d00 target 25 iva 2 sl2 ?
> 44000e00 flagmux l3f
> 44000f00 flagmux top
> 44001000 statcoll
Oh there's a gap here and it goes all the way to 2400.. Is there
a gap on am335x too?
> 44001400 statcoll
> 44001800 statcoll
> 44001c00 bw-regulator
> 44001d00 bw-regulator
> 44001e00 bw-regulator
> 44001f00 bw-regulator
> 44002000 bw-regulator
> 44002100 bw-regulator
> 44002200 bw-regulator
> 44002300 bw-regulator
> 44002400 bw-regulator
>
> 44400000 host L3M
> 44400100 target 0d ducati
> 44400200 target 0e sgx
> 44400300 target 0f pcie
> 44400400 target 10 ocmc ram
> 44400500 target 11 vcp
> 44400600 target 12 iva config
> 44400700 target 13 iss
> 44400800 target 14 tppss
> 44400900 target 15 l4hs port 0
> 44400a00 target 16 secss
> 44400b00 target 24 l4hs port 1
> 44400c00 target 26 mmc 2
> 44400d00 target 1f l3_instr
> 44400e00 flagmux L3M
> 44401000 statcoll
>
> 44800000 host L3S
> 44800100 target 18 vlynq ?
> 44800200 target 19 mcbsp
> 44800300 target 1a hdmi
> 44800400 target 1b l4fw
> 44800500 target 1c l4ls port 0
> 44800600 target 1d l4ls port 1
> 44800700 target 1e gpmc
> 44800800 target 20 mcasp 0
> 44800900 target 21 mcasp 1
> 44800a00 target 22 mcasp 2
> 44800b00 target 27 usb
> 44800c00 flagmux L3S
OK that's great, thanks for the data!
> Note BTW that centaurus (in contrast with netra and subarctic)
> actually has a pretty good interconnect chapter with full register
> maps (except for the L3 firewals).
OK that's good to hear.
> > That got me wondering if we can actually scan that data based
> > on the ranges below as target is 00130001 and flagmux 00370001.
> > We would be missing the names, but that would be still less data
> > to pile up in the kernel :) If some module is disabled, then it
> > should never produce errors so it seems safe to scan the data..
>
> Note that reading invalid addresses while scanning does yield bus
> errors you'd need to trap. There can be gaps, and some modules can be
> larger than 0x100 (e.g. statcoll is variable in size), but other than
> that it's just a matter of reading words in increments of 0x100 and
> match with one of the known types:
> // 13'0001 target
> // 1a'0001 host
> // 2c'0001 bw_limiter
> // 2d'0001 rate_adapter
> // 31'0001 bw_regulator
> // 37'0001 flagmux
> // 38'0001 pwr_discon
> // 3a'0001 statcoll
>
> The statcoll content should read as zeros after reset, so no risk in
> accidently detecting a module inside it.
>
> > Can we dig even more info?
>
> Much can be auto-detected indeed, although it may be preferred to use
> auto-detection to generate the data, assign missing names, and then
> have other users use that data file.
>
> If you know where the FlexNOC L3 intercon registers themselves are
> located (called the "service network" in Vayu), then you can scan the
> L3 with the following steps:
>
> 1. Detect all FlexNOC components as mentioned above. The components we
> care about for now are Target NIUs and Flagmuxes, and optionally the
> Host to decode errors while scanning the service network itself. In
> this step you learn the association Target NIU regbase <-> Target NIU
> ID since this is indicated in one of the regs. Make sure error
> logging is enabled for all targets.
>
> 2. Disable all L3 Target NIUs. You will temporarily lose access to all
> peripherals, OCMC ram, and on subarctic also DDR memory (I think on
> devices with a DMM you'd retain access to DDR memory). Note that the
> service network itself isn't considered an L3 target.
Hmm well we could that in the kernel using the SRAM code as long as
it does not reset the devices.
> 3. Probe the whole address space with reads or writes, while trapping
> data aborts (or use posted writes, those won't generate a data abort
> but only signal the L3 error irq). The smallest L3 ranges I've seen
> so far were 64 KB, so scanning the whole address space would require
> 2^16 accesses. Shouldn't take too long. Ranges which are not routed to
> L3 targets (e.g. the service networks themselves, or MPUSS-local
> peripherals) should be manually excluded.
OK the driver would have to be enabled with interrupts while scanning.
> 4. For each access, examine the Flagmux modules and Target NIU error
> logs. (Then clear the error log for the next access) You should now
> learn:
> a. which target was reached at that address
> b. to which target-local address it was mapped
> c. which bit of which flagmux is used for errors from this target
> d. to which bit of the top flagmux this flagmux connects
>
> Note that usually a Target NIU will have its regs in the service
> network of the L3 it belongs to, and report errors to the associated
> Flagmux. Centaurus is a counter-example since for some odd reason its
> DMM Target NIUs regs moved to the L3M service network, even though
> they attach to the L3F and report errors to the L3F flagmux.
>
> Distinguishing the top flagmux from the others, or even more general
> flagmux topologies, can also be deduced programmatically but I'm not
> sure that's worth the effort.
>
> The target which seems to be reachable at many many address ranges,
> none of which documented as containing any peripheral, is your "error
> target" where unroutable packets are sent to to generate an error
> reply.
>
> 5. Reenable all target NIUs.
>
> 6. Identify the L3 targets. This will be semi-automatic at best, since
> there's no generally reliable way to do this. Not all peripherals have
> a highlander-style revision register, and even the ones that do
> sometimes have it at a non-zero offset or failed to pick a unique
> function code to identify the module. (Or split it into two 16-bit
> halves in consecutive 32-bit registers... nicely done, omap-i2c)
>
> One interesting option is keeping a database of L3 targets across
> multiple devices and taking advantage of design reuse: if you find a
> target whose NIU ID and mapped memory ranges match those of a specific
> target in another device, then there's a good chance they are in fact
> the same. This is highly visible in centaurus vs subarctic for
> example.
Yes sounds like that would be probably the best way to go eventually.
> 7. Some targets will be other interconnects; proceed with inspecting
> those. (Fortunately the L4 intercons are easier to scan).
Thanks for all the info :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-03-18 16:54 ` Tony Lindgren
0 siblings, 0 replies; 66+ messages in thread
From: Tony Lindgren @ 2015-03-18 16:54 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [150318 01:33]:
> > And we also need to populate the tables along the lines of 27b7d5f3cc49
> > ("bus: omap_l3_noc: Add AM4372 interconnect error data").
>
> I think intercon data should be in DT rather than some hardcoded table.
Yeah so it seems.
> > Do the below ranges match your JTAG results?
>
> Yup. Based a memory dump I had done earlier, combined with the high
> degree of similarity with centaurus and filling in the remaining
> blanks with my best guess yields:
>
> 44000000 host L3F
> 44000100 target 01 dmm port 0
> 44000200 target 02 dmm port 1
> 44000300 target 03 iva 0 sl2 ?
> 44000400 target 04 iva 1 sl2 ?
> 44000500 target 05 dsp sdma
> 44000600 target 06 expansion port
> 44000700 target 07 edma tc 0
> 44000800 target 08 edma tc 1
> 44000900 target 09 edma tc 2
> 44000a00 target 0a edma tc 3
> 44000b00 target 0b edma cc
> 44000c00 target 23 system mmu
> 44000d00 target 25 iva 2 sl2 ?
> 44000e00 flagmux l3f
> 44000f00 flagmux top
> 44001000 statcoll
Oh there's a gap here and it goes all the way to 2400.. Is there
a gap on am335x too?
> 44001400 statcoll
> 44001800 statcoll
> 44001c00 bw-regulator
> 44001d00 bw-regulator
> 44001e00 bw-regulator
> 44001f00 bw-regulator
> 44002000 bw-regulator
> 44002100 bw-regulator
> 44002200 bw-regulator
> 44002300 bw-regulator
> 44002400 bw-regulator
>
> 44400000 host L3M
> 44400100 target 0d ducati
> 44400200 target 0e sgx
> 44400300 target 0f pcie
> 44400400 target 10 ocmc ram
> 44400500 target 11 vcp
> 44400600 target 12 iva config
> 44400700 target 13 iss
> 44400800 target 14 tppss
> 44400900 target 15 l4hs port 0
> 44400a00 target 16 secss
> 44400b00 target 24 l4hs port 1
> 44400c00 target 26 mmc 2
> 44400d00 target 1f l3_instr
> 44400e00 flagmux L3M
> 44401000 statcoll
>
> 44800000 host L3S
> 44800100 target 18 vlynq ?
> 44800200 target 19 mcbsp
> 44800300 target 1a hdmi
> 44800400 target 1b l4fw
> 44800500 target 1c l4ls port 0
> 44800600 target 1d l4ls port 1
> 44800700 target 1e gpmc
> 44800800 target 20 mcasp 0
> 44800900 target 21 mcasp 1
> 44800a00 target 22 mcasp 2
> 44800b00 target 27 usb
> 44800c00 flagmux L3S
OK that's great, thanks for the data!
> Note BTW that centaurus (in contrast with netra and subarctic)
> actually has a pretty good interconnect chapter with full register
> maps (except for the L3 firewals).
OK that's good to hear.
> > That got me wondering if we can actually scan that data based
> > on the ranges below as target is 00130001 and flagmux 00370001.
> > We would be missing the names, but that would be still less data
> > to pile up in the kernel :) If some module is disabled, then it
> > should never produce errors so it seems safe to scan the data..
>
> Note that reading invalid addresses while scanning does yield bus
> errors you'd need to trap. There can be gaps, and some modules can be
> larger than 0x100 (e.g. statcoll is variable in size), but other than
> that it's just a matter of reading words in increments of 0x100 and
> match with one of the known types:
> // 13'0001 target
> // 1a'0001 host
> // 2c'0001 bw_limiter
> // 2d'0001 rate_adapter
> // 31'0001 bw_regulator
> // 37'0001 flagmux
> // 38'0001 pwr_discon
> // 3a'0001 statcoll
>
> The statcoll content should read as zeros after reset, so no risk in
> accidently detecting a module inside it.
>
> > Can we dig even more info?
>
> Much can be auto-detected indeed, although it may be preferred to use
> auto-detection to generate the data, assign missing names, and then
> have other users use that data file.
>
> If you know where the FlexNOC L3 intercon registers themselves are
> located (called the "service network" in Vayu), then you can scan the
> L3 with the following steps:
>
> 1. Detect all FlexNOC components as mentioned above. The components we
> care about for now are Target NIUs and Flagmuxes, and optionally the
> Host to decode errors while scanning the service network itself. In
> this step you learn the association Target NIU regbase <-> Target NIU
> ID since this is indicated in one of the regs. Make sure error
> logging is enabled for all targets.
>
> 2. Disable all L3 Target NIUs. You will temporarily lose access to all
> peripherals, OCMC ram, and on subarctic also DDR memory (I think on
> devices with a DMM you'd retain access to DDR memory). Note that the
> service network itself isn't considered an L3 target.
Hmm well we could that in the kernel using the SRAM code as long as
it does not reset the devices.
> 3. Probe the whole address space with reads or writes, while trapping
> data aborts (or use posted writes, those won't generate a data abort
> but only signal the L3 error irq). The smallest L3 ranges I've seen
> so far were 64 KB, so scanning the whole address space would require
> 2^16 accesses. Shouldn't take too long. Ranges which are not routed to
> L3 targets (e.g. the service networks themselves, or MPUSS-local
> peripherals) should be manually excluded.
OK the driver would have to be enabled with interrupts while scanning.
> 4. For each access, examine the Flagmux modules and Target NIU error
> logs. (Then clear the error log for the next access) You should now
> learn:
> a. which target was reached at that address
> b. to which target-local address it was mapped
> c. which bit of which flagmux is used for errors from this target
> d. to which bit of the top flagmux this flagmux connects
>
> Note that usually a Target NIU will have its regs in the service
> network of the L3 it belongs to, and report errors to the associated
> Flagmux. Centaurus is a counter-example since for some odd reason its
> DMM Target NIUs regs moved to the L3M service network, even though
> they attach to the L3F and report errors to the L3F flagmux.
>
> Distinguishing the top flagmux from the others, or even more general
> flagmux topologies, can also be deduced programmatically but I'm not
> sure that's worth the effort.
>
> The target which seems to be reachable at many many address ranges,
> none of which documented as containing any peripheral, is your "error
> target" where unroutable packets are sent to to generate an error
> reply.
>
> 5. Reenable all target NIUs.
>
> 6. Identify the L3 targets. This will be semi-automatic at best, since
> there's no generally reliable way to do this. Not all peripherals have
> a highlander-style revision register, and even the ones that do
> sometimes have it at a non-zero offset or failed to pick a unique
> function code to identify the module. (Or split it into two 16-bit
> halves in consecutive 32-bit registers... nicely done, omap-i2c)
>
> One interesting option is keeping a database of L3 targets across
> multiple devices and taking advantage of design reuse: if you find a
> target whose NIU ID and mapped memory ranges match those of a specific
> target in another device, then there's a good chance they are in fact
> the same. This is highly visible in centaurus vs subarctic for
> example.
Yes sounds like that would be probably the best way to go eventually.
> 7. Some targets will be other interconnects; proceed with inspecting
> those. (Fortunately the L4 intercons are easier to scan).
Thanks for all the info :)
Regards,
Tony
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
2015-03-18 16:54 ` Tony Lindgren
@ 2015-03-19 5:13 ` Matthijs van Duin
-1 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-03-19 5:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm-kernel, Brian Hutchinson, Felipe Balbi
> Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> 44400500 target 11 vcp
> 44800100 target 18 vlynq ?
scrap these guesses: I don't think Netra has a vcp module, and I had
only filled in vlynq based on it being the only remaining target NIU.
Once the memory ranges for the targets have been determined they
should be easy to identify conclusively.
On 18 March 2015 at 17:54, Tony Lindgren <tony@atomide.com> wrote:
> Oh there's a gap here and it goes all the way to 2400.. Is there
> a gap on am335x too?
There are indeed. See my work-in-progress spreadsheet on its L3
interconnect: http://goo.gl/miyCQw
As with the memory map, there are some "ghost" modules which I'm
reasonably sure don't exist, even though they have a target NIU and
clkctrl registers.
I haven't yet checked which initiator the sole bandwidth regulator on
subarctic is attached to. Plausible options are SGX, the LCD
controller, or one of the EDMA TCs.
I also just noticed how *big* its statistics collectors are. o.O For
comparison, the ones on netra and centaurus are 0x200 (statcoll 0 and
3) or 0x400 (statcoll 1 and 2).
>> 2. Disable all L3 Target NIUs. You will temporarily lose access to all
>> peripherals, OCMC ram, and on subarctic also DDR memory (I think on
>> devices with a DMM you'd retain access to DDR memory). Note that the
>> service network itself isn't considered an L3 target.
>
> Hmm well we could that in the kernel using the SRAM code as long as
> it does not reset the devices.
If you run with MMU disabled then you'd have to run out of the 64K
internal SRAM, and catch data aborts since all writes will be
non-posted. With MMU enabled, locking code and MMU translation tables
into the (much larger) L2 cache makes more sense.
I *think* disabling the NIU only blocks access to the module and
doesn't affect the module operationally. I'd be inclined to put
external RAM into self-refresh during the procedure just to be sure,
in case disabling NIUs results in clock gating (which would otherwise
be hard to notice).
> OK the driver would have to be enabled with interrupts while scanning.
Polling makes more sense, especially since nothing else can be going
on at the same time anyway.
I still think a separate tool that scrapes as much data as possible
from the target and pours it into DT form makes more sense than doing
it in a kernel driver, especially since discovered targets may often
still need manual identification. Also, probing discovered targets
requires you enable the clock(s) they need and if necessary release
local reset. Auto-discovery of these associations may also be
possible, but probably would become a rather lenghy procedure. A
separate tool can also leave a record of what it's doing in SRAM and
enable the watchdog to be able to recover from probes that lock up the
system (and log a warning about them).
Also, on HS devices, it would surprise me if you're allowed to access
any interconnect registers at all.
Matthijs
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
@ 2015-03-19 5:13 ` Matthijs van Duin
0 siblings, 0 replies; 66+ messages in thread
From: Matthijs van Duin @ 2015-03-19 5:13 UTC (permalink / raw)
To: linux-arm-kernel
> Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> 44400500 target 11 vcp
> 44800100 target 18 vlynq ?
scrap these guesses: I don't think Netra has a vcp module, and I had
only filled in vlynq based on it being the only remaining target NIU.
Once the memory ranges for the targets have been determined they
should be easy to identify conclusively.
On 18 March 2015 at 17:54, Tony Lindgren <tony@atomide.com> wrote:
> Oh there's a gap here and it goes all the way to 2400.. Is there
> a gap on am335x too?
There are indeed. See my work-in-progress spreadsheet on its L3
interconnect: http://goo.gl/miyCQw
As with the memory map, there are some "ghost" modules which I'm
reasonably sure don't exist, even though they have a target NIU and
clkctrl registers.
I haven't yet checked which initiator the sole bandwidth regulator on
subarctic is attached to. Plausible options are SGX, the LCD
controller, or one of the EDMA TCs.
I also just noticed how *big* its statistics collectors are. o.O For
comparison, the ones on netra and centaurus are 0x200 (statcoll 0 and
3) or 0x400 (statcoll 1 and 2).
>> 2. Disable all L3 Target NIUs. You will temporarily lose access to all
>> peripherals, OCMC ram, and on subarctic also DDR memory (I think on
>> devices with a DMM you'd retain access to DDR memory). Note that the
>> service network itself isn't considered an L3 target.
>
> Hmm well we could that in the kernel using the SRAM code as long as
> it does not reset the devices.
If you run with MMU disabled then you'd have to run out of the 64K
internal SRAM, and catch data aborts since all writes will be
non-posted. With MMU enabled, locking code and MMU translation tables
into the (much larger) L2 cache makes more sense.
I *think* disabling the NIU only blocks access to the module and
doesn't affect the module operationally. I'd be inclined to put
external RAM into self-refresh during the procedure just to be sure,
in case disabling NIUs results in clock gating (which would otherwise
be hard to notice).
> OK the driver would have to be enabled with interrupts while scanning.
Polling makes more sense, especially since nothing else can be going
on at the same time anyway.
I still think a separate tool that scrapes as much data as possible
from the target and pours it into DT form makes more sense than doing
it in a kernel driver, especially since discovered targets may often
still need manual identification. Also, probing discovered targets
requires you enable the clock(s) they need and if necessary release
local reset. Auto-discovery of these associations may also be
possible, but probably would become a rather lenghy procedure. A
separate tool can also leave a record of what it's doing in SRAM and
enable the watchdog to be able to recover from probes that lock up the
system (and log a warning about them).
Also, on HS devices, it would surprise me if you're allowed to access
any interconnect registers at all.
Matthijs
^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2015-03-19 5:14 UTC | newest]
Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-13 23:37 [PATCH 0/4] Device tree related changes to boot dm816x Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-14 13:51 ` Sergei Shtylyov
2015-01-14 13:51 ` Sergei Shtylyov
2015-01-15 0:07 ` Tony Lindgren
2015-01-15 0:07 ` Tony Lindgren
2015-01-19 19:18 ` Tony Lindgren
2015-01-19 19:18 ` Tony Lindgren
2015-01-19 20:42 ` Felipe Balbi
2015-01-19 20:42 ` Felipe Balbi
2015-01-19 21:05 ` Tony Lindgren
2015-01-19 21:05 ` Tony Lindgren
2015-01-19 21:10 ` Felipe Balbi
2015-01-19 21:10 ` Felipe Balbi
2015-01-13 23:37 ` [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-15 21:23 ` Suman Anna
2015-01-15 21:23 ` Suman Anna
2015-01-15 22:59 ` Tony Lindgren
2015-01-15 22:59 ` Tony Lindgren
2015-01-17 16:41 ` Tony Lindgren
2015-01-17 16:41 ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 3/4] ARM: dts: Add basic clocks for dm816x Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-17 16:47 ` Tony Lindgren
2015-01-17 16:47 ` Tony Lindgren
2015-01-17 17:51 ` Matthijs van Duin
2015-01-17 17:51 ` Matthijs van Duin
2015-01-17 18:14 ` Tony Lindgren
2015-01-17 18:14 ` Tony Lindgren
2015-01-17 22:37 ` Matthijs van Duin
2015-01-17 22:37 ` Matthijs van Duin
2015-01-19 17:29 ` Tony Lindgren
2015-01-19 17:29 ` Tony Lindgren
2015-01-22 3:17 ` Matthijs van Duin
2015-01-22 3:17 ` Matthijs van Duin
2015-01-23 16:47 ` Tony Lindgren
2015-01-23 16:47 ` Tony Lindgren
2015-01-25 8:34 ` Matthijs van Duin
2015-01-25 8:34 ` Matthijs van Duin
2015-01-26 15:58 ` Tony Lindgren
2015-01-26 15:58 ` Tony Lindgren
2015-01-28 21:43 ` Matthijs van Duin
2015-01-28 21:43 ` Matthijs van Duin
2015-02-02 17:44 ` Tony Lindgren
2015-02-02 17:44 ` Tony Lindgren
2015-02-03 5:51 ` Matthijs van Duin
2015-02-03 5:51 ` Matthijs van Duin
2015-01-28 17:04 ` Tony Lindgren
2015-01-28 17:04 ` Tony Lindgren
2015-02-01 1:51 ` Matthijs van Duin
2015-02-01 1:51 ` Matthijs van Duin
2015-02-02 16:09 ` Tony Lindgren
2015-02-02 16:09 ` Tony Lindgren
2015-03-18 0:06 ` Tony Lindgren
2015-03-18 0:06 ` Tony Lindgren
2015-03-18 8:32 ` Matthijs van Duin
2015-03-18 8:32 ` Matthijs van Duin
2015-03-18 16:54 ` Tony Lindgren
2015-03-18 16:54 ` Tony Lindgren
2015-03-19 5:13 ` Matthijs van Duin
2015-03-19 5:13 ` Matthijs van Duin
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.