* [PATCH 1/6] ARM: OMAP2+: Drop legacy platform data for omap4 gpu
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
2019-08-14 13:14 ` [PATCH 2/6] bus: ti-sysc: Add module enable quirk for SGX on omap36xx Tony Lindgren
` (5 subsequent siblings)
6 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
I've tested that the interconnect target module enables and idles
just fine when probed with ti-sysc with PM runtime control via sys:
# echo on > $(find /sys -name control | grep \/5601)
# rwmem 0x56000024
0x56000024 = 0x00010200 # SGX540 CORE_REVISION
# echo auto > $(find /sys -name control | grep \/5601)
# rwmem 0x56000024
And when idled, it will produce "Bus error" as expected.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap4.dtsi | 1 -
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 53 ----------------------
2 files changed, 54 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -330,7 +330,6 @@
target-module@56000000 {
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "gpu";
reg = <0x5601fc00 0x4>,
<0x5601fc10 0x4>;
reg-names = "rev", "sysc";
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1085,41 +1085,6 @@ static struct omap_hwmod omap44xx_gpmc_hwmod = {
},
};
-/*
- * 'gpu' class
- * 2d/3d graphics accelerator
- */
-
-static struct omap_hwmod_class_sysconfig omap44xx_gpu_sysc = {
- .rev_offs = 0x1fc00,
- .sysc_offs = 0x1fc10,
- .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
- MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
- .sysc_fields = &omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class omap44xx_gpu_hwmod_class = {
- .name = "gpu",
- .sysc = &omap44xx_gpu_sysc,
-};
-
-/* gpu */
-static struct omap_hwmod omap44xx_gpu_hwmod = {
- .name = "gpu",
- .class = &omap44xx_gpu_hwmod_class,
- .clkdm_name = "l3_gfx_clkdm",
- .main_clk = "sgx_clk_mux",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = OMAP4_CM_GFX_GFX_CLKCTRL_OFFSET,
- .context_offs = OMAP4_RM_GFX_GFX_CONTEXT_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/*
* 'hdq1w' class
* hdq / 1-wire serial interface controller
@@ -2596,14 +2561,6 @@ static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* gpu -> l3_main_2 */
-static struct omap_hwmod_ocp_if omap44xx_gpu__l3_main_2 = {
- .master = &omap44xx_gpu_hwmod,
- .slave = &omap44xx_l3_main_2_hwmod,
- .clk = "l3_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* hsi -> l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = &omap44xx_hsi_hwmod,
@@ -3028,14 +2985,6 @@ static struct omap_hwmod_ocp_if omap44xx_l3_main_2__gpmc = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l3_main_2 -> gpu */
-static struct omap_hwmod_ocp_if omap44xx_l3_main_2__gpu = {
- .master = &omap44xx_l3_main_2_hwmod,
- .slave = &omap44xx_gpu_hwmod,
- .clk = "l3_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l4_per -> hdq1w */
static struct omap_hwmod_ocp_if omap44xx_l4_per__hdq1w = {
.master = &omap44xx_l4_per_hwmod,
@@ -3450,7 +3399,6 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_debugss__l3_main_2,
&omap44xx_dma_system__l3_main_2,
&omap44xx_fdif__l3_main_2,
- &omap44xx_gpu__l3_main_2,
&omap44xx_hsi__l3_main_2,
&omap44xx_ipu__l3_main_2,
&omap44xx_iss__l3_main_2,
@@ -3503,7 +3451,6 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l4_per__elm,
&omap44xx_l4_cfg__fdif,
&omap44xx_l3_main_2__gpmc,
- &omap44xx_l3_main_2__gpu,
&omap44xx_l4_per__hdq1w,
&omap44xx_l4_cfg__hsi,
&omap44xx_l3_main_2__ipu,
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 2/6] bus: ti-sysc: Add module enable quirk for SGX on omap36xx
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
2019-08-14 13:14 ` [PATCH 1/6] ARM: OMAP2+: Drop legacy platform data for omap4 gpu Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
2019-08-14 13:14 ` [PATCH 3/6] clk: ti: add clkctrl data omap5 sgx Tony Lindgren
` (4 subsequent siblings)
6 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
Add module enable quirk for SGX needed on omap36xx.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/bus/ti-sysc.c | 21 +++++++++++++++++++++
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -73,6 +73,7 @@ static const char * const clock_names[SYSC_MAX_CLOCKS] = {
* @clk_enable_quirk: module specific clock enable quirk
* @clk_disable_quirk: module specific clock disable quirk
* @reset_done_quirk: module specific reset done quirk
+ * @module_enable_quirk: module specific enable quirk
*/
struct sysc {
struct device *dev;
@@ -98,6 +99,7 @@ struct sysc {
void (*clk_enable_quirk)(struct sysc *sysc);
void (*clk_disable_quirk)(struct sysc *sysc);
void (*reset_done_quirk)(struct sysc *sysc);
+ void (*module_enable_quirk)(struct sysc *sysc);
};
static void sysc_parse_dts_quirks(struct sysc *ddata, struct device_node *np,
@@ -938,6 +940,9 @@ static int sysc_enable_module(struct device *dev)
sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
}
+ if (ddata->module_enable_quirk)
+ ddata->module_enable_quirk(ddata);
+
return 0;
}
@@ -1251,6 +1256,9 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = {
SYSC_MODULE_QUIRK_I2C),
SYSC_QUIRK("i2c", 0, 0, 0x10, 0x90, 0x5040000a, 0xfffff0f0,
SYSC_MODULE_QUIRK_I2C),
+ SYSC_QUIRK("gpu", 0x50000000, 0x14, -1, -1, 0x00010201, 0xffffffff, 0),
+ SYSC_QUIRK("gpu", 0x50000000, 0xfe00, 0xfe10, -1, 0x40000000 , 0xffffffff,
+ SYSC_MODULE_QUIRK_SGX),
SYSC_QUIRK("wdt", 0, 0, 0x10, 0x14, 0x502a0500, 0xfffff0f0,
SYSC_MODULE_QUIRK_WDT),
@@ -1268,6 +1276,7 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = {
SYSC_QUIRK("dwc3", 0, 0, 0x10, -1, 0x500a0200, 0xffffffff, 0),
SYSC_QUIRK("epwmss", 0, 0, 0x4, -1, 0x47400001, 0xffffffff, 0),
SYSC_QUIRK("gpu", 0, 0x1fc00, 0x1fc10, -1, 0, 0, 0),
+ SYSC_QUIRK("gpu", 0, 0xfe00, 0xfe10, -1, 0x40000000 , 0xffffffff, 0),
SYSC_QUIRK("hsi", 0, 0, 0x10, 0x14, 0x50043101, 0xffffffff, 0),
SYSC_QUIRK("iss", 0, 0, 0x10, -1, 0x40000101, 0xffffffff, 0),
SYSC_QUIRK("lcdc", 0, 0, 0x54, -1, 0x4f201000, 0xffffffff, 0),
@@ -1419,6 +1428,15 @@ static void sysc_clk_disable_quirk_i2c(struct sysc *ddata)
sysc_clk_quirk_i2c(ddata, false);
}
+/* 36xx SGX needs a quirk for to bypass OCP IPG interrupt logic */
+static void sysc_module_enable_quirk_sgx(struct sysc *ddata)
+{
+ int offset = 0xff08; /* OCP_DEBUG_CONFIG */
+ u32 val = BIT(31); /* THALIA_INT_BYPASS */
+
+ sysc_write(ddata, offset, val);
+}
+
/* Watchdog timer needs a disable sequence after reset */
static void sysc_reset_done_quirk_wdt(struct sysc *ddata)
{
@@ -1461,6 +1479,9 @@ static void sysc_init_module_quirks(struct sysc *ddata)
return;
}
+ if (ddata->cfg.quirks & SYSC_MODULE_QUIRK_SGX)
+ ddata->module_enable_quirk = sysc_module_enable_quirk_sgx;
+
if (ddata->cfg.quirks & SYSC_MODULE_QUIRK_WDT)
ddata->reset_done_quirk = sysc_reset_done_quirk_wdt;
}
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -49,6 +49,7 @@ struct sysc_regbits {
s8 emufree_shift;
};
+#define SYSC_MODULE_QUIRK_SGX BIT(18)
#define SYSC_MODULE_QUIRK_HDQ1W BIT(17)
#define SYSC_MODULE_QUIRK_I2C BIT(16)
#define SYSC_MODULE_QUIRK_WDT BIT(15)
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/6] clk: ti: add clkctrl data omap5 sgx
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
2019-08-14 13:14 ` [PATCH 1/6] ARM: OMAP2+: Drop legacy platform data for omap4 gpu Tony Lindgren
2019-08-14 13:14 ` [PATCH 2/6] bus: ti-sysc: Add module enable quirk for SGX on omap36xx Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
2019-08-14 13:14 ` [PATCH 4/6] ARM: dts: Configure sgx for omap5 Tony Lindgren
` (3 subsequent siblings)
6 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Michael Turquette, Paweł Chmiel,
Philipp Rossak, Stephen Boyd, Tero Kristo, Tomi Valkeinen,
linux-clk
Looks like we have sgx clock missing currently so let's add it.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/clk/ti/clk-54xx.c | 34 +++++++++++++++++++++++++++++++
include/dt-bindings/clock/omap5.h | 3 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -314,6 +314,39 @@ static const struct omap_clkctrl_reg_data omap5_dss_clkctrl_regs[] __initconst =
{ 0 },
};
+static const char * const omap5_gpu_core_mux_parents[] __initconst = {
+ "dpll_core_h14x2_ck",
+ "dpll_per_h14x2_ck",
+ NULL,
+};
+
+static const char * const omap5_gpu_hyd_mux_parents[] __initconst = {
+ "dpll_core_h14x2_ck",
+ "dpll_per_h14x2_ck",
+ NULL,
+};
+
+static const char * const omap5_gpu_sys_clk_parents[] __initconst = {
+ "sys_clkin",
+ NULL,
+};
+
+static const struct omap_clkctrl_div_data omap5_gpu_sys_clk_data __initconst = {
+ .max_div = 2,
+};
+
+static const struct omap_clkctrl_bit_data omap5_gpu_core_bit_data[] __initconst = {
+ { 24, TI_CLK_MUX, omap5_gpu_core_mux_parents, NULL },
+ { 25, TI_CLK_MUX, omap5_gpu_hyd_mux_parents, NULL },
+ { 26, TI_CLK_DIVIDER, omap5_gpu_sys_clk_parents, &omap5_gpu_sys_clk_data },
+ { 0 },
+};
+
+static const struct omap_clkctrl_reg_data omap5_gpu_clkctrl_regs[] __initconst = {
+ { OMAP5_GPU_CLKCTRL, omap5_gpu_core_bit_data, CLKF_SW_SUP, "gpu_cm:clk:0000:24" },
+ { 0 },
+};
+
static const char * const omap5_mmc1_fclk_mux_parents[] __initconst = {
"func_128m_clk",
"dpll_per_m2x2_ck",
@@ -470,6 +503,7 @@ const struct omap_clkctrl_data omap5_clkctrl_data[] __initconst = {
{ 0x4a008e20, omap5_l3instr_clkctrl_regs },
{ 0x4a009020, omap5_l4per_clkctrl_regs },
{ 0x4a009420, omap5_dss_clkctrl_regs },
+ { 0x4a009520, omap5_gpu_clkctrl_regs },
{ 0x4a009620, omap5_l3init_clkctrl_regs },
{ 0x4ae07920, omap5_wkupaon_clkctrl_regs },
{ 0 },
diff --git a/include/dt-bindings/clock/omap5.h b/include/dt-bindings/clock/omap5.h
--- a/include/dt-bindings/clock/omap5.h
+++ b/include/dt-bindings/clock/omap5.h
@@ -89,6 +89,9 @@
/* dss clocks */
#define OMAP5_DSS_CORE_CLKCTRL OMAP5_CLKCTRL_INDEX(0x20)
+/* gpu clocks */
+#define OMAP5_GPU_CLKCTRL OMAP5_CLKCTRL_INDEX(0x20)
+
/* l3init clocks */
#define OMAP5_MMC1_CLKCTRL OMAP5_CLKCTRL_INDEX(0x28)
#define OMAP5_MMC2_CLKCTRL OMAP5_CLKCTRL_INDEX(0x30)
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 4/6] ARM: dts: Configure sgx for omap5
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
` (2 preceding siblings ...)
2019-08-14 13:14 ` [PATCH 3/6] clk: ti: add clkctrl data omap5 sgx Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
[not found] ` <20190815182348.8A1BA2063F@mail.kernel.org>
2019-08-14 13:14 ` [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx Tony Lindgren
` (2 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
I've tested that the interconnect target module enables and idles
just fine when probed with ti-sysc with PM runtime control via sys:
# echo on > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe00 # OCP Revision
0x5600fe00 = 0x40000000
# echo auto > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe10
# rwmem 0x56000024
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap5.dtsi | 23 +++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 14 ++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -257,6 +257,29 @@
ports-implemented = <0x1>;
};
+ target-module@56000000 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5600fe00 0x4>,
+ <0x5600fe10 0x4>;
+ reg-names = "rev", "sysc";
+ 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 = <&gpu_clkctrl OMAP5_GPU_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x56000000 0x2000000>;
+
+ /*
+ * Closed source PowerVR driver, no child device
+ * binding or driver in mainline
+ */
+ };
+
dss: dss@58000000 {
compatible = "ti,omap5-dss";
reg = <0x58000000 0x80>;
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -1146,6 +1146,20 @@
};
};
+ gpu_cm: gpu_cm@1500 {
+ compatible = "ti,omap4-cm";
+ reg = <0x1500 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1500 0x100>;
+
+ gpu_clkctrl: clk@20 {
+ compatible = "ti,clkctrl";
+ reg = <0x20 0x4>;
+ #clock-cells = <2>;
+ };
+ };
+
l3init_cm: l3init_cm@1600 {
compatible = "ti,omap4-cm";
reg = <0x1600 0x100>;
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
` (3 preceding siblings ...)
2019-08-14 13:14 ` [PATCH 4/6] ARM: dts: Configure sgx for omap5 Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
2019-08-14 14:46 ` Andrew F. Davis
2019-08-19 19:12 ` Adam Ford
2019-08-14 13:14 ` [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX Tony Lindgren
2019-08-14 19:13 ` [PATCH 0/6] Configure sgx interconnect data for some omap variants Adam Ford
6 siblings, 2 replies; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
Looks like omap34xx OCP registers are not readable unlike on omap36xx.
We use SGX revision register instead of the OCP revision register for
34xx and do not configure any SYSCONFIG register unlike for 36xx.
I've tested that the interconnect target module enables and idles
just fine with PM runtime control via sys:
# echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
# rwmem 0x50000014 # SGX revision register on 36xx
0x50000014 = 0x00010205
# echo auto > $(find /sys -name control | grep \/5000)
# rwmem 0x5000fe00
And when idled, it will produce "Bus error" as expected.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap34xx.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 27 +++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -100,6 +100,32 @@
interrupts = <18>;
};
};
+
+ /*
+ * On omap34xx the OCP registers do not seem to be accessible
+ * at all unlike on 36xx. Maybe SGX is permanently set to
+ * "OCP bypass mode", or maybe there is OCP_SYSCONFIG that is
+ * write-only at 0x50000e10. We detect SGX based on the SGX
+ * revision register instead of the unreadable OCP revision
+ * register. Also note that on early 34xx es1 revision there
+ * are also different clocks, but we do not have any dts users
+ * for it.
+ */
+ sgx_module: target-module@50000000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x50000014 0x4>;
+ reg-names = "rev";
+ clocks = <&sgx_fck>, <&sgx_ick>;
+ clock-names = "fck", "ick";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x50000000 0x4000>;
+
+ /*
+ * Closed source PowerVR driver, no cnhild device
+ * binding or driver in mainline
+ */
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -139,6 +139,33 @@
interrupts = <18>;
};
};
+
+ /*
+ * The OCP register layout seems to be a subset of the
+ * "ti,sysc-omap4" with just sidle and midle bits.
+ */
+ sgx_module: target-module@50000000 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5000fe00 0x4>,
+ <0x5000fe10 0x4>;
+ reg-names = "rev", "sysc";
+ 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 = <&sgx_fck>, <&sgx_ick>;
+ clock-names = "fck", "ick";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x50000000 0x2000000>;
+
+ /*
+ * Closed source PowerVR driver, no cnhild device
+ * binding or driver in mainline
+ */
+ };
};
thermal_zones: thermal-zones {
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx
2019-08-14 13:14 ` [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx Tony Lindgren
@ 2019-08-14 14:46 ` Andrew F. Davis
2019-08-19 19:12 ` Adam Ford
1 sibling, 0 replies; 27+ messages in thread
From: Andrew F. Davis @ 2019-08-14 14:46 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
On 8/14/19 9:14 AM, Tony Lindgren wrote:
> Looks like omap34xx OCP registers are not readable unlike on omap36xx.
> We use SGX revision register instead of the OCP revision register for
> 34xx and do not configure any SYSCONFIG register unlike for 36xx.
>
> I've tested that the interconnect target module enables and idles
> just fine with PM runtime control via sys:
>
> # echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
> # rwmem 0x50000014 # SGX revision register on 36xx
> 0x50000014 = 0x00010205
> # echo auto > $(find /sys -name control | grep \/5000)
> # rwmem 0x5000fe00
> And when idled, it will produce "Bus error" as expected.
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
> Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Cc: moaz korena <moaz@korena.xyz>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Cc: Philipp Rossak <embed3d@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 26 ++++++++++++++++++++++++++
> arch/arm/boot/dts/omap36xx.dtsi | 27 +++++++++++++++++++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -100,6 +100,32 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * On omap34xx the OCP registers do not seem to be accessible
> + * at all unlike on 36xx. Maybe SGX is permanently set to
> + * "OCP bypass mode", or maybe there is OCP_SYSCONFIG that is
> + * write-only at 0x50000e10. We detect SGX based on the SGX
> + * revision register instead of the unreadable OCP revision
> + * register. Also note that on early 34xx es1 revision there
> + * are also different clocks, but we do not have any dts users
> + * for it.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap2", "ti,sysc";
> + reg = <0x50000014 0x4>;
> + reg-names = "rev";
> + clocks = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x4000>;
> +
> + /*
> + * Closed source PowerVR driver, no cnhild device
s/cnhild/child same below
Andrew
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -139,6 +139,33 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * The OCP register layout seems to be a subset of the
> + * "ti,sysc-omap4" with just sidle and midle bits.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap4", "ti,sysc";
> + reg = <0x5000fe00 0x4>,
> + <0x5000fe10 0x4>;
> + reg-names = "rev", "sysc";
> + 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 = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x2000000>;
> +
> + /*
> + * Closed source PowerVR driver, no cnhild device
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx
2019-08-14 13:14 ` [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx Tony Lindgren
2019-08-14 14:46 ` Andrew F. Davis
@ 2019-08-19 19:12 ` Adam Ford
2019-09-07 11:51 ` H. Nikolaus Schaller
1 sibling, 1 reply; 27+ messages in thread
From: Adam Ford @ 2019-08-19 19:12 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
On Wed, Aug 14, 2019 at 8:14 AM Tony Lindgren <tony@atomide.com> wrote:
>
> Looks like omap34xx OCP registers are not readable unlike on omap36xx.
> We use SGX revision register instead of the OCP revision register for
> 34xx and do not configure any SYSCONFIG register unlike for 36xx.
>
> I've tested that the interconnect target module enables and idles
> just fine with PM runtime control via sys:
>
> # echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
> # rwmem 0x50000014 # SGX revision register on 36xx
> 0x50000014 = 0x00010205
For an OMAP3530, I got:
# echo on > $(find /sys -name control | grep \/5000)
# devmem 0x50000014
0x00010201
Does 0x00010201 seem reasonable? I am not sure where to find this in
the TRM unless it's located elsewhere, but [1] seems to lead me to
believe this is correct.
> # echo auto > $(find /sys -name control | grep \/5000)
> # rwmem 0x5000fe00
I assume the above address should be 0x50000014 for OMAP34/35, is that
correct? It was listed as 0x50000014 above.
If my assumption if correct, it appears to work for me as well.
[1] - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#How_to_check_for_SGX_core_revision
> And when idled, it will produce "Bus error" as expected.
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
> Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Cc: moaz korena <moaz@korena.xyz>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Cc: Philipp Rossak <embed3d@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
If my assumptions are correct, then you can mark it as
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-som-lv-35xx-devkit
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 26 ++++++++++++++++++++++++++
> arch/arm/boot/dts/omap36xx.dtsi | 27 +++++++++++++++++++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -100,6 +100,32 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * On omap34xx the OCP registers do not seem to be accessible
> + * at all unlike on 36xx. Maybe SGX is permanently set to
> + * "OCP bypass mode", or maybe there is OCP_SYSCONFIG that is
> + * write-only at 0x50000e10. We detect SGX based on the SGX
> + * revision register instead of the unreadable OCP revision
> + * register. Also note that on early 34xx es1 revision there
> + * are also different clocks, but we do not have any dts users
> + * for it.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap2", "ti,sysc";
> + reg = <0x50000014 0x4>;
> + reg-names = "rev";
> + clocks = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x4000>;
> +
> + /*
> + * Closed source PowerVR driver, no cnhild device
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -139,6 +139,33 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * The OCP register layout seems to be a subset of the
> + * "ti,sysc-omap4" with just sidle and midle bits.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap4", "ti,sysc";
> + reg = <0x5000fe00 0x4>,
> + <0x5000fe10 0x4>;
> + reg-names = "rev", "sysc";
> + 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 = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x2000000>;
> +
> + /*
> + * Closed source PowerVR driver, no cnhild device
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
> --
> 2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx
2019-08-19 19:12 ` Adam Ford
@ 2019-09-07 11:51 ` H. Nikolaus Schaller
0 siblings, 0 replies; 27+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-07 11:51 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, Linux-OMAP, Benoît Cousson, devicetree,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
Hi Adam,
> Am 19.08.2019 um 21:12 schrieb Adam Ford <aford173@gmail.com>:
>
> On Wed, Aug 14, 2019 at 8:14 AM Tony Lindgren <tony@atomide.com> wrote:
>>
>> Looks like omap34xx OCP registers are not readable unlike on omap36xx.
>> We use SGX revision register instead of the OCP revision register for
>> 34xx and do not configure any SYSCONFIG register unlike for 36xx.
>>
>> I've tested that the interconnect target module enables and idles
>> just fine with PM runtime control via sys:
>>
>> # echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
>> # rwmem 0x50000014 # SGX revision register on 36xx
>> 0x50000014 = 0x00010205
>
> For an OMAP3530, I got:
> # echo on > $(find /sys -name control | grep \/5000)
> # devmem 0x50000014
> 0x00010201
>
> Does 0x00010201 seem reasonable? I am not sure where to find this in
> the TRM unless it's located elsewhere, but [1] seems to lead me to
> believe this is correct.
I got on dm3730:
root@letux:~# echo on >/sys/devices/platform/68000000.ocp/5000fe00.target-module/50000000.sgx/power/control
root@letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x50000014
/dev/mem opened.
Memory mapped at address 0xb6fc0000.
Value at address 0x50000014 (0xb6fc0014): 0x10205
root@letux:~#
which indicates ES5.0, as expected for dm3730.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
` (4 preceding siblings ...)
2019-08-14 13:14 ` [PATCH 5/6] ARM: dts: Configure interconnect target module for omap3 sgx Tony Lindgren
@ 2019-08-14 13:14 ` Tony Lindgren
2019-09-13 9:49 ` H. Nikolaus Schaller
2019-08-14 19:13 ` [PATCH 0/6] Configure sgx interconnect data for some omap variants Adam Ford
6 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-08-14 13:14 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, Adam Ford, Filip Matijević,
H. Nikolaus Schaller, Ivaylo Dimitrov, moaz korena,
Merlijn Wajer, Paweł Chmiel, Philipp Rossak, Tomi Valkeinen,
Michael Turquette, Stephen Boyd, Tero Kristo, linux-clk
The following can be tested via sysfs with the following to ensure the SGX
module gets enabled and disabled properly:
# echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
# rwmem 0x5600fe00 # revision register
0x5600fe00 = 0x40000000
# echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
# rwmem 0x5000fe00
Bus error
Note that this patch depends on the PRM rstctrl driver that has
been recently posted. If the child device driver(s) need to prevent
rstctrl reset on PM runtime suspend, the drivers need to increase
the usecount for the shared rstctrl reset that can be mapped also
for the child device(s) or accessed via dev->parent.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am33xx.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -460,6 +460,31 @@
<&edma 5 0>;
dma-names = "tx", "rx";
};
+
+ target-module@56000000 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5600fe00 0x4>,
+ <0x5600fe10 0x4>;
+ reg-names = "rev", "sysc";
+ 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 = <&gfx_l3_clkctrl AM3_GFX_L3_GFX_CLKCTRL 0>;
+ clock-names = "fck";
+ resets = <&prm_gfx 0>;
+ reset-names = "rstctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x56000000 0x1000000>;
+
+ /*
+ * Closed source PowerVR driver, no child device
+ * binding or driver in mainline
+ */
+ };
};
};
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-08-14 13:14 ` [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX Tony Lindgren
@ 2019-09-13 9:49 ` H. Nikolaus Schaller
2019-09-16 15:17 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-13 9:49 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree, Adam Ford,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
Hi Tony,
> Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
>
> The following can be tested via sysfs with the following to ensure the SGX
> module gets enabled and disabled properly:
>
> # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
> # rwmem 0x5600fe00 # revision register
> 0x5600fe00 = 0x40000000
> # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
> # rwmem 0x5000fe00
> Bus error
>
> Note that this patch depends on the PRM rstctrl driver that has
> been recently posted.
Do you have a list of these patches or a git for pulling the complete set
of changes? Does it depend on mainline or linux-next?
I tried to find the correct patches but it does not seem to work for
me on beaglebone.
> If the child device driver(s) need to prevent
> rstctrl reset on PM runtime suspend, the drivers need to increase
> the usecount for the shared rstctrl reset that can be mapped also
> for the child device(s) or accessed via dev->parent.
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
> Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Cc: moaz korena <moaz@korena.xyz>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Cc: Philipp Rossak <embed3d@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/am33xx.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -460,6 +460,31 @@
> <&edma 5 0>;
> dma-names = "tx", "rx";
> };
> +
> + target-module@56000000 {
> + compatible = "ti,sysc-omap4", "ti,sysc";
> + reg = <0x5600fe00 0x4>,
> + <0x5600fe10 0x4>;
> + reg-names = "rev", "sysc";
> + 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 = <&gfx_l3_clkctrl AM3_GFX_L3_GFX_CLKCTRL 0>;
> + clock-names = "fck";
> + resets = <&prm_gfx 0>;
> + reset-names = "rstctrl";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x56000000 0x1000000>;
> +
> + /*
> + * Closed source PowerVR driver, no child device
> + * binding or driver in mainline
> + */
> + };
> };
> };
>
> --
> 2.21.0
BR and thanks,
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-13 9:49 ` H. Nikolaus Schaller
@ 2019-09-16 15:17 ` Tony Lindgren
2019-09-16 18:04 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-09-16 15:17 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Linux-OMAP, Benoît Cousson, devicetree, Adam Ford,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
Hi,
* H. Nikolaus Schaller <hns@goldelico.com> [190913 09:50]:
> Hi Tony,
>
> > Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
> >
> > The following can be tested via sysfs with the following to ensure the SGX
> > module gets enabled and disabled properly:
> >
> > # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
> > # rwmem 0x5600fe00 # revision register
> > 0x5600fe00 = 0x40000000
> > # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
> > # rwmem 0x5000fe00
> > Bus error
> >
> > Note that this patch depends on the PRM rstctrl driver that has
> > been recently posted.
>
> Do you have a list of these patches or a git for pulling the complete set
> of changes? Does it depend on mainline or linux-next?
You need the drivers/bus/ti-sysc.c changes from Linux next,
and the most recent clkctrl and rstctrl patches posted by
Tero.
> I tried to find the correct patches but it does not seem to work for
> me on beaglebone.
OK can you please check the dependencies again and let me know
if you still have issues?
Regards,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-16 15:17 ` Tony Lindgren
@ 2019-09-16 18:04 ` Tony Lindgren
2019-09-16 18:12 ` H. Nikolaus Schaller
0 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-09-16 18:04 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Linux-OMAP, Benoît Cousson, devicetree, Adam Ford,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
Hi,
* Tony Lindgren <tony@atomide.com> [190916 15:18]:
> * H. Nikolaus Schaller <hns@goldelico.com> [190913 09:50]:
> > Hi Tony,
> >
> > > Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
> > >
> > > The following can be tested via sysfs with the following to ensure the SGX
> > > module gets enabled and disabled properly:
> > >
> > > # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
> > > # rwmem 0x5600fe00 # revision register
> > > 0x5600fe00 = 0x40000000
> > > # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
> > > # rwmem 0x5000fe00
> > > Bus error
> > >
> > > Note that this patch depends on the PRM rstctrl driver that has
> > > been recently posted.
> >
> > Do you have a list of these patches or a git for pulling the complete set
> > of changes? Does it depend on mainline or linux-next?
>
> You need the drivers/bus/ti-sysc.c changes from Linux next,
> and the most recent clkctrl and rstctrl patches posted by
> Tero.
>
> > I tried to find the correct patches but it does not seem to work for
> > me on beaglebone.
>
> OK can you please check the dependencies again and let me know
> if you still have issues?
To make things easier to test, I pushed out a test branch with
all the pending dependencies :)
It's basically v5.3 + ti-sysc changes in Linux next, and
the following patches posted by Tero:
[PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
[PATCHv3 00/10] clk: ti: remoteproc / iommu support patches
[PATCH 00/10] ARM: dts: omap changes for IOMMU / reset support
And then finally the $subject patch applied on top, and the
tests above still work for me.
The test branch is test-pending-ti-sysc-clkctrl-rstctrl-v5.3
at [0] and [1] below.
Can you please test and see if that works for you?
Regards,
Tony
[0] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git test-pending-ti-sysc-clkctrl-rstctrl-v5.3
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=test-pending-ti-sysc-clkctrl-rstctrl-v5.3
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-16 18:04 ` Tony Lindgren
@ 2019-09-16 18:12 ` H. Nikolaus Schaller
2019-09-16 19:15 ` H. Nikolaus Schaller
0 siblings, 1 reply; 27+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-16 18:12 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree, Adam Ford,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
> Am 16.09.2019 um 20:04 schrieb Tony Lindgren <tony@atomide.com>:
>
> Hi,
>
> * Tony Lindgren <tony@atomide.com> [190916 15:18]:
>> * H. Nikolaus Schaller <hns@goldelico.com> [190913 09:50]:
>>> Hi Tony,
>>>
>>>> Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
>>>>
>>>> The following can be tested via sysfs with the following to ensure the SGX
>>>> module gets enabled and disabled properly:
>>>>
>>>> # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>>> # rwmem 0x5600fe00 # revision register
>>>> 0x5600fe00 = 0x40000000
>>>> # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>>> # rwmem 0x5000fe00
>>>> Bus error
>>>>
>>>> Note that this patch depends on the PRM rstctrl driver that has
>>>> been recently posted.
>>>
>>> Do you have a list of these patches or a git for pulling the complete set
>>> of changes? Does it depend on mainline or linux-next?
>>
>> You need the drivers/bus/ti-sysc.c changes from Linux next,
>> and the most recent clkctrl and rstctrl patches posted by
>> Tero.
>>
>>> I tried to find the correct patches but it does not seem to work for
>>> me on beaglebone.
>>
>> OK can you please check the dependencies again and let me know
>> if you still have issues?
>
> To make things easier to test, I pushed out a test branch with
> all the pending dependencies :)
>
> It's basically v5.3 + ti-sysc changes in Linux next, and
> the following patches posted by Tero:
>
> [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
> [PATCHv3 00/10] clk: ti: remoteproc / iommu support patches
> [PATCH 00/10] ARM: dts: omap changes for IOMMU / reset support
>
> And then finally the $subject patch applied on top, and the
> tests above still work for me.
Ok, fine!
>
> The test branch is test-pending-ti-sysc-clkctrl-rstctrl-v5.3
> at [0] and [1] below.
>
> Can you please test and see if that works for you?
>
> Regards,
>
> Tony
>
> [0] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git test-pending-ti-sysc-clkctrl-rstctrl-v5.3
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=test-pending-ti-sysc-clkctrl-rstctrl-v5.3
I'll check out and try to locate missing pieces.
BR and thanks,
Nikolaus
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-16 18:12 ` H. Nikolaus Schaller
@ 2019-09-16 19:15 ` H. Nikolaus Schaller
2019-09-16 19:20 ` Adam Ford
0 siblings, 1 reply; 27+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-16 19:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree, Adam Ford,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
> Am 16.09.2019 um 20:12 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>
>> Am 16.09.2019 um 20:04 schrieb Tony Lindgren <tony@atomide.com>:
>>
>> Hi,
>>
>> * Tony Lindgren <tony@atomide.com> [190916 15:18]:
>>> * H. Nikolaus Schaller <hns@goldelico.com> [190913 09:50]:
>>>> Hi Tony,
>>>>
>>>>> Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
>>>>>
>>>>> The following can be tested via sysfs with the following to ensure the SGX
>>>>> module gets enabled and disabled properly:
>>>>>
>>>>> # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>>>> # rwmem 0x5600fe00 # revision register
>>>>> 0x5600fe00 = 0x40000000
>>>>> # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>>>> # rwmem 0x5000fe00
>>>>> Bus error
>>>>>
>>>>> Note that this patch depends on the PRM rstctrl driver that has
>>>>> been recently posted.
>>>>
>>>> Do you have a list of these patches or a git for pulling the complete set
>>>> of changes? Does it depend on mainline or linux-next?
>>>
>>> You need the drivers/bus/ti-sysc.c changes from Linux next,
>>> and the most recent clkctrl and rstctrl patches posted by
>>> Tero.
>>>
>>>> I tried to find the correct patches but it does not seem to work for
>>>> me on beaglebone.
>>>
>>> OK can you please check the dependencies again and let me know
>>> if you still have issues?
>>
>> To make things easier to test, I pushed out a test branch with
>> all the pending dependencies :)
>>
>> It's basically v5.3 + ti-sysc changes in Linux next, and
>> the following patches posted by Tero:
>>
>> [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
>> [PATCHv3 00/10] clk: ti: remoteproc / iommu support patches
>> [PATCH 00/10] ARM: dts: omap changes for IOMMU / reset support
>>
>> And then finally the $subject patch applied on top, and the
>> tests above still work for me.
>
> Ok, fine!
>
>>
>> The test branch is test-pending-ti-sysc-clkctrl-rstctrl-v5.3
>> at [0] and [1] below.
>>
>> Can you please test and see if that works for you?
>>
>> Regards,
>>
>> Tony
>>
>> [0] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git test-pending-ti-sysc-clkctrl-rstctrl-v5.3
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=test-pending-ti-sysc-clkctrl-rstctrl-v5.3
>
> I'll check out and try to locate missing pieces.
Ok, this variant works as a basis! At least for register access.
root@letux:~# devmem2 0x5600fe00
Value at address 0x5600FE00 (0xb6fede00): 0x40000000
root@letux:~# devmem2 0x5600fe04
Value at address 0x5600FE04 (0xb6fa1e04): 0x5
root@letux:~# devmem2 0x5600fe10
Value at address 0x5600FE10 (0xb6f80e10): 0x28
root@letux:~#
This is quite similar to OMAP5 where I got
> root@letux:~# devmem2 0x5600fe00
> Value at address 0x5600FE00 (0xb6f87e00): 0x40000000
> root@letux:~# devmem2 0x5600fe04
> Value at address 0x5600FE04 (0xb6f11e04): 0x5
> root@letux:~# devmem2 0x5600fe10
> Value at address 0x5600FE10 (0xb6f93e10): 0x3C
or OMAP3:
> root@letux:~# devmem2 0x5000fe00
> Value at address 0x5000FE00 (0xb6f81e00): 0x40000000
> root@letux:~# devmem2 0x5000fe04
> Value at address 0x5000FE04 (0xb6f28e04): 0x5
> root@letux:~# devmem2 0x5000fe10
> Value at address 0x5000FE10 (0xb6f5fe10): 0x28
> root@letux:~#
But SGX driver initialization still fails with a reset_deassert timeout.
root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
[ 187.528139] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
[ 187.584580] omap_reset_deassert: timedout waiting for gfx:0
[ 187.614430] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1
root@letux:~# pvrsrvctl --start --no-module
[ 209.085931] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ]
[ 209.116399] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable.
PVR:(Error): LoaduKernelProgram : SGX ukernel program Device Addr: 0xe400000 invalid alignment [0, ]
PVR:(Error): SetupuKernel : Failed to load uKernel programs [0, ]
PVR:(Error): SrvInit: Initialisation for device of class 0, type 7, index 0, failed (1) [0, ]
PVR:(Error): PVRSRVBridgeCall: Failed to access device. Function ID:3223086862 (strerror returns no value.). [0, ]
pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_OUT_OF_MEMORY - Unable to allocate required memory)
root@letux:~#
A simple reason may be that I have a bad offset in my device tree setup
and the driver doesn't see feedback from SGX.
" for 56000000.sgx on minor 1" is suspect.
IMHO, it should have to be " for 5600fe00.sgx on minor 1"
But anyways this is a big step forwards having giving me three different
platforms for testing and comparisons.
BR and thanks,
Nikolaus
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-16 19:15 ` H. Nikolaus Schaller
@ 2019-09-16 19:20 ` Adam Ford
2019-09-16 19:45 ` H. Nikolaus Schaller
0 siblings, 1 reply; 27+ messages in thread
From: Adam Ford @ 2019-09-16 19:20 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Tony Lindgren, Linux-OMAP, Benoît Cousson, devicetree,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
On Mon, Sep 16, 2019 at 2:15 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>
> > Am 16.09.2019 um 20:12 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> >
> >> Am 16.09.2019 um 20:04 schrieb Tony Lindgren <tony@atomide.com>:
> >>
> >> Hi,
> >>
> >> * Tony Lindgren <tony@atomide.com> [190916 15:18]:
> >>> * H. Nikolaus Schaller <hns@goldelico.com> [190913 09:50]:
> >>>> Hi Tony,
> >>>>
> >>>>> Am 14.08.2019 um 15:14 schrieb Tony Lindgren <tony@atomide.com>:
> >>>>>
> >>>>> The following can be tested via sysfs with the following to ensure the SGX
> >>>>> module gets enabled and disabled properly:
> >>>>>
> >>>>> # echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
> >>>>> # rwmem 0x5600fe00 # revision register
> >>>>> 0x5600fe00 = 0x40000000
> >>>>> # echo auto > /sys/bus/platform/devices/5600fe00.target-module/power/control
> >>>>> # rwmem 0x5000fe00
> >>>>> Bus error
> >>>>>
> >>>>> Note that this patch depends on the PRM rstctrl driver that has
> >>>>> been recently posted.
> >>>>
> >>>> Do you have a list of these patches or a git for pulling the complete set
> >>>> of changes? Does it depend on mainline or linux-next?
> >>>
> >>> You need the drivers/bus/ti-sysc.c changes from Linux next,
> >>> and the most recent clkctrl and rstctrl patches posted by
> >>> Tero.
> >>>
> >>>> I tried to find the correct patches but it does not seem to work for
> >>>> me on beaglebone.
> >>>
> >>> OK can you please check the dependencies again and let me know
> >>> if you still have issues?
> >>
> >> To make things easier to test, I pushed out a test branch with
> >> all the pending dependencies :)
> >>
> >> It's basically v5.3 + ti-sysc changes in Linux next, and
> >> the following patches posted by Tero:
> >>
> >> [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
> >> [PATCHv3 00/10] clk: ti: remoteproc / iommu support patches
> >> [PATCH 00/10] ARM: dts: omap changes for IOMMU / reset support
> >>
> >> And then finally the $subject patch applied on top, and the
> >> tests above still work for me.
> >
> > Ok, fine!
> >
> >>
> >> The test branch is test-pending-ti-sysc-clkctrl-rstctrl-v5.3
> >> at [0] and [1] below.
> >>
> >> Can you please test and see if that works for you?
> >>
> >> Regards,
> >>
> >> Tony
> >>
> >> [0] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git test-pending-ti-sysc-clkctrl-rstctrl-v5.3
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=test-pending-ti-sysc-clkctrl-rstctrl-v5.3
> >
> > I'll check out and try to locate missing pieces.
>
> Ok, this variant works as a basis! At least for register access.
>
> root@letux:~# devmem2 0x5600fe00
> Value at address 0x5600FE00 (0xb6fede00): 0x40000000
> root@letux:~# devmem2 0x5600fe04
> Value at address 0x5600FE04 (0xb6fa1e04): 0x5
> root@letux:~# devmem2 0x5600fe10
> Value at address 0x5600FE10 (0xb6f80e10): 0x28
> root@letux:~#
>
> This is quite similar to OMAP5 where I got
>
> > root@letux:~# devmem2 0x5600fe00
> > Value at address 0x5600FE00 (0xb6f87e00): 0x40000000
> > root@letux:~# devmem2 0x5600fe04
> > Value at address 0x5600FE04 (0xb6f11e04): 0x5
> > root@letux:~# devmem2 0x5600fe10
> > Value at address 0x5600FE10 (0xb6f93e10): 0x3C
>
> or OMAP3:
>
> > root@letux:~# devmem2 0x5000fe00
> > Value at address 0x5000FE00 (0xb6f81e00): 0x40000000
> > root@letux:~# devmem2 0x5000fe04
> > Value at address 0x5000FE04 (0xb6f28e04): 0x5
> > root@letux:~# devmem2 0x5000fe10
> > Value at address 0x5000FE10 (0xb6f5fe10): 0x28
> > root@letux:~#
>
> But SGX driver initialization still fails with a reset_deassert timeout.
>
> root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
> [ 187.528139] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
> [ 187.584580] omap_reset_deassert: timedout waiting for gfx:0
> [ 187.614430] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1
> root@letux:~# pvrsrvctl --start --no-module
> [ 209.085931] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ]
> [ 209.116399] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable.
> PVR:(Error): LoaduKernelProgram : SGX ukernel program Device Addr: 0xe400000 invalid alignment [0, ]
> PVR:(Error): SetupuKernel : Failed to load uKernel programs [0, ]
> PVR:(Error): SrvInit: Initialisation for device of class 0, type 7, index 0, failed (1) [0, ]
> PVR:(Error): PVRSRVBridgeCall: Failed to access device. Function ID:3223086862 (strerror returns no value.). [0, ]
> pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_OUT_OF_MEMORY - Unable to allocate required memory)
> root@letux:~#
>
> A simple reason may be that I have a bad offset in my device tree setup
> and the driver doesn't see feedback from SGX.
>
> " for 56000000.sgx on minor 1" is suspect.
> IMHO, it should have to be " for 5600fe00.sgx on minor 1"
> But anyways this is a big step forwards having giving me three different
> platforms for testing and comparisons.
I can try to help again with the SGX once I can get the LCD stuff
working. At some point, the panel-dpi driver was removed, and I am
struggling to get my LCD's back. Until I can get the LCD's fully
function, I can't test the SGX. I got a little distracted with the
OPP stuff you did and the thermal throttling.
adam
>
> BR and thanks,
> Nikolaus
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX
2019-09-16 19:20 ` Adam Ford
@ 2019-09-16 19:45 ` H. Nikolaus Schaller
0 siblings, 0 replies; 27+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-16 19:45 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, Linux-OMAP, Benoît Cousson, devicetree,
Filip Matijević,
Ivaylo Dimitrov, moaz korena, Merlijn Wajer, Paweł Chmiel,
Philipp Rossak, Tomi Valkeinen, Michael Turquette, Stephen Boyd,
Tero Kristo, linux-clk
> Am 16.09.2019 um 21:20 schrieb Adam Ford <aford173@gmail.com>:
>
> On Mon, Sep 16, 2019 at 2:15 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>>
>>> Am 16.09.2019 um 20:12 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>
>>>
>> " for 56000000.sgx on minor 1" is suspect.
>> IMHO, it should have to be " for 5600fe00.sgx on minor 1"
>> But anyways this is a big step forwards having giving me three different
>> platforms for testing and comparisons.
>
> I can try to help again with the SGX once I can get the LCD stuff
> working. At some point, the panel-dpi driver was removed, and I am
> struggling to get my LCD's back.
We had similar issues when that happened...
> Until I can get the LCD's fully
> function, I can't test the SGX. I got a little distracted with the
> OPP stuff you did and the thermal throttling.
Same for me. I just started over today
I have pushed my latest trees (where this now working-for-me patch is included) to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/branches/active
This branch contains everything on top of v5.3:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr
Maybe for further more general SGX discussion we should now start a new mail
thread or continue the "Lay common foundation to make PVR/SGX work ...".
BR,
Nikolaus
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants
2019-08-14 13:14 [PATCH 0/6] Configure sgx interconnect data for some omap variants Tony Lindgren
` (5 preceding siblings ...)
2019-08-14 13:14 ` [PATCH 6/6] ARM: dts: Configure rstctrl reset for SGX Tony Lindgren
@ 2019-08-14 19:13 ` Adam Ford
2019-08-15 4:02 ` Tony Lindgren
6 siblings, 1 reply; 27+ messages in thread
From: Adam Ford @ 2019-08-14 19:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree,
H. Nikolaus Schaller, Filip Matijević,
Ivaylo Dimitrov, Merlijn Wajer, Michael Turquette,
Paweł Chmiel, Philipp Rossak, Stephen Boyd, Tero Kristo,
Tomi Valkeinen, linux-clk, moaz korena
On Wed, Aug 14, 2019 at 8:14 AM Tony Lindgren <tony@atomide.com> wrote:
>
> Hi all,
>
> For a while we've been idling sgx module on omap4 by probing it with
> ti-sysc interconnect target module driver. This allows leaving out any
> platform data in favor of device tree data, and idles the module for
> PM even if we don't have any sgx driver.
>
> I've added similar configuration for omap34xx, omap36xx, omap5 and
> am335x. Adding dra7 should work too, but my beagle x15 is suffering
> from a power supply problem right now and I'll need to work more on
> that later on.
>
> For am335x, the recently posted prm rstctrl driver is needed. The
> other SoCs here don't have a dependency to the prm rstctrl driver.
> And probably am335x child driver(s) also need to map the rstctrl
> register to increase the deassert use count.
>
> Please review and test, this should allow sgx child driver(s) to
> just use PM runtime to enable the module with no platform data.
>
> I've only tested these SoCs via sysfs to ensure the sgx module gets
> enabled and disabled properly. If you know something about sgx,
> please describe more why the sgx registers seem to be at different
> place for each SoC like between omap34xx and omap36xx.
>
> These patches may have some dependencies to what I've queued into
> my for-next branch for fixes so it's best to test with that merged
> in. Linux next should be usable for testing with these the next
> time it gets integrated.
>
> Regards,
>
> Tony
>
>
> Tony Lindgren (6):
> ARM: OMAP2+: Drop legacy platform data for omap4 gpu
> bus: ti-sysc: Add module enable quirk for SGX on omap36xx
> clk: ti: add clkctrl data omap5 sgx
> ARM: dts: Configure sgx for omap5
> ARM: dts: Configure interconnect target module for omap3 sgx
> ARM: dts: Configure rstctrl reset for SGX
>
Assuming the following is correct:
echo on > /sys/bus/platform/devices/5000fe00.target-module/power/control
# devmem 0x5000fe00 32
0x40000000
and
echo auto > /sys/bus/platform/devices/5000fe00.target-module/power/control
# devmem 0x5000fe00 32
[ 776.373504] 8<--- cut here ---
[ 776.376617] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6
f76e00
[ 776.384338] pgd = bde98bb0
[ 776.387054] [b6f76e00] *pgd=8cb61831, *pte=5000f383, *ppte=5000fa33
[ 776.393402] In-band Error seen by MPU at address 0
Then
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
I do wonder if an omap34xx or omap36xx should use
compatible = "ti,sysc-omap4", "ti,sysc";
should it use an omap3 equivalent?
adam
> arch/arm/boot/dts/am33xx.dtsi | 25 ++++++++++
> arch/arm/boot/dts/omap34xx.dtsi | 26 +++++++++++
> arch/arm/boot/dts/omap36xx.dtsi | 27 +++++++++++
> arch/arm/boot/dts/omap4.dtsi | 1 -
> arch/arm/boot/dts/omap5.dtsi | 23 ++++++++++
> arch/arm/boot/dts/omap54xx-clocks.dtsi | 14 ++++++
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 53 ----------------------
> drivers/bus/ti-sysc.c | 21 +++++++++
> drivers/clk/ti/clk-54xx.c | 34 ++++++++++++++
> include/dt-bindings/clock/omap5.h | 3 ++
> include/linux/platform_data/ti-sysc.h | 1 +
> 11 files changed, 174 insertions(+), 54 deletions(-)
>
> --
> 2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants
2019-08-14 19:13 ` [PATCH 0/6] Configure sgx interconnect data for some omap variants Adam Ford
@ 2019-08-15 4:02 ` Tony Lindgren
2019-08-15 4:15 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-08-15 4:02 UTC (permalink / raw)
To: Adam Ford
Cc: Linux-OMAP, Benoît Cousson, devicetree,
H. Nikolaus Schaller, Filip Matijević,
Ivaylo Dimitrov, Merlijn Wajer, Michael Turquette,
Paweł Chmiel, Philipp Rossak, Stephen Boyd, Tero Kristo,
Tomi Valkeinen, linux-clk, moaz korena
* Adam Ford <aford173@gmail.com> [190814 19:14]:
> echo on > /sys/bus/platform/devices/5000fe00.target-module/power/control
> # devmem 0x5000fe00 32
> 0x40000000
>
> and
>
> echo auto > /sys/bus/platform/devices/5000fe00.target-module/power/control
> # devmem 0x5000fe00 32
> [ 776.373504] 8<--- cut here ---
> [ 776.376617] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6
> f76e00
> [ 776.384338] pgd = bde98bb0
> [ 776.387054] [b6f76e00] *pgd=8cb61831, *pte=5000f383, *ppte=5000fa33
> [ 776.393402] In-band Error seen by MPU at address 0
>
> Then
>
> Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Thanks for testing, yes that's all there is to it for the SoC glue in
this case. The child device driver(s) can be just generic sgx driver(s)
that just do pm_runtime_get_sync() to access the registers and that
enables the parent interconnect target module as needed.
> I do wonder if an omap34xx or omap36xx should use
> compatible = "ti,sysc-omap4", "ti,sysc";
>
> should it use an omap3 equivalent?
We named the old hwmod type1 as ti,sysc-omap2, type2 as ti,sysc-omap4,
and type3 as ti,sysc-omap4-simple based on where we thought they
appeared. Based on the sysconfig register bit layout, sgx on omap36xx
seems to have a subset of ti,sysc-omap4 and we can recycle it. If we
used a wrong type, the module would not get enabled or disabled as
the register bits would not match.
How about let's add a comment like:
Yes sg has a subset of ti,sysc-omap4 type sysconfig register
Regards,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants
2019-08-15 4:02 ` Tony Lindgren
@ 2019-08-15 4:15 ` Tony Lindgren
2019-08-15 13:05 ` Adam Ford
0 siblings, 1 reply; 27+ messages in thread
From: Tony Lindgren @ 2019-08-15 4:15 UTC (permalink / raw)
To: Adam Ford
Cc: Linux-OMAP, Benoît Cousson, devicetree,
H. Nikolaus Schaller, Filip Matijević,
Ivaylo Dimitrov, Merlijn Wajer, Michael Turquette,
Paweł Chmiel, Philipp Rossak, Stephen Boyd, Tero Kristo,
Tomi Valkeinen, linux-clk, moaz korena, Andrew F. Davis
* Tony Lindgren <tony@atomide.com> [190815 04:03]:
> * Adam Ford <aford173@gmail.com> [190814 19:14]:
> > I do wonder if an omap34xx or omap36xx should use
> > compatible = "ti,sysc-omap4", "ti,sysc";
> >
> > should it use an omap3 equivalent?
>
> We named the old hwmod type1 as ti,sysc-omap2, type2 as ti,sysc-omap4,
> and type3 as ti,sysc-omap4-simple based on where we thought they
> appeared. Based on the sysconfig register bit layout, sgx on omap36xx
> seems to have a subset of ti,sysc-omap4 and we can recycle it. If we
> used a wrong type, the module would not get enabled or disabled as
> the register bits would not match.
>
> How about let's add a comment like:
>
> Yes sg has a subset of ti,sysc-omap4 type sysconfig register
Well actually we already have some comments there, I clarified
it a bit more and fixed the typos noted by Andrew. Updated patch
below.
Regards,
Tony
8< ------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 14 Aug 2019 05:18:16 -0700
Subject: [PATCH] ARM: dts: Configure interconnect target module for omap3
sgx
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Looks like omap34xx OCP registers are not readable unlike on omap36xx.
We use SGX revision register instead of the OCP revision register for
34xx and do not configure any SYSCONFIG register unlike for 36xx.
I've tested that the interconnect target module enables and idles
just fine with PM runtime control via sys:
# echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
# rwmem 0x50000014 # SGX revision register on 36xx
0x50000014 = 0x00010205
# echo auto > $(find /sys -name control | grep \/5000)
# rwmem 0x5000fe00
And when idled, it will produce "Bus error" as expected.
Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap34xx.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 28 ++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -100,6 +100,32 @@
interrupts = <18>;
};
};
+
+ /*
+ * On omap34xx the OCP registers do not seem to be accessible
+ * at all unlike on 36xx. Maybe SGX is permanently set to
+ * "OCP bypass mode", or maybe there is OCP_SYSCONFIG that is
+ * write-only at 0x50000e10. We detect SGX based on the SGX
+ * revision register instead of the unreadable OCP revision
+ * register. Also note that on early 34xx es1 revision there
+ * are also different clocks, but we do not have any dts users
+ * for it.
+ */
+ sgx_module: target-module@50000000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x50000014 0x4>;
+ reg-names = "rev";
+ clocks = <&sgx_fck>, <&sgx_ick>;
+ clock-names = "fck", "ick";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x50000000 0x4000>;
+
+ /*
+ * Closed source PowerVR driver, no child device
+ * binding or driver in mainline
+ */
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -139,6 +139,34 @@
interrupts = <18>;
};
};
+
+ /*
+ * Note that the sysconfig register layout is a subset of the
+ * "ti,sysc-omap4" type register with just sidle and midle bits
+ * available while omap34xx has "ti,sysc-omap2" type sysconfig.
+ */
+ sgx_module: target-module@50000000 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5000fe00 0x4>,
+ <0x5000fe10 0x4>;
+ reg-names = "rev", "sysc";
+ 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 = <&sgx_fck>, <&sgx_ick>;
+ clock-names = "fck", "ick";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x50000000 0x2000000>;
+
+ /*
+ * Closed source PowerVR driver, no child device
+ * binding or driver in mainline
+ */
+ };
};
thermal_zones: thermal-zones {
--
2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants
2019-08-15 4:15 ` Tony Lindgren
@ 2019-08-15 13:05 ` Adam Ford
2019-08-17 7:05 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Adam Ford @ 2019-08-15 13:05 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux-OMAP, Benoît Cousson, devicetree,
H. Nikolaus Schaller, Filip Matijević,
Ivaylo Dimitrov, Merlijn Wajer, Michael Turquette,
Paweł Chmiel, Philipp Rossak, Stephen Boyd, Tero Kristo,
Tomi Valkeinen, linux-clk, moaz korena, Andrew F. Davis
On Wed, Aug 14, 2019 at 11:15 PM Tony Lindgren <tony@atomide.com> wrote:
>
> * Tony Lindgren <tony@atomide.com> [190815 04:03]:
> > * Adam Ford <aford173@gmail.com> [190814 19:14]:
> > > I do wonder if an omap34xx or omap36xx should use
> > > compatible = "ti,sysc-omap4", "ti,sysc";
> > >
> > > should it use an omap3 equivalent?
> >
> > We named the old hwmod type1 as ti,sysc-omap2, type2 as ti,sysc-omap4,
> > and type3 as ti,sysc-omap4-simple based on where we thought they
> > appeared. Based on the sysconfig register bit layout, sgx on omap36xx
> > seems to have a subset of ti,sysc-omap4 and we can recycle it. If we
> > used a wrong type, the module would not get enabled or disabled as
> > the register bits would not match.
> >
> > How about let's add a comment like:
> >
> > Yes sg has a subset of ti,sysc-omap4 type sysconfig register
>
> Well actually we already have some comments there, I clarified
> it a bit more and fixed the typos noted by Andrew. Updated patch
> below.
>
> Regards,
>
> Tony
>
> 8< ------------------
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 14 Aug 2019 05:18:16 -0700
> Subject: [PATCH] ARM: dts: Configure interconnect target module for omap3
> sgx
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Looks like omap34xx OCP registers are not readable unlike on omap36xx.
> We use SGX revision register instead of the OCP revision register for
> 34xx and do not configure any SYSCONFIG register unlike for 36xx.
Do you want/need me to test the OMAP3530? I can run the same tests I
did for the DM3730.
adam
>
> I've tested that the interconnect target module enables and idles
> just fine with PM runtime control via sys:
>
> # echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
> # rwmem 0x50000014 # SGX revision register on 36xx
> 0x50000014 = 0x00010205
> # echo auto > $(find /sys -name control | grep \/5000)
> # rwmem 0x5000fe00
> And when idled, it will produce "Bus error" as expected.
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
> Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Cc: moaz korena <moaz@korena.xyz>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Cc: Philipp Rossak <embed3d@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 26 ++++++++++++++++++++++++++
> arch/arm/boot/dts/omap36xx.dtsi | 28 ++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -100,6 +100,32 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * On omap34xx the OCP registers do not seem to be accessible
> + * at all unlike on 36xx. Maybe SGX is permanently set to
> + * "OCP bypass mode", or maybe there is OCP_SYSCONFIG that is
> + * write-only at 0x50000e10. We detect SGX based on the SGX
> + * revision register instead of the unreadable OCP revision
> + * register. Also note that on early 34xx es1 revision there
> + * are also different clocks, but we do not have any dts users
> + * for it.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap2", "ti,sysc";
> + reg = <0x50000014 0x4>;
> + reg-names = "rev";
> + clocks = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x4000>;
> +
> + /*
> + * Closed source PowerVR driver, no child device
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -139,6 +139,34 @@
> interrupts = <18>;
> };
> };
> +
> + /*
> + * Note that the sysconfig register layout is a subset of the
> + * "ti,sysc-omap4" type register with just sidle and midle bits
> + * available while omap34xx has "ti,sysc-omap2" type sysconfig.
> + */
> + sgx_module: target-module@50000000 {
> + compatible = "ti,sysc-omap4", "ti,sysc";
> + reg = <0x5000fe00 0x4>,
> + <0x5000fe10 0x4>;
> + reg-names = "rev", "sysc";
> + 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 = <&sgx_fck>, <&sgx_ick>;
> + clock-names = "fck", "ick";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x50000000 0x2000000>;
> +
> + /*
> + * Closed source PowerVR driver, no child device
> + * binding or driver in mainline
> + */
> + };
> };
>
> thermal_zones: thermal-zones {
> --
> 2.21.0
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants
2019-08-15 13:05 ` Adam Ford
@ 2019-08-17 7:05 ` Tony Lindgren
0 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2019-08-17 7:05 UTC (permalink / raw)
To: Adam Ford
Cc: Linux-OMAP, Benoît Cousson, devicetree,
H. Nikolaus Schaller, Filip Matijević,
Ivaylo Dimitrov, Merlijn Wajer, Michael Turquette,
Paweł Chmiel, Philipp Rossak, Stephen Boyd, Tero Kristo,
Tomi Valkeinen, linux-clk, moaz korena, Andrew F. Davis
* Adam Ford <aford173@gmail.com> [190815 13:06]:
> On Wed, Aug 14, 2019 at 11:15 PM Tony Lindgren <tony@atomide.com> wrote:
> > Looks like omap34xx OCP registers are not readable unlike on omap36xx.
> > We use SGX revision register instead of the OCP revision register for
> > 34xx and do not configure any SYSCONFIG register unlike for 36xx.
>
> Do you want/need me to test the OMAP3530? I can run the same tests I
> did for the DM3730.
Sure if you can dod that easily.
Regards,
Tony
^ permalink raw reply [flat|nested] 27+ messages in thread