| Message ID | 20240823-opp-v2-3-e2f67b37c299@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: ti: k3-am62{a,p}x-sk: add opp frequencies | expand |
Hi Bryan, On Aug 23, 2024 at 16:54:30 -0500, Bryan Brattlof wrote: > ONe power management technique available to the Cortex-A53s is their s/ONe/One > ability to dynamically scale their frequency across the device's > Operating Performance Points (OPP) > > The OPPs available for the Cortex-A53s on the AM62Px can vary based on > the silicon variant used. The SoC variant is encoded into the > WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit > the OPP entries the SoC supports. A table of all these variants can be > found in its data sheet[0] for the AM62Px processor family. Error 404! Not found [0] ;) > > Add the OPP table into the SoC's ftdi file along with the syscon node to What is ftdi? > describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect > the SoC variant. > > Signed-off-by: Bryan Brattlof <bb@ti.com> > --- > .../boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi | 5 +++ > arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 47 ++++++++++++++++++++++ > 2 files changed, 52 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > index 315d0092e7366..6f32135f00a55 100644 > --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > @@ -20,6 +20,11 @@ chipid: chipid@14 { > bootph-all; > }; > > + opp_efuse_table: syscon@18 { > + compatible = "ti,am62-opp-efuse-table", "syscon"; Huh, curious why I don't see this particular compatible in am62 itself.. Also, I am still not clear where this discussion got left off: (If it's related) https://lore.kernel.org/all/5chxjwybmsxq73pagtlw4zr2asbtxov7ezrpn5j37cr77bmepa@fejdlxomfgae/ In AM625, I see k3-am625.dtsi:111: col 14: syscon = <&wkup_conf>; But the approach you've used here seems different. Is there a justification given on which one should be used/why somewhere that I can refer? > + reg = <0x18 0x4>; > + }; > + > cpsw_mac_syscon: ethernet-mac-syscon@200 { > compatible = "ti,am62p-cpsw-mac-efuse", "syscon"; > reg = <0x200 0x8>; > diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi > index 41f479dca4555..140587d02e88e 100644 > --- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi > @@ -47,6 +47,7 @@ cpu0: cpu@0 { > d-cache-line-size = <64>; > d-cache-sets = <128>; > next-level-cache = <&l2_0>; > + operating-points-v2 = <&a53_opp_table>; > clocks = <&k3_clks 135 0>; > }; > > @@ -62,6 +63,7 @@ cpu1: cpu@1 { > d-cache-line-size = <64>; > d-cache-sets = <128>; > next-level-cache = <&l2_0>; > + operating-points-v2 = <&a53_opp_table>; > clocks = <&k3_clks 136 0>; > }; > > @@ -77,6 +79,7 @@ cpu2: cpu@2 { > d-cache-line-size = <64>; > d-cache-sets = <128>; > next-level-cache = <&l2_0>; > + operating-points-v2 = <&a53_opp_table>; > clocks = <&k3_clks 137 0>; > }; > > @@ -92,10 +95,54 @@ cpu3: cpu@3 { > d-cache-line-size = <64>; > d-cache-sets = <128>; > next-level-cache = <&l2_0>; > + operating-points-v2 = <&a53_opp_table>; > clocks = <&k3_clks 138 0>; > }; > }; > > + a53_opp_table: opp-table { > + compatible = "operating-points-v2-ti-cpu"; > + opp-shared; > + syscon = <&opp_efuse_table>; > + > + opp-200000000 { > + opp-hz = /bits/ 64 <200000000>; > + opp-supported-hw = <0x01 0x0007>; > + clock-latency-ns = <6000000>; > + }; > + > + opp-400000000 { > + opp-hz = /bits/ 64 <400000000>; > + opp-supported-hw = <0x01 0x0007>; > + clock-latency-ns = <6000000>; > + }; > + > + opp-600000000 { > + opp-hz = /bits/ 64 <600000000>; > + opp-supported-hw = <0x01 0x0007>; > + clock-latency-ns = <6000000>; > + }; > + > + opp-800000000 { > + opp-hz = /bits/ 64 <800000000>; > + opp-supported-hw = <0x01 0x0007>; > + clock-latency-ns = <6000000>; > + }; > + > + opp-1000000000 { > + opp-hz = /bits/ 64 <1000000000>; > + opp-supported-hw = <0x01 0x0006>; > + clock-latency-ns = <6000000>; > + }; > + > + opp-1250000000 { > + opp-hz = /bits/ 64 <1250000000>; > + opp-supported-hw = <0x01 0x0004>; > + clock-latency-ns = <6000000>; > + opp-suspend; > + }; > + }; > +
On August 26, 2024 thus sayeth Dhruva Gole: > Hi Bryan, > > On Aug 23, 2024 at 16:54:30 -0500, Bryan Brattlof wrote: > > ONe power management technique available to the Cortex-A53s is their > > s/ONe/One > > > ability to dynamically scale their frequency across the device's > > Operating Performance Points (OPP) > > > > The OPPs available for the Cortex-A53s on the AM62Px can vary based on > > the silicon variant used. The SoC variant is encoded into the > > WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit > > the OPP entries the SoC supports. A table of all these variants can be > > found in its data sheet[0] for the AM62Px processor family. > > Error 404! Not found [0] ;) > Oops. I'll fix these up > > > > Add the OPP table into the SoC's ftdi file along with the syscon node to > > What is ftdi? FTDI is a chip, what I tried to type out was fdti or Flattened Device Tree Includes :) > > > describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect > > the SoC variant. > > > > Signed-off-by: Bryan Brattlof <bb@ti.com> > > --- > > .../boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi | 5 +++ > > arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 47 ++++++++++++++++++++++ > > 2 files changed, 52 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > > index 315d0092e7366..6f32135f00a55 100644 > > --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > > +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi > > @@ -20,6 +20,11 @@ chipid: chipid@14 { > > bootph-all; > > }; > > > > + opp_efuse_table: syscon@18 { > > + compatible = "ti,am62-opp-efuse-table", "syscon"; > > Huh, curious why I don't see this particular compatible in am62 itself.. > Also, I am still not clear where this discussion got left off: (If it's > related) > https://lore.kernel.org/all/5chxjwybmsxq73pagtlw4zr2asbtxov7ezrpn5j37cr77bmepa@fejdlxomfgae/ > > In AM625, I see > k3-am625.dtsi:111: col 14: syscon = <&wkup_conf>; > > But the approach you've used here seems different. Is there a > justification given on which one should be used/why somewhere that I can > refer? Labeling the entire &wkup_conf as a syscon node is kinda abusing what the syscon node is used for. There are a lot of things inside that WKUP_CTRL_MMR that do not belong under the miscellaneous registers category. For the 62A and 62P we've chosen to label &wkup_conf as a bus with little syscon sub-nodes inside of it. I don't think the discussion[0] ever finalized but we started going that direction with new SoCs, looks like the older SoCs never received the cleanup. ~Bryan [0] https://lore.kernel.org/all/e7114cb4-e24f-4e78-a89f-4e2e2e704b8a@ti.com/
On 26/08/24 21:41, Bryan Brattlof wrote: > On August 26, 2024 thus sayeth Dhruva Gole: >> Hi Bryan, >> >> On Aug 23, 2024 at 16:54:30 -0500, Bryan Brattlof wrote: >>> ONe power management technique available to the Cortex-A53s is their >> >> s/ONe/One >> >>> ability to dynamically scale their frequency across the device's >>> Operating Performance Points (OPP) >>> >>> The OPPs available for the Cortex-A53s on the AM62Px can vary based on >>> the silicon variant used. The SoC variant is encoded into the >>> WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit >>> the OPP entries the SoC supports. A table of all these variants can be >>> found in its data sheet[0] for the AM62Px processor family. >> >> Error 404! Not found [0] ;) >> > > Oops. I'll fix these up > >>> >>> Add the OPP table into the SoC's ftdi file along with the syscon node to >> >> What is ftdi? > > FTDI is a chip, what I tried to type out was fdti or Flattened Device > Tree Includes :) > >> >>> describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect >>> the SoC variant. >>> >>> Signed-off-by: Bryan Brattlof <bb@ti.com> >>> --- >>> .../boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi | 5 +++ >>> arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 47 ++++++++++++++++++++++ >>> 2 files changed, 52 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi >>> index 315d0092e7366..6f32135f00a55 100644 >>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi >>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi >>> @@ -20,6 +20,11 @@ chipid: chipid@14 { >>> bootph-all; >>> }; >>> >>> + opp_efuse_table: syscon@18 { >>> + compatible = "ti,am62-opp-efuse-table", "syscon"; >> >> Huh, curious why I don't see this particular compatible in am62 itself.. >> Also, I am still not clear where this discussion got left off: (If it's >> related) >> https://lore.kernel.org/all/5chxjwybmsxq73pagtlw4zr2asbtxov7ezrpn5j37cr77bmepa@fejdlxomfgae/ >> >> In AM625, I see >> k3-am625.dtsi:111: col 14: syscon = <&wkup_conf>; >> >> But the approach you've used here seems different. Is there a >> justification given on which one should be used/why somewhere that I can >> refer? > > Labeling the entire &wkup_conf as a syscon node is kinda abusing what > the syscon node is used for. There are a lot of things inside that > WKUP_CTRL_MMR that do not belong under the miscellaneous registers > category. For the 62A and 62P we've chosen to label &wkup_conf as a bus > with little syscon sub-nodes inside of it. > > I don't think the discussion[0] ever finalized but we started going that > direction with new SoCs, looks like the older SoCs never received the > cleanup. This patch seems to be in the right direction. Marking entire wkup_conf as "syscon", "simple-mfd" is wrong and needs to be addressed in k3-am62-wakeup.dtsi similar to how other child-nodes in wkup_conf are implemented in same file. [...]
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi index 315d0092e7366..6f32135f00a55 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi @@ -20,6 +20,11 @@ chipid: chipid@14 { bootph-all; }; + opp_efuse_table: syscon@18 { + compatible = "ti,am62-opp-efuse-table", "syscon"; + reg = <0x18 0x4>; + }; + cpsw_mac_syscon: ethernet-mac-syscon@200 { compatible = "ti,am62p-cpsw-mac-efuse", "syscon"; reg = <0x200 0x8>; diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi index 41f479dca4555..140587d02e88e 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi @@ -47,6 +47,7 @@ cpu0: cpu@0 { d-cache-line-size = <64>; d-cache-sets = <128>; next-level-cache = <&l2_0>; + operating-points-v2 = <&a53_opp_table>; clocks = <&k3_clks 135 0>; }; @@ -62,6 +63,7 @@ cpu1: cpu@1 { d-cache-line-size = <64>; d-cache-sets = <128>; next-level-cache = <&l2_0>; + operating-points-v2 = <&a53_opp_table>; clocks = <&k3_clks 136 0>; }; @@ -77,6 +79,7 @@ cpu2: cpu@2 { d-cache-line-size = <64>; d-cache-sets = <128>; next-level-cache = <&l2_0>; + operating-points-v2 = <&a53_opp_table>; clocks = <&k3_clks 137 0>; }; @@ -92,10 +95,54 @@ cpu3: cpu@3 { d-cache-line-size = <64>; d-cache-sets = <128>; next-level-cache = <&l2_0>; + operating-points-v2 = <&a53_opp_table>; clocks = <&k3_clks 138 0>; }; }; + a53_opp_table: opp-table { + compatible = "operating-points-v2-ti-cpu"; + opp-shared; + syscon = <&opp_efuse_table>; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-supported-hw = <0x01 0x0007>; + clock-latency-ns = <6000000>; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-supported-hw = <0x01 0x0007>; + clock-latency-ns = <6000000>; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-supported-hw = <0x01 0x0007>; + clock-latency-ns = <6000000>; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-supported-hw = <0x01 0x0007>; + clock-latency-ns = <6000000>; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-supported-hw = <0x01 0x0006>; + clock-latency-ns = <6000000>; + }; + + opp-1250000000 { + opp-hz = /bits/ 64 <1250000000>; + opp-supported-hw = <0x01 0x0004>; + clock-latency-ns = <6000000>; + opp-suspend; + }; + }; + l2_0: l2-cache0 { compatible = "cache"; cache-unified;
ONe power management technique available to the Cortex-A53s is their ability to dynamically scale their frequency across the device's Operating Performance Points (OPP) The OPPs available for the Cortex-A53s on the AM62Px can vary based on the silicon variant used. The SoC variant is encoded into the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit the OPP entries the SoC supports. A table of all these variants can be found in its data sheet[0] for the AM62Px processor family. Add the OPP table into the SoC's ftdi file along with the syscon node to describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect the SoC variant. Signed-off-by: Bryan Brattlof <bb@ti.com> --- .../boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi | 5 +++ arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 47 ++++++++++++++++++++++ 2 files changed, 52 insertions(+)