Message ID | 20240826-opp-v3-1-0934f8309e13@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | arm64: dts: ti: k3-am62{a,p}x-sk: add opp frequencies | expand |
On 12:22-20240826, Bryan Brattlof wrote: > 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 AM62Ax 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 > to only OPP entries the variant supports. A table of all these variants > can be found in it's data sheet[0] for the AM62Ax family. > > Add the OPP table into the SoC's fdti file along with the syscon node to > describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect > the SoC variant. > > [0] https://www.ti.com/lit/ds/symlink/am62a3.pdf > > Signed-off-by: Bryan Brattlof <bb@ti.com> > --- > arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 5 +++ > arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 51 +++++++++++++++++++++++++++++ > 2 files changed, 56 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi > index f5ac101a04dfa..0b1dd5390cd3f 100644 > --- a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi > @@ -17,6 +17,11 @@ chipid: chipid@14 { > reg = <0x14 0x4>; > }; > > + opp_efuse_table: syscon@18 { > + compatible = "ti,am62-opp-efuse-table", "syscon"; > + reg = <0x18 0x4>; Does this really work?? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/ti-cpufreq.c#n309 efuse_offset is 0x0 -> OK.. BUT, .rev_offset = 0x0014 from a syscon which is one register wide??? Seems like you have been sidetracked by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/ti-cpufreq.c#n384 bug to read some omap register offset? This is probably not getting exposed due to the syscon bug that I just fixed: https://lore.kernel.org/r/20240828121008.3066002-1-nm@ti.com I just have to NAK this series while you folks figure out how to do this properly. > + }; > + > 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-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi > index f86a23404e6dd..6c99221beb6bd 100644 > --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi > @@ -48,6 +48,8 @@ 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>; > }; > > cpu1: cpu@1 { > @@ -62,6 +64,8 @@ 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>; > }; > > cpu2: cpu@2 { > @@ -76,6 +80,8 @@ 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>; > }; > > cpu3: cpu@3 { > @@ -90,6 +96,51 @@ 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; > }; > }; > > > -- > 2.46.0 >
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi index f5ac101a04dfa..0b1dd5390cd3f 100644 --- a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi @@ -17,6 +17,11 @@ chipid: chipid@14 { reg = <0x14 0x4>; }; + 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-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi index f86a23404e6dd..6c99221beb6bd 100644 --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi @@ -48,6 +48,8 @@ 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>; }; cpu1: cpu@1 { @@ -62,6 +64,8 @@ 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>; }; cpu2: cpu@2 { @@ -76,6 +80,8 @@ 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>; }; cpu3: cpu@3 { @@ -90,6 +96,51 @@ 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; }; };
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 AM62Ax 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 to only OPP entries the variant supports. A table of all these variants can be found in it's data sheet[0] for the AM62Ax family. Add the OPP table into the SoC's fdti file along with the syscon node to describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect the SoC variant. [0] https://www.ti.com/lit/ds/symlink/am62a3.pdf Signed-off-by: Bryan Brattlof <bb@ti.com> --- arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 5 +++ arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 51 +++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+)