AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-22 11:58:21 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
90444b9584
linux_dsm_epyc7002/arch/arm/boot/dts/am33xx-l4.dtsi

2122 lines
59 KiB
Plaintext
Raw Normal View History

ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
&l4_wkup { /* 0x44c00000 */
compatible = "ti,am33xx-l4-wkup", "simple-bus";
reg = <0x44c00000 0x800>,
<0x44c00800 0x800>,
<0x44c01000 0x400>,
<0x44c01400 0x400>;
reg-names = "ap", "la", "ia0", "ia1";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x44c00000 0x100000>, /* segment 0 */
<0x00100000 0x44d00000 0x100000>, /* segment 1 */
<0x00200000 0x44e00000 0x100000>; /* segment 2 */
segment@0 { /* 0x44c00000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
<0x00000800 0x00000800 0x000800>, /* ap 1 */
<0x00001000 0x00001000 0x000400>, /* ap 2 */
<0x00001400 0x00001400 0x000400>; /* ap 3 */
};
segment@100000 { /* 0x44d00000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00100000 0x004000>, /* ap 4 */
<0x00004000 0x00104000 0x001000>, /* ap 5 */
<0x00080000 0x00180000 0x002000>, /* ap 6 */
<0x00082000 0x00182000 0x001000>; /* ap 7 */
target-module@0 { /* 0x44d00000, ap 4 28.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x0 0x4>;
reg-names = "rev";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x4000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
status = "disabled";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@80000 { /* 0x44d80000, ap 6 10.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x80000 0x2000>;
};
};
segment@200000 { /* 0x44e00000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00200000 0x002000>, /* ap 8 */
<0x00002000 0x00202000 0x001000>, /* ap 9 */
<0x00003000 0x00203000 0x001000>, /* ap 10 */
<0x00004000 0x00204000 0x001000>, /* ap 11 */
<0x00005000 0x00205000 0x001000>, /* ap 12 */
<0x00006000 0x00206000 0x001000>, /* ap 13 */
<0x00007000 0x00207000 0x001000>, /* ap 14 */
<0x00008000 0x00208000 0x001000>, /* ap 15 */
<0x00009000 0x00209000 0x001000>, /* ap 16 */
<0x0000a000 0x0020a000 0x001000>, /* ap 17 */
<0x0000b000 0x0020b000 0x001000>, /* ap 18 */
<0x0000c000 0x0020c000 0x001000>, /* ap 19 */
<0x0000d000 0x0020d000 0x001000>, /* ap 20 */
<0x0000f000 0x0020f000 0x001000>, /* ap 21 */
<0x00010000 0x00210000 0x010000>, /* ap 22 */
<0x00020000 0x00220000 0x010000>, /* ap 23 */
<0x00030000 0x00230000 0x001000>, /* ap 24 */
<0x00031000 0x00231000 0x001000>, /* ap 25 */
<0x00032000 0x00232000 0x001000>, /* ap 26 */
<0x00033000 0x00233000 0x001000>, /* ap 27 */
<0x00034000 0x00234000 0x001000>, /* ap 28 */
<0x00035000 0x00235000 0x001000>, /* ap 29 */
<0x00036000 0x00236000 0x001000>, /* ap 30 */
<0x00037000 0x00237000 0x001000>, /* ap 31 */
<0x00038000 0x00238000 0x001000>, /* ap 32 */
<0x00039000 0x00239000 0x001000>, /* ap 33 */
<0x0003a000 0x0023a000 0x001000>, /* ap 34 */
<0x0003e000 0x0023e000 0x001000>, /* ap 35 */
<0x0003f000 0x0023f000 0x001000>, /* ap 36 */
<0x0000e000 0x0020e000 0x001000>, /* ap 37 */
<0x00040000 0x00240000 0x040000>, /* ap 38 */
<0x00080000 0x00280000 0x001000>; /* ap 39 */
target-module@0 { /* 0x44e00000, ap 8 58.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0 0x4>;
reg-names = "rev";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x2000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
prcm: prcm@0 {
compatible = "ti,am3-prcm", "simple-bus";
reg = <0 0x2000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x2000>;
prcm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
prcm_clockdomains: clockdomains {
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@3000 { /* 0x44e03000, ap 10 0a.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3000 0x1000>;
};
target-module@5000 { /* 0x44e05000, ap 12 30.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x5000 0x1000>;
};
ARM: dts: Fix gpio0 flags for am335x-icev2 The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at the interconnect target module level for the modules that have it defined. Otherwise we get the following warnings: dts flag should be at module level for ti,no-idle-on-init dts flag should be at module level for ti,no-reset-on-init Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Cc: Lokesh Vutla <lokeshvutla@ti.com> Reported-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-09-24 23:24:28 +07:00
gpio0_target: target-module@7000 { /* 0x44e07000, ap 14 20.0 */
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x7000 0x4>,
<0x7010 0x4>,
<0x7114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_GPIO1_CLKCTRL 0>,
<&l4_wkup_clkctrl AM3_L4_WKUP_GPIO1_CLKCTRL 18>;
clock-names = "fck", "dbclk";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x7000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
gpio0: gpio@0 {
compatible = "ti,omap4-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x1000>;
interrupts = <96>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@9000 { /* 0x44e09000, ap 16 04.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x9050 0x4>,
<0x9054 0x4>,
<0x9058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_UART1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x9000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart0: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <72>;
status = "disabled";
dmas = <&edma 26 0>, <&edma 27 0>;
dma-names = "tx", "rx";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@b000 { /* 0x44e0b000, ap 18 48.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xb000 0x8>,
<0xb010 0x8>,
<0xb090 0x8>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_I2C1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xb000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
i2c0: i2c@0 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x1000>;
interrupts = <70>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@d000 { /* 0x44e0d000, ap 20 38.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0xd000 0x4>,
<0xd010 0x4>;
reg-names = "rev", "sysc";
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_ADC_TSC_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x0000d000 0x00001000>,
<0x00001000 0x0000e000 0x00001000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
tscadc: tscadc@0 {
compatible = "ti,am3359-tscadc";
reg = <0x0 0x1000>;
interrupts = <16>;
status = "disabled";
dmas = <&edma 53 0>, <&edma 57 0>;
dma-names = "fifo0", "fifo1";
tsc {
compatible = "ti,am3359-tsc";
};
am335x_adc: adc {
#io-channel-cells = <1>;
compatible = "ti,am3359-adc";
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@10000 { /* 0x44e10000, ap 22 0c.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x10000 0x4>;
reg-names = "rev";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00010000 0x00010000>,
<0x00010000 0x00020000 0x00010000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
scm: scm@0 {
compatible = "ti,am3-scm", "simple-bus";
reg = <0x0 0x2000>;
#address-cells = <1>;
#size-cells = <1>;
#pinctrl-cells = <1>;
ranges = <0 0 0x2000>;
am33xx_pinmux: pinmux@800 {
compatible = "pinctrl-single";
reg = <0x800 0x238>;
#pinctrl-cells = <1>;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x7f>;
};
scm_conf: scm_conf@0 {
compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x800>;
ARM: dts: am335x: switch to use phy-gmii-sel Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-02-20 22:25:17 +07:00
phy_gmii_sel: phy-gmii-sel {
compatible = "ti,am3352-phy-gmii-sel";
reg = <0x650 0x4>;
#phy-cells = <2>;
};
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
};
ARM: dts: Probe am335x musb with ti-sysc We can now probe musb with ti-sysc interconnect driver and dts data with the following changes: 1. Swap the old ti,am33xx-usb compatible wrapper to generic ti-sysc driver. This means later on we can also remove the old wrapper driver drivers/usb/musb/musb_am335x.c 2. Update the child nodes to use the ranges provided by ti-sysc 3. Drop unneeded status = "enabled" tinkering for SoC internal devices. This allows us to remove some useless board specific boilerplate code in the following patches Cc: Bin Liu <b-liu@ti.com> Cc: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22 04:16:41 +07:00
usb_ctrl_mod: control@620 {
compatible = "ti,am335x-usb-ctrl-module";
reg = <0x620 0x10>,
<0x648 0x4>;
reg-names = "phy_ctrl", "wakeup";
};
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
wkup_m3_ipc: wkup_m3_ipc@1324 {
compatible = "ti,am3352-wkup-m3-ipc";
reg = <0x1324 0x24>;
interrupts = <78>;
ti,rproc = <&wkup_m3>;
mboxes = <&mailbox &mbox_wkupm3>;
};
edma_xbar: dma-router@f90 {
compatible = "ti,am335x-edma-crossbar";
reg = <0xf90 0x40>;
#dma-cells = <3>;
dma-requests = <32>;
dma-masters = <&edma>;
};
scm_clockdomains: clockdomains {
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@31000 { /* 0x44e31000, ap 25 40.0 */
compatible = "ti,sysc-omap2-timer", "ti,sysc";
ti,hwmods = "timer1";
reg = <0x31000 0x4>,
<0x31010 0x4>,
<0x31014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_TIMER1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x31000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer1: timer@0 {
compatible = "ti,am335x-timer-1ms";
reg = <0x0 0x400>;
interrupts = <67>;
ti,timer-alwon;
clocks = <&timer1_fck>;
clock-names = "fck";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@33000 { /* 0x44e33000, ap 27 18.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x33000 0x1000>;
};
target-module@35000 { /* 0x44e35000, ap 29 50.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x35000 0x4>,
<0x35010 0x4>,
<0x35014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_EMUFREE |
SYSC_OMAP2_SOFTRESET)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): wkup_pwrdm, l4_wkup_clkdm */
clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_WD_TIMER2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x35000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
wdt2: wdt@0 {
compatible = "ti,omap3-wdt";
reg = <0x0 0x1000>;
interrupts = <91>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@37000 { /* 0x44e37000, ap 31 08.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x37000 0x1000>;
};
target-module@39000 { /* 0x44e39000, ap 33 02.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x39000 0x1000>;
};
target-module@3e000 { /* 0x44e3e000, ap 35 60.0 */
compatible = "ti,sysc-omap4-simple", "ti,sysc";
ti,hwmods = "rtc";
reg = <0x3e074 0x4>,
<0x3e078 0x4>;
reg-names = "rev", "sysc";
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): rtc_pwrdm, l4_rtc_clkdm */
clocks = <&l4_rtc_clkctrl AM3_L4_RTC_RTC_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3e000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
rtc: rtc@0 {
compatible = "ti,am3352-rtc", "ti,da830-rtc";
reg = <0x0 0x1000>;
interrupts = <75
76>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@40000 { /* 0x44e40000, ap 38 68.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x40000 0x40000>;
};
};
};
&l4_fw { /* 0x47c00000 */
compatible = "ti,am33xx-l4-fw", "simple-bus";
reg = <0x47c00000 0x800>,
<0x47c00800 0x800>,
<0x47c01000 0x400>;
reg-names = "ap", "la", "ia0";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x47c00000 0x1000000>; /* segment 0 */
segment@0 { /* 0x47c00000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
<0x00000800 0x00000800 0x000800>, /* ap 1 */
<0x00001000 0x00001000 0x000400>, /* ap 2 */
<0x0000c000 0x0000c000 0x001000>, /* ap 3 */
<0x0000d000 0x0000d000 0x001000>, /* ap 4 */
<0x0000e000 0x0000e000 0x001000>, /* ap 5 */
<0x0000f000 0x0000f000 0x001000>, /* ap 6 */
<0x00010000 0x00010000 0x001000>, /* ap 7 */
<0x00011000 0x00011000 0x001000>, /* ap 8 */
<0x0001a000 0x0001a000 0x001000>, /* ap 9 */
<0x0001b000 0x0001b000 0x001000>, /* ap 10 */
<0x00024000 0x00024000 0x001000>, /* ap 11 */
<0x00025000 0x00025000 0x001000>, /* ap 12 */
<0x00026000 0x00026000 0x001000>, /* ap 13 */
<0x00027000 0x00027000 0x001000>, /* ap 14 */
<0x00030000 0x00030000 0x001000>, /* ap 15 */
<0x00031000 0x00031000 0x001000>, /* ap 16 */
<0x00038000 0x00038000 0x001000>, /* ap 17 */
<0x00039000 0x00039000 0x001000>, /* ap 18 */
<0x0003a000 0x0003a000 0x001000>, /* ap 19 */
<0x0003b000 0x0003b000 0x001000>, /* ap 20 */
<0x0003e000 0x0003e000 0x001000>, /* ap 21 */
<0x0003f000 0x0003f000 0x001000>, /* ap 22 */
<0x0003c000 0x0003c000 0x001000>, /* ap 23 */
<0x00040000 0x00040000 0x001000>, /* ap 24 */
<0x00046000 0x00046000 0x001000>, /* ap 25 */
<0x00047000 0x00047000 0x001000>, /* ap 26 */
<0x00044000 0x00044000 0x001000>, /* ap 27 */
<0x00045000 0x00045000 0x001000>, /* ap 28 */
<0x00028000 0x00028000 0x001000>, /* ap 29 */
<0x00029000 0x00029000 0x001000>, /* ap 30 */
<0x00032000 0x00032000 0x001000>, /* ap 31 */
<0x00033000 0x00033000 0x001000>, /* ap 32 */
<0x0003d000 0x0003d000 0x001000>, /* ap 33 */
<0x00041000 0x00041000 0x001000>, /* ap 34 */
<0x00042000 0x00042000 0x001000>, /* ap 35 */
<0x00043000 0x00043000 0x001000>, /* ap 36 */
<0x00014000 0x00014000 0x001000>, /* ap 37 */
<0x00015000 0x00015000 0x001000>; /* ap 38 */
target-module@c000 { /* 0x47c0c000, ap 3 04.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xc000 0x1000>;
};
target-module@e000 { /* 0x47c0e000, ap 5 0c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xe000 0x1000>;
};
target-module@10000 { /* 0x47c10000, ap 7 20.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x10000 0x1000>;
};
target-module@14000 { /* 0x47c14000, ap 37 3c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x14000 0x1000>;
};
target-module@1a000 { /* 0x47c1a000, ap 9 08.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1a000 0x1000>;
};
target-module@24000 { /* 0x47c24000, ap 11 28.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x24000 0x1000>;
};
target-module@26000 { /* 0x47c26000, ap 13 30.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x26000 0x1000>;
};
target-module@28000 { /* 0x47c28000, ap 29 40.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x28000 0x1000>;
};
target-module@30000 { /* 0x47c30000, ap 15 14.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x30000 0x1000>;
};
target-module@32000 { /* 0x47c32000, ap 31 06.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x32000 0x1000>;
};
target-module@38000 { /* 0x47c38000, ap 17 18.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x38000 0x1000>;
};
target-module@3a000 { /* 0x47c3a000, ap 19 1c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3a000 0x1000>;
};
target-module@3c000 { /* 0x47c3c000, ap 23 38.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3c000 0x1000>;
};
target-module@3e000 { /* 0x47c3e000, ap 21 10.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3e000 0x1000>;
};
target-module@40000 { /* 0x47c40000, ap 24 02.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x40000 0x1000>;
};
target-module@42000 { /* 0x47c42000, ap 35 34.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x42000 0x1000>;
};
target-module@44000 { /* 0x47c44000, ap 27 24.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x44000 0x1000>;
};
target-module@46000 { /* 0x47c46000, ap 25 2c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x46000 0x1000>;
};
};
};
&l4_fast { /* 0x4a000000 */
compatible = "ti,am33xx-l4-fast", "simple-bus";
reg = <0x4a000000 0x800>,
<0x4a000800 0x800>,
<0x4a001000 0x400>;
reg-names = "ap", "la", "ia0";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x4a000000 0x1000000>; /* segment 0 */
segment@0 { /* 0x4a000000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
<0x00000800 0x00000800 0x000800>, /* ap 1 */
<0x00001000 0x00001000 0x000400>, /* ap 2 */
<0x00100000 0x00100000 0x008000>, /* ap 3 */
<0x00108000 0x00108000 0x001000>, /* ap 4 */
<0x00180000 0x00180000 0x020000>, /* ap 5 */
<0x001a0000 0x001a0000 0x001000>, /* ap 6 */
<0x00200000 0x00200000 0x080000>, /* ap 7 */
<0x00280000 0x00280000 0x001000>, /* ap 8 */
<0x00300000 0x00300000 0x080000>, /* ap 9 */
<0x00380000 0x00380000 0x001000>; /* ap 10 */
target-module@100000 { /* 0x4a100000, ap 3 08.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4-simple", "ti,sysc";
reg = <0x101200 0x4>,
<0x101208 0x4>,
<0x101204 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <0>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>;
ti,syss-mask = <1>;
clocks = <&cpsw_125mhz_clkctrl AM3_CPSW_125MHZ_CPGMAC0_CLKCTRL 0>;
clock-names = "fck";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x100000 0x8000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
mac: ethernet@0 {
compatible = "ti,am335x-cpsw","ti,cpsw";
clocks = <&cpsw_125mhz_gclk>, <&cpsw_cpts_rft_clk>;
clock-names = "fck", "cpts";
cpdma_channels = <8>;
ale_entries = <1024>;
bd_ram_size = <0x2000>;
mac_control = <0x20>;
slaves = <2>;
active_slave = <0>;
cpts_clock_mult = <0x80000000>;
cpts_clock_shift = <29>;
reg = <0x0 0x800
0x1200 0x100>;
#address-cells = <1>;
#size-cells = <1>;
/*
* c0_rx_thresh_pend
* c0_rx_pend
* c0_tx_pend
* c0_misc_pend
*/
interrupts = <40 41 42 43>;
ranges = <0 0 0x8000>;
syscon = <&scm_conf>;
status = "disabled";
davinci_mdio: mdio@1000 {
compatible = "ti,cpsw-mdio","ti,davinci_mdio";
ARM: dts: Add fck for cpsw mdio for omap variants In preparation for dropping legacy platform data and custom ti,hwmods property, we need to make functional clock available for mdio for the SoCs so the the mdio driver can find it. The mdio hardware currently relies on a mdio_hwmod to manage the clock for omap variants. This is wrong though as there are no separate sysconfig registers for mdio. All the cpsw related components are just children of the gmac module. Note that since mdio is a child of cpsw, just doing pm_runtime_get() in the mdio driver enables the clock. However, since mdio is also used by davinci that does not implement runtime PM, let's just add the fck for now. Also note that am437x mdio already has a clock, let's update it to not use the legacy clock naming to unify things further. Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Cc: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 22:41:14 +07:00
clocks = <&cpsw_125mhz_clkctrl AM3_CPSW_125MHZ_CPGMAC0_CLKCTRL 0>;
clock-names = "fck";
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
#address-cells = <1>;
#size-cells = <0>;
bus_freq = <1000000>;
reg = <0x1000 0x100>;
status = "disabled";
};
cpsw_emac0: slave@200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
ARM: dts: am335x: switch to use phy-gmii-sel Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-02-20 22:25:17 +07:00
phys = <&phy_gmii_sel 1 1>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
};
cpsw_emac1: slave@300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
ARM: dts: am335x: switch to use phy-gmii-sel Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-02-20 22:25:17 +07:00
phys = <&phy_gmii_sel 2 1>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@180000 { /* 0x4a180000, ap 5 10.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x180000 0x20000>;
};
target-module@200000 { /* 0x4a200000, ap 7 02.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x200000 0x80000>;
};
ARM: dts: AM33xx-l4: Update PRUSS interconnect target-module node The PRU-ICSS present on some AM33xx SoCs has a very unique SYSC register. The IP also uses a hard-reset line, and requires this PRCM reset to be deasserted to be able to access any registers. Update the existing PRUSS interconnect target-module with all the required properties. The PRUSS device itself shall be added as a child node to this interconnect node in the future. PRU-ICSS is not supported on AM3351/AM3352/AM3354 SoCs though in the AM33xx family, so the target module node should be disabled in derivative board files that use any of these SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-28 05:28:35 +07:00
pruss_tm: target-module@300000 { /* 0x4a300000, ap 9 04.0 */
compatible = "ti,sysc-pruss", "ti,sysc";
reg = <0x326000 0x4>,
<0x326004 0x4>;
reg-names = "rev", "sysc";
ti,sysc-mask = <(SYSC_PRUSS_STANDBY_INIT |
SYSC_PRUSS_SUB_MWAIT)>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
clocks = <&pruss_ocp_clkctrl AM3_PRUSS_OCP_PRUSS_CLKCTRL 0>;
clock-names = "fck";
resets = <&prm_per 1>;
reset-names = "rstctrl";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x300000 0x80000>;
ARM: dts: AM33xx-l4: Update PRUSS interconnect target-module node The PRU-ICSS present on some AM33xx SoCs has a very unique SYSC register. The IP also uses a hard-reset line, and requires this PRCM reset to be deasserted to be able to access any registers. Update the existing PRUSS interconnect target-module with all the required properties. The PRUSS device itself shall be added as a child node to this interconnect node in the future. PRU-ICSS is not supported on AM3351/AM3352/AM3354 SoCs though in the AM33xx family, so the target module node should be disabled in derivative board files that use any of these SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-28 05:28:35 +07:00
status = "disabled";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
};
};
&l4_mpuss { /* 0x4b140000 */
compatible = "ti,am33xx-l4-mpuss", "simple-bus";
reg = <0x4b144400 0x100>,
<0x4b144800 0x400>;
reg-names = "la", "ap";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x4b140000 0x008000>; /* segment 0 */
segment@0 { /* 0x4b140000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00004800 0x00004800 0x000400>, /* ap 0 */
<0x00001000 0x00001000 0x001000>, /* ap 1 */
<0x00002000 0x00002000 0x001000>, /* ap 2 */
<0x00004000 0x00004000 0x000400>, /* ap 3 */
<0x00005000 0x00005000 0x000400>, /* ap 4 */
<0x00000000 0x00000000 0x001000>, /* ap 5 */
<0x00003000 0x00003000 0x001000>, /* ap 6 */
<0x00000800 0x00000800 0x000800>; /* ap 7 */
target-module@0 { /* 0x4b140000, ap 5 02.2 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x00001000>,
<0x00001000 0x00001000 0x00001000>,
<0x00002000 0x00002000 0x00001000>;
};
target-module@3000 { /* 0x4b143000, ap 6 04.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x3000 0x1000>;
};
};
};
&l4_per { /* 0x48000000 */
compatible = "ti,am33xx-l4-per", "simple-bus";
reg = <0x48000000 0x800>,
<0x48000800 0x800>,
<0x48001000 0x400>,
<0x48001400 0x400>,
<0x48001800 0x400>,
<0x48001c00 0x400>;
reg-names = "ap", "la", "ia0", "ia1", "ia2", "ia3";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x48000000 0x100000>, /* segment 0 */
<0x00100000 0x48100000 0x100000>, /* segment 1 */
<0x00200000 0x48200000 0x100000>, /* segment 2 */
ARM: dts: Add am335x mcasp with l3 data port ranges Earlier attempt to move am335x mcasp to probe with ti-sysc interconnect target module caused audio to stop working and and the dts changes were reverted by commit 5d2632a577ba ("ARM: dts: Revert am335x mcasp ti-sysc changes"). Turns out we were missing the l3 data port ranges for mcasp. This caused mcasp dma to attempt to use wrong port address. So let's try again essentially reverting the earlier revert and adding the missing l3 data port ranges. Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-06 05:08:37 +07:00
<0x00300000 0x48300000 0x100000>, /* segment 3 */
<0x46000000 0x46000000 0x400000>, /* l3 data port */
<0x46400000 0x46400000 0x400000>; /* l3 data port */
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
segment@0 { /* 0x48000000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
<0x00000800 0x00000800 0x000800>, /* ap 1 */
<0x00001000 0x00001000 0x000400>, /* ap 2 */
<0x00001400 0x00001400 0x000400>, /* ap 3 */
<0x00001800 0x00001800 0x000400>, /* ap 4 */
<0x00001c00 0x00001c00 0x000400>, /* ap 5 */
<0x00008000 0x00008000 0x001000>, /* ap 6 */
<0x00009000 0x00009000 0x001000>, /* ap 7 */
<0x00016000 0x00016000 0x001000>, /* ap 8 */
<0x00017000 0x00017000 0x001000>, /* ap 9 */
<0x00022000 0x00022000 0x001000>, /* ap 10 */
<0x00023000 0x00023000 0x001000>, /* ap 11 */
<0x00024000 0x00024000 0x001000>, /* ap 12 */
<0x00025000 0x00025000 0x001000>, /* ap 13 */
<0x0002a000 0x0002a000 0x001000>, /* ap 14 */
<0x0002b000 0x0002b000 0x001000>, /* ap 15 */
<0x00038000 0x00038000 0x002000>, /* ap 16 */
<0x0003a000 0x0003a000 0x001000>, /* ap 17 */
<0x00014000 0x00014000 0x001000>, /* ap 18 */
<0x00015000 0x00015000 0x001000>, /* ap 19 */
<0x0003c000 0x0003c000 0x002000>, /* ap 20 */
<0x0003e000 0x0003e000 0x001000>, /* ap 21 */
<0x00040000 0x00040000 0x001000>, /* ap 22 */
<0x00041000 0x00041000 0x001000>, /* ap 23 */
<0x00042000 0x00042000 0x001000>, /* ap 24 */
<0x00043000 0x00043000 0x001000>, /* ap 25 */
<0x00044000 0x00044000 0x001000>, /* ap 26 */
<0x00045000 0x00045000 0x001000>, /* ap 27 */
<0x00046000 0x00046000 0x001000>, /* ap 28 */
<0x00047000 0x00047000 0x001000>, /* ap 29 */
<0x00048000 0x00048000 0x001000>, /* ap 30 */
<0x00049000 0x00049000 0x001000>, /* ap 31 */
<0x0004c000 0x0004c000 0x001000>, /* ap 32 */
<0x0004d000 0x0004d000 0x001000>, /* ap 33 */
<0x00050000 0x00050000 0x002000>, /* ap 34 */
<0x00052000 0x00052000 0x001000>, /* ap 35 */
<0x00060000 0x00060000 0x001000>, /* ap 36 */
<0x00061000 0x00061000 0x001000>, /* ap 37 */
<0x00080000 0x00080000 0x010000>, /* ap 38 */
<0x00090000 0x00090000 0x001000>, /* ap 39 */
<0x000a0000 0x000a0000 0x010000>, /* ap 40 */
<0x000b0000 0x000b0000 0x001000>, /* ap 41 */
<0x00030000 0x00030000 0x001000>, /* ap 77 */
<0x00031000 0x00031000 0x001000>, /* ap 78 */
<0x0004a000 0x0004a000 0x001000>, /* ap 85 */
<0x0004b000 0x0004b000 0x001000>, /* ap 86 */
<0x000c8000 0x000c8000 0x001000>, /* ap 87 */
<0x000c9000 0x000c9000 0x001000>, /* ap 88 */
<0x000cc000 0x000cc000 0x001000>, /* ap 89 */
<0x000cd000 0x000cd000 0x001000>, /* ap 90 */
<0x000ca000 0x000ca000 0x001000>, /* ap 91 */
ARM: dts: Add am335x mcasp with l3 data port ranges Earlier attempt to move am335x mcasp to probe with ti-sysc interconnect target module caused audio to stop working and and the dts changes were reverted by commit 5d2632a577ba ("ARM: dts: Revert am335x mcasp ti-sysc changes"). Turns out we were missing the l3 data port ranges for mcasp. This caused mcasp dma to attempt to use wrong port address. So let's try again essentially reverting the earlier revert and adding the missing l3 data port ranges. Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-06 05:08:37 +07:00
<0x000cb000 0x000cb000 0x001000>, /* ap 92 */
<0x46000000 0x46000000 0x400000>, /* l3 data port */
<0x46400000 0x46400000 0x400000>; /* l3 data port */
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
target-module@8000 { /* 0x48008000, ap 6 10.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x8000 0x1000>;
};
target-module@14000 { /* 0x48014000, ap 18 58.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x14000 0x1000>;
};
target-module@16000 { /* 0x48016000, ap 8 3c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x16000 0x1000>;
};
target-module@22000 { /* 0x48022000, ap 10 12.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x22050 0x4>,
<0x22054 0x4>,
<0x22058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_UART2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x22000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart1: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <73>;
status = "disabled";
dmas = <&edma 28 0>, <&edma 29 0>;
dma-names = "tx", "rx";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@24000 { /* 0x48024000, ap 12 14.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x24050 0x4>,
<0x24054 0x4>,
<0x24058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_UART3_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x24000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart2: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <74>;
status = "disabled";
dmas = <&edma 30 0>, <&edma 31 0>;
dma-names = "tx", "rx";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@2a000 { /* 0x4802a000, ap 14 2a.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x2a000 0x8>,
<0x2a010 0x8>,
<0x2a090 0x8>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_I2C2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2a000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
i2c1: i2c@0 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x1000>;
interrupts = <71>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@30000 { /* 0x48030000, ap 77 08.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x30000 0x4>,
<0x30110 0x4>,
<0x30114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_SPI0_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x30000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
spi0: spi@0 {
compatible = "ti,omap4-mcspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x400>;
interrupts = <65>;
ti,spi-num-cs = <2>;
dmas = <&edma 16 0
&edma 17 0
&edma 18 0
&edma 19 0>;
dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@38000 { /* 0x48038000, ap 16 02.0 */
compatible = "ti,sysc-omap4-simple", "ti,sysc";
reg = <0x38000 0x4>,
<0x38004 0x4>;
reg-names = "rev", "sysc";
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): per_pwrdm, l3s_clkdm */
clocks = <&l3s_clkctrl AM3_L3S_MCASP0_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ARM: dts: Add am335x mcasp with l3 data port ranges Earlier attempt to move am335x mcasp to probe with ti-sysc interconnect target module caused audio to stop working and and the dts changes were reverted by commit 5d2632a577ba ("ARM: dts: Revert am335x mcasp ti-sysc changes"). Turns out we were missing the l3 data port ranges for mcasp. This caused mcasp dma to attempt to use wrong port address. So let's try again essentially reverting the earlier revert and adding the missing l3 data port ranges. Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-06 05:08:37 +07:00
ranges = <0x0 0x38000 0x2000>,
<0x46000000 0x46000000 0x400000>;
mcasp0: mcasp@0 {
compatible = "ti,am33xx-mcasp-audio";
reg = <0x0 0x2000>,
<0x46000000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <80>, <81>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 8 2>,
<&edma 9 2>;
dma-names = "tx", "rx";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@3c000 { /* 0x4803c000, ap 20 32.0 */
compatible = "ti,sysc-omap4-simple", "ti,sysc";
reg = <0x3c000 0x4>,
<0x3c004 0x4>;
reg-names = "rev", "sysc";
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): per_pwrdm, l3s_clkdm */
clocks = <&l3s_clkctrl AM3_L3S_MCASP1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ARM: dts: Add am335x mcasp with l3 data port ranges Earlier attempt to move am335x mcasp to probe with ti-sysc interconnect target module caused audio to stop working and and the dts changes were reverted by commit 5d2632a577ba ("ARM: dts: Revert am335x mcasp ti-sysc changes"). Turns out we were missing the l3 data port ranges for mcasp. This caused mcasp dma to attempt to use wrong port address. So let's try again essentially reverting the earlier revert and adding the missing l3 data port ranges. Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-06 05:08:37 +07:00
ranges = <0x0 0x3c000 0x2000>,
<0x46400000 0x46400000 0x400000>;
mcasp1: mcasp@0 {
compatible = "ti,am33xx-mcasp-audio";
reg = <0x0 0x2000>,
<0x46400000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <82>, <83>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 10 2>,
<&edma 11 2>;
dma-names = "tx", "rx";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@40000 { /* 0x48040000, ap 22 1e.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
ti,hwmods = "timer2";
reg = <0x40000 0x4>,
<0x40010 0x4>,
<0x40014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x40000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer2: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <68>;
clocks = <&timer2_fck>;
clock-names = "fck";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@42000 { /* 0x48042000, ap 24 1c.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x42000 0x4>,
<0x42010 0x4>,
<0x42014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER3_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x42000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer3: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <69>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@44000 { /* 0x48044000, ap 26 26.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x44000 0x4>,
<0x44010 0x4>,
<0x44014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER4_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x44000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer4: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <92>;
ti,timer-pwm;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@46000 { /* 0x48046000, ap 28 28.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x46000 0x4>,
<0x46010 0x4>,
<0x46014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER5_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x46000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer5: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <93>;
ti,timer-pwm;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@48000 { /* 0x48048000, ap 30 22.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x48000 0x4>,
<0x48010 0x4>,
<0x48014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER6_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x48000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer6: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <94>;
ti,timer-pwm;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@4a000 { /* 0x4804a000, ap 85 60.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x4a000 0x4>,
<0x4a010 0x4>,
<0x4a014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_TIMER7_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x4a000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
timer7: timer@0 {
compatible = "ti,am335x-timer";
reg = <0x0 0x400>;
interrupts = <95>;
ti,timer-pwm;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@4c000 { /* 0x4804c000, ap 32 36.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x4c000 0x4>,
<0x4c010 0x4>,
<0x4c114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_GPIO2_CLKCTRL 0>,
<&l4ls_clkctrl AM3_L4LS_GPIO2_CLKCTRL 18>;
clock-names = "fck", "dbclk";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x4c000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
gpio1: gpio@0 {
compatible = "ti,omap4-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x1000>;
interrupts = <98>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@50000 { /* 0x48050000, ap 34 2c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x50000 0x2000>;
};
target-module@60000 { /* 0x48060000, ap 36 0c.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x602fc 0x4>,
<0x60110 0x4>,
<0x60114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_MMC1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x60000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
mmc1: mmc@0 {
compatible = "ti,omap4-hsmmc";
ti,dual-volt;
ti,needs-special-reset;
ti,needs-special-hs-handling;
dmas = <&edma_xbar 24 0 0
&edma_xbar 25 0 0>;
dma-names = "tx", "rx";
interrupts = <64>;
reg = <0x0 0x1000>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@80000 { /* 0x48080000, ap 38 18.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x80000 0x4>,
<0x80010 0x4>,
<0x80014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_ELM_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x80000 0x10000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
elm: elm@0 {
compatible = "ti,am3352-elm";
reg = <0x0 0x2000>;
interrupts = <4>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@a0000 { /* 0x480a0000, ap 40 5e.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa0000 0x10000>;
};
target-module@c8000 { /* 0x480c8000, ap 87 06.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0xc8000 0x4>,
<0xc8010 0x4>;
reg-names = "rev", "sysc";
ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_MAILBOX_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xc8000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
mailbox: mailbox@0 {
compatible = "ti,omap4-mailbox";
reg = <0x0 0x200>;
interrupts = <77>;
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <8>;
mbox_wkupm3: wkup_m3 {
ti,mbox-send-noirq;
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@ca000 { /* 0x480ca000, ap 91 40.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xca000 0x4>,
<0xca010 0x4>,
<0xca014 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_SPINLOCK_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xca000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
hwspinlock: spinlock@0 {
compatible = "ti,omap4-hwspinlock";
reg = <0x0 0x1000>;
#hwlock-cells = <1>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@cc000 { /* 0x480cc000, ap 89 0e.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xcc000 0x1000>;
};
};
segment@100000 { /* 0x48100000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0008c000 0x0018c000 0x001000>, /* ap 42 */
<0x0008d000 0x0018d000 0x001000>, /* ap 43 */
<0x0008e000 0x0018e000 0x001000>, /* ap 44 */
<0x0008f000 0x0018f000 0x001000>, /* ap 45 */
<0x0009c000 0x0019c000 0x001000>, /* ap 46 */
<0x0009d000 0x0019d000 0x001000>, /* ap 47 */
<0x000a6000 0x001a6000 0x001000>, /* ap 48 */
<0x000a7000 0x001a7000 0x001000>, /* ap 49 */
<0x000a8000 0x001a8000 0x001000>, /* ap 50 */
<0x000a9000 0x001a9000 0x001000>, /* ap 51 */
<0x000aa000 0x001aa000 0x001000>, /* ap 52 */
<0x000ab000 0x001ab000 0x001000>, /* ap 53 */
<0x000ac000 0x001ac000 0x001000>, /* ap 54 */
<0x000ad000 0x001ad000 0x001000>, /* ap 55 */
<0x000ae000 0x001ae000 0x001000>, /* ap 56 */
<0x000af000 0x001af000 0x001000>, /* ap 57 */
<0x000b0000 0x001b0000 0x010000>, /* ap 58 */
<0x000c0000 0x001c0000 0x001000>, /* ap 59 */
<0x000cc000 0x001cc000 0x002000>, /* ap 60 */
<0x000ce000 0x001ce000 0x002000>, /* ap 61 */
<0x000d0000 0x001d0000 0x002000>, /* ap 62 */
<0x000d2000 0x001d2000 0x002000>, /* ap 63 */
<0x000d8000 0x001d8000 0x001000>, /* ap 64 */
<0x000d9000 0x001d9000 0x001000>, /* ap 65 */
<0x000a0000 0x001a0000 0x001000>, /* ap 79 */
<0x000a1000 0x001a1000 0x001000>, /* ap 80 */
<0x000a2000 0x001a2000 0x001000>, /* ap 81 */
<0x000a3000 0x001a3000 0x001000>, /* ap 82 */
<0x000a4000 0x001a4000 0x001000>, /* ap 83 */
<0x000a5000 0x001a5000 0x001000>; /* ap 84 */
target-module@8c000 { /* 0x4818c000, ap 42 04.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x8c000 0x1000>;
};
target-module@8e000 { /* 0x4818e000, ap 44 0a.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x8e000 0x1000>;
};
target-module@9c000 { /* 0x4819c000, ap 46 5a.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x9c000 0x8>,
<0x9c010 0x8>,
<0x9c090 0x8>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_I2C3_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x9c000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
i2c2: i2c@0 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x1000>;
interrupts = <30>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@a0000 { /* 0x481a0000, ap 79 24.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xa0000 0x4>,
<0xa0110 0x4>,
<0xa0114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_SPI1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa0000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
spi1: spi@0 {
compatible = "ti,omap4-mcspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x400>;
interrupts = <125>;
ti,spi-num-cs = <2>;
dmas = <&edma 42 0
&edma 43 0
&edma 44 0
&edma 45 0>;
dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@a2000 { /* 0x481a2000, ap 81 2e.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa2000 0x1000>;
};
target-module@a4000 { /* 0x481a4000, ap 83 30.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa4000 0x1000>;
};
target-module@a6000 { /* 0x481a6000, ap 48 16.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xa6050 0x4>,
<0xa6054 0x4>,
<0xa6058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_UART4_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa6000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart3: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <44>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@a8000 { /* 0x481a8000, ap 50 20.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xa8050 0x4>,
<0xa8054 0x4>,
<0xa8058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_UART5_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xa8000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart4: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <45>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@aa000 { /* 0x481aa000, ap 52 1a.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xaa050 0x4>,
<0xaa054 0x4>,
<0xaa058 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_UART6_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xaa000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
uart5: serial@0 {
compatible = "ti,am3352-uart", "ti,omap3-uart";
clock-frequency = <48000000>;
ARM: dts: am335x: Fix UARTs length As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-24 19:23:29 +07:00
reg = <0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
interrupts = <46>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@ac000 { /* 0x481ac000, ap 54 38.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xac000 0x4>,
<0xac010 0x4>,
<0xac114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_GPIO3_CLKCTRL 0>,
<&l4ls_clkctrl AM3_L4LS_GPIO3_CLKCTRL 18>;
clock-names = "fck", "dbclk";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xac000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
gpio2: gpio@0 {
compatible = "ti,omap4-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x1000>;
interrupts = <32>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@ae000 { /* 0x481ae000, ap 56 3a.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xae000 0x4>,
<0xae010 0x4>,
<0xae114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_GPIO4_CLKCTRL 0>,
<&l4ls_clkctrl AM3_L4LS_GPIO4_CLKCTRL 18>;
clock-names = "fck", "dbclk";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xae000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
gpio3: gpio@0 {
compatible = "ti,omap4-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x1000>;
interrupts = <62>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@b0000 { /* 0x481b0000, ap 58 50.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xb0000 0x10000>;
};
target-module@cc000 { /* 0x481cc000, ap 60 46.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4", "ti,sysc";
ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 We are currently using a wrong register for dcan revision. Although this is currently only used for detecting the dcan module, let's fix it to avoid confusion. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-22 17:44:42 +07:00
reg = <0xcc020 0x4>;
reg-names = "rev";
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
ARM: dts: Configure osc clock for d_can on am335x Reading the module revision register can cause an external abort on non-linefetch depending of osc clock is not already enabled. This started happening with commit 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision") as reported by Sebastian Andrzej Siewior <bigeasy@linutronix.de>. The reason why the issue happens is because we now attempt to read the interconnect target module revision register by first manually enabling all the device clocks in sysc_probe(). And looks like d_can also needs the osc clock in addition to the module clock, and it may or may not be enabled depending on the bootloader version and if other devices have already requested osc clock. Let's fix the issue by adding osc clock as an optional clock for the module for am335x. Note that am437x does not seem to list the osc clock at all, so presumably it is not needed for am437x. I also noticed that we're incorrectly assuming the revision register for d_can exists. But the module does not seem to have any revision, sysconfig or sysstatus registers. But that's mostly a cosmetic issues, so I'll send a patch separately for that. Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision") Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-02 04:24:09 +07:00
clocks = <&l4ls_clkctrl AM3_L4LS_D_CAN0_CLKCTRL 0>,
<&dcan0_fck>;
clock-names = "fck", "osc";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xcc000 0x2000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
dcan0: can@0 {
compatible = "ti,am3352-d_can";
reg = <0x0 0x2000>;
clocks = <&dcan0_fck>;
clock-names = "fck";
syscon-raminit = <&scm_conf 0x644 0>;
interrupts = <52>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@d0000 { /* 0x481d0000, ap 62 42.0 */
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,sysc-omap4", "ti,sysc";
ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 We are currently using a wrong register for dcan revision. Although this is currently only used for detecting the dcan module, let's fix it to avoid confusion. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-07-22 17:44:42 +07:00
reg = <0xd0020 0x4>;
reg-names = "rev";
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
ARM: dts: Configure osc clock for d_can on am335x Reading the module revision register can cause an external abort on non-linefetch depending of osc clock is not already enabled. This started happening with commit 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision") as reported by Sebastian Andrzej Siewior <bigeasy@linutronix.de>. The reason why the issue happens is because we now attempt to read the interconnect target module revision register by first manually enabling all the device clocks in sysc_probe(). And looks like d_can also needs the osc clock in addition to the module clock, and it may or may not be enabled depending on the bootloader version and if other devices have already requested osc clock. Let's fix the issue by adding osc clock as an optional clock for the module for am335x. Note that am437x does not seem to list the osc clock at all, so presumably it is not needed for am437x. I also noticed that we're incorrectly assuming the revision register for d_can exists. But the module does not seem to have any revision, sysconfig or sysstatus registers. But that's mostly a cosmetic issues, so I'll send a patch separately for that. Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision") Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-02 04:24:09 +07:00
clocks = <&l4ls_clkctrl AM3_L4LS_D_CAN1_CLKCTRL 0>,
<&dcan1_fck>;
clock-names = "fck", "osc";
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xd0000 0x2000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
dcan1: can@0 {
compatible = "ti,am3352-d_can";
reg = <0x0 0x2000>;
clocks = <&dcan1_fck>;
clock-names = "fck";
syscon-raminit = <&scm_conf 0x644 1>;
interrupts = <55>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@d8000 { /* 0x481d8000, ap 64 66.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0xd82fc 0x4>,
<0xd8110 0x4>,
<0xd8114 0x4>;
reg-names = "rev", "sysc", "syss";
ti,sysc-mask = <(SYSC_OMAP2_CLOCKACTIVITY |
SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,syss-mask = <1>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_MMC2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xd8000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
mmc2: mmc@0 {
compatible = "ti,omap4-hsmmc";
ti,needs-special-reset;
dmas = <&edma 2 0
&edma 3 0>;
dma-names = "tx", "rx";
interrupts = <28>;
reg = <0x0 0x1000>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
};
segment@200000 { /* 0x48200000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
};
segment@300000 { /* 0x48300000 */
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00300000 0x001000>, /* ap 66 */
<0x00001000 0x00301000 0x001000>, /* ap 67 */
<0x00002000 0x00302000 0x001000>, /* ap 68 */
<0x00003000 0x00303000 0x001000>, /* ap 69 */
<0x00004000 0x00304000 0x001000>, /* ap 70 */
<0x00005000 0x00305000 0x001000>, /* ap 71 */
<0x0000e000 0x0030e000 0x001000>, /* ap 72 */
<0x0000f000 0x0030f000 0x001000>, /* ap 73 */
<0x00018000 0x00318000 0x004000>, /* ap 74 */
<0x0001c000 0x0031c000 0x001000>, /* ap 75 */
<0x00010000 0x00310000 0x002000>, /* ap 76 */
<0x00012000 0x00312000 0x001000>, /* ap 93 */
<0x00015000 0x00315000 0x001000>, /* ap 94 */
<0x00016000 0x00316000 0x001000>, /* ap 95 */
<0x00017000 0x00317000 0x001000>, /* ap 96 */
<0x00013000 0x00313000 0x001000>, /* ap 97 */
<0x00014000 0x00314000 0x001000>, /* ap 98 */
<0x00020000 0x00320000 0x001000>, /* ap 99 */
<0x00021000 0x00321000 0x001000>, /* ap 100 */
<0x00022000 0x00322000 0x001000>, /* ap 101 */
<0x00023000 0x00323000 0x001000>, /* ap 102 */
<0x00024000 0x00324000 0x001000>, /* ap 103 */
<0x00025000 0x00325000 0x001000>; /* ap 104 */
target-module@0 { /* 0x48300000, ap 66 48.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x0 0x4>,
<0x4 0x4>;
reg-names = "rev", "sysc";
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS0_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
epwmss0: epwmss@0 {
compatible = "ti,am33xx-pwmss";
reg = <0x0 0x10>;
#address-cells = <1>;
#size-cells = <1>;
status = "disabled";
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ranges = <0 0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ecap0: ecap@100 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ecap",
"ti,am33xx-ecap";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x100 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&l4ls_gclk>;
clock-names = "fck";
interrupts = <31>;
interrupt-names = "ecap0";
status = "disabled";
};
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ehrpwm0: pwm@200 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x200 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&ehrpwm0_tbclk>, <&l4ls_gclk>;
clock-names = "tbclk", "fck";
status = "disabled";
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@2000 { /* 0x48302000, ap 68 52.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x2000 0x4>,
<0x2004 0x4>;
reg-names = "rev", "sysc";
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS1_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
epwmss1: epwmss@0 {
compatible = "ti,am33xx-pwmss";
reg = <0x0 0x10>;
#address-cells = <1>;
#size-cells = <1>;
status = "disabled";
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ranges = <0 0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ecap1: ecap@100 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ecap",
"ti,am33xx-ecap";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x100 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&l4ls_gclk>;
clock-names = "fck";
interrupts = <47>;
interrupt-names = "ecap1";
status = "disabled";
};
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ehrpwm1: pwm@200 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x200 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&ehrpwm1_tbclk>, <&l4ls_gclk>;
clock-names = "tbclk", "fck";
status = "disabled";
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@4000 { /* 0x48304000, ap 70 44.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x4000 0x4>,
<0x4004 0x4>;
reg-names = "rev", "sysc";
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS2_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x4000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
epwmss2: epwmss@0 {
compatible = "ti,am33xx-pwmss";
reg = <0x0 0x10>;
#address-cells = <1>;
#size-cells = <1>;
status = "disabled";
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ranges = <0 0 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ecap2: ecap@100 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ecap",
"ti,am33xx-ecap";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x100 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&l4ls_gclk>;
clock-names = "fck";
interrupts = <61>;
interrupt-names = "ecap2";
status = "disabled";
};
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
ehrpwm2: pwm@200 {
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
#pwm-cells = <3>;
ARM: dts: Fix ranges for am335x epwmss Looks like I missed the ranges for am335x epwmss. Let's set it up the same way as for am437x and dra7. Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc") Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-12-11 04:43:11 +07:00
reg = <0x200 0x80>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
clocks = <&ehrpwm2_tbclk>, <&l4ls_gclk>;
clock-names = "tbclk", "fck";
status = "disabled";
};
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@e000 { /* 0x4830e000, ap 72 4a.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0xe000 0x4>,
<0xe054 0x4>;
reg-names = "rev", "sysc";
ARM: OMAP2+: Add missing LCDC midlemode for am335x TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both standbymode and idlemode that should be just the sidle and midle registers where midle is currently unconfigured for lcdc_sysc. As the dts data has been generated based on lcdc_sysc, we now have an empty "ti,sysc-midle" property. And so we currently get a warning for lcdc because of a difference with dts provided configuration compared to the legacy platform data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in the platform data without configuring the modes. Let's fix the issue by adding the missing midlemode to lcdc_sysc, and configuring the "ti,sysc-midle" property based on the TRM values. Fixes: f711c575cfec ("ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data") Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Robert Nelson <robertcnelson@gmail.com> Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-09-24 23:25:51 +07:00
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
/* Domains (P, C): per_pwrdm, lcdc_clkdm */
clocks = <&lcdc_clkctrl AM3_LCDC_LCDC_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xe000 0x1000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
lcdc: lcdc@0 {
compatible = "ti,am33xx-tilcdc";
reg = <0x0 0x1000>;
interrupts = <36>;
status = "disabled";
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@10000 { /* 0x48310000, ap 76 4e.1 */
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x11fe0 0x4>,
<0x11fe4 0x4>;
reg-names = "rev", "sysc";
ti,sysc-mask = <SYSC_OMAP2_AUTOIDLE>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>;
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_RNG_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x10000 0x2000>;
ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc With l4 interconnect hierarchy and ti-sysc interconnect target module data in place, we can simply move all the related child devices to their proper location and enable probing using ti-sysc. In general the first child device address range starts at range 0 from the ti-sysc interconnect target so the move involves adjusting the child device reg properties for that. In case of any regressions, problem devices can be reverted to probe with legacy platform data as needed by moving them back and removing the related interconnect target module node. Note that we are not yet moving dss or wkup_m3, those will be moved later after some related driver changes. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:54 +07:00
rng: rng@0 {
compatible = "ti,omap4-rng";
reg = <0x0 0x2000>;
interrupts = <111>;
};
ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data Similar to commit 8f42cb7f64c7 ("ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data"), let's add proper interconnect hierarchy for l4 interconnect instances with the related ti-sysc interconnect module data as in Documentation/devicetree/bindings/bus/ti-sysc.txt. Using ti-sysc driver binding allows us to start dropping legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c files later on in favor of ti-sysc dts data. This data is generated based on platform data from a booted system and the interconnect acces protection registers for ranges. To avoid regressions, we initially validate the device tree provided data against the existing platform data on boot. Note that we cannot yet include this file from the SoC dtsi file until the child devices are moved to their proper locations in the interconnect hierarchy in the following patch. Otherwise we would have the each module probed twice. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2018-09-25 06:20:37 +07:00
};
target-module@13000 { /* 0x48313000, ap 97 62.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x13000 0x1000>;
};
target-module@15000 { /* 0x48315000, ap 94 56.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00015000 0x00001000>,
<0x00001000 0x00016000 0x00001000>;
};
target-module@18000 { /* 0x48318000, ap 74 4c.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x18000 0x4000>;
};
target-module@20000 { /* 0x48320000, ap 99 34.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x20000 0x1000>;
};
target-module@22000 { /* 0x48322000, ap 101 3e.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x22000 0x1000>;
};
target-module@24000 { /* 0x48324000, ap 103 68.0 */
compatible = "ti,sysc";
status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x24000 0x1000>;
};
};
};
Reference in New Issue Copy Permalink