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