Hi Tony,
The following series adds the ti-sysc support for the PRUSS IP present
on some AM33xx, AM437x and AM57xx SoCs. This series is a revamped and
more complete version of the previous attempt [1] made last year and
includes support for AM33xx and AM437x now that the reset dependencies
are fully upstream. The OCP master ports are not enabled by default
now, and the ti-sysc bus driver only handles the important quirk needed
for suspend/resume on AM33xx and AM437x SoCs.
The series includes patches for both the ti-sysc bindings and the bus
driver, along with all the DTS nodes. Patches are based on 5.6-rc1. The
dts nodes can be added added independently of the corresponding hwmod
cleanup [2]. This forms the foundation before the rest of the PRUSS
platform drivers can be added. Please consider the series for 5.7, and
I can post the PRUSS platform driver and/or PRUSS INTC driver for 5.8.
The integration of the IP is different on different SoC families, and
following are some differences:
1. AM33xx and AM437x SoCs need a PRCM reset line to be deasserted as well
to be able to access any PRUSS registers.
2. AM437x has two PRUSS instances, with the smaller PRU-ICSS0 connected
through the larger PRU-ICSS1. There is only a single interconnect target
node added. AM57xx has no reset lines,
and only requires the module to be enabled.
3. AM57xx has two identical instances, but do not require any reset lines.
4. PRUSS is present only on some SoCs on each SoC family:
- AM3356 and above SoCs on AM335x family
- AM4376 and above SoCs on AM437x family
- AM57xx SoCs only; not supported on DRA7xx SoCs.
The sanity testing can be done by turning on the power through the sysfs for
now. These will be taken care of automatically when the PRUSS platform driver
will invoke the pm_runtime_get_sync() and put_sync() as the PRUSS nodes will
be children of the ti-sysc interconnect nodes.
1. AM335x
echo on > /sys/bus/platform/devices/4a326000.target-module/power/control
2. AM437x
echo on > /sys/bus/platform/devices/54426000.target-module/power/control
3. AM57xx
echo on > /sys/bus/platform/devices/4b226000.target-module/power/control
echo on > /sys/bus/platform/devices/4b2a6000.target-module/power/control
Here are the version numbers from the CFG sub-module on these IPs that are
used for the ti-sysc quirks:
AM335x : 0x47000000
AM437x PRUSS1 : 0x47000200
AM437x PRUSS0 : 0x47010100
AM57xx PRUSS0 & PRUSS1 : 0x47000201
regards
Suman
[1] https://patchwork.kernel.org/cover/10796015/
[2] https://patchwork.kernel.org/cover/11402083/
Roger Quadros (1):
dt-bindings: bus: ti-sysc: Add support for PRUSS SYSC type
Suman Anna (11):
bus: ti-sysc: Add support for PRUSS SYSC type
ARM: dts: AM33xx-l4: Update PRUSS interconnect target-module node
ARM: dts: AM4372: Add the PRU-ICSS interconnect target-module node
ARM: dts: dra7: Add PRU-ICSS interconnect target-module nodes
ARM: dts: am335x-bone-common: Enable PRU-ICSS interconnect node
ARM: dts: am335x-evm: Enable PRU-ICSS interconnect node
ARM: dts: am335x-evmsk: Enable PRU-ICSS interconnect node
ARM: dts: am335x-icev2: Enable PRU-ICSS interconnect node
ARM: dts: am437x-gp-evm: Enable PRU-ICSS interconnect node
ARM: dts: am437x-sk: Enable PRU-ICSS interconnect node
ARM: dts: am437x-idk: Enable PRU-ICSS interconnect node
.../devicetree/bindings/bus/ti-sysc.txt | 1 +
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++
arch/arm/boot/dts/am335x-evm.dts | 4 ++
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++
arch/arm/boot/dts/am335x-icev2.dts | 4 ++
arch/arm/boot/dts/am33xx-l4.dtsi | 21 ++++++--
arch/arm/boot/dts/am4372.dtsi | 23 +++++++++
arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++
arch/arm/boot/dts/am437x-idk-evm.dts | 4 ++
arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++
arch/arm/boot/dts/am57-pruss.dtsi | 50 +++++++++++++++++++
arch/arm/boot/dts/am5718.dtsi | 1 +
arch/arm/boot/dts/am5728.dtsi | 1 +
arch/arm/boot/dts/am5748.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 2 +-
drivers/bus/ti-sysc.c | 27 ++++++++++
include/dt-bindings/bus/ti-sysc.h | 4 ++
include/linux/platform_data/ti-sysc.h | 2 +
18 files changed, 157 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/am57-pruss.dtsi
--
2.23.0
The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x SK
EVM board, so enable this node to support PRUSS on this board.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 32f515a295ee..f0dd66649877 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -717,3 +717,7 @@
clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The AM437x IDK EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS target module node was left in disabled state
in the base am4372.dtsi file. Enable the PRU-ICSS target module node
on this board.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am437x-idk-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts
index f3ced6df0c9b..380fbb52ebd4 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -534,3 +534,7 @@
opp-suspend;
};
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The PRU-ICSS present on AM33xx/AM43xx/AM57xx has a very unique
SYSCFG register. The register follows the OMAP4-style SYSC_TYPE3
for Master Standby and Slave Idle, but also has two additional
unique fields - STANDBY_INIT and SUB_MWAIT. The STANDBY_INIT is
a control bit that is used to initiate a Standby sequence (when
set) and trigger a MStandby request to the SoC's PRCM module. This
same bit is also used to enable the OCP master ports (when cleared)
to allow the PRU cores to access any peripherals or memory beyond
the PRU subsystem. The SUB_MWAIT is a ready status field for the
external access.
Add support for this SYSC type. The STANDBY_INIT has to be set
during suspend, without which it results in a hang in the resume
sequence on AM33xx/AM43xx boards and requires a board reset to
come out of the hang. Any PRU applications requiring external
access are supposed to clear the STANDBY_INIT bit. Note that
the PRUSS context is lost during a suspend sequence because the
PRUSS module is reset and/or disabled.
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
---
drivers/bus/ti-sysc.c | 27 +++++++++++++++++++++++++++
include/linux/platform_data/ti-sysc.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index f702c85c81b6..855f851e99be 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1272,6 +1272,9 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = {
SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_SWSUP_MSTANDBY),
SYSC_QUIRK("wdt", 0, 0, 0x10, 0x14, 0x502a0500, 0xfffff0f0,
SYSC_MODULE_QUIRK_WDT),
+ /* PRUSS on am3, am4 and am5 */
+ SYSC_QUIRK("pruss", 0, 0x26000, 0x26004, -1, 0x47000000, 0xff000000,
+ SYSC_MODULE_QUIRK_PRUSS),
/* Watchdog on am3 and am4 */
SYSC_QUIRK("wdt", 0x44e35000, 0, 0x10, 0x14, 0x502a0500, 0xfffff0f0,
SYSC_MODULE_QUIRK_WDT | SYSC_QUIRK_SWSUP_SIDLE),
@@ -1482,6 +1485,16 @@ static void sysc_reset_done_quirk_wdt(struct sysc *ddata)
dev_warn(ddata->dev, "wdt disable step2 failed\n");
}
+/* PRUSS needs to set MSTANDBY_INIT inorder to idle properly */
+static void sysc_module_disable_quirk_pruss(struct sysc *ddata)
+{
+ u32 reg;
+
+ reg = sysc_read(ddata, ddata->offsets[SYSC_SYSCONFIG]);
+ reg |= SYSC_PRUSS_STANDBY_INIT;
+ sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
+}
+
static void sysc_init_module_quirks(struct sysc *ddata)
{
if (ddata->legacy_mode || !ddata->name)
@@ -1510,6 +1523,9 @@ static void sysc_init_module_quirks(struct sysc *ddata)
ddata->reset_done_quirk = sysc_reset_done_quirk_wdt;
ddata->module_disable_quirk = sysc_reset_done_quirk_wdt;
}
+
+ if (ddata->cfg.quirks & SYSC_MODULE_QUIRK_PRUSS)
+ ddata->module_disable_quirk = sysc_module_disable_quirk_pruss;
}
static int sysc_clockdomain_init(struct sysc *ddata)
@@ -2313,6 +2329,16 @@ static const struct sysc_capabilities sysc_dra7_mcan = {
.mod_quirks = SYSS_QUIRK_RESETDONE_INVERTED,
};
+/*
+ * PRUSS found on some AM33xx, AM437x and AM57xx SoCs
+ */
+static const struct sysc_capabilities sysc_pruss = {
+ .type = TI_SYSC_PRUSS,
+ .sysc_mask = SYSC_PRUSS_STANDBY_INIT | SYSC_PRUSS_SUB_MWAIT,
+ .regbits = &sysc_regbits_omap4_simple,
+ .mod_quirks = SYSC_MODULE_QUIRK_PRUSS,
+};
+
static int sysc_init_pdata(struct sysc *ddata)
{
struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
@@ -2538,6 +2564,7 @@ static const struct of_device_id sysc_match[] = {
{ .compatible = "ti,sysc-usb-host-fs",
.data = &sysc_omap4_usb_host_fs, },
{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
+ { .compatible = "ti,sysc-pruss", .data = &sysc_pruss, },
{ },
};
MODULE_DEVICE_TABLE(of, sysc_match);
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
index 2cbde6542849..b04575fb9f73 100644
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -17,6 +17,7 @@ enum ti_sysc_module_type {
TI_SYSC_OMAP4_MCASP,
TI_SYSC_OMAP4_USB_HOST_FS,
TI_SYSC_DRA7_MCAN,
+ TI_SYSC_PRUSS,
};
struct ti_sysc_cookie {
@@ -49,6 +50,7 @@ struct sysc_regbits {
s8 emufree_shift;
};
+#define SYSC_MODULE_QUIRK_PRUSS BIT(22)
#define SYSC_QUIRK_CLKDM_NOAUTO BIT(21)
#define SYSC_QUIRK_FORCE_MSTANDBY BIT(20)
#define SYSC_MODULE_QUIRK_AESS BIT(19)
--
2.23.0
The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x EVM,
so enable this node on the AM335x EVM.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 68252dab32c3..e8c0ae0ccbef 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -776,3 +776,7 @@
clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The AM437x SK EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS target module node was left in disabled state
in the base am4372.dtsi file. Enable the PRU-ICSS target module node
on this board.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 25222497f828..9fafb01e0521 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -910,3 +910,7 @@
};
};
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The AM437x GP EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS target module node was left in disabled state
in the base am4372.dtsi file. Enable the PRU-ICSS target module node
on this board.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 811c8cae315b..537686688a8b 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -1128,3 +1128,7 @@
&cpu {
cpu0-supply = <&dcdc2>;
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The PRU-ICSS target module node was left in disabled state in the base
am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
boards as they mostly use a AM3358 or a AM3359 SoC which do contain
the PRU-ICSS IP.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6c9187bc0f17..e507ef74d8e6 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -397,3 +397,7 @@
clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x ICEv2
board, so enable this node to support PRUSS on this board.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am335x-icev2.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-icev2.dts b/arch/arm/boot/dts/am335x-icev2.dts
index 021eb57261fe..83b4bd91a44c 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -510,3 +510,7 @@
reg = <3>;
};
};
+
+&pruss_tm {
+ status = "okay";
+};
--
2.23.0
The AM57xx family of SoCs contains two identical PRU-ICSS instances
that have a very unique SYSC register. The IPs do not have any
PRCM reset lines unlike those on AM33xx/AM437x SoCs. Add the PRUSS
interconnect target-module nodes with all the required properties.
Each of the PRUSS devices themselves shall be added as child nodes
to the corresponding interconnect node in the future. The PRU-ICSS
instances are only available on AM57xx family of SoCs and are not
supported on DRA7xx family of SoCs in general, so the target module
nodes are added in a separate dtsi file. This new dtsi file is
included in all the AM57xx SoC dtsi files, so the nodes are
automatically inherited and enabled on all AM57xx boards.
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
---
arch/arm/boot/dts/am57-pruss.dtsi | 50 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/am5718.dtsi | 1 +
arch/arm/boot/dts/am5728.dtsi | 1 +
arch/arm/boot/dts/am5748.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 2 +-
5 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am57-pruss.dtsi
diff --git a/arch/arm/boot/dts/am57-pruss.dtsi b/arch/arm/boot/dts/am57-pruss.dtsi
new file mode 100644
index 000000000000..b1c583dee10b
--- /dev/null
+++ b/arch/arm/boot/dts/am57-pruss.dtsi
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Common PRUSS data for TI AM57xx platforms
+ */
+
+&ocp {
+ pruss1_tm: target-module@4b226000 {
+ compatible = "ti,sysc-pruss", "ti,sysc";
+ reg = <0x4b226000 0x4>,
+ <0x4b226004 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>;
+ /* Domains (P, C): coreaon_pwrdm, l4per2_clkdm */
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_PRUSS1_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00000000 0x4b200000 0x80000>;
+ };
+
+ pruss2_tm: target-module@4b2a6000 {
+ compatible = "ti,sysc-pruss", "ti,sysc";
+ reg = <0x4b2a6000 0x4>,
+ <0x4b2a6004 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>;
+ /* Domains (P, C): coreaon_pwrdm, l4per2_clkdm */
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_PRUSS2_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00000000 0x4b280000 0x80000>;
+ };
+};
diff --git a/arch/arm/boot/dts/am5718.dtsi b/arch/arm/boot/dts/am5718.dtsi
index d51007c3e8c4..a80c2e3eee2e 100644
--- a/arch/arm/boot/dts/am5718.dtsi
+++ b/arch/arm/boot/dts/am5718.dtsi
@@ -4,6 +4,7 @@
*/
#include "dra72x.dtsi"
+#include "am57-pruss.dtsi"
/ {
compatible = "ti,am5718", "ti,dra7";
diff --git a/arch/arm/boot/dts/am5728.dtsi b/arch/arm/boot/dts/am5728.dtsi
index 82e5427ef6a9..9a3810f5adcc 100644
--- a/arch/arm/boot/dts/am5728.dtsi
+++ b/arch/arm/boot/dts/am5728.dtsi
@@ -4,6 +4,7 @@
*/
#include "dra74x.dtsi"
+#include "am57-pruss.dtsi"
/ {
compatible = "ti,am5728", "ti,dra7";
diff --git a/arch/arm/boot/dts/am5748.dtsi b/arch/arm/boot/dts/am5748.dtsi
index 5e129759d04a..2b65317b1513 100644
--- a/arch/arm/boot/dts/am5748.dtsi
+++ b/arch/arm/boot/dts/am5748.dtsi
@@ -4,6 +4,7 @@
*/
#include "dra76x.dtsi"
+#include "am57-pruss.dtsi"
/ {
compatible = "ti,am5748", "ti,dra762", "ti,dra7";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d78b684e7fca..f2e44c0dcd1e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -143,7 +143,7 @@
* the moment, just use a fake OCP bus entry to represent the whole bus
* hierarchy.
*/
- ocp {
+ ocp: ocp {
compatible = "ti,dra7-l3-noc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.23.0
The AM437x family of SoCs contains two dissimilar PRU-ICSS instances,
but leverage a common reset line and SYSCFG from the larger PRU-ICSS1
instance. This SYSC register has also very unique bit-fields. Both
the IPs require the PRCM reset to be deasserted to be able to access
any registers. Add a common PRUSS interconnect target-module with all
the required properties.
The PRUSS devices themselves shall be added as child nodes to this
interconnect node in the future. The PRU-ICSS instances are not
supported on AM4372 SoC though in the AM437x family, so the target
module node should be enabled in only those derivative board files
that use a SoC containing the PRU-ICSS IPs.
Signed-off-by: Suman Anna <[email protected]>
---
arch/arm/boot/dts/am4372.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index faa14dc0faff..979fa7f67825 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -344,6 +344,29 @@
};
};
+ pruss_tm: target-module@54400000 {
+ compatible = "ti,sysc-pruss", "ti,sysc";
+ reg = <0x54426000 0x4>,
+ <0x54426004 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 AM4_PRUSS_OCP_PRUSS_CLKCTRL 0>;
+ clock-names = "fck";
+ resets = <&prm_per 1>;
+ reset-names = "rstctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x54400000 0x80000>;
+ status = "disabled";
+ };
+
gpmc: gpmc@50000000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
--
2.23.0
* Suman Anna <[email protected]> [200225 20:47]:
> The PRU-ICSS target module node was left in disabled state in the base
> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> the PRU-ICSS IP.
Just get rid of the top level status = "disabled". The default
is enabled, and the device is there for sure inside the SoC.
And then there's no need for pointless status = "okay" tinkering
in the board specific dts files so no need for this patch.
Regards,
Tony
On 2/26/20 12:29 PM, Tony Lindgren wrote:
> * Suman Anna <[email protected]> [200225 20:47]:
>> The PRU-ICSS target module node was left in disabled state in the base
>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
>> the PRU-ICSS IP.
>
> Just get rid of the top level status = "disabled". The default
> is enabled, and the device is there for sure inside the SoC.
> And then there's no need for pointless status = "okay" tinkering
> in the board specific dts files so no need for this patch.
The IP is not available on all SoCs, and there are about 40 different
board files atm across AM33xx and AM437x, and am not sure what SoCs they
are actually using.
regards
Suman
* Suman Anna <[email protected]> [200226 20:35]:
> On 2/26/20 12:29 PM, Tony Lindgren wrote:
> > * Suman Anna <[email protected]> [200225 20:47]:
> >> The PRU-ICSS target module node was left in disabled state in the base
> >> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> >> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> >> the PRU-ICSS IP.
> >
> > Just get rid of the top level status = "disabled". The default
> > is enabled, and the device is there for sure inside the SoC.
> > And then there's no need for pointless status = "okay" tinkering
> > in the board specific dts files so no need for this patch.
>
> The IP is not available on all SoCs, and there are about 40 different
> board files atm across AM33xx and AM437x, and am not sure what SoCs they
> are actually using.
Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
Detect display subsystem related devices" if you can add runtime
detection for the accelerators there similar to what I hadded for omap3.
acclerators.
Regards,
Tony
* Tony Lindgren <[email protected]> [200226 22:38]:
> * Suman Anna <[email protected]> [200226 20:35]:
> > On 2/26/20 12:29 PM, Tony Lindgren wrote:
> > > * Suman Anna <[email protected]> [200225 20:47]:
> > >> The PRU-ICSS target module node was left in disabled state in the base
> > >> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> > >> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> > >> the PRU-ICSS IP.
> > >
> > > Just get rid of the top level status = "disabled". The default
> > > is enabled, and the device is there for sure inside the SoC.
> > > And then there's no need for pointless status = "okay" tinkering
> > > in the board specific dts files so no need for this patch.
> >
> > The IP is not available on all SoCs, and there are about 40 different
> > board files atm across AM33xx and AM437x, and am not sure what SoCs they
> > are actually using.
>
> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
> Detect display subsystem related devices" if you can add runtime
> detection for the accelerators there similar to what I hadded for omap3.
> acclerators.
Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
revision handling".
Regards,
Tony
Hi Tony,
On 2/26/20 4:39 PM, Tony Lindgren wrote:
> * Tony Lindgren <[email protected]> [200226 22:38]:
>> * Suman Anna <[email protected]> [200226 20:35]:
>>> On 2/26/20 12:29 PM, Tony Lindgren wrote:
>>>> * Suman Anna <[email protected]> [200225 20:47]:
>>>>> The PRU-ICSS target module node was left in disabled state in the base
>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
>>>>> the PRU-ICSS IP.
>>>>
>>>> Just get rid of the top level status = "disabled". The default
>>>> is enabled, and the device is there for sure inside the SoC.
>>>> And then there's no need for pointless status = "okay" tinkering
>>>> in the board specific dts files so no need for this patch.
>>>
>>> The IP is not available on all SoCs, and there are about 40 different
>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they
>>> are actually using.
>>
>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
>> Detect display subsystem related devices" if you can add runtime
>> detection for the accelerators there similar to what I hadded for omap3.
>> acclerators.
>
> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
> revision handling".
OK, looked down that path a bit more and looking through mach-omap2/id.c
and soc.h, I see some of the part number infrastructure build on top of
DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the
generic family and the Silicon Revision number for AM33xx and AM437x and
we currently do not have any infrastructure around exact SoC
identification for AM33xx and AM437x atleast.
Do you have the bit-field split for the DEV_FEATURE bits somewhere,
because I couldn't find any in either the DM or the TRM. On AM437x,
there is no difference between AM4372 and AM4376 DEV_FEATURE value even
though the former doesn't have the PRUSS. On AM335x, may be bit 0
signifies the presence of PRUSS??
regards
Suman
* Suman Anna <[email protected]> [200227 00:59]:
> Hi Tony,
>
> On 2/26/20 4:39 PM, Tony Lindgren wrote:
> > * Tony Lindgren <[email protected]> [200226 22:38]:
> >> * Suman Anna <[email protected]> [200226 20:35]:
> >>> On 2/26/20 12:29 PM, Tony Lindgren wrote:
> >>>> * Suman Anna <[email protected]> [200225 20:47]:
> >>>>> The PRU-ICSS target module node was left in disabled state in the base
> >>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> >>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> >>>>> the PRU-ICSS IP.
> >>>>
> >>>> Just get rid of the top level status = "disabled". The default
> >>>> is enabled, and the device is there for sure inside the SoC.
> >>>> And then there's no need for pointless status = "okay" tinkering
> >>>> in the board specific dts files so no need for this patch.
> >>>
> >>> The IP is not available on all SoCs, and there are about 40 different
> >>> board files atm across AM33xx and AM437x, and am not sure what SoCs they
> >>> are actually using.
> >>
> >> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
> >> Detect display subsystem related devices" if you can add runtime
> >> detection for the accelerators there similar to what I hadded for omap3.
> >> acclerators.
> >
> > Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
> > revision handling".
>
> OK, looked down that path a bit more and looking through mach-omap2/id.c
> and soc.h, I see some of the part number infrastructure build on top of
> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the
> generic family and the Silicon Revision number for AM33xx and AM437x and
> we currently do not have any infrastructure around exact SoC
> identification for AM33xx and AM437x atleast.
>
> Do you have the bit-field split for the DEV_FEATURE bits somewhere,
> because I couldn't find any in either the DM or the TRM. On AM437x,
> there is no difference between AM4372 and AM4376 DEV_FEATURE value even
> though the former doesn't have the PRUSS. On AM335x, may be bit 0
> signifies the presence of PRUSS??
OK not sure how that could be detected. Maybe check the efuses on
the newer SoCs?
Regards,
Tony
* Suman Anna <[email protected]> [200227 21:29]:
> On 2/26/20 8:07 PM, Tony Lindgren wrote:
> > * Suman Anna <[email protected]> [200227 00:59]:
> >> Hi Tony,
> >>
> >> On 2/26/20 4:39 PM, Tony Lindgren wrote:
> >>> * Tony Lindgren <[email protected]> [200226 22:38]:
> >>>> * Suman Anna <[email protected]> [200226 20:35]:
> >>>>> On 2/26/20 12:29 PM, Tony Lindgren wrote:
> >>>>>> * Suman Anna <[email protected]> [200225 20:47]:
> >>>>>>> The PRU-ICSS target module node was left in disabled state in the base
> >>>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> >>>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> >>>>>>> the PRU-ICSS IP.
> >>>>>>
> >>>>>> Just get rid of the top level status = "disabled". The default
> >>>>>> is enabled, and the device is there for sure inside the SoC.
> >>>>>> And then there's no need for pointless status = "okay" tinkering
> >>>>>> in the board specific dts files so no need for this patch.
> >>>>>
> >>>>> The IP is not available on all SoCs, and there are about 40 different
> >>>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they
> >>>>> are actually using.
> >>>>
> >>>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
> >>>> Detect display subsystem related devices" if you can add runtime
> >>>> detection for the accelerators there similar to what I hadded for omap3.
> >>>> acclerators.
> >>>
> >>> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
> >>> revision handling".
> >>
> >> OK, looked down that path a bit more and looking through mach-omap2/id.c
> >> and soc.h, I see some of the part number infrastructure build on top of
> >> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the
> >> generic family and the Silicon Revision number for AM33xx and AM437x and
> >> we currently do not have any infrastructure around exact SoC
> >> identification for AM33xx and AM437x atleast.
> >>
> >> Do you have the bit-field split for the DEV_FEATURE bits somewhere,
> >> because I couldn't find any in either the DM or the TRM. On AM437x,
> >> there is no difference between AM4372 and AM4376 DEV_FEATURE value even
> >> though the former doesn't have the PRUSS. On AM335x, may be bit 0
> >> signifies the presence of PRUSS??
> >
> > OK not sure how that could be detected. Maybe check the efuses on
> > the newer SoCs?
>
> OK, latest datasheeet has fixed these values up, and they are no longer
> identical. In anycase, none of the current AM437x board dts files in the
> kernel use AM4372, so atleast for AM4372, I can drop the status=disabled
> even without adding any SoC name support.
OK sounds good to me.
Thanks,
Tony
On 2/26/20 8:07 PM, Tony Lindgren wrote:
> * Suman Anna <[email protected]> [200227 00:59]:
>> Hi Tony,
>>
>> On 2/26/20 4:39 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <[email protected]> [200226 22:38]:
>>>> * Suman Anna <[email protected]> [200226 20:35]:
>>>>> On 2/26/20 12:29 PM, Tony Lindgren wrote:
>>>>>> * Suman Anna <[email protected]> [200225 20:47]:
>>>>>>> The PRU-ICSS target module node was left in disabled state in the base
>>>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
>>>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
>>>>>>> the PRU-ICSS IP.
>>>>>>
>>>>>> Just get rid of the top level status = "disabled". The default
>>>>>> is enabled, and the device is there for sure inside the SoC.
>>>>>> And then there's no need for pointless status = "okay" tinkering
>>>>>> in the board specific dts files so no need for this patch.
>>>>>
>>>>> The IP is not available on all SoCs, and there are about 40 different
>>>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they
>>>>> are actually using.
>>>>
>>>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
>>>> Detect display subsystem related devices" if you can add runtime
>>>> detection for the accelerators there similar to what I hadded for omap3.
>>>> acclerators.
>>>
>>> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
>>> revision handling".
>>
>> OK, looked down that path a bit more and looking through mach-omap2/id.c
>> and soc.h, I see some of the part number infrastructure build on top of
>> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the
>> generic family and the Silicon Revision number for AM33xx and AM437x and
>> we currently do not have any infrastructure around exact SoC
>> identification for AM33xx and AM437x atleast.
>>
>> Do you have the bit-field split for the DEV_FEATURE bits somewhere,
>> because I couldn't find any in either the DM or the TRM. On AM437x,
>> there is no difference between AM4372 and AM4376 DEV_FEATURE value even
>> though the former doesn't have the PRUSS. On AM335x, may be bit 0
>> signifies the presence of PRUSS??
>
> OK not sure how that could be detected. Maybe check the efuses on
> the newer SoCs?
OK, latest datasheeet has fixed these values up, and they are no longer
identical. In anycase, none of the current AM437x board dts files in the
kernel use AM4372, so atleast for AM4372, I can drop the status=disabled
even without adding any SoC name support.
regards
Suman