| Message ID | 20190814131408.57162-6-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Configure sgx interconnect data for some omap variants | expand |
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 { >
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
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
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 {
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(+)