* [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
[2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
[3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
Change since v24:
- Rebase to Linux 5.18-rc6
- Show specific fail log in svs_platform_probe() to help catch which step fails quickly
- Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
Test in below environment:
SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
HW: mt8183-Krane
[4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
[5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
Boots up log:
[ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
[ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
[ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
[ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
[ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
[ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
[ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
[ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
SVS commands log:
localhost ~ # cat /sys/kernel/debug/svs/*/*
init2
SVSB_CCI: temperature ignore, turn_pt = 0
opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
init2
SVSB_CPU_BIG: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
init2
SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
mon mode
SVSB_GPU: temperature = 33492, turn_pt = 0
opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
Roger Lu (7):
[v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
[v25,2/7] arm64: dts: mt8183: add svs device information
[v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
[v25,4/7] soc: mediatek: SVS: add monitor mode
[v25,5/7] soc: mediatek: SVS: add debug commands
[v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
[v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
.../bindings/soc/mediatek/mtk-svs.yaml | 91 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
5 files changed, 2517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
create mode 100644 drivers/soc/mediatek/mtk-svs.c
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
[2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
[3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
Change since v24:
- Rebase to Linux 5.18-rc6
- Show specific fail log in svs_platform_probe() to help catch which step fails quickly
- Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
Test in below environment:
SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
HW: mt8183-Krane
[4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
[5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
Boots up log:
[ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
[ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
[ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
[ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
[ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
[ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
[ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
[ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
SVS commands log:
localhost ~ # cat /sys/kernel/debug/svs/*/*
init2
SVSB_CCI: temperature ignore, turn_pt = 0
opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
init2
SVSB_CPU_BIG: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
init2
SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
mon mode
SVSB_GPU: temperature = 33492, turn_pt = 0
opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
Roger Lu (7):
[v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
[v25,2/7] arm64: dts: mt8183: add svs device information
[v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
[v25,4/7] soc: mediatek: SVS: add monitor mode
[v25,5/7] soc: mediatek: SVS: add debug commands
[v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
[v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
.../bindings/soc/mediatek/mtk-svs.yaml | 91 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
5 files changed, 2517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
create mode 100644 drivers/soc/mediatek/mtk-svs.c
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
[2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
[3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
Change since v24:
- Rebase to Linux 5.18-rc6
- Show specific fail log in svs_platform_probe() to help catch which step fails quickly
- Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
Test in below environment:
SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
HW: mt8183-Krane
[4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
[5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
Boots up log:
[ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
[ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
[ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
[ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
[ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
[ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
[ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
[ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
SVS commands log:
localhost ~ # cat /sys/kernel/debug/svs/*/*
init2
SVSB_CCI: temperature ignore, turn_pt = 0
opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
init2
SVSB_CPU_BIG: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
init2
SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
mon mode
SVSB_GPU: temperature = 33492, turn_pt = 0
opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
Roger Lu (7):
[v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
[v25,2/7] arm64: dts: mt8183: add svs device information
[v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
[v25,4/7] soc: mediatek: SVS: add monitor mode
[v25,5/7] soc: mediatek: SVS: add debug commands
[v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
[v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
.../bindings/soc/mediatek/mtk-svs.yaml | 91 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
5 files changed, 2517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
create mode 100644 drivers/soc/mediatek/mtk-svs.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Document the binding for enabling mtk svs on MediaTek SoC.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../bindings/soc/mediatek/mtk-svs.yaml | 83 +++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
new file mode 100644
index 000000000000..1e51e5f562d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Smart Voltage Scaling (SVS) Device Tree Bindings
+
+maintainers:
+ - Roger Lu <roger.lu@mediatek.com>
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Kevin Hilman <khilman@kernel.org>
+
+description: |+
+ The SVS engine is a piece of hardware which has several
+ controllers(banks) for calculating suitable voltage to
+ different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-svs
+
+ reg:
+ maxItems: 1
+ description: Address range of the MTK SVS controller.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: Main clock for MTK SVS controller to work.
+
+ clock-names:
+ const: main
+
+ nvmem-cells:
+ minItems: 1
+ description:
+ Phandle to the calibration data provided by a nvmem device.
+ items:
+ - description: SVS efuse for SVS controller
+ - description: Thermal efuse for SVS controller
+
+ nvmem-cell-names:
+ items:
+ - const: svs-calibration-data
+ - const: t-calibration-data
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
+ };
+ };
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Document the binding for enabling mtk svs on MediaTek SoC.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../bindings/soc/mediatek/mtk-svs.yaml | 83 +++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
new file mode 100644
index 000000000000..1e51e5f562d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Smart Voltage Scaling (SVS) Device Tree Bindings
+
+maintainers:
+ - Roger Lu <roger.lu@mediatek.com>
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Kevin Hilman <khilman@kernel.org>
+
+description: |+
+ The SVS engine is a piece of hardware which has several
+ controllers(banks) for calculating suitable voltage to
+ different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-svs
+
+ reg:
+ maxItems: 1
+ description: Address range of the MTK SVS controller.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: Main clock for MTK SVS controller to work.
+
+ clock-names:
+ const: main
+
+ nvmem-cells:
+ minItems: 1
+ description:
+ Phandle to the calibration data provided by a nvmem device.
+ items:
+ - description: SVS efuse for SVS controller
+ - description: Thermal efuse for SVS controller
+
+ nvmem-cell-names:
+ items:
+ - const: svs-calibration-data
+ - const: t-calibration-data
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
+ };
+ };
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Document the binding for enabling mtk svs on MediaTek SoC.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../bindings/soc/mediatek/mtk-svs.yaml | 83 +++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
new file mode 100644
index 000000000000..1e51e5f562d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Smart Voltage Scaling (SVS) Device Tree Bindings
+
+maintainers:
+ - Roger Lu <roger.lu@mediatek.com>
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Kevin Hilman <khilman@kernel.org>
+
+description: |+
+ The SVS engine is a piece of hardware which has several
+ controllers(banks) for calculating suitable voltage to
+ different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-svs
+
+ reg:
+ maxItems: 1
+ description: Address range of the MTK SVS controller.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: Main clock for MTK SVS controller to work.
+
+ clock-names:
+ const: main
+
+ nvmem-cells:
+ minItems: 1
+ description:
+ Phandle to the calibration data provided by a nvmem device.
+ items:
+ - description: SVS efuse for SVS controller
+ - description: Thermal efuse for SVS controller
+
+ nvmem-cell-names:
+ items:
+ - const: svs-calibration-data
+ - const: t-calibration-data
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
+ };
+ };
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 2/7] arm64: dts: mt8183: add svs device information
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add compatible/reg/irq/clock/efuse setting in svs node.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4b08691ed39e..e8901cbbdf38 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -807,6 +807,18 @@
status = "disabled";
};
+ svs: svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>,
+ <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data",
+ "t-calibration-data";
+ };
+
thermal: thermal@1100b000 {
#thermal-sensor-cells = <1>;
compatible = "mediatek,mt8183-thermal";
@@ -1325,6 +1337,10 @@
mipi_tx_calibration: calib@190 {
reg = <0x190 0xc>;
};
+
+ svs_calibration: calib@580 {
+ reg = <0x580 0x64>;
+ };
};
u3phy: t-phy@11f40000 {
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 2/7] arm64: dts: mt8183: add svs device information
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add compatible/reg/irq/clock/efuse setting in svs node.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4b08691ed39e..e8901cbbdf38 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -807,6 +807,18 @@
status = "disabled";
};
+ svs: svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>,
+ <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data",
+ "t-calibration-data";
+ };
+
thermal: thermal@1100b000 {
#thermal-sensor-cells = <1>;
compatible = "mediatek,mt8183-thermal";
@@ -1325,6 +1337,10 @@
mipi_tx_calibration: calib@190 {
reg = <0x190 0xc>;
};
+
+ svs_calibration: calib@580 {
+ reg = <0x580 0x64>;
+ };
};
u3phy: t-phy@11f40000 {
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 2/7] arm64: dts: mt8183: add svs device information
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add compatible/reg/irq/clock/efuse setting in svs node.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4b08691ed39e..e8901cbbdf38 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -807,6 +807,18 @@
status = "disabled";
};
+ svs: svs@1100b000 {
+ compatible = "mediatek,mt8183-svs";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_THERM>;
+ clock-names = "main";
+ nvmem-cells = <&svs_calibration>,
+ <&thermal_calibration>;
+ nvmem-cell-names = "svs-calibration-data",
+ "t-calibration-data";
+ };
+
thermal: thermal@1100b000 {
#thermal-sensor-cells = <1>;
compatible = "mediatek,mt8183-thermal";
@@ -1325,6 +1337,10 @@
mipi_tx_calibration: calib@190 {
reg = <0x190 0xc>;
};
+
+ svs_calibration: calib@580 {
+ reg = <0x580 0x64>;
+ };
};
u3phy: t-phy@11f40000 {
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 1417 ++++++++++++++++++++++++++++++++
3 files changed, 1428 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-svs.c
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..3c3eedea35f7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -73,4 +73,14 @@ config MTK_MMSYS
Say yes here to add support for the MediaTek Multimedia
Subsystem (MMSYS).
+config MTK_SVS
+ tristate "MediaTek Smart Voltage Scaling(SVS)"
+ depends on MTK_EFUSE && NVMEM
+ help
+ The Smart Voltage Scaling(SVS) engine is a piece of hardware
+ which has several controllers(banks) for calculating suitable
+ voltage to different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 90270f8114ed..0e9e703c931a 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
+obj-$(CONFIG_MTK_SVS) += mtk-svs.o
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
new file mode 100644
index 000000000000..cc23a701159e
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -0,0 +1,1417 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/cpuidle.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+/* svs bank 1-line software id */
+#define SVSB_CPU_LITTLE BIT(0)
+#define SVSB_CPU_BIG BIT(1)
+#define SVSB_CCI BIT(2)
+#define SVSB_GPU BIT(3)
+
+/* svs bank mode support */
+#define SVSB_MODE_ALL_DISABLE 0
+#define SVSB_MODE_INIT01 BIT(1)
+#define SVSB_MODE_INIT02 BIT(2)
+
+/* svs bank volt flags */
+#define SVSB_INIT01_PD_REQ BIT(0)
+#define SVSB_INIT01_VOLT_IGNORE BIT(1)
+#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+
+/* svs bank register common configuration */
+#define SVSB_DET_MAX 0xffff
+#define SVSB_DET_WINDOW 0xa28
+#define SVSB_DTHI 0x1
+#define SVSB_DTLO 0xfe
+#define SVSB_EN_INIT01 0x1
+#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_OFF 0x0
+#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTSTS_CLEAN 0x00ffffff
+#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_RUNCONFIG_DEFAULT 0x80000000
+
+/* svs bank related setting */
+#define MAX_OPP_ENTRIES 16
+#define SVSB_DC_SIGNED_BIT BIT(15)
+#define SVSB_DET_CLK_EN BIT(31)
+
+static DEFINE_SPINLOCK(svs_lock);
+
+/**
+ * enum svsb_phase - svs bank phase enumeration
+ * @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
+ * @SVSB_PHASE_INIT01: svs bank basic init for data calibration
+ * @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
+ *
+ * Each svs bank has its own independent phase and we enable each svs bank by
+ * running their phase orderly. However, when svs bank encounters unexpected
+ * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
+ *
+ * svs bank general phase-enabled order:
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ */
+enum svsb_phase {
+ SVSB_PHASE_ERROR = 0,
+ SVSB_PHASE_INIT01,
+ SVSB_PHASE_INIT02,
+ SVSB_PHASE_MAX,
+};
+
+enum svs_reg_index {
+ DESCHAR = 0,
+ TEMPCHAR,
+ DETCHAR,
+ AGECHAR,
+ DCCONFIG,
+ AGECONFIG,
+ FREQPCT30,
+ FREQPCT74,
+ LIMITVALS,
+ VBOOT,
+ DETWINDOW,
+ CONFIG,
+ TSCALCS,
+ RUNCONFIG,
+ SVSEN,
+ INIT2VALS,
+ DCVALUES,
+ AGEVALUES,
+ VOP30,
+ VOP74,
+ TEMP,
+ INTSTS,
+ INTSTSRAW,
+ INTEN,
+ CHKINT,
+ CHKSHIFT,
+ STATUS,
+ VDESIGN30,
+ VDESIGN74,
+ DVT30,
+ DVT74,
+ AGECOUNT,
+ SMSTATE0,
+ SMSTATE1,
+ CTL0,
+ DESDETSEC,
+ TEMPAGESEC,
+ CTRLSPARE0,
+ CTRLSPARE1,
+ CTRLSPARE2,
+ CTRLSPARE3,
+ CORESEL,
+ THERMINTST,
+ INTST,
+ THSTAGE0ST,
+ THSTAGE1ST,
+ THSTAGE2ST,
+ THAHBST0,
+ THAHBST1,
+ SPARE0,
+ SPARE1,
+ SPARE2,
+ SPARE3,
+ THSLPEVEB,
+ SVS_REG_MAX,
+};
+
+static const u32 svs_regs_v2[] = {
+ [DESCHAR] = 0xc00,
+ [TEMPCHAR] = 0xc04,
+ [DETCHAR] = 0xc08,
+ [AGECHAR] = 0xc0c,
+ [DCCONFIG] = 0xc10,
+ [AGECONFIG] = 0xc14,
+ [FREQPCT30] = 0xc18,
+ [FREQPCT74] = 0xc1c,
+ [LIMITVALS] = 0xc20,
+ [VBOOT] = 0xc24,
+ [DETWINDOW] = 0xc28,
+ [CONFIG] = 0xc2c,
+ [TSCALCS] = 0xc30,
+ [RUNCONFIG] = 0xc34,
+ [SVSEN] = 0xc38,
+ [INIT2VALS] = 0xc3c,
+ [DCVALUES] = 0xc40,
+ [AGEVALUES] = 0xc44,
+ [VOP30] = 0xc48,
+ [VOP74] = 0xc4c,
+ [TEMP] = 0xc50,
+ [INTSTS] = 0xc54,
+ [INTSTSRAW] = 0xc58,
+ [INTEN] = 0xc5c,
+ [CHKINT] = 0xc60,
+ [CHKSHIFT] = 0xc64,
+ [STATUS] = 0xc68,
+ [VDESIGN30] = 0xc6c,
+ [VDESIGN74] = 0xc70,
+ [DVT30] = 0xc74,
+ [DVT74] = 0xc78,
+ [AGECOUNT] = 0xc7c,
+ [SMSTATE0] = 0xc80,
+ [SMSTATE1] = 0xc84,
+ [CTL0] = 0xc88,
+ [DESDETSEC] = 0xce0,
+ [TEMPAGESEC] = 0xce4,
+ [CTRLSPARE0] = 0xcf0,
+ [CTRLSPARE1] = 0xcf4,
+ [CTRLSPARE2] = 0xcf8,
+ [CTRLSPARE3] = 0xcfc,
+ [CORESEL] = 0xf00,
+ [THERMINTST] = 0xf04,
+ [INTST] = 0xf08,
+ [THSTAGE0ST] = 0xf0c,
+ [THSTAGE1ST] = 0xf10,
+ [THSTAGE2ST] = 0xf14,
+ [THAHBST0] = 0xf18,
+ [THAHBST1] = 0xf1c,
+ [SPARE0] = 0xf20,
+ [SPARE1] = 0xf24,
+ [SPARE2] = 0xf28,
+ [SPARE3] = 0xf2c,
+ [THSLPEVEB] = 0xf30,
+};
+
+/**
+ * struct svs_platform - svs platform control
+ * @name: svs platform name
+ * @base: svs platform register base
+ * @dev: svs platform device
+ * @main_clk: main clock for svs bank
+ * @pbank: svs bank pointer needing to be protected by spin_lock section
+ * @banks: svs banks that svs platform supports
+ * @efuse_parsing: svs platform efuse parsing function pointer
+ * @probe: svs platform probe function pointer
+ * @irqflags: svs platform irq settings flags
+ * @efuse_max: total number of svs efuse
+ * @regs: svs platform registers map
+ * @bank_max: total number of svs banks
+ * @efuse: svs efuse data received from NVMEM framework
+ */
+struct svs_platform {
+ char *name;
+ void __iomem *base;
+ struct device *dev;
+ struct clk *main_clk;
+ struct svs_bank *pbank;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ size_t efuse_max;
+ const u32 *regs;
+ u32 bank_max;
+ u32 *efuse;
+};
+
+struct svs_platform_data {
+ char *name;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ const u32 *regs;
+ u32 bank_max;
+};
+
+/**
+ * struct svs_bank - svs bank representation
+ * @dev: bank device
+ * @opp_dev: device for opp table/buck control
+ * @init_completion: the timeout completion for bank init
+ * @buck: regulator used by opp_dev
+ * @lock: mutex lock to protect voltage update process
+ * @set_freq_pct: function pointer to set bank frequency percent table
+ * @get_volts: function pointer to get bank voltages
+ * @name: bank name
+ * @buck_name: regulator name
+ * @phase: bank current phase
+ * @volt_od: bank voltage overdrive
+ * @pm_runtime_enabled_count: bank pm runtime enabled count
+ * @mode_support: bank mode support.
+ * @freq_base: reference frequency for bank init
+ * @vboot: voltage request for bank init01 only
+ * @opp_dfreq: default opp frequency table
+ * @opp_dvolt: default opp voltage table
+ * @freq_pct: frequency percent table for bank init
+ * @volt: bank voltage table
+ * @volt_step: bank voltage step
+ * @volt_base: bank voltage base
+ * @volt_flags: bank voltage flags
+ * @vmax: bank voltage maximum
+ * @vmin: bank voltage minimum
+ * @age_config: bank age configuration
+ * @age_voffset_in: bank age voltage offset
+ * @dc_config: bank dc configuration
+ * @dc_voffset_in: bank dc voltage offset
+ * @dvt_fixed: bank dvt fixed value
+ * @vco: bank VCO value
+ * @chk_shift: bank chicken shift
+ * @core_sel: bank selection
+ * @opp_count: bank opp count
+ * @int_st: bank interrupt identification
+ * @sw_id: bank software identification
+ * @cpu_id: cpu core id for SVS CPU bank use only
+ * @ctl0: TS-x selection
+ * @bdes: svs efuse data
+ * @mdes: svs efuse data
+ * @mtdes: svs efuse data
+ * @dcbdet: svs efuse data
+ * @dcmdet: svs efuse data
+ *
+ * Svs bank will generate suitalbe voltages by below general math equation
+ * and provide these voltages to opp voltage table.
+ *
+ * opp_volt[i] = (volt[i] * volt_step) + volt_base;
+ */
+struct svs_bank {
+ struct device *dev;
+ struct device *opp_dev;
+ struct completion init_completion;
+ struct regulator *buck;
+ struct mutex lock; /* lock to protect voltage update process */
+ void (*set_freq_pct)(struct svs_platform *svsp);
+ void (*get_volts)(struct svs_platform *svsp);
+ char *name;
+ char *buck_name;
+ enum svsb_phase phase;
+ s32 volt_od;
+ u32 pm_runtime_enabled_count;
+ u32 mode_support;
+ u32 freq_base;
+ u32 vboot;
+ u32 opp_dfreq[MAX_OPP_ENTRIES];
+ u32 opp_dvolt[MAX_OPP_ENTRIES];
+ u32 freq_pct[MAX_OPP_ENTRIES];
+ u32 volt[MAX_OPP_ENTRIES];
+ u32 volt_step;
+ u32 volt_base;
+ u32 volt_flags;
+ u32 vmax;
+ u32 vmin;
+ u32 age_config;
+ u32 age_voffset_in;
+ u32 dc_config;
+ u32 dc_voffset_in;
+ u32 dvt_fixed;
+ u32 vco;
+ u32 chk_shift;
+ u32 core_sel;
+ u32 opp_count;
+ u32 int_st;
+ u32 sw_id;
+ u32 cpu_id;
+ u32 ctl0;
+ u32 bdes;
+ u32 mdes;
+ u32 mtdes;
+ u32 dcbdet;
+ u32 dcmdet;
+};
+
+static u32 percent(u32 numerator, u32 denominator)
+{
+ /* If not divide 1000, "numerator * 100" will have data overflow. */
+ numerator /= 1000;
+ denominator /= 1000;
+
+ return DIV_ROUND_UP(numerator * 100, denominator);
+}
+
+static u32 svs_readl_relaxed(struct svs_platform *svsp, enum svs_reg_index rg_i)
+{
+ return readl_relaxed(svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_writel_relaxed(struct svs_platform *svsp, u32 val,
+ enum svs_reg_index rg_i)
+{
+ writel_relaxed(val, svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_switch_bank(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp, svsb->core_sel, CORESEL);
+}
+
+static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (svsb_volt * svsb_volt_step) + svsb_volt_base;
+}
+
+static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
+{
+ int ret = -EPERM;
+ u32 i, svsb_volt, opp_volt;
+
+ mutex_lock(&svsb->lock);
+
+ /* vmin <= svsb_volt (opp_volt) <= default opp voltage */
+ for (i = 0; i < svsb->opp_count; i++) {
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ opp_volt = svsb->opp_dvolt[i];
+ break;
+ case SVSB_PHASE_INIT01:
+ /* do nothing */
+ goto unlock_mutex;
+ case SVSB_PHASE_INIT02:
+ svsb_volt = max(svsb->volt[i], svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
+ default:
+ dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ opp_volt = min(opp_volt, svsb->opp_dvolt[i]);
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ opp_volt, opp_volt,
+ svsb->opp_dvolt[i]);
+ if (ret) {
+ dev_err(svsb->dev, "set %uuV fail: %d\n",
+ opp_volt, ret);
+ goto unlock_mutex;
+ }
+ }
+
+unlock_mutex:
+ mutex_unlock(&svsb->lock);
+
+ return ret;
+}
+
+static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
+{
+ u32 vx;
+
+ if (v0 == v1 || f0 == f1)
+ return v0;
+
+ /* *100 to have decimal fraction factor */
+ vx = (v0 * 100) - ((((v0 - v1) * 100) / (f0 - f1)) * (f0 - fx));
+
+ return DIV_ROUND_UP(vx, 100);
+}
+
+static void svs_get_bank_volts_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 temp, i;
+
+ temp = svs_readl_relaxed(svsp, VOP74);
+ svsb->volt[14] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[12] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[10] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[8] = (temp & GENMASK(7, 0));
+
+ temp = svs_readl_relaxed(svsp, VOP30);
+ svsb->volt[6] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[4] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[2] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[0] = (temp & GENMASK(7, 0));
+
+ for (i = 0; i <= 12; i += 2)
+ svsb->volt[i + 1] = interpolate(svsb->freq_pct[i],
+ svsb->freq_pct[i + 2],
+ svsb->volt[i],
+ svsb->volt[i + 2],
+ svsb->freq_pct[i + 1]);
+
+ svsb->volt[15] = interpolate(svsb->freq_pct[12],
+ svsb->freq_pct[14],
+ svsb->volt[12],
+ svsb->volt[14],
+ svsb->freq_pct[15]);
+
+ for (i = 0; i < svsb->opp_count; i++)
+ svsb->volt[i] += svsb->volt_od;
+}
+
+static void svs_set_bank_freq_pct_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[14] << 24) |
+ (svsb->freq_pct[12] << 16) |
+ (svsb->freq_pct[10] << 8) |
+ svsb->freq_pct[8],
+ FREQPCT74);
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[6] << 24) |
+ (svsb->freq_pct[4] << 16) |
+ (svsb->freq_pct[2] << 8) |
+ svsb->freq_pct[0],
+ FREQPCT30);
+}
+
+static void svs_set_bank_phase(struct svs_platform *svsp,
+ enum svsb_phase target_phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals;
+
+ svs_switch_bank(svsp);
+
+ des_char = (svsb->bdes << 8) | svsb->mdes;
+ svs_writel_relaxed(svsp, des_char, DESCHAR);
+
+ temp_char = (svsb->vco << 16) | (svsb->mtdes << 8) | svsb->dvt_fixed;
+ svs_writel_relaxed(svsp, temp_char, TEMPCHAR);
+
+ det_char = (svsb->dcbdet << 8) | svsb->dcmdet;
+ svs_writel_relaxed(svsp, det_char, DETCHAR);
+
+ svs_writel_relaxed(svsp, svsb->dc_config, DCCONFIG);
+ svs_writel_relaxed(svsp, svsb->age_config, AGECONFIG);
+ svs_writel_relaxed(svsp, SVSB_RUNCONFIG_DEFAULT, RUNCONFIG);
+
+ svsb->set_freq_pct(svsp);
+
+ limit_vals = (svsb->vmax << 24) | (svsb->vmin << 16) |
+ (SVSB_DTHI << 8) | SVSB_DTLO;
+ svs_writel_relaxed(svsp, limit_vals, LIMITVALS);
+
+ svs_writel_relaxed(svsp, SVSB_DET_WINDOW, DETWINDOW);
+ svs_writel_relaxed(svsp, SVSB_DET_MAX, CONFIG);
+ svs_writel_relaxed(svsp, svsb->chk_shift, CHKSHIFT);
+ svs_writel_relaxed(svsp, svsb->ctl0, CTL0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+
+ switch (target_phase) {
+ case SVSB_PHASE_INIT01:
+ svs_writel_relaxed(svsp, svsb->vboot, VBOOT);
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT01, SVSEN);
+ break;
+ case SVSB_PHASE_INIT02:
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ init2vals = (svsb->age_voffset_in << 16) | svsb->dc_voffset_in;
+ svs_writel_relaxed(svsp, init2vals, INIT2VALS);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
+ break;
+ default:
+ dev_err(svsb->dev, "requested unknown target phase: %u\n",
+ target_phase);
+ break;
+ }
+}
+
+static inline void svs_error_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, CORESEL));
+ dev_err(svsb->dev, "SVSEN = 0x%08x, INTSTS = 0x%08x\n",
+ svs_readl_relaxed(svsp, SVSEN),
+ svs_readl_relaxed(svsp, INTSTS));
+ dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
+ svs_readl_relaxed(svsp, SMSTATE0),
+ svs_readl_relaxed(svsp, SMSTATE1));
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+}
+
+static inline void svs_init01_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VDESIGN74),
+ svs_readl_relaxed(svsp, VDESIGN30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT01;
+ svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
+ GENMASK(15, 0)) + 1;
+ if (svsb->volt_flags & SVSB_INIT01_VOLT_IGNORE ||
+ (svsb->dc_voffset_in & SVSB_DC_SIGNED_BIT &&
+ svsb->volt_flags & SVSB_INIT01_VOLT_INC_ONLY))
+ svsb->dc_voffset_in = 0;
+
+ svsb->age_voffset_in = svs_readl_relaxed(svsp, AGEVALUES) &
+ GENMASK(15, 0);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+ svsb->core_sel &= ~SVSB_DET_CLK_EN;
+}
+
+static inline void svs_init02_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VOP74),
+ svs_readl_relaxed(svsp, VOP30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT02;
+ svsb->get_volts(svsp);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+}
+
+static irqreturn_t svs_isr(int irq, void *data)
+{
+ struct svs_platform *svsp = data;
+ struct svs_bank *svsb = NULL;
+ unsigned long flags;
+ u32 idx, int_sts, svs_en;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ WARN(!svsb, "%s: svsb(%s) is null", __func__, svsb->name);
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+
+ /* Find out which svs bank fires interrupt */
+ if (svsb->int_st & svs_readl_relaxed(svsp, INTST)) {
+ spin_unlock_irqrestore(&svs_lock, flags);
+ continue;
+ }
+
+ svs_switch_bank(svsp);
+ int_sts = svs_readl_relaxed(svsp, INTSTS);
+ svs_en = svs_readl_relaxed(svsp, SVSEN);
+
+ if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT01)
+ svs_init01_isr_handler(svsp);
+ else if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT02)
+ svs_init02_isr_handler(svsp);
+ else
+ svs_error_isr_handler(svsp);
+
+ spin_unlock_irqrestore(&svs_lock, flags);
+ break;
+ }
+
+ svs_adjust_pm_opp_volts(svsb);
+
+ if (svsb->phase == SVSB_PHASE_INIT01 ||
+ svsb->phase == SVSB_PHASE_INIT02)
+ complete(&svsb->init_completion);
+
+ return IRQ_HANDLED;
+}
+
+static int svs_init01(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ bool search_done;
+ int ret = 0, r;
+ u32 opp_freq, opp_vboot, buck_volt, idx, i;
+
+ /* Keep CPUs' core power on for svs_init01 initialization */
+ cpuidle_pause_and_lock();
+
+ /* Svs bank init01 preparation - power enable */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ ret = regulator_enable(svsb->buck);
+ if (ret) {
+ dev_err(svsb->dev, "%s enable fail: %d\n",
+ svsb->buck_name, ret);
+ goto svs_init01_resume_cpuidle;
+ }
+
+ /* Some buck doesn't support mode change. Show fail msg only */
+ ret = regulator_set_mode(svsb->buck, REGULATOR_MODE_FAST);
+ if (ret)
+ dev_notice(svsb->dev, "set fast mode fail: %d\n", ret);
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ if (!pm_runtime_enabled(svsb->opp_dev)) {
+ pm_runtime_enable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count++;
+ }
+
+ ret = pm_runtime_get_sync(svsb->opp_dev);
+ if (ret < 0) {
+ dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
+ goto svs_init01_resume_cpuidle;
+ }
+ }
+ }
+
+ /*
+ * Svs bank init01 preparation - vboot voltage adjustment
+ * Sometimes two svs banks use the same buck. Therefore,
+ * we have to set each svs bank to target voltage(vboot) first.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ /*
+ * Find the fastest freq that can be run at vboot and
+ * fix to that freq until svs_init01 is done.
+ */
+ search_done = false;
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp_freq = svsb->opp_dfreq[i];
+ if (!search_done && svsb->opp_dvolt[i] <= opp_vboot) {
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ opp_freq,
+ opp_vboot,
+ opp_vboot,
+ opp_vboot);
+ if (ret) {
+ dev_err(svsb->dev,
+ "set opp %uuV vboot fail: %d\n",
+ opp_vboot, ret);
+ goto svs_init01_finish;
+ }
+
+ search_done = true;
+ } else {
+ ret = dev_pm_opp_disable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (ret) {
+ dev_err(svsb->dev,
+ "opp %uHz disable fail: %d\n",
+ svsb->opp_dfreq[i], ret);
+ goto svs_init01_finish;
+ }
+ }
+ }
+ }
+
+ /* Svs bank init01 begins */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ buck_volt = regulator_get_voltage(svsb->buck);
+ if (buck_volt != opp_vboot) {
+ dev_err(svsb->dev,
+ "buck voltage: %uuV, expected vboot: %uuV\n",
+ buck_volt, opp_vboot);
+ ret = -EPERM;
+ goto svs_init01_finish;
+ }
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT01);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init01 completion timeout\n");
+ ret = -EBUSY;
+ goto svs_init01_finish;
+ }
+ }
+
+svs_init01_finish:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ r = dev_pm_opp_enable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (r)
+ dev_err(svsb->dev, "opp %uHz enable fail: %d\n",
+ svsb->opp_dfreq[i], r);
+ }
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ r = pm_runtime_put_sync(svsb->opp_dev);
+ if (r)
+ dev_err(svsb->dev, "mtcmos off fail: %d\n", r);
+
+ if (svsb->pm_runtime_enabled_count > 0) {
+ pm_runtime_disable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count--;
+ }
+ }
+
+ r = regulator_set_mode(svsb->buck, REGULATOR_MODE_NORMAL);
+ if (r)
+ dev_notice(svsb->dev, "set normal mode fail: %d\n", r);
+
+ r = regulator_disable(svsb->buck);
+ if (r)
+ dev_err(svsb->dev, "%s disable fail: %d\n",
+ svsb->buck_name, r);
+ }
+
+svs_init01_resume_cpuidle:
+ cpuidle_resume_and_unlock();
+
+ return ret;
+}
+
+static int svs_init02(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ reinit_completion(&svsb->init_completion);
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT02);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init02 completion timeout\n");
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static int svs_start(struct svs_platform *svsp)
+{
+ int ret;
+
+ ret = svs_init01(svsp);
+ if (ret)
+ return ret;
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_suspend(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ /* This might wait for svs_isr() process */
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ clk_disable_unprepare(svsp->main_clk);
+
+ return 0;
+}
+
+static int svs_resume(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main_clk, disable svs\n");
+ return ret;
+ }
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_bank_resource_setup(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dev_pm_opp *opp;
+ unsigned long freq;
+ int count, ret;
+ u32 idx, i;
+
+ dev_set_drvdata(svsp->dev, svsp);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->name = "SVSB_CPU_LITTLE";
+ break;
+ case SVSB_CPU_BIG:
+ svsb->name = "SVSB_CPU_BIG";
+ break;
+ case SVSB_CCI:
+ svsb->name = "SVSB_CCI";
+ break;
+ case SVSB_GPU:
+ svsb->name = "SVSB_GPU";
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ svsb->dev = devm_kzalloc(svsp->dev, sizeof(*svsb->dev),
+ GFP_KERNEL);
+ if (!svsb->dev)
+ return -ENOMEM;
+
+ ret = dev_set_name(svsb->dev, "%s", svsb->name);
+ if (ret)
+ return ret;
+
+ dev_set_drvdata(svsb->dev, svsp);
+
+ ret = dev_pm_opp_of_add_table(svsb->opp_dev);
+ if (ret) {
+ dev_err(svsb->dev, "add opp table fail: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&svsb->lock);
+ init_completion(&svsb->init_completion);
+
+ if (svsb->mode_support & SVSB_MODE_INIT01) {
+ svsb->buck = devm_regulator_get_optional(svsb->opp_dev,
+ svsb->buck_name);
+ if (IS_ERR(svsb->buck)) {
+ dev_err(svsb->dev, "cannot get \"%s-supply\"\n",
+ svsb->buck_name);
+ return PTR_ERR(svsb->buck);
+ }
+ }
+
+ count = dev_pm_opp_get_opp_count(svsb->opp_dev);
+ if (svsb->opp_count != count) {
+ dev_err(svsb->dev,
+ "opp_count not \"%u\" but get \"%d\"?\n",
+ svsb->opp_count, count);
+ return count;
+ }
+
+ for (i = 0, freq = U32_MAX; i < svsb->opp_count; i++, freq--) {
+ opp = dev_pm_opp_find_freq_floor(svsb->opp_dev, &freq);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %ld\n",
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ svsb->opp_dfreq[i] = freq;
+ svsb->opp_dvolt[i] = dev_pm_opp_get_voltage(opp);
+ svsb->freq_pct[i] = percent(svsb->opp_dfreq[i],
+ svsb->freq_base);
+ dev_pm_opp_put(opp);
+ }
+ }
+
+ return 0;
+}
+
+static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx, i, ft_pgm;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[2]) {
+ dev_notice(svsp->dev, "svs_efuse[2] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ ft_pgm = (svsp->efuse[0] >> 4) & GENMASK(3, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (ft_pgm <= 1)
+ svsb->volt_flags |= SVSB_INIT01_VOLT_IGNORE;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->bdes = svsp->efuse[16] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[16] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[16] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[16] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_CPU_BIG:
+ svsb->bdes = svsp->efuse[18] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[18] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[18] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[18] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[17] & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 15;
+ else
+ svsb->volt_od += 12;
+ break;
+ case SVSB_CCI:
+ svsb->bdes = svsp->efuse[4] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[4] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[4] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[4] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[5] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_GPU:
+ svsb->bdes = svsp->efuse[6] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[6] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[6] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[6] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[5] & GENMASK(7, 0);
+
+ if (ft_pgm >= 2) {
+ svsb->freq_base = 800000000; /* 800MHz */
+ svsb->dvt_fixed = 2;
+ }
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return false;
+ }
+ }
+
+ return true;
+}
+
+static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
+{
+ struct nvmem_cell *cell;
+
+ /* Get svs efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"svs-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_max);
+ if (IS_ERR(svsp->efuse)) {
+ dev_err(svsp->dev, "cannot read svs efuse: %ld\n",
+ PTR_ERR(svsp->efuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->efuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ return svsp->efuse_parsing(svsp);
+}
+
+static struct device *svs_get_subsys_device(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct platform_device *pdev;
+ struct device_node *np;
+
+ np = of_find_node_by_name(NULL, node_name);
+ if (!np) {
+ dev_err(svsp->dev, "cannot find %s node\n", node_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ of_node_put(np);
+ dev_err(svsp->dev, "cannot find pdev by %s\n", node_name);
+ return ERR_PTR(-ENXIO);
+ }
+
+ of_node_put(np);
+
+ return &pdev->dev;
+}
+
+static struct device *svs_add_device_link(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct device *dev;
+ struct device_link *sup_link;
+
+ if (!node_name) {
+ dev_err(svsp->dev, "node name cannot be null\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev = svs_get_subsys_device(svsp, node_name);
+ if (IS_ERR(dev))
+ return dev;
+
+ sup_link = device_link_add(svsp->dev, dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!sup_link) {
+ dev_err(svsp->dev, "sup_link is NULL\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return dev;
+}
+
+static int svs_mt8183_platform_probe(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ case SVSB_CPU_BIG:
+ svsb->opp_dev = get_cpu_device(svsb->cpu_id);
+ break;
+ case SVSB_CCI:
+ svsb->opp_dev = svs_add_device_link(svsp, "cci");
+ break;
+ case SVSB_GPU:
+ svsb->opp_dev = svs_add_device_link(svsp, "gpu");
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
+static struct svs_bank svs_mt8183_banks[] = {
+ {
+ .sw_id = SVSB_CPU_LITTLE,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 0,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0000,
+ .int_st = BIT(0),
+ .ctl0 = 0x00010001,
+ },
+ {
+ .sw_id = SVSB_CPU_BIG,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 4,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x58,
+ .vmin = 0x10,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0001,
+ .int_st = BIT(1),
+ .ctl0 = 0x00000001,
+ },
+ {
+ .sw_id = SVSB_CCI,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1196000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0002,
+ .int_st = BIT(2),
+ .ctl0 = 0x00100003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "mali",
+ .volt_flags = SVSB_INIT01_PD_REQ |
+ SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 900000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x40,
+ .vmin = 0x14,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x3,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0003,
+ .int_st = BIT(3),
+ .ctl0 = 0x00050001,
+ },
+};
+
+static const struct svs_platform_data svs_mt8183_platform_data = {
+ .name = "mt8183-svs",
+ .banks = svs_mt8183_banks,
+ .efuse_parsing = svs_mt8183_efuse_parsing,
+ .probe = svs_mt8183_platform_probe,
+ .irqflags = IRQF_TRIGGER_LOW,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8183_banks),
+};
+
+static const struct of_device_id svs_of_match[] = {
+ {
+ .compatible = "mediatek,mt8183-svs",
+ .data = &svs_mt8183_platform_data,
+ }, {
+ /* Sentinel */
+ },
+};
+
+static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ const struct svs_platform_data *svsp_data;
+ int ret;
+
+ svsp_data = of_device_get_match_data(&pdev->dev);
+ if (!svsp_data) {
+ dev_err(&pdev->dev, "no svs platform data?\n");
+ return ERR_PTR(-EPERM);
+ }
+
+ svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
+ if (!svsp)
+ return ERR_PTR(-ENOMEM);
+
+ svsp->dev = &pdev->dev;
+ svsp->name = svsp_data->name;
+ svsp->banks = svsp_data->banks;
+ svsp->efuse_parsing = svsp_data->efuse_parsing;
+ svsp->probe = svsp_data->probe;
+ svsp->irqflags = svsp_data->irqflags;
+ svsp->regs = svsp_data->regs;
+ svsp->bank_max = svsp_data->bank_max;
+
+ ret = svsp->probe(svsp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return svsp;
+}
+
+static int svs_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ unsigned int svsp_irq;
+ int ret;
+
+ svsp = svs_platform_probe(pdev);
+ if (IS_ERR(svsp))
+ return PTR_ERR(svsp);
+
+ if (!svs_is_efuse_data_correct(svsp)) {
+ dev_notice(svsp->dev, "efuse data isn't correct\n");
+ ret = -EPERM;
+ goto svs_probe_free_resource;
+ }
+
+ ret = svs_bank_resource_setup(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs bank resource setup fail: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp_irq = irq_of_parse_and_map(svsp->dev->of_node, 0);
+ ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+ svsp->irqflags | IRQF_ONESHOT,
+ svsp->name, svsp);
+ if (ret) {
+ dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+ svsp_irq, ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->main_clk = devm_clk_get(svsp->dev, "main");
+ if (IS_ERR(svsp->main_clk)) {
+ dev_err(svsp->dev, "failed to get clock: %ld\n",
+ PTR_ERR(svsp->main_clk));
+ ret = PTR_ERR(svsp->main_clk);
+ goto svs_probe_free_resource;
+ }
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->base = of_iomap(svsp->dev->of_node, 0);
+ if (IS_ERR_OR_NULL(svsp->base)) {
+ dev_err(svsp->dev, "cannot find svs register base\n");
+ ret = -EINVAL;
+ goto svs_probe_clk_disable;
+ }
+
+ ret = svs_start(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs start fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
+ return 0;
+
+svs_probe_iounmap:
+ iounmap(svsp->base);
+
+svs_probe_clk_disable:
+ clk_disable_unprepare(svsp->main_clk);
+
+svs_probe_free_resource:
+ if (!IS_ERR_OR_NULL(svsp->efuse))
+ kfree(svsp->efuse);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(svs_pm_ops, svs_suspend, svs_resume);
+
+static struct platform_driver svs_driver = {
+ .probe = svs_probe,
+ .driver = {
+ .name = "mtk-svs",
+ .pm = &svs_pm_ops,
+ .of_match_table = of_match_ptr(svs_of_match),
+ },
+};
+
+module_platform_driver(svs_driver);
+
+MODULE_AUTHOR("Roger Lu <roger.lu@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek SVS driver");
+MODULE_LICENSE("GPL");
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 1417 ++++++++++++++++++++++++++++++++
3 files changed, 1428 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-svs.c
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..3c3eedea35f7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -73,4 +73,14 @@ config MTK_MMSYS
Say yes here to add support for the MediaTek Multimedia
Subsystem (MMSYS).
+config MTK_SVS
+ tristate "MediaTek Smart Voltage Scaling(SVS)"
+ depends on MTK_EFUSE && NVMEM
+ help
+ The Smart Voltage Scaling(SVS) engine is a piece of hardware
+ which has several controllers(banks) for calculating suitable
+ voltage to different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 90270f8114ed..0e9e703c931a 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
+obj-$(CONFIG_MTK_SVS) += mtk-svs.o
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
new file mode 100644
index 000000000000..cc23a701159e
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -0,0 +1,1417 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/cpuidle.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+/* svs bank 1-line software id */
+#define SVSB_CPU_LITTLE BIT(0)
+#define SVSB_CPU_BIG BIT(1)
+#define SVSB_CCI BIT(2)
+#define SVSB_GPU BIT(3)
+
+/* svs bank mode support */
+#define SVSB_MODE_ALL_DISABLE 0
+#define SVSB_MODE_INIT01 BIT(1)
+#define SVSB_MODE_INIT02 BIT(2)
+
+/* svs bank volt flags */
+#define SVSB_INIT01_PD_REQ BIT(0)
+#define SVSB_INIT01_VOLT_IGNORE BIT(1)
+#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+
+/* svs bank register common configuration */
+#define SVSB_DET_MAX 0xffff
+#define SVSB_DET_WINDOW 0xa28
+#define SVSB_DTHI 0x1
+#define SVSB_DTLO 0xfe
+#define SVSB_EN_INIT01 0x1
+#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_OFF 0x0
+#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTSTS_CLEAN 0x00ffffff
+#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_RUNCONFIG_DEFAULT 0x80000000
+
+/* svs bank related setting */
+#define MAX_OPP_ENTRIES 16
+#define SVSB_DC_SIGNED_BIT BIT(15)
+#define SVSB_DET_CLK_EN BIT(31)
+
+static DEFINE_SPINLOCK(svs_lock);
+
+/**
+ * enum svsb_phase - svs bank phase enumeration
+ * @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
+ * @SVSB_PHASE_INIT01: svs bank basic init for data calibration
+ * @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
+ *
+ * Each svs bank has its own independent phase and we enable each svs bank by
+ * running their phase orderly. However, when svs bank encounters unexpected
+ * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
+ *
+ * svs bank general phase-enabled order:
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ */
+enum svsb_phase {
+ SVSB_PHASE_ERROR = 0,
+ SVSB_PHASE_INIT01,
+ SVSB_PHASE_INIT02,
+ SVSB_PHASE_MAX,
+};
+
+enum svs_reg_index {
+ DESCHAR = 0,
+ TEMPCHAR,
+ DETCHAR,
+ AGECHAR,
+ DCCONFIG,
+ AGECONFIG,
+ FREQPCT30,
+ FREQPCT74,
+ LIMITVALS,
+ VBOOT,
+ DETWINDOW,
+ CONFIG,
+ TSCALCS,
+ RUNCONFIG,
+ SVSEN,
+ INIT2VALS,
+ DCVALUES,
+ AGEVALUES,
+ VOP30,
+ VOP74,
+ TEMP,
+ INTSTS,
+ INTSTSRAW,
+ INTEN,
+ CHKINT,
+ CHKSHIFT,
+ STATUS,
+ VDESIGN30,
+ VDESIGN74,
+ DVT30,
+ DVT74,
+ AGECOUNT,
+ SMSTATE0,
+ SMSTATE1,
+ CTL0,
+ DESDETSEC,
+ TEMPAGESEC,
+ CTRLSPARE0,
+ CTRLSPARE1,
+ CTRLSPARE2,
+ CTRLSPARE3,
+ CORESEL,
+ THERMINTST,
+ INTST,
+ THSTAGE0ST,
+ THSTAGE1ST,
+ THSTAGE2ST,
+ THAHBST0,
+ THAHBST1,
+ SPARE0,
+ SPARE1,
+ SPARE2,
+ SPARE3,
+ THSLPEVEB,
+ SVS_REG_MAX,
+};
+
+static const u32 svs_regs_v2[] = {
+ [DESCHAR] = 0xc00,
+ [TEMPCHAR] = 0xc04,
+ [DETCHAR] = 0xc08,
+ [AGECHAR] = 0xc0c,
+ [DCCONFIG] = 0xc10,
+ [AGECONFIG] = 0xc14,
+ [FREQPCT30] = 0xc18,
+ [FREQPCT74] = 0xc1c,
+ [LIMITVALS] = 0xc20,
+ [VBOOT] = 0xc24,
+ [DETWINDOW] = 0xc28,
+ [CONFIG] = 0xc2c,
+ [TSCALCS] = 0xc30,
+ [RUNCONFIG] = 0xc34,
+ [SVSEN] = 0xc38,
+ [INIT2VALS] = 0xc3c,
+ [DCVALUES] = 0xc40,
+ [AGEVALUES] = 0xc44,
+ [VOP30] = 0xc48,
+ [VOP74] = 0xc4c,
+ [TEMP] = 0xc50,
+ [INTSTS] = 0xc54,
+ [INTSTSRAW] = 0xc58,
+ [INTEN] = 0xc5c,
+ [CHKINT] = 0xc60,
+ [CHKSHIFT] = 0xc64,
+ [STATUS] = 0xc68,
+ [VDESIGN30] = 0xc6c,
+ [VDESIGN74] = 0xc70,
+ [DVT30] = 0xc74,
+ [DVT74] = 0xc78,
+ [AGECOUNT] = 0xc7c,
+ [SMSTATE0] = 0xc80,
+ [SMSTATE1] = 0xc84,
+ [CTL0] = 0xc88,
+ [DESDETSEC] = 0xce0,
+ [TEMPAGESEC] = 0xce4,
+ [CTRLSPARE0] = 0xcf0,
+ [CTRLSPARE1] = 0xcf4,
+ [CTRLSPARE2] = 0xcf8,
+ [CTRLSPARE3] = 0xcfc,
+ [CORESEL] = 0xf00,
+ [THERMINTST] = 0xf04,
+ [INTST] = 0xf08,
+ [THSTAGE0ST] = 0xf0c,
+ [THSTAGE1ST] = 0xf10,
+ [THSTAGE2ST] = 0xf14,
+ [THAHBST0] = 0xf18,
+ [THAHBST1] = 0xf1c,
+ [SPARE0] = 0xf20,
+ [SPARE1] = 0xf24,
+ [SPARE2] = 0xf28,
+ [SPARE3] = 0xf2c,
+ [THSLPEVEB] = 0xf30,
+};
+
+/**
+ * struct svs_platform - svs platform control
+ * @name: svs platform name
+ * @base: svs platform register base
+ * @dev: svs platform device
+ * @main_clk: main clock for svs bank
+ * @pbank: svs bank pointer needing to be protected by spin_lock section
+ * @banks: svs banks that svs platform supports
+ * @efuse_parsing: svs platform efuse parsing function pointer
+ * @probe: svs platform probe function pointer
+ * @irqflags: svs platform irq settings flags
+ * @efuse_max: total number of svs efuse
+ * @regs: svs platform registers map
+ * @bank_max: total number of svs banks
+ * @efuse: svs efuse data received from NVMEM framework
+ */
+struct svs_platform {
+ char *name;
+ void __iomem *base;
+ struct device *dev;
+ struct clk *main_clk;
+ struct svs_bank *pbank;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ size_t efuse_max;
+ const u32 *regs;
+ u32 bank_max;
+ u32 *efuse;
+};
+
+struct svs_platform_data {
+ char *name;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ const u32 *regs;
+ u32 bank_max;
+};
+
+/**
+ * struct svs_bank - svs bank representation
+ * @dev: bank device
+ * @opp_dev: device for opp table/buck control
+ * @init_completion: the timeout completion for bank init
+ * @buck: regulator used by opp_dev
+ * @lock: mutex lock to protect voltage update process
+ * @set_freq_pct: function pointer to set bank frequency percent table
+ * @get_volts: function pointer to get bank voltages
+ * @name: bank name
+ * @buck_name: regulator name
+ * @phase: bank current phase
+ * @volt_od: bank voltage overdrive
+ * @pm_runtime_enabled_count: bank pm runtime enabled count
+ * @mode_support: bank mode support.
+ * @freq_base: reference frequency for bank init
+ * @vboot: voltage request for bank init01 only
+ * @opp_dfreq: default opp frequency table
+ * @opp_dvolt: default opp voltage table
+ * @freq_pct: frequency percent table for bank init
+ * @volt: bank voltage table
+ * @volt_step: bank voltage step
+ * @volt_base: bank voltage base
+ * @volt_flags: bank voltage flags
+ * @vmax: bank voltage maximum
+ * @vmin: bank voltage minimum
+ * @age_config: bank age configuration
+ * @age_voffset_in: bank age voltage offset
+ * @dc_config: bank dc configuration
+ * @dc_voffset_in: bank dc voltage offset
+ * @dvt_fixed: bank dvt fixed value
+ * @vco: bank VCO value
+ * @chk_shift: bank chicken shift
+ * @core_sel: bank selection
+ * @opp_count: bank opp count
+ * @int_st: bank interrupt identification
+ * @sw_id: bank software identification
+ * @cpu_id: cpu core id for SVS CPU bank use only
+ * @ctl0: TS-x selection
+ * @bdes: svs efuse data
+ * @mdes: svs efuse data
+ * @mtdes: svs efuse data
+ * @dcbdet: svs efuse data
+ * @dcmdet: svs efuse data
+ *
+ * Svs bank will generate suitalbe voltages by below general math equation
+ * and provide these voltages to opp voltage table.
+ *
+ * opp_volt[i] = (volt[i] * volt_step) + volt_base;
+ */
+struct svs_bank {
+ struct device *dev;
+ struct device *opp_dev;
+ struct completion init_completion;
+ struct regulator *buck;
+ struct mutex lock; /* lock to protect voltage update process */
+ void (*set_freq_pct)(struct svs_platform *svsp);
+ void (*get_volts)(struct svs_platform *svsp);
+ char *name;
+ char *buck_name;
+ enum svsb_phase phase;
+ s32 volt_od;
+ u32 pm_runtime_enabled_count;
+ u32 mode_support;
+ u32 freq_base;
+ u32 vboot;
+ u32 opp_dfreq[MAX_OPP_ENTRIES];
+ u32 opp_dvolt[MAX_OPP_ENTRIES];
+ u32 freq_pct[MAX_OPP_ENTRIES];
+ u32 volt[MAX_OPP_ENTRIES];
+ u32 volt_step;
+ u32 volt_base;
+ u32 volt_flags;
+ u32 vmax;
+ u32 vmin;
+ u32 age_config;
+ u32 age_voffset_in;
+ u32 dc_config;
+ u32 dc_voffset_in;
+ u32 dvt_fixed;
+ u32 vco;
+ u32 chk_shift;
+ u32 core_sel;
+ u32 opp_count;
+ u32 int_st;
+ u32 sw_id;
+ u32 cpu_id;
+ u32 ctl0;
+ u32 bdes;
+ u32 mdes;
+ u32 mtdes;
+ u32 dcbdet;
+ u32 dcmdet;
+};
+
+static u32 percent(u32 numerator, u32 denominator)
+{
+ /* If not divide 1000, "numerator * 100" will have data overflow. */
+ numerator /= 1000;
+ denominator /= 1000;
+
+ return DIV_ROUND_UP(numerator * 100, denominator);
+}
+
+static u32 svs_readl_relaxed(struct svs_platform *svsp, enum svs_reg_index rg_i)
+{
+ return readl_relaxed(svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_writel_relaxed(struct svs_platform *svsp, u32 val,
+ enum svs_reg_index rg_i)
+{
+ writel_relaxed(val, svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_switch_bank(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp, svsb->core_sel, CORESEL);
+}
+
+static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (svsb_volt * svsb_volt_step) + svsb_volt_base;
+}
+
+static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
+{
+ int ret = -EPERM;
+ u32 i, svsb_volt, opp_volt;
+
+ mutex_lock(&svsb->lock);
+
+ /* vmin <= svsb_volt (opp_volt) <= default opp voltage */
+ for (i = 0; i < svsb->opp_count; i++) {
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ opp_volt = svsb->opp_dvolt[i];
+ break;
+ case SVSB_PHASE_INIT01:
+ /* do nothing */
+ goto unlock_mutex;
+ case SVSB_PHASE_INIT02:
+ svsb_volt = max(svsb->volt[i], svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
+ default:
+ dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ opp_volt = min(opp_volt, svsb->opp_dvolt[i]);
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ opp_volt, opp_volt,
+ svsb->opp_dvolt[i]);
+ if (ret) {
+ dev_err(svsb->dev, "set %uuV fail: %d\n",
+ opp_volt, ret);
+ goto unlock_mutex;
+ }
+ }
+
+unlock_mutex:
+ mutex_unlock(&svsb->lock);
+
+ return ret;
+}
+
+static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
+{
+ u32 vx;
+
+ if (v0 == v1 || f0 == f1)
+ return v0;
+
+ /* *100 to have decimal fraction factor */
+ vx = (v0 * 100) - ((((v0 - v1) * 100) / (f0 - f1)) * (f0 - fx));
+
+ return DIV_ROUND_UP(vx, 100);
+}
+
+static void svs_get_bank_volts_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 temp, i;
+
+ temp = svs_readl_relaxed(svsp, VOP74);
+ svsb->volt[14] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[12] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[10] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[8] = (temp & GENMASK(7, 0));
+
+ temp = svs_readl_relaxed(svsp, VOP30);
+ svsb->volt[6] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[4] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[2] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[0] = (temp & GENMASK(7, 0));
+
+ for (i = 0; i <= 12; i += 2)
+ svsb->volt[i + 1] = interpolate(svsb->freq_pct[i],
+ svsb->freq_pct[i + 2],
+ svsb->volt[i],
+ svsb->volt[i + 2],
+ svsb->freq_pct[i + 1]);
+
+ svsb->volt[15] = interpolate(svsb->freq_pct[12],
+ svsb->freq_pct[14],
+ svsb->volt[12],
+ svsb->volt[14],
+ svsb->freq_pct[15]);
+
+ for (i = 0; i < svsb->opp_count; i++)
+ svsb->volt[i] += svsb->volt_od;
+}
+
+static void svs_set_bank_freq_pct_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[14] << 24) |
+ (svsb->freq_pct[12] << 16) |
+ (svsb->freq_pct[10] << 8) |
+ svsb->freq_pct[8],
+ FREQPCT74);
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[6] << 24) |
+ (svsb->freq_pct[4] << 16) |
+ (svsb->freq_pct[2] << 8) |
+ svsb->freq_pct[0],
+ FREQPCT30);
+}
+
+static void svs_set_bank_phase(struct svs_platform *svsp,
+ enum svsb_phase target_phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals;
+
+ svs_switch_bank(svsp);
+
+ des_char = (svsb->bdes << 8) | svsb->mdes;
+ svs_writel_relaxed(svsp, des_char, DESCHAR);
+
+ temp_char = (svsb->vco << 16) | (svsb->mtdes << 8) | svsb->dvt_fixed;
+ svs_writel_relaxed(svsp, temp_char, TEMPCHAR);
+
+ det_char = (svsb->dcbdet << 8) | svsb->dcmdet;
+ svs_writel_relaxed(svsp, det_char, DETCHAR);
+
+ svs_writel_relaxed(svsp, svsb->dc_config, DCCONFIG);
+ svs_writel_relaxed(svsp, svsb->age_config, AGECONFIG);
+ svs_writel_relaxed(svsp, SVSB_RUNCONFIG_DEFAULT, RUNCONFIG);
+
+ svsb->set_freq_pct(svsp);
+
+ limit_vals = (svsb->vmax << 24) | (svsb->vmin << 16) |
+ (SVSB_DTHI << 8) | SVSB_DTLO;
+ svs_writel_relaxed(svsp, limit_vals, LIMITVALS);
+
+ svs_writel_relaxed(svsp, SVSB_DET_WINDOW, DETWINDOW);
+ svs_writel_relaxed(svsp, SVSB_DET_MAX, CONFIG);
+ svs_writel_relaxed(svsp, svsb->chk_shift, CHKSHIFT);
+ svs_writel_relaxed(svsp, svsb->ctl0, CTL0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+
+ switch (target_phase) {
+ case SVSB_PHASE_INIT01:
+ svs_writel_relaxed(svsp, svsb->vboot, VBOOT);
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT01, SVSEN);
+ break;
+ case SVSB_PHASE_INIT02:
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ init2vals = (svsb->age_voffset_in << 16) | svsb->dc_voffset_in;
+ svs_writel_relaxed(svsp, init2vals, INIT2VALS);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
+ break;
+ default:
+ dev_err(svsb->dev, "requested unknown target phase: %u\n",
+ target_phase);
+ break;
+ }
+}
+
+static inline void svs_error_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, CORESEL));
+ dev_err(svsb->dev, "SVSEN = 0x%08x, INTSTS = 0x%08x\n",
+ svs_readl_relaxed(svsp, SVSEN),
+ svs_readl_relaxed(svsp, INTSTS));
+ dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
+ svs_readl_relaxed(svsp, SMSTATE0),
+ svs_readl_relaxed(svsp, SMSTATE1));
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+}
+
+static inline void svs_init01_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VDESIGN74),
+ svs_readl_relaxed(svsp, VDESIGN30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT01;
+ svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
+ GENMASK(15, 0)) + 1;
+ if (svsb->volt_flags & SVSB_INIT01_VOLT_IGNORE ||
+ (svsb->dc_voffset_in & SVSB_DC_SIGNED_BIT &&
+ svsb->volt_flags & SVSB_INIT01_VOLT_INC_ONLY))
+ svsb->dc_voffset_in = 0;
+
+ svsb->age_voffset_in = svs_readl_relaxed(svsp, AGEVALUES) &
+ GENMASK(15, 0);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+ svsb->core_sel &= ~SVSB_DET_CLK_EN;
+}
+
+static inline void svs_init02_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VOP74),
+ svs_readl_relaxed(svsp, VOP30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT02;
+ svsb->get_volts(svsp);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+}
+
+static irqreturn_t svs_isr(int irq, void *data)
+{
+ struct svs_platform *svsp = data;
+ struct svs_bank *svsb = NULL;
+ unsigned long flags;
+ u32 idx, int_sts, svs_en;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ WARN(!svsb, "%s: svsb(%s) is null", __func__, svsb->name);
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+
+ /* Find out which svs bank fires interrupt */
+ if (svsb->int_st & svs_readl_relaxed(svsp, INTST)) {
+ spin_unlock_irqrestore(&svs_lock, flags);
+ continue;
+ }
+
+ svs_switch_bank(svsp);
+ int_sts = svs_readl_relaxed(svsp, INTSTS);
+ svs_en = svs_readl_relaxed(svsp, SVSEN);
+
+ if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT01)
+ svs_init01_isr_handler(svsp);
+ else if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT02)
+ svs_init02_isr_handler(svsp);
+ else
+ svs_error_isr_handler(svsp);
+
+ spin_unlock_irqrestore(&svs_lock, flags);
+ break;
+ }
+
+ svs_adjust_pm_opp_volts(svsb);
+
+ if (svsb->phase == SVSB_PHASE_INIT01 ||
+ svsb->phase == SVSB_PHASE_INIT02)
+ complete(&svsb->init_completion);
+
+ return IRQ_HANDLED;
+}
+
+static int svs_init01(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ bool search_done;
+ int ret = 0, r;
+ u32 opp_freq, opp_vboot, buck_volt, idx, i;
+
+ /* Keep CPUs' core power on for svs_init01 initialization */
+ cpuidle_pause_and_lock();
+
+ /* Svs bank init01 preparation - power enable */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ ret = regulator_enable(svsb->buck);
+ if (ret) {
+ dev_err(svsb->dev, "%s enable fail: %d\n",
+ svsb->buck_name, ret);
+ goto svs_init01_resume_cpuidle;
+ }
+
+ /* Some buck doesn't support mode change. Show fail msg only */
+ ret = regulator_set_mode(svsb->buck, REGULATOR_MODE_FAST);
+ if (ret)
+ dev_notice(svsb->dev, "set fast mode fail: %d\n", ret);
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ if (!pm_runtime_enabled(svsb->opp_dev)) {
+ pm_runtime_enable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count++;
+ }
+
+ ret = pm_runtime_get_sync(svsb->opp_dev);
+ if (ret < 0) {
+ dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
+ goto svs_init01_resume_cpuidle;
+ }
+ }
+ }
+
+ /*
+ * Svs bank init01 preparation - vboot voltage adjustment
+ * Sometimes two svs banks use the same buck. Therefore,
+ * we have to set each svs bank to target voltage(vboot) first.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ /*
+ * Find the fastest freq that can be run at vboot and
+ * fix to that freq until svs_init01 is done.
+ */
+ search_done = false;
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp_freq = svsb->opp_dfreq[i];
+ if (!search_done && svsb->opp_dvolt[i] <= opp_vboot) {
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ opp_freq,
+ opp_vboot,
+ opp_vboot,
+ opp_vboot);
+ if (ret) {
+ dev_err(svsb->dev,
+ "set opp %uuV vboot fail: %d\n",
+ opp_vboot, ret);
+ goto svs_init01_finish;
+ }
+
+ search_done = true;
+ } else {
+ ret = dev_pm_opp_disable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (ret) {
+ dev_err(svsb->dev,
+ "opp %uHz disable fail: %d\n",
+ svsb->opp_dfreq[i], ret);
+ goto svs_init01_finish;
+ }
+ }
+ }
+ }
+
+ /* Svs bank init01 begins */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ buck_volt = regulator_get_voltage(svsb->buck);
+ if (buck_volt != opp_vboot) {
+ dev_err(svsb->dev,
+ "buck voltage: %uuV, expected vboot: %uuV\n",
+ buck_volt, opp_vboot);
+ ret = -EPERM;
+ goto svs_init01_finish;
+ }
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT01);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init01 completion timeout\n");
+ ret = -EBUSY;
+ goto svs_init01_finish;
+ }
+ }
+
+svs_init01_finish:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ r = dev_pm_opp_enable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (r)
+ dev_err(svsb->dev, "opp %uHz enable fail: %d\n",
+ svsb->opp_dfreq[i], r);
+ }
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ r = pm_runtime_put_sync(svsb->opp_dev);
+ if (r)
+ dev_err(svsb->dev, "mtcmos off fail: %d\n", r);
+
+ if (svsb->pm_runtime_enabled_count > 0) {
+ pm_runtime_disable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count--;
+ }
+ }
+
+ r = regulator_set_mode(svsb->buck, REGULATOR_MODE_NORMAL);
+ if (r)
+ dev_notice(svsb->dev, "set normal mode fail: %d\n", r);
+
+ r = regulator_disable(svsb->buck);
+ if (r)
+ dev_err(svsb->dev, "%s disable fail: %d\n",
+ svsb->buck_name, r);
+ }
+
+svs_init01_resume_cpuidle:
+ cpuidle_resume_and_unlock();
+
+ return ret;
+}
+
+static int svs_init02(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ reinit_completion(&svsb->init_completion);
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT02);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init02 completion timeout\n");
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static int svs_start(struct svs_platform *svsp)
+{
+ int ret;
+
+ ret = svs_init01(svsp);
+ if (ret)
+ return ret;
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_suspend(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ /* This might wait for svs_isr() process */
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ clk_disable_unprepare(svsp->main_clk);
+
+ return 0;
+}
+
+static int svs_resume(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main_clk, disable svs\n");
+ return ret;
+ }
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_bank_resource_setup(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dev_pm_opp *opp;
+ unsigned long freq;
+ int count, ret;
+ u32 idx, i;
+
+ dev_set_drvdata(svsp->dev, svsp);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->name = "SVSB_CPU_LITTLE";
+ break;
+ case SVSB_CPU_BIG:
+ svsb->name = "SVSB_CPU_BIG";
+ break;
+ case SVSB_CCI:
+ svsb->name = "SVSB_CCI";
+ break;
+ case SVSB_GPU:
+ svsb->name = "SVSB_GPU";
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ svsb->dev = devm_kzalloc(svsp->dev, sizeof(*svsb->dev),
+ GFP_KERNEL);
+ if (!svsb->dev)
+ return -ENOMEM;
+
+ ret = dev_set_name(svsb->dev, "%s", svsb->name);
+ if (ret)
+ return ret;
+
+ dev_set_drvdata(svsb->dev, svsp);
+
+ ret = dev_pm_opp_of_add_table(svsb->opp_dev);
+ if (ret) {
+ dev_err(svsb->dev, "add opp table fail: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&svsb->lock);
+ init_completion(&svsb->init_completion);
+
+ if (svsb->mode_support & SVSB_MODE_INIT01) {
+ svsb->buck = devm_regulator_get_optional(svsb->opp_dev,
+ svsb->buck_name);
+ if (IS_ERR(svsb->buck)) {
+ dev_err(svsb->dev, "cannot get \"%s-supply\"\n",
+ svsb->buck_name);
+ return PTR_ERR(svsb->buck);
+ }
+ }
+
+ count = dev_pm_opp_get_opp_count(svsb->opp_dev);
+ if (svsb->opp_count != count) {
+ dev_err(svsb->dev,
+ "opp_count not \"%u\" but get \"%d\"?\n",
+ svsb->opp_count, count);
+ return count;
+ }
+
+ for (i = 0, freq = U32_MAX; i < svsb->opp_count; i++, freq--) {
+ opp = dev_pm_opp_find_freq_floor(svsb->opp_dev, &freq);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %ld\n",
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ svsb->opp_dfreq[i] = freq;
+ svsb->opp_dvolt[i] = dev_pm_opp_get_voltage(opp);
+ svsb->freq_pct[i] = percent(svsb->opp_dfreq[i],
+ svsb->freq_base);
+ dev_pm_opp_put(opp);
+ }
+ }
+
+ return 0;
+}
+
+static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx, i, ft_pgm;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[2]) {
+ dev_notice(svsp->dev, "svs_efuse[2] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ ft_pgm = (svsp->efuse[0] >> 4) & GENMASK(3, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (ft_pgm <= 1)
+ svsb->volt_flags |= SVSB_INIT01_VOLT_IGNORE;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->bdes = svsp->efuse[16] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[16] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[16] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[16] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_CPU_BIG:
+ svsb->bdes = svsp->efuse[18] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[18] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[18] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[18] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[17] & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 15;
+ else
+ svsb->volt_od += 12;
+ break;
+ case SVSB_CCI:
+ svsb->bdes = svsp->efuse[4] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[4] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[4] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[4] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[5] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_GPU:
+ svsb->bdes = svsp->efuse[6] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[6] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[6] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[6] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[5] & GENMASK(7, 0);
+
+ if (ft_pgm >= 2) {
+ svsb->freq_base = 800000000; /* 800MHz */
+ svsb->dvt_fixed = 2;
+ }
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return false;
+ }
+ }
+
+ return true;
+}
+
+static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
+{
+ struct nvmem_cell *cell;
+
+ /* Get svs efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"svs-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_max);
+ if (IS_ERR(svsp->efuse)) {
+ dev_err(svsp->dev, "cannot read svs efuse: %ld\n",
+ PTR_ERR(svsp->efuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->efuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ return svsp->efuse_parsing(svsp);
+}
+
+static struct device *svs_get_subsys_device(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct platform_device *pdev;
+ struct device_node *np;
+
+ np = of_find_node_by_name(NULL, node_name);
+ if (!np) {
+ dev_err(svsp->dev, "cannot find %s node\n", node_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ of_node_put(np);
+ dev_err(svsp->dev, "cannot find pdev by %s\n", node_name);
+ return ERR_PTR(-ENXIO);
+ }
+
+ of_node_put(np);
+
+ return &pdev->dev;
+}
+
+static struct device *svs_add_device_link(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct device *dev;
+ struct device_link *sup_link;
+
+ if (!node_name) {
+ dev_err(svsp->dev, "node name cannot be null\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev = svs_get_subsys_device(svsp, node_name);
+ if (IS_ERR(dev))
+ return dev;
+
+ sup_link = device_link_add(svsp->dev, dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!sup_link) {
+ dev_err(svsp->dev, "sup_link is NULL\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return dev;
+}
+
+static int svs_mt8183_platform_probe(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ case SVSB_CPU_BIG:
+ svsb->opp_dev = get_cpu_device(svsb->cpu_id);
+ break;
+ case SVSB_CCI:
+ svsb->opp_dev = svs_add_device_link(svsp, "cci");
+ break;
+ case SVSB_GPU:
+ svsb->opp_dev = svs_add_device_link(svsp, "gpu");
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
+static struct svs_bank svs_mt8183_banks[] = {
+ {
+ .sw_id = SVSB_CPU_LITTLE,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 0,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0000,
+ .int_st = BIT(0),
+ .ctl0 = 0x00010001,
+ },
+ {
+ .sw_id = SVSB_CPU_BIG,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 4,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x58,
+ .vmin = 0x10,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0001,
+ .int_st = BIT(1),
+ .ctl0 = 0x00000001,
+ },
+ {
+ .sw_id = SVSB_CCI,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1196000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0002,
+ .int_st = BIT(2),
+ .ctl0 = 0x00100003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "mali",
+ .volt_flags = SVSB_INIT01_PD_REQ |
+ SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 900000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x40,
+ .vmin = 0x14,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x3,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0003,
+ .int_st = BIT(3),
+ .ctl0 = 0x00050001,
+ },
+};
+
+static const struct svs_platform_data svs_mt8183_platform_data = {
+ .name = "mt8183-svs",
+ .banks = svs_mt8183_banks,
+ .efuse_parsing = svs_mt8183_efuse_parsing,
+ .probe = svs_mt8183_platform_probe,
+ .irqflags = IRQF_TRIGGER_LOW,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8183_banks),
+};
+
+static const struct of_device_id svs_of_match[] = {
+ {
+ .compatible = "mediatek,mt8183-svs",
+ .data = &svs_mt8183_platform_data,
+ }, {
+ /* Sentinel */
+ },
+};
+
+static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ const struct svs_platform_data *svsp_data;
+ int ret;
+
+ svsp_data = of_device_get_match_data(&pdev->dev);
+ if (!svsp_data) {
+ dev_err(&pdev->dev, "no svs platform data?\n");
+ return ERR_PTR(-EPERM);
+ }
+
+ svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
+ if (!svsp)
+ return ERR_PTR(-ENOMEM);
+
+ svsp->dev = &pdev->dev;
+ svsp->name = svsp_data->name;
+ svsp->banks = svsp_data->banks;
+ svsp->efuse_parsing = svsp_data->efuse_parsing;
+ svsp->probe = svsp_data->probe;
+ svsp->irqflags = svsp_data->irqflags;
+ svsp->regs = svsp_data->regs;
+ svsp->bank_max = svsp_data->bank_max;
+
+ ret = svsp->probe(svsp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return svsp;
+}
+
+static int svs_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ unsigned int svsp_irq;
+ int ret;
+
+ svsp = svs_platform_probe(pdev);
+ if (IS_ERR(svsp))
+ return PTR_ERR(svsp);
+
+ if (!svs_is_efuse_data_correct(svsp)) {
+ dev_notice(svsp->dev, "efuse data isn't correct\n");
+ ret = -EPERM;
+ goto svs_probe_free_resource;
+ }
+
+ ret = svs_bank_resource_setup(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs bank resource setup fail: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp_irq = irq_of_parse_and_map(svsp->dev->of_node, 0);
+ ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+ svsp->irqflags | IRQF_ONESHOT,
+ svsp->name, svsp);
+ if (ret) {
+ dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+ svsp_irq, ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->main_clk = devm_clk_get(svsp->dev, "main");
+ if (IS_ERR(svsp->main_clk)) {
+ dev_err(svsp->dev, "failed to get clock: %ld\n",
+ PTR_ERR(svsp->main_clk));
+ ret = PTR_ERR(svsp->main_clk);
+ goto svs_probe_free_resource;
+ }
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->base = of_iomap(svsp->dev->of_node, 0);
+ if (IS_ERR_OR_NULL(svsp->base)) {
+ dev_err(svsp->dev, "cannot find svs register base\n");
+ ret = -EINVAL;
+ goto svs_probe_clk_disable;
+ }
+
+ ret = svs_start(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs start fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
+ return 0;
+
+svs_probe_iounmap:
+ iounmap(svsp->base);
+
+svs_probe_clk_disable:
+ clk_disable_unprepare(svsp->main_clk);
+
+svs_probe_free_resource:
+ if (!IS_ERR_OR_NULL(svsp->efuse))
+ kfree(svsp->efuse);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(svs_pm_ops, svs_suspend, svs_resume);
+
+static struct platform_driver svs_driver = {
+ .probe = svs_probe,
+ .driver = {
+ .name = "mtk-svs",
+ .pm = &svs_pm_ops,
+ .of_match_table = of_match_ptr(svs_of_match),
+ },
+};
+
+module_platform_driver(svs_driver);
+
+MODULE_AUTHOR("Roger Lu <roger.lu@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek SVS driver");
+MODULE_LICENSE("GPL");
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/Kconfig | 10 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-svs.c | 1417 ++++++++++++++++++++++++++++++++
3 files changed, 1428 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-svs.c
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..3c3eedea35f7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -73,4 +73,14 @@ config MTK_MMSYS
Say yes here to add support for the MediaTek Multimedia
Subsystem (MMSYS).
+config MTK_SVS
+ tristate "MediaTek Smart Voltage Scaling(SVS)"
+ depends on MTK_EFUSE && NVMEM
+ help
+ The Smart Voltage Scaling(SVS) engine is a piece of hardware
+ which has several controllers(banks) for calculating suitable
+ voltage to different power domains(CPU/GPU/CCI) according to
+ chip process corner, temperatures and other factors. Then DVFS
+ driver could apply SVS bank voltage to PMIC/Buck.
+
endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 90270f8114ed..0e9e703c931a 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
+obj-$(CONFIG_MTK_SVS) += mtk-svs.o
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
new file mode 100644
index 000000000000..cc23a701159e
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -0,0 +1,1417 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/cpuidle.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+/* svs bank 1-line software id */
+#define SVSB_CPU_LITTLE BIT(0)
+#define SVSB_CPU_BIG BIT(1)
+#define SVSB_CCI BIT(2)
+#define SVSB_GPU BIT(3)
+
+/* svs bank mode support */
+#define SVSB_MODE_ALL_DISABLE 0
+#define SVSB_MODE_INIT01 BIT(1)
+#define SVSB_MODE_INIT02 BIT(2)
+
+/* svs bank volt flags */
+#define SVSB_INIT01_PD_REQ BIT(0)
+#define SVSB_INIT01_VOLT_IGNORE BIT(1)
+#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+
+/* svs bank register common configuration */
+#define SVSB_DET_MAX 0xffff
+#define SVSB_DET_WINDOW 0xa28
+#define SVSB_DTHI 0x1
+#define SVSB_DTLO 0xfe
+#define SVSB_EN_INIT01 0x1
+#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_OFF 0x0
+#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTSTS_CLEAN 0x00ffffff
+#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_RUNCONFIG_DEFAULT 0x80000000
+
+/* svs bank related setting */
+#define MAX_OPP_ENTRIES 16
+#define SVSB_DC_SIGNED_BIT BIT(15)
+#define SVSB_DET_CLK_EN BIT(31)
+
+static DEFINE_SPINLOCK(svs_lock);
+
+/**
+ * enum svsb_phase - svs bank phase enumeration
+ * @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
+ * @SVSB_PHASE_INIT01: svs bank basic init for data calibration
+ * @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
+ *
+ * Each svs bank has its own independent phase and we enable each svs bank by
+ * running their phase orderly. However, when svs bank encounters unexpected
+ * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
+ *
+ * svs bank general phase-enabled order:
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ */
+enum svsb_phase {
+ SVSB_PHASE_ERROR = 0,
+ SVSB_PHASE_INIT01,
+ SVSB_PHASE_INIT02,
+ SVSB_PHASE_MAX,
+};
+
+enum svs_reg_index {
+ DESCHAR = 0,
+ TEMPCHAR,
+ DETCHAR,
+ AGECHAR,
+ DCCONFIG,
+ AGECONFIG,
+ FREQPCT30,
+ FREQPCT74,
+ LIMITVALS,
+ VBOOT,
+ DETWINDOW,
+ CONFIG,
+ TSCALCS,
+ RUNCONFIG,
+ SVSEN,
+ INIT2VALS,
+ DCVALUES,
+ AGEVALUES,
+ VOP30,
+ VOP74,
+ TEMP,
+ INTSTS,
+ INTSTSRAW,
+ INTEN,
+ CHKINT,
+ CHKSHIFT,
+ STATUS,
+ VDESIGN30,
+ VDESIGN74,
+ DVT30,
+ DVT74,
+ AGECOUNT,
+ SMSTATE0,
+ SMSTATE1,
+ CTL0,
+ DESDETSEC,
+ TEMPAGESEC,
+ CTRLSPARE0,
+ CTRLSPARE1,
+ CTRLSPARE2,
+ CTRLSPARE3,
+ CORESEL,
+ THERMINTST,
+ INTST,
+ THSTAGE0ST,
+ THSTAGE1ST,
+ THSTAGE2ST,
+ THAHBST0,
+ THAHBST1,
+ SPARE0,
+ SPARE1,
+ SPARE2,
+ SPARE3,
+ THSLPEVEB,
+ SVS_REG_MAX,
+};
+
+static const u32 svs_regs_v2[] = {
+ [DESCHAR] = 0xc00,
+ [TEMPCHAR] = 0xc04,
+ [DETCHAR] = 0xc08,
+ [AGECHAR] = 0xc0c,
+ [DCCONFIG] = 0xc10,
+ [AGECONFIG] = 0xc14,
+ [FREQPCT30] = 0xc18,
+ [FREQPCT74] = 0xc1c,
+ [LIMITVALS] = 0xc20,
+ [VBOOT] = 0xc24,
+ [DETWINDOW] = 0xc28,
+ [CONFIG] = 0xc2c,
+ [TSCALCS] = 0xc30,
+ [RUNCONFIG] = 0xc34,
+ [SVSEN] = 0xc38,
+ [INIT2VALS] = 0xc3c,
+ [DCVALUES] = 0xc40,
+ [AGEVALUES] = 0xc44,
+ [VOP30] = 0xc48,
+ [VOP74] = 0xc4c,
+ [TEMP] = 0xc50,
+ [INTSTS] = 0xc54,
+ [INTSTSRAW] = 0xc58,
+ [INTEN] = 0xc5c,
+ [CHKINT] = 0xc60,
+ [CHKSHIFT] = 0xc64,
+ [STATUS] = 0xc68,
+ [VDESIGN30] = 0xc6c,
+ [VDESIGN74] = 0xc70,
+ [DVT30] = 0xc74,
+ [DVT74] = 0xc78,
+ [AGECOUNT] = 0xc7c,
+ [SMSTATE0] = 0xc80,
+ [SMSTATE1] = 0xc84,
+ [CTL0] = 0xc88,
+ [DESDETSEC] = 0xce0,
+ [TEMPAGESEC] = 0xce4,
+ [CTRLSPARE0] = 0xcf0,
+ [CTRLSPARE1] = 0xcf4,
+ [CTRLSPARE2] = 0xcf8,
+ [CTRLSPARE3] = 0xcfc,
+ [CORESEL] = 0xf00,
+ [THERMINTST] = 0xf04,
+ [INTST] = 0xf08,
+ [THSTAGE0ST] = 0xf0c,
+ [THSTAGE1ST] = 0xf10,
+ [THSTAGE2ST] = 0xf14,
+ [THAHBST0] = 0xf18,
+ [THAHBST1] = 0xf1c,
+ [SPARE0] = 0xf20,
+ [SPARE1] = 0xf24,
+ [SPARE2] = 0xf28,
+ [SPARE3] = 0xf2c,
+ [THSLPEVEB] = 0xf30,
+};
+
+/**
+ * struct svs_platform - svs platform control
+ * @name: svs platform name
+ * @base: svs platform register base
+ * @dev: svs platform device
+ * @main_clk: main clock for svs bank
+ * @pbank: svs bank pointer needing to be protected by spin_lock section
+ * @banks: svs banks that svs platform supports
+ * @efuse_parsing: svs platform efuse parsing function pointer
+ * @probe: svs platform probe function pointer
+ * @irqflags: svs platform irq settings flags
+ * @efuse_max: total number of svs efuse
+ * @regs: svs platform registers map
+ * @bank_max: total number of svs banks
+ * @efuse: svs efuse data received from NVMEM framework
+ */
+struct svs_platform {
+ char *name;
+ void __iomem *base;
+ struct device *dev;
+ struct clk *main_clk;
+ struct svs_bank *pbank;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ size_t efuse_max;
+ const u32 *regs;
+ u32 bank_max;
+ u32 *efuse;
+};
+
+struct svs_platform_data {
+ char *name;
+ struct svs_bank *banks;
+ bool (*efuse_parsing)(struct svs_platform *svsp);
+ int (*probe)(struct svs_platform *svsp);
+ unsigned long irqflags;
+ const u32 *regs;
+ u32 bank_max;
+};
+
+/**
+ * struct svs_bank - svs bank representation
+ * @dev: bank device
+ * @opp_dev: device for opp table/buck control
+ * @init_completion: the timeout completion for bank init
+ * @buck: regulator used by opp_dev
+ * @lock: mutex lock to protect voltage update process
+ * @set_freq_pct: function pointer to set bank frequency percent table
+ * @get_volts: function pointer to get bank voltages
+ * @name: bank name
+ * @buck_name: regulator name
+ * @phase: bank current phase
+ * @volt_od: bank voltage overdrive
+ * @pm_runtime_enabled_count: bank pm runtime enabled count
+ * @mode_support: bank mode support.
+ * @freq_base: reference frequency for bank init
+ * @vboot: voltage request for bank init01 only
+ * @opp_dfreq: default opp frequency table
+ * @opp_dvolt: default opp voltage table
+ * @freq_pct: frequency percent table for bank init
+ * @volt: bank voltage table
+ * @volt_step: bank voltage step
+ * @volt_base: bank voltage base
+ * @volt_flags: bank voltage flags
+ * @vmax: bank voltage maximum
+ * @vmin: bank voltage minimum
+ * @age_config: bank age configuration
+ * @age_voffset_in: bank age voltage offset
+ * @dc_config: bank dc configuration
+ * @dc_voffset_in: bank dc voltage offset
+ * @dvt_fixed: bank dvt fixed value
+ * @vco: bank VCO value
+ * @chk_shift: bank chicken shift
+ * @core_sel: bank selection
+ * @opp_count: bank opp count
+ * @int_st: bank interrupt identification
+ * @sw_id: bank software identification
+ * @cpu_id: cpu core id for SVS CPU bank use only
+ * @ctl0: TS-x selection
+ * @bdes: svs efuse data
+ * @mdes: svs efuse data
+ * @mtdes: svs efuse data
+ * @dcbdet: svs efuse data
+ * @dcmdet: svs efuse data
+ *
+ * Svs bank will generate suitalbe voltages by below general math equation
+ * and provide these voltages to opp voltage table.
+ *
+ * opp_volt[i] = (volt[i] * volt_step) + volt_base;
+ */
+struct svs_bank {
+ struct device *dev;
+ struct device *opp_dev;
+ struct completion init_completion;
+ struct regulator *buck;
+ struct mutex lock; /* lock to protect voltage update process */
+ void (*set_freq_pct)(struct svs_platform *svsp);
+ void (*get_volts)(struct svs_platform *svsp);
+ char *name;
+ char *buck_name;
+ enum svsb_phase phase;
+ s32 volt_od;
+ u32 pm_runtime_enabled_count;
+ u32 mode_support;
+ u32 freq_base;
+ u32 vboot;
+ u32 opp_dfreq[MAX_OPP_ENTRIES];
+ u32 opp_dvolt[MAX_OPP_ENTRIES];
+ u32 freq_pct[MAX_OPP_ENTRIES];
+ u32 volt[MAX_OPP_ENTRIES];
+ u32 volt_step;
+ u32 volt_base;
+ u32 volt_flags;
+ u32 vmax;
+ u32 vmin;
+ u32 age_config;
+ u32 age_voffset_in;
+ u32 dc_config;
+ u32 dc_voffset_in;
+ u32 dvt_fixed;
+ u32 vco;
+ u32 chk_shift;
+ u32 core_sel;
+ u32 opp_count;
+ u32 int_st;
+ u32 sw_id;
+ u32 cpu_id;
+ u32 ctl0;
+ u32 bdes;
+ u32 mdes;
+ u32 mtdes;
+ u32 dcbdet;
+ u32 dcmdet;
+};
+
+static u32 percent(u32 numerator, u32 denominator)
+{
+ /* If not divide 1000, "numerator * 100" will have data overflow. */
+ numerator /= 1000;
+ denominator /= 1000;
+
+ return DIV_ROUND_UP(numerator * 100, denominator);
+}
+
+static u32 svs_readl_relaxed(struct svs_platform *svsp, enum svs_reg_index rg_i)
+{
+ return readl_relaxed(svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_writel_relaxed(struct svs_platform *svsp, u32 val,
+ enum svs_reg_index rg_i)
+{
+ writel_relaxed(val, svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_switch_bank(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp, svsb->core_sel, CORESEL);
+}
+
+static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (svsb_volt * svsb_volt_step) + svsb_volt_base;
+}
+
+static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
+{
+ int ret = -EPERM;
+ u32 i, svsb_volt, opp_volt;
+
+ mutex_lock(&svsb->lock);
+
+ /* vmin <= svsb_volt (opp_volt) <= default opp voltage */
+ for (i = 0; i < svsb->opp_count; i++) {
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ opp_volt = svsb->opp_dvolt[i];
+ break;
+ case SVSB_PHASE_INIT01:
+ /* do nothing */
+ goto unlock_mutex;
+ case SVSB_PHASE_INIT02:
+ svsb_volt = max(svsb->volt[i], svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
+ default:
+ dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ opp_volt = min(opp_volt, svsb->opp_dvolt[i]);
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ opp_volt, opp_volt,
+ svsb->opp_dvolt[i]);
+ if (ret) {
+ dev_err(svsb->dev, "set %uuV fail: %d\n",
+ opp_volt, ret);
+ goto unlock_mutex;
+ }
+ }
+
+unlock_mutex:
+ mutex_unlock(&svsb->lock);
+
+ return ret;
+}
+
+static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
+{
+ u32 vx;
+
+ if (v0 == v1 || f0 == f1)
+ return v0;
+
+ /* *100 to have decimal fraction factor */
+ vx = (v0 * 100) - ((((v0 - v1) * 100) / (f0 - f1)) * (f0 - fx));
+
+ return DIV_ROUND_UP(vx, 100);
+}
+
+static void svs_get_bank_volts_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 temp, i;
+
+ temp = svs_readl_relaxed(svsp, VOP74);
+ svsb->volt[14] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[12] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[10] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[8] = (temp & GENMASK(7, 0));
+
+ temp = svs_readl_relaxed(svsp, VOP30);
+ svsb->volt[6] = (temp >> 24) & GENMASK(7, 0);
+ svsb->volt[4] = (temp >> 16) & GENMASK(7, 0);
+ svsb->volt[2] = (temp >> 8) & GENMASK(7, 0);
+ svsb->volt[0] = (temp & GENMASK(7, 0));
+
+ for (i = 0; i <= 12; i += 2)
+ svsb->volt[i + 1] = interpolate(svsb->freq_pct[i],
+ svsb->freq_pct[i + 2],
+ svsb->volt[i],
+ svsb->volt[i + 2],
+ svsb->freq_pct[i + 1]);
+
+ svsb->volt[15] = interpolate(svsb->freq_pct[12],
+ svsb->freq_pct[14],
+ svsb->volt[12],
+ svsb->volt[14],
+ svsb->freq_pct[15]);
+
+ for (i = 0; i < svsb->opp_count; i++)
+ svsb->volt[i] += svsb->volt_od;
+}
+
+static void svs_set_bank_freq_pct_v2(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[14] << 24) |
+ (svsb->freq_pct[12] << 16) |
+ (svsb->freq_pct[10] << 8) |
+ svsb->freq_pct[8],
+ FREQPCT74);
+
+ svs_writel_relaxed(svsp,
+ (svsb->freq_pct[6] << 24) |
+ (svsb->freq_pct[4] << 16) |
+ (svsb->freq_pct[2] << 8) |
+ svsb->freq_pct[0],
+ FREQPCT30);
+}
+
+static void svs_set_bank_phase(struct svs_platform *svsp,
+ enum svsb_phase target_phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals;
+
+ svs_switch_bank(svsp);
+
+ des_char = (svsb->bdes << 8) | svsb->mdes;
+ svs_writel_relaxed(svsp, des_char, DESCHAR);
+
+ temp_char = (svsb->vco << 16) | (svsb->mtdes << 8) | svsb->dvt_fixed;
+ svs_writel_relaxed(svsp, temp_char, TEMPCHAR);
+
+ det_char = (svsb->dcbdet << 8) | svsb->dcmdet;
+ svs_writel_relaxed(svsp, det_char, DETCHAR);
+
+ svs_writel_relaxed(svsp, svsb->dc_config, DCCONFIG);
+ svs_writel_relaxed(svsp, svsb->age_config, AGECONFIG);
+ svs_writel_relaxed(svsp, SVSB_RUNCONFIG_DEFAULT, RUNCONFIG);
+
+ svsb->set_freq_pct(svsp);
+
+ limit_vals = (svsb->vmax << 24) | (svsb->vmin << 16) |
+ (SVSB_DTHI << 8) | SVSB_DTLO;
+ svs_writel_relaxed(svsp, limit_vals, LIMITVALS);
+
+ svs_writel_relaxed(svsp, SVSB_DET_WINDOW, DETWINDOW);
+ svs_writel_relaxed(svsp, SVSB_DET_MAX, CONFIG);
+ svs_writel_relaxed(svsp, svsb->chk_shift, CHKSHIFT);
+ svs_writel_relaxed(svsp, svsb->ctl0, CTL0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+
+ switch (target_phase) {
+ case SVSB_PHASE_INIT01:
+ svs_writel_relaxed(svsp, svsb->vboot, VBOOT);
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT01, SVSEN);
+ break;
+ case SVSB_PHASE_INIT02:
+ svs_writel_relaxed(svsp, SVSB_INTEN_INIT0x, INTEN);
+ init2vals = (svsb->age_voffset_in << 16) | svsb->dc_voffset_in;
+ svs_writel_relaxed(svsp, init2vals, INIT2VALS);
+ svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
+ break;
+ default:
+ dev_err(svsb->dev, "requested unknown target phase: %u\n",
+ target_phase);
+ break;
+ }
+}
+
+static inline void svs_error_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, CORESEL));
+ dev_err(svsb->dev, "SVSEN = 0x%08x, INTSTS = 0x%08x\n",
+ svs_readl_relaxed(svsp, SVSEN),
+ svs_readl_relaxed(svsp, INTSTS));
+ dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
+ svs_readl_relaxed(svsp, SMSTATE0),
+ svs_readl_relaxed(svsp, SMSTATE1));
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+}
+
+static inline void svs_init01_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VDESIGN74),
+ svs_readl_relaxed(svsp, VDESIGN30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT01;
+ svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
+ GENMASK(15, 0)) + 1;
+ if (svsb->volt_flags & SVSB_INIT01_VOLT_IGNORE ||
+ (svsb->dc_voffset_in & SVSB_DC_SIGNED_BIT &&
+ svsb->volt_flags & SVSB_INIT01_VOLT_INC_ONLY))
+ svsb->dc_voffset_in = 0;
+
+ svsb->age_voffset_in = svs_readl_relaxed(svsp, AGEVALUES) &
+ GENMASK(15, 0);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+ svsb->core_sel &= ~SVSB_DET_CLK_EN;
+}
+
+static inline void svs_init02_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
+ __func__, svs_readl_relaxed(svsp, VOP74),
+ svs_readl_relaxed(svsp, VOP30),
+ svs_readl_relaxed(svsp, DCVALUES));
+
+ svsb->phase = SVSB_PHASE_INIT02;
+ svsb->get_volts(svsp);
+
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+}
+
+static irqreturn_t svs_isr(int irq, void *data)
+{
+ struct svs_platform *svsp = data;
+ struct svs_bank *svsb = NULL;
+ unsigned long flags;
+ u32 idx, int_sts, svs_en;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ WARN(!svsb, "%s: svsb(%s) is null", __func__, svsb->name);
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+
+ /* Find out which svs bank fires interrupt */
+ if (svsb->int_st & svs_readl_relaxed(svsp, INTST)) {
+ spin_unlock_irqrestore(&svs_lock, flags);
+ continue;
+ }
+
+ svs_switch_bank(svsp);
+ int_sts = svs_readl_relaxed(svsp, INTSTS);
+ svs_en = svs_readl_relaxed(svsp, SVSEN);
+
+ if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT01)
+ svs_init01_isr_handler(svsp);
+ else if (int_sts == SVSB_INTSTS_COMPLETE &&
+ svs_en == SVSB_EN_INIT02)
+ svs_init02_isr_handler(svsp);
+ else
+ svs_error_isr_handler(svsp);
+
+ spin_unlock_irqrestore(&svs_lock, flags);
+ break;
+ }
+
+ svs_adjust_pm_opp_volts(svsb);
+
+ if (svsb->phase == SVSB_PHASE_INIT01 ||
+ svsb->phase == SVSB_PHASE_INIT02)
+ complete(&svsb->init_completion);
+
+ return IRQ_HANDLED;
+}
+
+static int svs_init01(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ bool search_done;
+ int ret = 0, r;
+ u32 opp_freq, opp_vboot, buck_volt, idx, i;
+
+ /* Keep CPUs' core power on for svs_init01 initialization */
+ cpuidle_pause_and_lock();
+
+ /* Svs bank init01 preparation - power enable */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ ret = regulator_enable(svsb->buck);
+ if (ret) {
+ dev_err(svsb->dev, "%s enable fail: %d\n",
+ svsb->buck_name, ret);
+ goto svs_init01_resume_cpuidle;
+ }
+
+ /* Some buck doesn't support mode change. Show fail msg only */
+ ret = regulator_set_mode(svsb->buck, REGULATOR_MODE_FAST);
+ if (ret)
+ dev_notice(svsb->dev, "set fast mode fail: %d\n", ret);
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ if (!pm_runtime_enabled(svsb->opp_dev)) {
+ pm_runtime_enable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count++;
+ }
+
+ ret = pm_runtime_get_sync(svsb->opp_dev);
+ if (ret < 0) {
+ dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
+ goto svs_init01_resume_cpuidle;
+ }
+ }
+ }
+
+ /*
+ * Svs bank init01 preparation - vboot voltage adjustment
+ * Sometimes two svs banks use the same buck. Therefore,
+ * we have to set each svs bank to target voltage(vboot) first.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ /*
+ * Find the fastest freq that can be run at vboot and
+ * fix to that freq until svs_init01 is done.
+ */
+ search_done = false;
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp_freq = svsb->opp_dfreq[i];
+ if (!search_done && svsb->opp_dvolt[i] <= opp_vboot) {
+ ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+ opp_freq,
+ opp_vboot,
+ opp_vboot,
+ opp_vboot);
+ if (ret) {
+ dev_err(svsb->dev,
+ "set opp %uuV vboot fail: %d\n",
+ opp_vboot, ret);
+ goto svs_init01_finish;
+ }
+
+ search_done = true;
+ } else {
+ ret = dev_pm_opp_disable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (ret) {
+ dev_err(svsb->dev,
+ "opp %uHz disable fail: %d\n",
+ svsb->opp_dfreq[i], ret);
+ goto svs_init01_finish;
+ }
+ }
+ }
+ }
+
+ /* Svs bank init01 begins */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+ svsb->volt_step,
+ svsb->volt_base);
+
+ buck_volt = regulator_get_voltage(svsb->buck);
+ if (buck_volt != opp_vboot) {
+ dev_err(svsb->dev,
+ "buck voltage: %uuV, expected vboot: %uuV\n",
+ buck_volt, opp_vboot);
+ ret = -EPERM;
+ goto svs_init01_finish;
+ }
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT01);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init01 completion timeout\n");
+ ret = -EBUSY;
+ goto svs_init01_finish;
+ }
+ }
+
+svs_init01_finish:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT01))
+ continue;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ r = dev_pm_opp_enable(svsb->opp_dev,
+ svsb->opp_dfreq[i]);
+ if (r)
+ dev_err(svsb->dev, "opp %uHz enable fail: %d\n",
+ svsb->opp_dfreq[i], r);
+ }
+
+ if (svsb->volt_flags & SVSB_INIT01_PD_REQ) {
+ r = pm_runtime_put_sync(svsb->opp_dev);
+ if (r)
+ dev_err(svsb->dev, "mtcmos off fail: %d\n", r);
+
+ if (svsb->pm_runtime_enabled_count > 0) {
+ pm_runtime_disable(svsb->opp_dev);
+ svsb->pm_runtime_enabled_count--;
+ }
+ }
+
+ r = regulator_set_mode(svsb->buck, REGULATOR_MODE_NORMAL);
+ if (r)
+ dev_notice(svsb->dev, "set normal mode fail: %d\n", r);
+
+ r = regulator_disable(svsb->buck);
+ if (r)
+ dev_err(svsb->dev, "%s disable fail: %d\n",
+ svsb->buck_name, r);
+ }
+
+svs_init01_resume_cpuidle:
+ cpuidle_resume_and_unlock();
+
+ return ret;
+}
+
+static int svs_init02(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags, time_left;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ reinit_completion(&svsb->init_completion);
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_INIT02);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ time_left = wait_for_completion_timeout(&svsb->init_completion,
+ msecs_to_jiffies(5000));
+ if (!time_left) {
+ dev_err(svsb->dev, "init02 completion timeout\n");
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static int svs_start(struct svs_platform *svsp)
+{
+ int ret;
+
+ ret = svs_init01(svsp);
+ if (ret)
+ return ret;
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_suspend(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ /* This might wait for svs_isr() process */
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ clk_disable_unprepare(svsp->main_clk);
+
+ return 0;
+}
+
+static int svs_resume(struct device *dev)
+{
+ struct svs_platform *svsp = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main_clk, disable svs\n");
+ return ret;
+ }
+
+ ret = svs_init02(svsp);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int svs_bank_resource_setup(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dev_pm_opp *opp;
+ unsigned long freq;
+ int count, ret;
+ u32 idx, i;
+
+ dev_set_drvdata(svsp->dev, svsp);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->name = "SVSB_CPU_LITTLE";
+ break;
+ case SVSB_CPU_BIG:
+ svsb->name = "SVSB_CPU_BIG";
+ break;
+ case SVSB_CCI:
+ svsb->name = "SVSB_CCI";
+ break;
+ case SVSB_GPU:
+ svsb->name = "SVSB_GPU";
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ svsb->dev = devm_kzalloc(svsp->dev, sizeof(*svsb->dev),
+ GFP_KERNEL);
+ if (!svsb->dev)
+ return -ENOMEM;
+
+ ret = dev_set_name(svsb->dev, "%s", svsb->name);
+ if (ret)
+ return ret;
+
+ dev_set_drvdata(svsb->dev, svsp);
+
+ ret = dev_pm_opp_of_add_table(svsb->opp_dev);
+ if (ret) {
+ dev_err(svsb->dev, "add opp table fail: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&svsb->lock);
+ init_completion(&svsb->init_completion);
+
+ if (svsb->mode_support & SVSB_MODE_INIT01) {
+ svsb->buck = devm_regulator_get_optional(svsb->opp_dev,
+ svsb->buck_name);
+ if (IS_ERR(svsb->buck)) {
+ dev_err(svsb->dev, "cannot get \"%s-supply\"\n",
+ svsb->buck_name);
+ return PTR_ERR(svsb->buck);
+ }
+ }
+
+ count = dev_pm_opp_get_opp_count(svsb->opp_dev);
+ if (svsb->opp_count != count) {
+ dev_err(svsb->dev,
+ "opp_count not \"%u\" but get \"%d\"?\n",
+ svsb->opp_count, count);
+ return count;
+ }
+
+ for (i = 0, freq = U32_MAX; i < svsb->opp_count; i++, freq--) {
+ opp = dev_pm_opp_find_freq_floor(svsb->opp_dev, &freq);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %ld\n",
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ svsb->opp_dfreq[i] = freq;
+ svsb->opp_dvolt[i] = dev_pm_opp_get_voltage(opp);
+ svsb->freq_pct[i] = percent(svsb->opp_dfreq[i],
+ svsb->freq_base);
+ dev_pm_opp_put(opp);
+ }
+ }
+
+ return 0;
+}
+
+static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx, i, ft_pgm;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[2]) {
+ dev_notice(svsp->dev, "svs_efuse[2] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ ft_pgm = (svsp->efuse[0] >> 4) & GENMASK(3, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (ft_pgm <= 1)
+ svsb->volt_flags |= SVSB_INIT01_VOLT_IGNORE;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ svsb->bdes = svsp->efuse[16] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[16] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[16] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[16] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_CPU_BIG:
+ svsb->bdes = svsp->efuse[18] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[18] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[18] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[18] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[17] & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 15;
+ else
+ svsb->volt_od += 12;
+ break;
+ case SVSB_CCI:
+ svsb->bdes = svsp->efuse[4] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[4] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[4] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[4] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = (svsp->efuse[5] >> 16) & GENMASK(7, 0);
+
+ if (ft_pgm <= 3)
+ svsb->volt_od += 10;
+ else
+ svsb->volt_od += 2;
+ break;
+ case SVSB_GPU:
+ svsb->bdes = svsp->efuse[6] & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[6] >> 8) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[6] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[6] >> 24) & GENMASK(7, 0);
+ svsb->mtdes = svsp->efuse[5] & GENMASK(7, 0);
+
+ if (ft_pgm >= 2) {
+ svsb->freq_base = 800000000; /* 800MHz */
+ svsb->dvt_fixed = 2;
+ }
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return false;
+ }
+ }
+
+ return true;
+}
+
+static bool svs_is_efuse_data_correct(struct svs_platform *svsp)
+{
+ struct nvmem_cell *cell;
+
+ /* Get svs efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"svs-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_max);
+ if (IS_ERR(svsp->efuse)) {
+ dev_err(svsp->dev, "cannot read svs efuse: %ld\n",
+ PTR_ERR(svsp->efuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->efuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ return svsp->efuse_parsing(svsp);
+}
+
+static struct device *svs_get_subsys_device(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct platform_device *pdev;
+ struct device_node *np;
+
+ np = of_find_node_by_name(NULL, node_name);
+ if (!np) {
+ dev_err(svsp->dev, "cannot find %s node\n", node_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ of_node_put(np);
+ dev_err(svsp->dev, "cannot find pdev by %s\n", node_name);
+ return ERR_PTR(-ENXIO);
+ }
+
+ of_node_put(np);
+
+ return &pdev->dev;
+}
+
+static struct device *svs_add_device_link(struct svs_platform *svsp,
+ const char *node_name)
+{
+ struct device *dev;
+ struct device_link *sup_link;
+
+ if (!node_name) {
+ dev_err(svsp->dev, "node name cannot be null\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ dev = svs_get_subsys_device(svsp, node_name);
+ if (IS_ERR(dev))
+ return dev;
+
+ sup_link = device_link_add(svsp->dev, dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!sup_link) {
+ dev_err(svsp->dev, "sup_link is NULL\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return dev;
+}
+
+static int svs_mt8183_platform_probe(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ case SVSB_CPU_BIG:
+ svsb->opp_dev = get_cpu_device(svsb->cpu_id);
+ break;
+ case SVSB_CCI:
+ svsb->opp_dev = svs_add_device_link(svsp, "cci");
+ break;
+ case SVSB_GPU:
+ svsb->opp_dev = svs_add_device_link(svsp, "gpu");
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ return -EINVAL;
+ }
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
+static struct svs_bank svs_mt8183_banks[] = {
+ {
+ .sw_id = SVSB_CPU_LITTLE,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 0,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0000,
+ .int_st = BIT(0),
+ .ctl0 = 0x00010001,
+ },
+ {
+ .sw_id = SVSB_CPU_BIG,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .cpu_id = 4,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1989000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x58,
+ .vmin = 0x10,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0001,
+ .int_st = BIT(1),
+ .ctl0 = 0x00000001,
+ },
+ {
+ .sw_id = SVSB_CCI,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "proc",
+ .volt_flags = SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 1196000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x64,
+ .vmin = 0x18,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x7,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0002,
+ .int_st = BIT(2),
+ .ctl0 = 0x00100003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .set_freq_pct = svs_set_bank_freq_pct_v2,
+ .get_volts = svs_get_bank_volts_v2,
+ .buck_name = "mali",
+ .volt_flags = SVSB_INIT01_PD_REQ |
+ SVSB_INIT01_VOLT_INC_ONLY,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 900000000,
+ .vboot = 0x30,
+ .volt_step = 6250,
+ .volt_base = 500000,
+ .vmax = 0x40,
+ .vmin = 0x14,
+ .age_config = 0x555555,
+ .dc_config = 0x555555,
+ .dvt_fixed = 0x3,
+ .vco = 0x10,
+ .chk_shift = 0x77,
+ .core_sel = 0x8fff0003,
+ .int_st = BIT(3),
+ .ctl0 = 0x00050001,
+ },
+};
+
+static const struct svs_platform_data svs_mt8183_platform_data = {
+ .name = "mt8183-svs",
+ .banks = svs_mt8183_banks,
+ .efuse_parsing = svs_mt8183_efuse_parsing,
+ .probe = svs_mt8183_platform_probe,
+ .irqflags = IRQF_TRIGGER_LOW,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8183_banks),
+};
+
+static const struct of_device_id svs_of_match[] = {
+ {
+ .compatible = "mediatek,mt8183-svs",
+ .data = &svs_mt8183_platform_data,
+ }, {
+ /* Sentinel */
+ },
+};
+
+static struct svs_platform *svs_platform_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ const struct svs_platform_data *svsp_data;
+ int ret;
+
+ svsp_data = of_device_get_match_data(&pdev->dev);
+ if (!svsp_data) {
+ dev_err(&pdev->dev, "no svs platform data?\n");
+ return ERR_PTR(-EPERM);
+ }
+
+ svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
+ if (!svsp)
+ return ERR_PTR(-ENOMEM);
+
+ svsp->dev = &pdev->dev;
+ svsp->name = svsp_data->name;
+ svsp->banks = svsp_data->banks;
+ svsp->efuse_parsing = svsp_data->efuse_parsing;
+ svsp->probe = svsp_data->probe;
+ svsp->irqflags = svsp_data->irqflags;
+ svsp->regs = svsp_data->regs;
+ svsp->bank_max = svsp_data->bank_max;
+
+ ret = svsp->probe(svsp);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return svsp;
+}
+
+static int svs_probe(struct platform_device *pdev)
+{
+ struct svs_platform *svsp;
+ unsigned int svsp_irq;
+ int ret;
+
+ svsp = svs_platform_probe(pdev);
+ if (IS_ERR(svsp))
+ return PTR_ERR(svsp);
+
+ if (!svs_is_efuse_data_correct(svsp)) {
+ dev_notice(svsp->dev, "efuse data isn't correct\n");
+ ret = -EPERM;
+ goto svs_probe_free_resource;
+ }
+
+ ret = svs_bank_resource_setup(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs bank resource setup fail: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp_irq = irq_of_parse_and_map(svsp->dev->of_node, 0);
+ ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+ svsp->irqflags | IRQF_ONESHOT,
+ svsp->name, svsp);
+ if (ret) {
+ dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+ svsp_irq, ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->main_clk = devm_clk_get(svsp->dev, "main");
+ if (IS_ERR(svsp->main_clk)) {
+ dev_err(svsp->dev, "failed to get clock: %ld\n",
+ PTR_ERR(svsp->main_clk));
+ ret = PTR_ERR(svsp->main_clk);
+ goto svs_probe_free_resource;
+ }
+
+ ret = clk_prepare_enable(svsp->main_clk);
+ if (ret) {
+ dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
+ goto svs_probe_free_resource;
+ }
+
+ svsp->base = of_iomap(svsp->dev->of_node, 0);
+ if (IS_ERR_OR_NULL(svsp->base)) {
+ dev_err(svsp->dev, "cannot find svs register base\n");
+ ret = -EINVAL;
+ goto svs_probe_clk_disable;
+ }
+
+ ret = svs_start(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs start fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
+ return 0;
+
+svs_probe_iounmap:
+ iounmap(svsp->base);
+
+svs_probe_clk_disable:
+ clk_disable_unprepare(svsp->main_clk);
+
+svs_probe_free_resource:
+ if (!IS_ERR_OR_NULL(svsp->efuse))
+ kfree(svsp->efuse);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(svs_pm_ops, svs_suspend, svs_resume);
+
+static struct platform_driver svs_driver = {
+ .probe = svs_probe,
+ .driver = {
+ .name = "mtk-svs",
+ .pm = &svs_pm_ops,
+ .of_match_table = of_match_ptr(svs_of_match),
+ },
+};
+
+module_platform_driver(svs_driver);
+
+MODULE_AUTHOR("Roger Lu <roger.lu@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek SVS driver");
+MODULE_LICENSE("GPL");
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
SVS monitor mode is based on different thermal temperature
to provide suitable SVS bank voltages.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 256 ++++++++++++++++++++++++++++++++-
1 file changed, 250 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index cc23a701159e..44ccad1e3327 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -25,6 +25,7 @@
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/thermal.h>
/* svs bank 1-line software id */
#define SVSB_CPU_LITTLE BIT(0)
@@ -36,6 +37,7 @@
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
#define SVSB_MODE_INIT02 BIT(2)
+#define SVSB_MODE_MON BIT(3)
/* svs bank volt flags */
#define SVSB_INIT01_PD_REQ BIT(0)
@@ -49,16 +51,21 @@
#define SVSB_DTLO 0xfe
#define SVSB_EN_INIT01 0x1
#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_MON 0x2
#define SVSB_EN_OFF 0x0
#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTEN_MONVOPEN 0x00ff0000
#define SVSB_INTSTS_CLEAN 0x00ffffff
#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_INTSTS_MONVOP 0x00ff0000
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
#define MAX_OPP_ENTRIES 16
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
+#define SVSB_TEMP_LOWER_BOUND 0xb2
+#define SVSB_TEMP_UPPER_BOUND 0x64
static DEFINE_SPINLOCK(svs_lock);
@@ -67,6 +74,7 @@ static DEFINE_SPINLOCK(svs_lock);
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
* @SVSB_PHASE_INIT01: svs bank basic init for data calibration
* @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
* @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
*
* Each svs bank has its own independent phase and we enable each svs bank by
@@ -74,12 +82,13 @@ static DEFINE_SPINLOCK(svs_lock);
* condition, it will fire an irq (PHASE_ERROR) to inform svs software.
*
* svs bank general phase-enabled order:
- * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
*/
enum svsb_phase {
SVSB_PHASE_ERROR = 0,
SVSB_PHASE_INIT01,
SVSB_PHASE_INIT02,
+ SVSB_PHASE_MON,
SVSB_PHASE_MAX,
};
@@ -210,9 +219,11 @@ static const u32 svs_regs_v2[] = {
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
* @efuse_max: total number of svs efuse
+ * @tefuse_max: total number of thermal efuse
* @regs: svs platform registers map
* @bank_max: total number of svs banks
* @efuse: svs efuse data received from NVMEM framework
+ * @tefuse: thermal efuse data received from NVMEM framework
*/
struct svs_platform {
char *name;
@@ -225,9 +236,11 @@ struct svs_platform {
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
size_t efuse_max;
+ size_t tefuse_max;
const u32 *regs;
u32 bank_max;
u32 *efuse;
+ u32 *tefuse;
};
struct svs_platform_data {
@@ -246,11 +259,13 @@ struct svs_platform_data {
* @opp_dev: device for opp table/buck control
* @init_completion: the timeout completion for bank init
* @buck: regulator used by opp_dev
+ * @tzd: thermal zone device for getting temperature
* @lock: mutex lock to protect voltage update process
* @set_freq_pct: function pointer to set bank frequency percent table
* @get_volts: function pointer to get bank voltages
* @name: bank name
* @buck_name: regulator name
+ * @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
* @pm_runtime_enabled_count: bank pm runtime enabled count
@@ -279,6 +294,13 @@ struct svs_platform_data {
* @sw_id: bank software identification
* @cpu_id: cpu core id for SVS CPU bank use only
* @ctl0: TS-x selection
+ * @temp: bank temperature
+ * @tzone_htemp: thermal zone high temperature threshold
+ * @tzone_htemp_voffset: thermal zone high temperature voltage offset
+ * @tzone_ltemp: thermal zone low temperature threshold
+ * @tzone_ltemp_voffset: thermal zone low temperature voltage offset
+ * @bts: svs efuse data
+ * @mts: svs efuse data
* @bdes: svs efuse data
* @mdes: svs efuse data
* @mtdes: svs efuse data
@@ -295,11 +317,13 @@ struct svs_bank {
struct device *opp_dev;
struct completion init_completion;
struct regulator *buck;
+ struct thermal_zone_device *tzd;
struct mutex lock; /* lock to protect voltage update process */
void (*set_freq_pct)(struct svs_platform *svsp);
void (*get_volts)(struct svs_platform *svsp);
char *name;
char *buck_name;
+ char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
u32 pm_runtime_enabled_count;
@@ -328,6 +352,13 @@ struct svs_bank {
u32 sw_id;
u32 cpu_id;
u32 ctl0;
+ u32 temp;
+ u32 tzone_htemp;
+ u32 tzone_htemp_voffset;
+ u32 tzone_ltemp;
+ u32 tzone_ltemp_voffset;
+ u32 bts;
+ u32 mts;
u32 bdes;
u32 mdes;
u32 mtdes;
@@ -370,11 +401,27 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
- int ret = -EPERM;
- u32 i, svsb_volt, opp_volt;
+ int ret = -EPERM, tzone_temp = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0;
mutex_lock(&svsb->lock);
+ /* Get thermal effect */
+ if (svsb->phase == SVSB_PHASE_MON) {
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret || (svsb->temp > SVSB_TEMP_UPPER_BOUND &&
+ svsb->temp < SVSB_TEMP_LOWER_BOUND)) {
+ dev_err(svsb->dev, "%s: %d (0x%x), run default volts\n",
+ svsb->tzone_name, ret, svsb->temp);
+ svsb->phase = SVSB_PHASE_ERROR;
+ }
+
+ if (tzone_temp >= svsb->tzone_htemp)
+ temp_voffset += svsb->tzone_htemp_voffset;
+ else if (tzone_temp <= svsb->tzone_ltemp)
+ temp_voffset += svsb->tzone_ltemp_voffset;
+ }
+
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
for (i = 0; i < svsb->opp_count; i++) {
switch (svsb->phase) {
@@ -390,6 +437,12 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
svsb->volt_step,
svsb->volt_base);
break;
+ case SVSB_PHASE_MON:
+ svsb_volt = max(svsb->volt[i] + temp_voffset, svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
default:
dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
ret = -EINVAL;
@@ -484,7 +537,7 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
enum svsb_phase target_phase)
{
struct svs_bank *svsb = svsp->pbank;
- u32 des_char, temp_char, det_char, limit_vals, init2vals;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals, ts_calcs;
svs_switch_bank(svsp);
@@ -525,6 +578,12 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
svs_writel_relaxed(svsp, init2vals, INIT2VALS);
svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
break;
+ case SVSB_PHASE_MON:
+ ts_calcs = (svsb->bts << 12) | svsb->mts;
+ svs_writel_relaxed(svsp, ts_calcs, TSCALCS);
+ svs_writel_relaxed(svsp, SVSB_INTEN_MONVOPEN, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_MON, SVSEN);
+ break;
default:
dev_err(svsb->dev, "requested unknown target phase: %u\n",
target_phase);
@@ -544,6 +603,7 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
svs_readl_relaxed(svsp, SMSTATE0),
svs_readl_relaxed(svsp, SMSTATE1));
+ dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
@@ -591,6 +651,17 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
}
+static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svsb->phase = SVSB_PHASE_MON;
+ svsb->get_volts(svsp);
+
+ svsb->temp = svs_readl_relaxed(svsp, TEMP) & GENMASK(7, 0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_MONVOP, INTSTS);
+}
+
static irqreturn_t svs_isr(int irq, void *data)
{
struct svs_platform *svsp = data;
@@ -621,6 +692,8 @@ static irqreturn_t svs_isr(int irq, void *data)
else if (int_sts == SVSB_INTSTS_COMPLETE &&
svs_en == SVSB_EN_INIT02)
svs_init02_isr_handler(svsp);
+ else if (int_sts & SVSB_INTSTS_MONVOP)
+ svs_mon_mode_isr_handler(svsp);
else
svs_error_isr_handler(svsp);
@@ -835,6 +908,25 @@ static int svs_init02(struct svs_platform *svsp)
return 0;
}
+static void svs_mon_mode(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_MON))
+ continue;
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_MON);
+ spin_unlock_irqrestore(&svs_lock, flags);
+ }
+}
+
static int svs_start(struct svs_platform *svsp)
{
int ret;
@@ -847,6 +939,8 @@ static int svs_start(struct svs_platform *svsp)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -892,6 +986,8 @@ static int svs_resume(struct device *dev)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -956,6 +1052,15 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
}
}
+ if (svsb->mode_support & SVSB_MODE_MON) {
+ svsb->tzd = thermal_zone_get_zone_by_name(svsb->tzone_name);
+ if (IS_ERR(svsb->tzd)) {
+ dev_err(svsb->dev, "cannot get \"%s\" thermal zone\n",
+ svsb->tzone_name);
+ return PTR_ERR(svsb->tzd);
+ }
+ }
+
count = dev_pm_opp_get_opp_count(svsb->opp_dev);
if (svsb->opp_count != count) {
dev_err(svsb->dev,
@@ -986,7 +1091,11 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
- u32 idx, i, ft_pgm;
+ struct nvmem_cell *cell;
+ int format[6], x_roomt[6], o_vtsmcu[5], o_vtsabb, tb_roomt = 0;
+ int adc_ge_t, adc_oe_t, ge, oe, gain, degc_cali, adc_cali_en_t;
+ int o_slope, o_slope_sign, ts_id;
+ u32 idx, i, ft_pgm, mts, temp0, temp1, temp2;
for (i = 0; i < svsp->efuse_max; i++)
if (svsp->efuse[i])
@@ -1062,6 +1171,127 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
}
}
+ /* Get thermal efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ /* Thermal efuse parsing */
+ adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
+ adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
+
+ o_vtsmcu[0] = (svsp->tefuse[0] >> 17) & GENMASK(8, 0);
+ o_vtsmcu[1] = (svsp->tefuse[0] >> 8) & GENMASK(8, 0);
+ o_vtsmcu[2] = svsp->tefuse[1] & GENMASK(8, 0);
+ o_vtsmcu[3] = (svsp->tefuse[2] >> 23) & GENMASK(8, 0);
+ o_vtsmcu[4] = (svsp->tefuse[2] >> 5) & GENMASK(8, 0);
+ o_vtsabb = (svsp->tefuse[2] >> 14) & GENMASK(8, 0);
+
+ degc_cali = (svsp->tefuse[0] >> 1) & GENMASK(5, 0);
+ adc_cali_en_t = svsp->tefuse[0] & BIT(0);
+ o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
+
+ ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
+ o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+
+ if (adc_cali_en_t == 1) {
+ if (!ts_id)
+ o_slope = 0;
+
+ if (adc_ge_t < 265 || adc_ge_t > 758 ||
+ adc_oe_t < 265 || adc_oe_t > 758 ||
+ o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
+ o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
+ o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
+ o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
+ o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
+ o_vtsabb < -8 || o_vtsabb > 484 ||
+ degc_cali < 1 || degc_cali > 63) {
+ dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+ } else {
+ dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ ge = ((adc_ge_t - 512) * 10000) / 4096;
+ oe = (adc_oe_t - 512);
+ gain = (10000 + ge);
+
+ format[0] = (o_vtsmcu[0] + 3350 - oe);
+ format[1] = (o_vtsmcu[1] + 3350 - oe);
+ format[2] = (o_vtsmcu[2] + 3350 - oe);
+ format[3] = (o_vtsmcu[3] + 3350 - oe);
+ format[4] = (o_vtsmcu[4] + 3350 - oe);
+ format[5] = (o_vtsabb + 3350 - oe);
+
+ for (i = 0; i < 6; i++)
+ x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / gain;
+
+ temp0 = (10000 * 100000 / gain) * 15 / 18;
+
+ if (!o_slope_sign)
+ mts = (temp0 * 10) / (1534 + o_slope * 10);
+ else
+ mts = (temp0 * 10) / (1534 - o_slope * 10);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = mts;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_CPU_BIG:
+ tb_roomt = x_roomt[4];
+ break;
+ case SVSB_CCI:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_GPU:
+ tb_roomt = x_roomt[1];
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ temp0 = (degc_cali * 10 / 2);
+ temp1 = ((10000 * 100000 / 4096 / gain) *
+ oe + tb_roomt * 10) * 15 / 18;
+
+ if (!o_slope_sign)
+ temp2 = temp1 * 100 / (1534 + o_slope * 10);
+ else
+ temp2 = temp1 * 100 / (1534 - o_slope * 10);
+
+ svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
+ }
+
+ return true;
+
+remove_mt8183_svsb_mon_mode:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mode_support &= ~SVSB_MODE_MON;
+ }
+
return true;
}
@@ -1145,9 +1375,15 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
+ struct device *dev;
struct svs_bank *svsb;
u32 idx;
+ dev = svs_add_device_link(svsp, "thermal");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get thermal device\n");
+
for (idx = 0; idx < svsp->bank_max; idx++) {
svsb = &svsp->banks[idx];
@@ -1253,9 +1489,11 @@ static struct svs_bank svs_mt8183_banks[] = {
.set_freq_pct = svs_set_bank_freq_pct_v2,
.get_volts = svs_get_bank_volts_v2,
.buck_name = "mali",
+ .tzone_name = "tzts2",
.volt_flags = SVSB_INIT01_PD_REQ |
SVSB_INIT01_VOLT_INC_ONLY,
- .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02 |
+ SVSB_MODE_MON,
.opp_count = MAX_OPP_ENTRIES,
.freq_base = 900000000,
.vboot = 0x30,
@@ -1271,6 +1509,10 @@ static struct svs_bank svs_mt8183_banks[] = {
.core_sel = 0x8fff0003,
.int_st = BIT(3),
.ctl0 = 0x00050001,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 3,
},
};
@@ -1395,6 +1637,8 @@ static int svs_probe(struct platform_device *pdev)
svs_probe_free_resource:
if (!IS_ERR_OR_NULL(svsp->efuse))
kfree(svsp->efuse);
+ if (!IS_ERR_OR_NULL(svsp->tefuse))
+ kfree(svsp->tefuse);
return ret;
}
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
SVS monitor mode is based on different thermal temperature
to provide suitable SVS bank voltages.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 256 ++++++++++++++++++++++++++++++++-
1 file changed, 250 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index cc23a701159e..44ccad1e3327 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -25,6 +25,7 @@
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/thermal.h>
/* svs bank 1-line software id */
#define SVSB_CPU_LITTLE BIT(0)
@@ -36,6 +37,7 @@
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
#define SVSB_MODE_INIT02 BIT(2)
+#define SVSB_MODE_MON BIT(3)
/* svs bank volt flags */
#define SVSB_INIT01_PD_REQ BIT(0)
@@ -49,16 +51,21 @@
#define SVSB_DTLO 0xfe
#define SVSB_EN_INIT01 0x1
#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_MON 0x2
#define SVSB_EN_OFF 0x0
#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTEN_MONVOPEN 0x00ff0000
#define SVSB_INTSTS_CLEAN 0x00ffffff
#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_INTSTS_MONVOP 0x00ff0000
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
#define MAX_OPP_ENTRIES 16
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
+#define SVSB_TEMP_LOWER_BOUND 0xb2
+#define SVSB_TEMP_UPPER_BOUND 0x64
static DEFINE_SPINLOCK(svs_lock);
@@ -67,6 +74,7 @@ static DEFINE_SPINLOCK(svs_lock);
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
* @SVSB_PHASE_INIT01: svs bank basic init for data calibration
* @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
* @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
*
* Each svs bank has its own independent phase and we enable each svs bank by
@@ -74,12 +82,13 @@ static DEFINE_SPINLOCK(svs_lock);
* condition, it will fire an irq (PHASE_ERROR) to inform svs software.
*
* svs bank general phase-enabled order:
- * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
*/
enum svsb_phase {
SVSB_PHASE_ERROR = 0,
SVSB_PHASE_INIT01,
SVSB_PHASE_INIT02,
+ SVSB_PHASE_MON,
SVSB_PHASE_MAX,
};
@@ -210,9 +219,11 @@ static const u32 svs_regs_v2[] = {
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
* @efuse_max: total number of svs efuse
+ * @tefuse_max: total number of thermal efuse
* @regs: svs platform registers map
* @bank_max: total number of svs banks
* @efuse: svs efuse data received from NVMEM framework
+ * @tefuse: thermal efuse data received from NVMEM framework
*/
struct svs_platform {
char *name;
@@ -225,9 +236,11 @@ struct svs_platform {
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
size_t efuse_max;
+ size_t tefuse_max;
const u32 *regs;
u32 bank_max;
u32 *efuse;
+ u32 *tefuse;
};
struct svs_platform_data {
@@ -246,11 +259,13 @@ struct svs_platform_data {
* @opp_dev: device for opp table/buck control
* @init_completion: the timeout completion for bank init
* @buck: regulator used by opp_dev
+ * @tzd: thermal zone device for getting temperature
* @lock: mutex lock to protect voltage update process
* @set_freq_pct: function pointer to set bank frequency percent table
* @get_volts: function pointer to get bank voltages
* @name: bank name
* @buck_name: regulator name
+ * @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
* @pm_runtime_enabled_count: bank pm runtime enabled count
@@ -279,6 +294,13 @@ struct svs_platform_data {
* @sw_id: bank software identification
* @cpu_id: cpu core id for SVS CPU bank use only
* @ctl0: TS-x selection
+ * @temp: bank temperature
+ * @tzone_htemp: thermal zone high temperature threshold
+ * @tzone_htemp_voffset: thermal zone high temperature voltage offset
+ * @tzone_ltemp: thermal zone low temperature threshold
+ * @tzone_ltemp_voffset: thermal zone low temperature voltage offset
+ * @bts: svs efuse data
+ * @mts: svs efuse data
* @bdes: svs efuse data
* @mdes: svs efuse data
* @mtdes: svs efuse data
@@ -295,11 +317,13 @@ struct svs_bank {
struct device *opp_dev;
struct completion init_completion;
struct regulator *buck;
+ struct thermal_zone_device *tzd;
struct mutex lock; /* lock to protect voltage update process */
void (*set_freq_pct)(struct svs_platform *svsp);
void (*get_volts)(struct svs_platform *svsp);
char *name;
char *buck_name;
+ char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
u32 pm_runtime_enabled_count;
@@ -328,6 +352,13 @@ struct svs_bank {
u32 sw_id;
u32 cpu_id;
u32 ctl0;
+ u32 temp;
+ u32 tzone_htemp;
+ u32 tzone_htemp_voffset;
+ u32 tzone_ltemp;
+ u32 tzone_ltemp_voffset;
+ u32 bts;
+ u32 mts;
u32 bdes;
u32 mdes;
u32 mtdes;
@@ -370,11 +401,27 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
- int ret = -EPERM;
- u32 i, svsb_volt, opp_volt;
+ int ret = -EPERM, tzone_temp = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0;
mutex_lock(&svsb->lock);
+ /* Get thermal effect */
+ if (svsb->phase == SVSB_PHASE_MON) {
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret || (svsb->temp > SVSB_TEMP_UPPER_BOUND &&
+ svsb->temp < SVSB_TEMP_LOWER_BOUND)) {
+ dev_err(svsb->dev, "%s: %d (0x%x), run default volts\n",
+ svsb->tzone_name, ret, svsb->temp);
+ svsb->phase = SVSB_PHASE_ERROR;
+ }
+
+ if (tzone_temp >= svsb->tzone_htemp)
+ temp_voffset += svsb->tzone_htemp_voffset;
+ else if (tzone_temp <= svsb->tzone_ltemp)
+ temp_voffset += svsb->tzone_ltemp_voffset;
+ }
+
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
for (i = 0; i < svsb->opp_count; i++) {
switch (svsb->phase) {
@@ -390,6 +437,12 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
svsb->volt_step,
svsb->volt_base);
break;
+ case SVSB_PHASE_MON:
+ svsb_volt = max(svsb->volt[i] + temp_voffset, svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
default:
dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
ret = -EINVAL;
@@ -484,7 +537,7 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
enum svsb_phase target_phase)
{
struct svs_bank *svsb = svsp->pbank;
- u32 des_char, temp_char, det_char, limit_vals, init2vals;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals, ts_calcs;
svs_switch_bank(svsp);
@@ -525,6 +578,12 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
svs_writel_relaxed(svsp, init2vals, INIT2VALS);
svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
break;
+ case SVSB_PHASE_MON:
+ ts_calcs = (svsb->bts << 12) | svsb->mts;
+ svs_writel_relaxed(svsp, ts_calcs, TSCALCS);
+ svs_writel_relaxed(svsp, SVSB_INTEN_MONVOPEN, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_MON, SVSEN);
+ break;
default:
dev_err(svsb->dev, "requested unknown target phase: %u\n",
target_phase);
@@ -544,6 +603,7 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
svs_readl_relaxed(svsp, SMSTATE0),
svs_readl_relaxed(svsp, SMSTATE1));
+ dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
@@ -591,6 +651,17 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
}
+static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svsb->phase = SVSB_PHASE_MON;
+ svsb->get_volts(svsp);
+
+ svsb->temp = svs_readl_relaxed(svsp, TEMP) & GENMASK(7, 0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_MONVOP, INTSTS);
+}
+
static irqreturn_t svs_isr(int irq, void *data)
{
struct svs_platform *svsp = data;
@@ -621,6 +692,8 @@ static irqreturn_t svs_isr(int irq, void *data)
else if (int_sts == SVSB_INTSTS_COMPLETE &&
svs_en == SVSB_EN_INIT02)
svs_init02_isr_handler(svsp);
+ else if (int_sts & SVSB_INTSTS_MONVOP)
+ svs_mon_mode_isr_handler(svsp);
else
svs_error_isr_handler(svsp);
@@ -835,6 +908,25 @@ static int svs_init02(struct svs_platform *svsp)
return 0;
}
+static void svs_mon_mode(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_MON))
+ continue;
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_MON);
+ spin_unlock_irqrestore(&svs_lock, flags);
+ }
+}
+
static int svs_start(struct svs_platform *svsp)
{
int ret;
@@ -847,6 +939,8 @@ static int svs_start(struct svs_platform *svsp)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -892,6 +986,8 @@ static int svs_resume(struct device *dev)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -956,6 +1052,15 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
}
}
+ if (svsb->mode_support & SVSB_MODE_MON) {
+ svsb->tzd = thermal_zone_get_zone_by_name(svsb->tzone_name);
+ if (IS_ERR(svsb->tzd)) {
+ dev_err(svsb->dev, "cannot get \"%s\" thermal zone\n",
+ svsb->tzone_name);
+ return PTR_ERR(svsb->tzd);
+ }
+ }
+
count = dev_pm_opp_get_opp_count(svsb->opp_dev);
if (svsb->opp_count != count) {
dev_err(svsb->dev,
@@ -986,7 +1091,11 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
- u32 idx, i, ft_pgm;
+ struct nvmem_cell *cell;
+ int format[6], x_roomt[6], o_vtsmcu[5], o_vtsabb, tb_roomt = 0;
+ int adc_ge_t, adc_oe_t, ge, oe, gain, degc_cali, adc_cali_en_t;
+ int o_slope, o_slope_sign, ts_id;
+ u32 idx, i, ft_pgm, mts, temp0, temp1, temp2;
for (i = 0; i < svsp->efuse_max; i++)
if (svsp->efuse[i])
@@ -1062,6 +1171,127 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
}
}
+ /* Get thermal efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ /* Thermal efuse parsing */
+ adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
+ adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
+
+ o_vtsmcu[0] = (svsp->tefuse[0] >> 17) & GENMASK(8, 0);
+ o_vtsmcu[1] = (svsp->tefuse[0] >> 8) & GENMASK(8, 0);
+ o_vtsmcu[2] = svsp->tefuse[1] & GENMASK(8, 0);
+ o_vtsmcu[3] = (svsp->tefuse[2] >> 23) & GENMASK(8, 0);
+ o_vtsmcu[4] = (svsp->tefuse[2] >> 5) & GENMASK(8, 0);
+ o_vtsabb = (svsp->tefuse[2] >> 14) & GENMASK(8, 0);
+
+ degc_cali = (svsp->tefuse[0] >> 1) & GENMASK(5, 0);
+ adc_cali_en_t = svsp->tefuse[0] & BIT(0);
+ o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
+
+ ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
+ o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+
+ if (adc_cali_en_t == 1) {
+ if (!ts_id)
+ o_slope = 0;
+
+ if (adc_ge_t < 265 || adc_ge_t > 758 ||
+ adc_oe_t < 265 || adc_oe_t > 758 ||
+ o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
+ o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
+ o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
+ o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
+ o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
+ o_vtsabb < -8 || o_vtsabb > 484 ||
+ degc_cali < 1 || degc_cali > 63) {
+ dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+ } else {
+ dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ ge = ((adc_ge_t - 512) * 10000) / 4096;
+ oe = (adc_oe_t - 512);
+ gain = (10000 + ge);
+
+ format[0] = (o_vtsmcu[0] + 3350 - oe);
+ format[1] = (o_vtsmcu[1] + 3350 - oe);
+ format[2] = (o_vtsmcu[2] + 3350 - oe);
+ format[3] = (o_vtsmcu[3] + 3350 - oe);
+ format[4] = (o_vtsmcu[4] + 3350 - oe);
+ format[5] = (o_vtsabb + 3350 - oe);
+
+ for (i = 0; i < 6; i++)
+ x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / gain;
+
+ temp0 = (10000 * 100000 / gain) * 15 / 18;
+
+ if (!o_slope_sign)
+ mts = (temp0 * 10) / (1534 + o_slope * 10);
+ else
+ mts = (temp0 * 10) / (1534 - o_slope * 10);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = mts;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_CPU_BIG:
+ tb_roomt = x_roomt[4];
+ break;
+ case SVSB_CCI:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_GPU:
+ tb_roomt = x_roomt[1];
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ temp0 = (degc_cali * 10 / 2);
+ temp1 = ((10000 * 100000 / 4096 / gain) *
+ oe + tb_roomt * 10) * 15 / 18;
+
+ if (!o_slope_sign)
+ temp2 = temp1 * 100 / (1534 + o_slope * 10);
+ else
+ temp2 = temp1 * 100 / (1534 - o_slope * 10);
+
+ svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
+ }
+
+ return true;
+
+remove_mt8183_svsb_mon_mode:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mode_support &= ~SVSB_MODE_MON;
+ }
+
return true;
}
@@ -1145,9 +1375,15 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
+ struct device *dev;
struct svs_bank *svsb;
u32 idx;
+ dev = svs_add_device_link(svsp, "thermal");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get thermal device\n");
+
for (idx = 0; idx < svsp->bank_max; idx++) {
svsb = &svsp->banks[idx];
@@ -1253,9 +1489,11 @@ static struct svs_bank svs_mt8183_banks[] = {
.set_freq_pct = svs_set_bank_freq_pct_v2,
.get_volts = svs_get_bank_volts_v2,
.buck_name = "mali",
+ .tzone_name = "tzts2",
.volt_flags = SVSB_INIT01_PD_REQ |
SVSB_INIT01_VOLT_INC_ONLY,
- .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02 |
+ SVSB_MODE_MON,
.opp_count = MAX_OPP_ENTRIES,
.freq_base = 900000000,
.vboot = 0x30,
@@ -1271,6 +1509,10 @@ static struct svs_bank svs_mt8183_banks[] = {
.core_sel = 0x8fff0003,
.int_st = BIT(3),
.ctl0 = 0x00050001,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 3,
},
};
@@ -1395,6 +1637,8 @@ static int svs_probe(struct platform_device *pdev)
svs_probe_free_resource:
if (!IS_ERR_OR_NULL(svsp->efuse))
kfree(svsp->efuse);
+ if (!IS_ERR_OR_NULL(svsp->tefuse))
+ kfree(svsp->tefuse);
return ret;
}
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
SVS monitor mode is based on different thermal temperature
to provide suitable SVS bank voltages.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 256 ++++++++++++++++++++++++++++++++-
1 file changed, 250 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index cc23a701159e..44ccad1e3327 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -25,6 +25,7 @@
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/thermal.h>
/* svs bank 1-line software id */
#define SVSB_CPU_LITTLE BIT(0)
@@ -36,6 +37,7 @@
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
#define SVSB_MODE_INIT02 BIT(2)
+#define SVSB_MODE_MON BIT(3)
/* svs bank volt flags */
#define SVSB_INIT01_PD_REQ BIT(0)
@@ -49,16 +51,21 @@
#define SVSB_DTLO 0xfe
#define SVSB_EN_INIT01 0x1
#define SVSB_EN_INIT02 0x5
+#define SVSB_EN_MON 0x2
#define SVSB_EN_OFF 0x0
#define SVSB_INTEN_INIT0x 0x00005f01
+#define SVSB_INTEN_MONVOPEN 0x00ff0000
#define SVSB_INTSTS_CLEAN 0x00ffffff
#define SVSB_INTSTS_COMPLETE 0x1
+#define SVSB_INTSTS_MONVOP 0x00ff0000
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
#define MAX_OPP_ENTRIES 16
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
+#define SVSB_TEMP_LOWER_BOUND 0xb2
+#define SVSB_TEMP_UPPER_BOUND 0x64
static DEFINE_SPINLOCK(svs_lock);
@@ -67,6 +74,7 @@ static DEFINE_SPINLOCK(svs_lock);
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
* @SVSB_PHASE_INIT01: svs bank basic init for data calibration
* @SVSB_PHASE_INIT02: svs bank can provide voltages to opp table
+ * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
* @SVSB_PHASE_MAX: total number of svs bank phase (debug purpose)
*
* Each svs bank has its own independent phase and we enable each svs bank by
@@ -74,12 +82,13 @@ static DEFINE_SPINLOCK(svs_lock);
* condition, it will fire an irq (PHASE_ERROR) to inform svs software.
*
* svs bank general phase-enabled order:
- * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
*/
enum svsb_phase {
SVSB_PHASE_ERROR = 0,
SVSB_PHASE_INIT01,
SVSB_PHASE_INIT02,
+ SVSB_PHASE_MON,
SVSB_PHASE_MAX,
};
@@ -210,9 +219,11 @@ static const u32 svs_regs_v2[] = {
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
* @efuse_max: total number of svs efuse
+ * @tefuse_max: total number of thermal efuse
* @regs: svs platform registers map
* @bank_max: total number of svs banks
* @efuse: svs efuse data received from NVMEM framework
+ * @tefuse: thermal efuse data received from NVMEM framework
*/
struct svs_platform {
char *name;
@@ -225,9 +236,11 @@ struct svs_platform {
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
size_t efuse_max;
+ size_t tefuse_max;
const u32 *regs;
u32 bank_max;
u32 *efuse;
+ u32 *tefuse;
};
struct svs_platform_data {
@@ -246,11 +259,13 @@ struct svs_platform_data {
* @opp_dev: device for opp table/buck control
* @init_completion: the timeout completion for bank init
* @buck: regulator used by opp_dev
+ * @tzd: thermal zone device for getting temperature
* @lock: mutex lock to protect voltage update process
* @set_freq_pct: function pointer to set bank frequency percent table
* @get_volts: function pointer to get bank voltages
* @name: bank name
* @buck_name: regulator name
+ * @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
* @pm_runtime_enabled_count: bank pm runtime enabled count
@@ -279,6 +294,13 @@ struct svs_platform_data {
* @sw_id: bank software identification
* @cpu_id: cpu core id for SVS CPU bank use only
* @ctl0: TS-x selection
+ * @temp: bank temperature
+ * @tzone_htemp: thermal zone high temperature threshold
+ * @tzone_htemp_voffset: thermal zone high temperature voltage offset
+ * @tzone_ltemp: thermal zone low temperature threshold
+ * @tzone_ltemp_voffset: thermal zone low temperature voltage offset
+ * @bts: svs efuse data
+ * @mts: svs efuse data
* @bdes: svs efuse data
* @mdes: svs efuse data
* @mtdes: svs efuse data
@@ -295,11 +317,13 @@ struct svs_bank {
struct device *opp_dev;
struct completion init_completion;
struct regulator *buck;
+ struct thermal_zone_device *tzd;
struct mutex lock; /* lock to protect voltage update process */
void (*set_freq_pct)(struct svs_platform *svsp);
void (*get_volts)(struct svs_platform *svsp);
char *name;
char *buck_name;
+ char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
u32 pm_runtime_enabled_count;
@@ -328,6 +352,13 @@ struct svs_bank {
u32 sw_id;
u32 cpu_id;
u32 ctl0;
+ u32 temp;
+ u32 tzone_htemp;
+ u32 tzone_htemp_voffset;
+ u32 tzone_ltemp;
+ u32 tzone_ltemp_voffset;
+ u32 bts;
+ u32 mts;
u32 bdes;
u32 mdes;
u32 mtdes;
@@ -370,11 +401,27 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
- int ret = -EPERM;
- u32 i, svsb_volt, opp_volt;
+ int ret = -EPERM, tzone_temp = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0;
mutex_lock(&svsb->lock);
+ /* Get thermal effect */
+ if (svsb->phase == SVSB_PHASE_MON) {
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret || (svsb->temp > SVSB_TEMP_UPPER_BOUND &&
+ svsb->temp < SVSB_TEMP_LOWER_BOUND)) {
+ dev_err(svsb->dev, "%s: %d (0x%x), run default volts\n",
+ svsb->tzone_name, ret, svsb->temp);
+ svsb->phase = SVSB_PHASE_ERROR;
+ }
+
+ if (tzone_temp >= svsb->tzone_htemp)
+ temp_voffset += svsb->tzone_htemp_voffset;
+ else if (tzone_temp <= svsb->tzone_ltemp)
+ temp_voffset += svsb->tzone_ltemp_voffset;
+ }
+
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
for (i = 0; i < svsb->opp_count; i++) {
switch (svsb->phase) {
@@ -390,6 +437,12 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
svsb->volt_step,
svsb->volt_base);
break;
+ case SVSB_PHASE_MON:
+ svsb_volt = max(svsb->volt[i] + temp_voffset, svsb->vmin);
+ opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ break;
default:
dev_err(svsb->dev, "unknown phase: %u\n", svsb->phase);
ret = -EINVAL;
@@ -484,7 +537,7 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
enum svsb_phase target_phase)
{
struct svs_bank *svsb = svsp->pbank;
- u32 des_char, temp_char, det_char, limit_vals, init2vals;
+ u32 des_char, temp_char, det_char, limit_vals, init2vals, ts_calcs;
svs_switch_bank(svsp);
@@ -525,6 +578,12 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
svs_writel_relaxed(svsp, init2vals, INIT2VALS);
svs_writel_relaxed(svsp, SVSB_EN_INIT02, SVSEN);
break;
+ case SVSB_PHASE_MON:
+ ts_calcs = (svsb->bts << 12) | svsb->mts;
+ svs_writel_relaxed(svsp, ts_calcs, TSCALCS);
+ svs_writel_relaxed(svsp, SVSB_INTEN_MONVOPEN, INTEN);
+ svs_writel_relaxed(svsp, SVSB_EN_MON, SVSEN);
+ break;
default:
dev_err(svsb->dev, "requested unknown target phase: %u\n",
target_phase);
@@ -544,6 +603,7 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
svs_readl_relaxed(svsp, SMSTATE0),
svs_readl_relaxed(svsp, SMSTATE1));
+ dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
@@ -591,6 +651,17 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_writel_relaxed(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
}
+static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+
+ svsb->phase = SVSB_PHASE_MON;
+ svsb->get_volts(svsp);
+
+ svsb->temp = svs_readl_relaxed(svsp, TEMP) & GENMASK(7, 0);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_MONVOP, INTSTS);
+}
+
static irqreturn_t svs_isr(int irq, void *data)
{
struct svs_platform *svsp = data;
@@ -621,6 +692,8 @@ static irqreturn_t svs_isr(int irq, void *data)
else if (int_sts == SVSB_INTSTS_COMPLETE &&
svs_en == SVSB_EN_INIT02)
svs_init02_isr_handler(svsp);
+ else if (int_sts & SVSB_INTSTS_MONVOP)
+ svs_mon_mode_isr_handler(svsp);
else
svs_error_isr_handler(svsp);
@@ -835,6 +908,25 @@ static int svs_init02(struct svs_platform *svsp)
return 0;
}
+static void svs_mon_mode(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ unsigned long flags;
+ u32 idx;
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_MON))
+ continue;
+
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svs_set_bank_phase(svsp, SVSB_PHASE_MON);
+ spin_unlock_irqrestore(&svs_lock, flags);
+ }
+}
+
static int svs_start(struct svs_platform *svsp)
{
int ret;
@@ -847,6 +939,8 @@ static int svs_start(struct svs_platform *svsp)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -892,6 +986,8 @@ static int svs_resume(struct device *dev)
if (ret)
return ret;
+ svs_mon_mode(svsp);
+
return 0;
}
@@ -956,6 +1052,15 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
}
}
+ if (svsb->mode_support & SVSB_MODE_MON) {
+ svsb->tzd = thermal_zone_get_zone_by_name(svsb->tzone_name);
+ if (IS_ERR(svsb->tzd)) {
+ dev_err(svsb->dev, "cannot get \"%s\" thermal zone\n",
+ svsb->tzone_name);
+ return PTR_ERR(svsb->tzd);
+ }
+ }
+
count = dev_pm_opp_get_opp_count(svsb->opp_dev);
if (svsb->opp_count != count) {
dev_err(svsb->dev,
@@ -986,7 +1091,11 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
- u32 idx, i, ft_pgm;
+ struct nvmem_cell *cell;
+ int format[6], x_roomt[6], o_vtsmcu[5], o_vtsabb, tb_roomt = 0;
+ int adc_ge_t, adc_oe_t, ge, oe, gain, degc_cali, adc_cali_en_t;
+ int o_slope, o_slope_sign, ts_id;
+ u32 idx, i, ft_pgm, mts, temp0, temp1, temp2;
for (i = 0; i < svsp->efuse_max; i++)
if (svsp->efuse[i])
@@ -1062,6 +1171,127 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
}
}
+ /* Get thermal efuse by nvmem */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ /* Thermal efuse parsing */
+ adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
+ adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
+
+ o_vtsmcu[0] = (svsp->tefuse[0] >> 17) & GENMASK(8, 0);
+ o_vtsmcu[1] = (svsp->tefuse[0] >> 8) & GENMASK(8, 0);
+ o_vtsmcu[2] = svsp->tefuse[1] & GENMASK(8, 0);
+ o_vtsmcu[3] = (svsp->tefuse[2] >> 23) & GENMASK(8, 0);
+ o_vtsmcu[4] = (svsp->tefuse[2] >> 5) & GENMASK(8, 0);
+ o_vtsabb = (svsp->tefuse[2] >> 14) & GENMASK(8, 0);
+
+ degc_cali = (svsp->tefuse[0] >> 1) & GENMASK(5, 0);
+ adc_cali_en_t = svsp->tefuse[0] & BIT(0);
+ o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
+
+ ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
+ o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+
+ if (adc_cali_en_t == 1) {
+ if (!ts_id)
+ o_slope = 0;
+
+ if (adc_ge_t < 265 || adc_ge_t > 758 ||
+ adc_oe_t < 265 || adc_oe_t > 758 ||
+ o_vtsmcu[0] < -8 || o_vtsmcu[0] > 484 ||
+ o_vtsmcu[1] < -8 || o_vtsmcu[1] > 484 ||
+ o_vtsmcu[2] < -8 || o_vtsmcu[2] > 484 ||
+ o_vtsmcu[3] < -8 || o_vtsmcu[3] > 484 ||
+ o_vtsmcu[4] < -8 || o_vtsmcu[4] > 484 ||
+ o_vtsabb < -8 || o_vtsabb > 484 ||
+ degc_cali < 1 || degc_cali > 63) {
+ dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+ } else {
+ dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ ge = ((adc_ge_t - 512) * 10000) / 4096;
+ oe = (adc_oe_t - 512);
+ gain = (10000 + ge);
+
+ format[0] = (o_vtsmcu[0] + 3350 - oe);
+ format[1] = (o_vtsmcu[1] + 3350 - oe);
+ format[2] = (o_vtsmcu[2] + 3350 - oe);
+ format[3] = (o_vtsmcu[3] + 3350 - oe);
+ format[4] = (o_vtsmcu[4] + 3350 - oe);
+ format[5] = (o_vtsabb + 3350 - oe);
+
+ for (i = 0; i < 6; i++)
+ x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / gain;
+
+ temp0 = (10000 * 100000 / gain) * 15 / 18;
+
+ if (!o_slope_sign)
+ mts = (temp0 * 10) / (1534 + o_slope * 10);
+ else
+ mts = (temp0 * 10) / (1534 - o_slope * 10);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = mts;
+
+ switch (svsb->sw_id) {
+ case SVSB_CPU_LITTLE:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_CPU_BIG:
+ tb_roomt = x_roomt[4];
+ break;
+ case SVSB_CCI:
+ tb_roomt = x_roomt[3];
+ break;
+ case SVSB_GPU:
+ tb_roomt = x_roomt[1];
+ break;
+ default:
+ dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
+ goto remove_mt8183_svsb_mon_mode;
+ }
+
+ temp0 = (degc_cali * 10 / 2);
+ temp1 = ((10000 * 100000 / 4096 / gain) *
+ oe + tb_roomt * 10) * 15 / 18;
+
+ if (!o_slope_sign)
+ temp2 = temp1 * 100 / (1534 + o_slope * 10);
+ else
+ temp2 = temp1 * 100 / (1534 - o_slope * 10);
+
+ svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
+ }
+
+ return true;
+
+remove_mt8183_svsb_mon_mode:
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mode_support &= ~SVSB_MODE_MON;
+ }
+
return true;
}
@@ -1145,9 +1375,15 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
+ struct device *dev;
struct svs_bank *svsb;
u32 idx;
+ dev = svs_add_device_link(svsp, "thermal");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get thermal device\n");
+
for (idx = 0; idx < svsp->bank_max; idx++) {
svsb = &svsp->banks[idx];
@@ -1253,9 +1489,11 @@ static struct svs_bank svs_mt8183_banks[] = {
.set_freq_pct = svs_set_bank_freq_pct_v2,
.get_volts = svs_get_bank_volts_v2,
.buck_name = "mali",
+ .tzone_name = "tzts2",
.volt_flags = SVSB_INIT01_PD_REQ |
SVSB_INIT01_VOLT_INC_ONLY,
- .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+ .mode_support = SVSB_MODE_INIT01 | SVSB_MODE_INIT02 |
+ SVSB_MODE_MON,
.opp_count = MAX_OPP_ENTRIES,
.freq_base = 900000000,
.vboot = 0x30,
@@ -1271,6 +1509,10 @@ static struct svs_bank svs_mt8183_banks[] = {
.core_sel = 0x8fff0003,
.int_st = BIT(3),
.ctl0 = 0x00050001,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 3,
},
};
@@ -1395,6 +1637,8 @@ static int svs_probe(struct platform_device *pdev)
svs_probe_free_resource:
if (!IS_ERR_OR_NULL(svsp->efuse))
kfree(svsp->efuse);
+ if (!IS_ERR_OR_NULL(svsp->tefuse))
+ kfree(svsp->tefuse);
return ret;
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 5/7] soc: mediatek: SVS: add debug commands
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The purpose of SVS is to help find the suitable voltages
for DVFS. Therefore, if SVS bank voltages are concerned
to be wrong, we can show/disable SVS bank voltages by
this patch.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 275 +++++++++++++++++++++++++++++++++
1 file changed, 275 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 44ccad1e3327..aa0665725339 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -7,6 +7,7 @@
#include <linux/clk.h>
#include <linux/completion.h>
#include <linux/cpuidle.h>
+#include <linux/debugfs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -23,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/thermal.h>
@@ -69,6 +71,39 @@
static DEFINE_SPINLOCK(svs_lock);
+#define debug_fops_ro(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define debug_fops_rw(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .write = svs_##name##_debug_write, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define svs_dentry_data(name) {__stringify(name), &svs_##name##_debug_fops}
+
/**
* enum svsb_phase - svs bank phase enumeration
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
@@ -268,6 +303,7 @@ struct svs_platform_data {
* @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
+ * @reg_data: bank register data in different phase for debug purpose
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
@@ -326,6 +362,7 @@ struct svs_bank {
char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
+ u32 reg_data[SVSB_PHASE_MAX][SVS_REG_MAX];
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
@@ -467,6 +504,220 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
return ret;
}
+static int svs_dump_debug_show(struct seq_file *m, void *p)
+{
+ struct svs_platform *svsp = (struct svs_platform *)m->private;
+ struct svs_bank *svsb;
+ unsigned long svs_reg_addr;
+ u32 idx, i, j, bank_id;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse && svsp->efuse[i])
+ seq_printf(m, "M_HW_RES%d = 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse)
+ seq_printf(m, "THERMAL_EFUSE%d = 0x%08x\n",
+ i, svsp->tefuse[i]);
+
+ for (bank_id = 0, idx = 0; idx < svsp->bank_max; idx++, bank_id++) {
+ svsb = &svsp->banks[idx];
+
+ for (i = SVSB_PHASE_INIT01; i <= SVSB_PHASE_MON; i++) {
+ seq_printf(m, "Bank_number = %u\n", bank_id);
+
+ if (i == SVSB_PHASE_INIT01 || i == SVSB_PHASE_INIT02)
+ seq_printf(m, "mode = init%d\n", i);
+ else if (i == SVSB_PHASE_MON)
+ seq_puts(m, "mode = mon\n");
+ else
+ seq_puts(m, "mode = error\n");
+
+ for (j = DESCHAR; j < SVS_REG_MAX; j++) {
+ svs_reg_addr = (unsigned long)(svsp->base +
+ svsp->regs[j]);
+ seq_printf(m, "0x%08lx = 0x%08x\n",
+ svs_reg_addr, svsb->reg_data[i][j]);
+ }
+ }
+ }
+
+ return 0;
+}
+
+debug_fops_ro(dump);
+
+static int svs_enable_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ seq_puts(m, "disabled\n");
+ break;
+ case SVSB_PHASE_INIT01:
+ seq_puts(m, "init1\n");
+ break;
+ case SVSB_PHASE_INIT02:
+ seq_puts(m, "init2\n");
+ break;
+ case SVSB_PHASE_MON:
+ seq_puts(m, "mon mode\n");
+ break;
+ default:
+ seq_puts(m, "unknown\n");
+ break;
+ }
+
+ return 0;
+}
+
+static ssize_t svs_enable_debug_write(struct file *filp,
+ const char __user *buffer,
+ size_t count, loff_t *pos)
+{
+ struct svs_bank *svsb = file_inode(filp)->i_private;
+ struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
+ unsigned long flags;
+ int enabled, ret;
+ char *buf = NULL;
+
+ if (count >= PAGE_SIZE)
+ return -EINVAL;
+
+ buf = (char *)memdup_user_nul(buffer, count);
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+
+ ret = kstrtoint(buf, 10, &enabled);
+ if (ret)
+ return ret;
+
+ if (!enabled) {
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ kfree(buf);
+
+ return count;
+}
+
+debug_fops_rw(enable);
+
+static int svs_status_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+ struct dev_pm_opp *opp;
+ int tzone_temp = 0, ret;
+ u32 i;
+
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret)
+ seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ else
+ seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i], true);
+ if (IS_ERR(opp)) {
+ seq_printf(m, "%s: cannot find freq = %u (%ld)\n",
+ svsb->name, svsb->opp_dfreq[i],
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ seq_printf(m, "opp_freq[%02u]: %u, opp_volt[%02u]: %lu, ",
+ i, svsb->opp_dfreq[i], i,
+ dev_pm_opp_get_voltage(opp));
+ seq_printf(m, "svsb_volt[%02u]: 0x%x, freq_pct[%02u]: %u\n",
+ i, svsb->volt[i], i, svsb->freq_pct[i]);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
+debug_fops_ro(status);
+
+static int svs_create_debug_cmds(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dentry *svs_dir, *svsb_dir, *file_entry;
+ const char *d = "/sys/kernel/debug/svs";
+ u32 i, idx;
+
+ struct svs_dentry {
+ const char *name;
+ const struct file_operations *fops;
+ };
+
+ struct svs_dentry svs_entries[] = {
+ svs_dentry_data(dump),
+ };
+
+ struct svs_dentry svsb_entries[] = {
+ svs_dentry_data(enable),
+ svs_dentry_data(status),
+ };
+
+ svs_dir = debugfs_create_dir("svs", NULL);
+ if (IS_ERR(svs_dir)) {
+ dev_err(svsp->dev, "cannot create %s: %ld\n",
+ d, PTR_ERR(svs_dir));
+ return PTR_ERR(svs_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svs_entries); i++) {
+ file_entry = debugfs_create_file(svs_entries[i].name, 0664,
+ svs_dir, svsp,
+ svs_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svs_entries[i].name, PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->mode_support == SVSB_MODE_ALL_DISABLE)
+ continue;
+
+ svsb_dir = debugfs_create_dir(svsb->name, svs_dir);
+ if (IS_ERR(svsb_dir)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svsb->name, PTR_ERR(svsb_dir));
+ return PTR_ERR(svsb_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svsb_entries); i++) {
+ file_entry = debugfs_create_file(svsb_entries[i].name,
+ 0664, svsb_dir, svsb,
+ svsb_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "no %s/%s/%s?: %ld\n",
+ d, svsb->name, svsb_entries[i].name,
+ PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+ }
+
+ return 0;
+}
+
static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
{
u32 vx;
@@ -591,6 +842,16 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
}
}
+static inline void svs_save_bank_register_data(struct svs_platform *svsp,
+ enum svsb_phase phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ enum svs_reg_index rg_i;
+
+ for (rg_i = DESCHAR; rg_i < SVS_REG_MAX; rg_i++)
+ svsb->reg_data[phase][rg_i] = svs_readl_relaxed(svsp, rg_i);
+}
+
static inline void svs_error_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -605,6 +866,8 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, SMSTATE1));
dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_ERROR);
+
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
@@ -619,6 +882,8 @@ static inline void svs_init01_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VDESIGN30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT01);
+
svsb->phase = SVSB_PHASE_INIT01;
svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
GENMASK(15, 0)) + 1;
@@ -644,6 +909,8 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VOP30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT02);
+
svsb->phase = SVSB_PHASE_INIT02;
svsb->get_volts(svsp);
@@ -655,6 +922,8 @@ static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
+ svs_save_bank_register_data(svsp, SVSB_PHASE_MON);
+
svsb->phase = SVSB_PHASE_MON;
svsb->get_volts(svsp);
@@ -1626,6 +1895,12 @@ static int svs_probe(struct platform_device *pdev)
goto svs_probe_iounmap;
}
+ ret = svs_create_debug_cmds(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
return 0;
svs_probe_iounmap:
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 5/7] soc: mediatek: SVS: add debug commands
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The purpose of SVS is to help find the suitable voltages
for DVFS. Therefore, if SVS bank voltages are concerned
to be wrong, we can show/disable SVS bank voltages by
this patch.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 275 +++++++++++++++++++++++++++++++++
1 file changed, 275 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 44ccad1e3327..aa0665725339 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -7,6 +7,7 @@
#include <linux/clk.h>
#include <linux/completion.h>
#include <linux/cpuidle.h>
+#include <linux/debugfs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -23,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/thermal.h>
@@ -69,6 +71,39 @@
static DEFINE_SPINLOCK(svs_lock);
+#define debug_fops_ro(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define debug_fops_rw(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .write = svs_##name##_debug_write, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define svs_dentry_data(name) {__stringify(name), &svs_##name##_debug_fops}
+
/**
* enum svsb_phase - svs bank phase enumeration
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
@@ -268,6 +303,7 @@ struct svs_platform_data {
* @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
+ * @reg_data: bank register data in different phase for debug purpose
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
@@ -326,6 +362,7 @@ struct svs_bank {
char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
+ u32 reg_data[SVSB_PHASE_MAX][SVS_REG_MAX];
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
@@ -467,6 +504,220 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
return ret;
}
+static int svs_dump_debug_show(struct seq_file *m, void *p)
+{
+ struct svs_platform *svsp = (struct svs_platform *)m->private;
+ struct svs_bank *svsb;
+ unsigned long svs_reg_addr;
+ u32 idx, i, j, bank_id;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse && svsp->efuse[i])
+ seq_printf(m, "M_HW_RES%d = 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse)
+ seq_printf(m, "THERMAL_EFUSE%d = 0x%08x\n",
+ i, svsp->tefuse[i]);
+
+ for (bank_id = 0, idx = 0; idx < svsp->bank_max; idx++, bank_id++) {
+ svsb = &svsp->banks[idx];
+
+ for (i = SVSB_PHASE_INIT01; i <= SVSB_PHASE_MON; i++) {
+ seq_printf(m, "Bank_number = %u\n", bank_id);
+
+ if (i == SVSB_PHASE_INIT01 || i == SVSB_PHASE_INIT02)
+ seq_printf(m, "mode = init%d\n", i);
+ else if (i == SVSB_PHASE_MON)
+ seq_puts(m, "mode = mon\n");
+ else
+ seq_puts(m, "mode = error\n");
+
+ for (j = DESCHAR; j < SVS_REG_MAX; j++) {
+ svs_reg_addr = (unsigned long)(svsp->base +
+ svsp->regs[j]);
+ seq_printf(m, "0x%08lx = 0x%08x\n",
+ svs_reg_addr, svsb->reg_data[i][j]);
+ }
+ }
+ }
+
+ return 0;
+}
+
+debug_fops_ro(dump);
+
+static int svs_enable_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ seq_puts(m, "disabled\n");
+ break;
+ case SVSB_PHASE_INIT01:
+ seq_puts(m, "init1\n");
+ break;
+ case SVSB_PHASE_INIT02:
+ seq_puts(m, "init2\n");
+ break;
+ case SVSB_PHASE_MON:
+ seq_puts(m, "mon mode\n");
+ break;
+ default:
+ seq_puts(m, "unknown\n");
+ break;
+ }
+
+ return 0;
+}
+
+static ssize_t svs_enable_debug_write(struct file *filp,
+ const char __user *buffer,
+ size_t count, loff_t *pos)
+{
+ struct svs_bank *svsb = file_inode(filp)->i_private;
+ struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
+ unsigned long flags;
+ int enabled, ret;
+ char *buf = NULL;
+
+ if (count >= PAGE_SIZE)
+ return -EINVAL;
+
+ buf = (char *)memdup_user_nul(buffer, count);
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+
+ ret = kstrtoint(buf, 10, &enabled);
+ if (ret)
+ return ret;
+
+ if (!enabled) {
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ kfree(buf);
+
+ return count;
+}
+
+debug_fops_rw(enable);
+
+static int svs_status_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+ struct dev_pm_opp *opp;
+ int tzone_temp = 0, ret;
+ u32 i;
+
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret)
+ seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ else
+ seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i], true);
+ if (IS_ERR(opp)) {
+ seq_printf(m, "%s: cannot find freq = %u (%ld)\n",
+ svsb->name, svsb->opp_dfreq[i],
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ seq_printf(m, "opp_freq[%02u]: %u, opp_volt[%02u]: %lu, ",
+ i, svsb->opp_dfreq[i], i,
+ dev_pm_opp_get_voltage(opp));
+ seq_printf(m, "svsb_volt[%02u]: 0x%x, freq_pct[%02u]: %u\n",
+ i, svsb->volt[i], i, svsb->freq_pct[i]);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
+debug_fops_ro(status);
+
+static int svs_create_debug_cmds(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dentry *svs_dir, *svsb_dir, *file_entry;
+ const char *d = "/sys/kernel/debug/svs";
+ u32 i, idx;
+
+ struct svs_dentry {
+ const char *name;
+ const struct file_operations *fops;
+ };
+
+ struct svs_dentry svs_entries[] = {
+ svs_dentry_data(dump),
+ };
+
+ struct svs_dentry svsb_entries[] = {
+ svs_dentry_data(enable),
+ svs_dentry_data(status),
+ };
+
+ svs_dir = debugfs_create_dir("svs", NULL);
+ if (IS_ERR(svs_dir)) {
+ dev_err(svsp->dev, "cannot create %s: %ld\n",
+ d, PTR_ERR(svs_dir));
+ return PTR_ERR(svs_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svs_entries); i++) {
+ file_entry = debugfs_create_file(svs_entries[i].name, 0664,
+ svs_dir, svsp,
+ svs_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svs_entries[i].name, PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->mode_support == SVSB_MODE_ALL_DISABLE)
+ continue;
+
+ svsb_dir = debugfs_create_dir(svsb->name, svs_dir);
+ if (IS_ERR(svsb_dir)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svsb->name, PTR_ERR(svsb_dir));
+ return PTR_ERR(svsb_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svsb_entries); i++) {
+ file_entry = debugfs_create_file(svsb_entries[i].name,
+ 0664, svsb_dir, svsb,
+ svsb_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "no %s/%s/%s?: %ld\n",
+ d, svsb->name, svsb_entries[i].name,
+ PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+ }
+
+ return 0;
+}
+
static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
{
u32 vx;
@@ -591,6 +842,16 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
}
}
+static inline void svs_save_bank_register_data(struct svs_platform *svsp,
+ enum svsb_phase phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ enum svs_reg_index rg_i;
+
+ for (rg_i = DESCHAR; rg_i < SVS_REG_MAX; rg_i++)
+ svsb->reg_data[phase][rg_i] = svs_readl_relaxed(svsp, rg_i);
+}
+
static inline void svs_error_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -605,6 +866,8 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, SMSTATE1));
dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_ERROR);
+
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
@@ -619,6 +882,8 @@ static inline void svs_init01_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VDESIGN30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT01);
+
svsb->phase = SVSB_PHASE_INIT01;
svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
GENMASK(15, 0)) + 1;
@@ -644,6 +909,8 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VOP30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT02);
+
svsb->phase = SVSB_PHASE_INIT02;
svsb->get_volts(svsp);
@@ -655,6 +922,8 @@ static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
+ svs_save_bank_register_data(svsp, SVSB_PHASE_MON);
+
svsb->phase = SVSB_PHASE_MON;
svsb->get_volts(svsp);
@@ -1626,6 +1895,12 @@ static int svs_probe(struct platform_device *pdev)
goto svs_probe_iounmap;
}
+ ret = svs_create_debug_cmds(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
return 0;
svs_probe_iounmap:
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 5/7] soc: mediatek: SVS: add debug commands
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
The purpose of SVS is to help find the suitable voltages
for DVFS. Therefore, if SVS bank voltages are concerned
to be wrong, we can show/disable SVS bank voltages by
this patch.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 275 +++++++++++++++++++++++++++++++++
1 file changed, 275 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 44ccad1e3327..aa0665725339 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -7,6 +7,7 @@
#include <linux/clk.h>
#include <linux/completion.h>
#include <linux/cpuidle.h>
+#include <linux/debugfs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -23,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/thermal.h>
@@ -69,6 +71,39 @@
static DEFINE_SPINLOCK(svs_lock);
+#define debug_fops_ro(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define debug_fops_rw(name) \
+ static int svs_##name##_debug_open(struct inode *inode, \
+ struct file *filp) \
+ { \
+ return single_open(filp, svs_##name##_debug_show, \
+ inode->i_private); \
+ } \
+ static const struct file_operations svs_##name##_debug_fops = { \
+ .owner = THIS_MODULE, \
+ .open = svs_##name##_debug_open, \
+ .read = seq_read, \
+ .write = svs_##name##_debug_write, \
+ .llseek = seq_lseek, \
+ .release = single_release, \
+ }
+
+#define svs_dentry_data(name) {__stringify(name), &svs_##name##_debug_fops}
+
/**
* enum svsb_phase - svs bank phase enumeration
* @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
@@ -268,6 +303,7 @@ struct svs_platform_data {
* @tzone_name: thermal zone name
* @phase: bank current phase
* @volt_od: bank voltage overdrive
+ * @reg_data: bank register data in different phase for debug purpose
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
@@ -326,6 +362,7 @@ struct svs_bank {
char *tzone_name;
enum svsb_phase phase;
s32 volt_od;
+ u32 reg_data[SVSB_PHASE_MAX][SVS_REG_MAX];
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
@@ -467,6 +504,220 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
return ret;
}
+static int svs_dump_debug_show(struct seq_file *m, void *p)
+{
+ struct svs_platform *svsp = (struct svs_platform *)m->private;
+ struct svs_bank *svsb;
+ unsigned long svs_reg_addr;
+ u32 idx, i, j, bank_id;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse && svsp->efuse[i])
+ seq_printf(m, "M_HW_RES%d = 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse)
+ seq_printf(m, "THERMAL_EFUSE%d = 0x%08x\n",
+ i, svsp->tefuse[i]);
+
+ for (bank_id = 0, idx = 0; idx < svsp->bank_max; idx++, bank_id++) {
+ svsb = &svsp->banks[idx];
+
+ for (i = SVSB_PHASE_INIT01; i <= SVSB_PHASE_MON; i++) {
+ seq_printf(m, "Bank_number = %u\n", bank_id);
+
+ if (i == SVSB_PHASE_INIT01 || i == SVSB_PHASE_INIT02)
+ seq_printf(m, "mode = init%d\n", i);
+ else if (i == SVSB_PHASE_MON)
+ seq_puts(m, "mode = mon\n");
+ else
+ seq_puts(m, "mode = error\n");
+
+ for (j = DESCHAR; j < SVS_REG_MAX; j++) {
+ svs_reg_addr = (unsigned long)(svsp->base +
+ svsp->regs[j]);
+ seq_printf(m, "0x%08lx = 0x%08x\n",
+ svs_reg_addr, svsb->reg_data[i][j]);
+ }
+ }
+ }
+
+ return 0;
+}
+
+debug_fops_ro(dump);
+
+static int svs_enable_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+ switch (svsb->phase) {
+ case SVSB_PHASE_ERROR:
+ seq_puts(m, "disabled\n");
+ break;
+ case SVSB_PHASE_INIT01:
+ seq_puts(m, "init1\n");
+ break;
+ case SVSB_PHASE_INIT02:
+ seq_puts(m, "init2\n");
+ break;
+ case SVSB_PHASE_MON:
+ seq_puts(m, "mon mode\n");
+ break;
+ default:
+ seq_puts(m, "unknown\n");
+ break;
+ }
+
+ return 0;
+}
+
+static ssize_t svs_enable_debug_write(struct file *filp,
+ const char __user *buffer,
+ size_t count, loff_t *pos)
+{
+ struct svs_bank *svsb = file_inode(filp)->i_private;
+ struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
+ unsigned long flags;
+ int enabled, ret;
+ char *buf = NULL;
+
+ if (count >= PAGE_SIZE)
+ return -EINVAL;
+
+ buf = (char *)memdup_user_nul(buffer, count);
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+
+ ret = kstrtoint(buf, 10, &enabled);
+ if (ret)
+ return ret;
+
+ if (!enabled) {
+ spin_lock_irqsave(&svs_lock, flags);
+ svsp->pbank = svsb;
+ svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+ svs_switch_bank(svsp);
+ svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
+ svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+ spin_unlock_irqrestore(&svs_lock, flags);
+
+ svsb->phase = SVSB_PHASE_ERROR;
+ svs_adjust_pm_opp_volts(svsb);
+ }
+
+ kfree(buf);
+
+ return count;
+}
+
+debug_fops_rw(enable);
+
+static int svs_status_debug_show(struct seq_file *m, void *v)
+{
+ struct svs_bank *svsb = (struct svs_bank *)m->private;
+ struct dev_pm_opp *opp;
+ int tzone_temp = 0, ret;
+ u32 i;
+
+ ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
+ if (ret)
+ seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ else
+ seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i], true);
+ if (IS_ERR(opp)) {
+ seq_printf(m, "%s: cannot find freq = %u (%ld)\n",
+ svsb->name, svsb->opp_dfreq[i],
+ PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ seq_printf(m, "opp_freq[%02u]: %u, opp_volt[%02u]: %lu, ",
+ i, svsb->opp_dfreq[i], i,
+ dev_pm_opp_get_voltage(opp));
+ seq_printf(m, "svsb_volt[%02u]: 0x%x, freq_pct[%02u]: %u\n",
+ i, svsb->volt[i], i, svsb->freq_pct[i]);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
+debug_fops_ro(status);
+
+static int svs_create_debug_cmds(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct dentry *svs_dir, *svsb_dir, *file_entry;
+ const char *d = "/sys/kernel/debug/svs";
+ u32 i, idx;
+
+ struct svs_dentry {
+ const char *name;
+ const struct file_operations *fops;
+ };
+
+ struct svs_dentry svs_entries[] = {
+ svs_dentry_data(dump),
+ };
+
+ struct svs_dentry svsb_entries[] = {
+ svs_dentry_data(enable),
+ svs_dentry_data(status),
+ };
+
+ svs_dir = debugfs_create_dir("svs", NULL);
+ if (IS_ERR(svs_dir)) {
+ dev_err(svsp->dev, "cannot create %s: %ld\n",
+ d, PTR_ERR(svs_dir));
+ return PTR_ERR(svs_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svs_entries); i++) {
+ file_entry = debugfs_create_file(svs_entries[i].name, 0664,
+ svs_dir, svsp,
+ svs_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svs_entries[i].name, PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->mode_support == SVSB_MODE_ALL_DISABLE)
+ continue;
+
+ svsb_dir = debugfs_create_dir(svsb->name, svs_dir);
+ if (IS_ERR(svsb_dir)) {
+ dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+ d, svsb->name, PTR_ERR(svsb_dir));
+ return PTR_ERR(svsb_dir);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(svsb_entries); i++) {
+ file_entry = debugfs_create_file(svsb_entries[i].name,
+ 0664, svsb_dir, svsb,
+ svsb_entries[i].fops);
+ if (IS_ERR(file_entry)) {
+ dev_err(svsp->dev, "no %s/%s/%s?: %ld\n",
+ d, svsb->name, svsb_entries[i].name,
+ PTR_ERR(file_entry));
+ return PTR_ERR(file_entry);
+ }
+ }
+ }
+
+ return 0;
+}
+
static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
{
u32 vx;
@@ -591,6 +842,16 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
}
}
+static inline void svs_save_bank_register_data(struct svs_platform *svsp,
+ enum svsb_phase phase)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ enum svs_reg_index rg_i;
+
+ for (rg_i = DESCHAR; rg_i < SVS_REG_MAX; rg_i++)
+ svsb->reg_data[phase][rg_i] = svs_readl_relaxed(svsp, rg_i);
+}
+
static inline void svs_error_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -605,6 +866,8 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, SMSTATE1));
dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl_relaxed(svsp, TEMP));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_ERROR);
+
svsb->phase = SVSB_PHASE_ERROR;
svs_writel_relaxed(svsp, SVSB_EN_OFF, SVSEN);
svs_writel_relaxed(svsp, SVSB_INTSTS_CLEAN, INTSTS);
@@ -619,6 +882,8 @@ static inline void svs_init01_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VDESIGN30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT01);
+
svsb->phase = SVSB_PHASE_INIT01;
svsb->dc_voffset_in = ~(svs_readl_relaxed(svsp, DCVALUES) &
GENMASK(15, 0)) + 1;
@@ -644,6 +909,8 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
svs_readl_relaxed(svsp, VOP30),
svs_readl_relaxed(svsp, DCVALUES));
+ svs_save_bank_register_data(svsp, SVSB_PHASE_INIT02);
+
svsb->phase = SVSB_PHASE_INIT02;
svsb->get_volts(svsp);
@@ -655,6 +922,8 @@ static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
+ svs_save_bank_register_data(svsp, SVSB_PHASE_MON);
+
svsb->phase = SVSB_PHASE_MON;
svsb->get_volts(svsp);
@@ -1626,6 +1895,12 @@ static int svs_probe(struct platform_device *pdev)
goto svs_probe_iounmap;
}
+ ret = svs_create_debug_cmds(svsp);
+ if (ret) {
+ dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
+ goto svs_probe_iounmap;
+ }
+
return 0;
svs_probe_iounmap:
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add mt8192 svs compatible/resets in dt-bindings.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/soc/mediatek/mtk-svs.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index 1e51e5f562d9..d911fa2d40ef 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -22,6 +22,7 @@ properties:
compatible:
enum:
- mediatek,mt8183-svs
+ - mediatek,mt8192-svs
reg:
maxItems: 1
@@ -50,6 +51,13 @@ properties:
- const: svs-calibration-data
- const: t-calibration-data
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: svs_rst
+
required:
- compatible
- reg
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add mt8192 svs compatible/resets in dt-bindings.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/soc/mediatek/mtk-svs.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index 1e51e5f562d9..d911fa2d40ef 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -22,6 +22,7 @@ properties:
compatible:
enum:
- mediatek,mt8183-svs
+ - mediatek,mt8192-svs
reg:
maxItems: 1
@@ -50,6 +51,13 @@ properties:
- const: svs-calibration-data
- const: t-calibration-data
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: svs_rst
+
required:
- compatible
- reg
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Add mt8192 svs compatible/resets in dt-bindings.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/soc/mediatek/mtk-svs.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index 1e51e5f562d9..d911fa2d40ef 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -22,6 +22,7 @@ properties:
compatible:
enum:
- mediatek,mt8183-svs
+ - mediatek,mt8192-svs
reg:
maxItems: 1
@@ -50,6 +51,13 @@ properties:
- const: svs-calibration-data
- const: t-calibration-data
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: svs_rst
+
required:
- compatible
- reg
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-16 0:43 ` Roger Lu
-1 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
mt8192 SVS GPU uses 2-line (high/low bank) HW architecture to provide
bank voltages. High bank helps update higher frequency's voltage
and low bank helps update lower frequency's voltage.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 473 ++++++++++++++++++++++++++++++++-
1 file changed, 468 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index aa0665725339..606a00a2e57d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -24,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -35,6 +36,10 @@
#define SVSB_CCI BIT(2)
#define SVSB_GPU BIT(3)
+/* svs bank 2-line type */
+#define SVSB_LOW BIT(8)
+#define SVSB_HIGH BIT(9)
+
/* svs bank mode support */
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
@@ -45,6 +50,8 @@
#define SVSB_INIT01_PD_REQ BIT(0)
#define SVSB_INIT01_VOLT_IGNORE BIT(1)
#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+#define SVSB_MON_VOLT_IGNORE BIT(16)
+#define SVSB_REMOVE_DVTFIXED_VOLT BIT(24)
/* svs bank register common configuration */
#define SVSB_DET_MAX 0xffff
@@ -63,7 +70,9 @@
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
+#define BITS8 8
#define MAX_OPP_ENTRIES 16
+#define REG_BYTES 4
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
#define SVSB_TEMP_LOWER_BOUND 0xb2
@@ -250,6 +259,7 @@ static const u32 svs_regs_v2[] = {
* @main_clk: main clock for svs bank
* @pbank: svs bank pointer needing to be protected by spin_lock section
* @banks: svs banks that svs platform supports
+ * @rst: svs platform reset control
* @efuse_parsing: svs platform efuse parsing function pointer
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
@@ -267,6 +277,7 @@ struct svs_platform {
struct clk *main_clk;
struct svs_bank *pbank;
struct svs_bank *banks;
+ struct reset_control *rst;
bool (*efuse_parsing)(struct svs_platform *svsp);
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
@@ -307,6 +318,7 @@ struct svs_platform_data {
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
+ * @turn_freq_base: refenrece frequency for 2-line turn point
* @vboot: voltage request for bank init01 only
* @opp_dfreq: default opp frequency table
* @opp_dvolt: default opp voltage table
@@ -342,6 +354,8 @@ struct svs_platform_data {
* @mtdes: svs efuse data
* @dcbdet: svs efuse data
* @dcmdet: svs efuse data
+ * @turn_pt: 2-line turn point tells which opp_volt calculated by high/low bank
+ * @type: bank type to represent it is 2-line (high/low) bank or 1-line bank
*
* Svs bank will generate suitalbe voltages by below general math equation
* and provide these voltages to opp voltage table.
@@ -366,6 +380,7 @@ struct svs_bank {
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
+ u32 turn_freq_base;
u32 vboot;
u32 opp_dfreq[MAX_OPP_ENTRIES];
u32 opp_dvolt[MAX_OPP_ENTRIES];
@@ -401,6 +416,8 @@ struct svs_bank {
u32 mtdes;
u32 dcbdet;
u32 dcmdet;
+ u32 turn_pt;
+ u32 type;
};
static u32 percent(u32 numerator, u32 denominator)
@@ -436,13 +453,59 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
return (svsb_volt * svsb_volt_step) + svsb_volt_base;
}
+static u32 svs_opp_volt_to_bank_volt(u32 opp_u_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (opp_u_volt - svsb_volt_base) / svsb_volt_step;
+}
+
+static int svs_sync_bank_volts_from_opp(struct svs_bank *svsb)
+{
+ struct dev_pm_opp *opp;
+ u32 i, opp_u_volt;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ true);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %u (%ld)\n",
+ svsb->opp_dfreq[i], PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ opp_u_volt = dev_pm_opp_get_voltage(opp);
+ svsb->volt[i] = svs_opp_volt_to_bank_volt(opp_u_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
int ret = -EPERM, tzone_temp = 0;
- u32 i, svsb_volt, opp_volt, temp_voffset = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0, opp_start, opp_stop;
mutex_lock(&svsb->lock);
+ /*
+ * 2-line bank updates its corresponding opp volts.
+ * 1-line bank updates all opp volts.
+ */
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ } else {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
+
/* Get thermal effect */
if (svsb->phase == SVSB_PHASE_MON) {
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
@@ -457,10 +520,16 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
temp_voffset += svsb->tzone_htemp_voffset;
else if (tzone_temp <= svsb->tzone_ltemp)
temp_voffset += svsb->tzone_ltemp_voffset;
+
+ /* 2-line bank update all opp volts when running mon mode */
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
}
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
- for (i = 0; i < svsb->opp_count; i++) {
+ for (i = opp_start; i < opp_stop; i++) {
switch (svsb->phase) {
case SVSB_PHASE_ERROR:
opp_volt = svsb->opp_dvolt[i];
@@ -623,9 +692,11 @@ static int svs_status_debug_show(struct seq_file *m, void *v)
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
if (ret)
- seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ seq_printf(m, "%s: temperature ignore, turn_pt = %u\n",
+ svsb->name, svsb->turn_pt);
else
- seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+ seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
+ svsb->name, tzone_temp, svsb->turn_pt);
for (i = 0; i < svsb->opp_count; i++) {
opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
@@ -731,6 +802,181 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
return DIV_ROUND_UP(vx, 100);
}
+static void svs_get_bank_volts_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *vop, vop74, vop30, turn_pt = svsb->turn_pt;
+ u32 b_sft, shift_byte = 0, opp_start = 0, opp_stop = 0;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ if (svsb->phase == SVSB_PHASE_MON &&
+ svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
+ return;
+
+ vop74 = svs_readl_relaxed(svsp, VOP74);
+ vop30 = svs_readl_relaxed(svsp, VOP30);
+
+ /* Target is to set svsb->volt[] by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] ~ volt[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] + volt[j] ~ volt[opp_count - 1] */
+ j = svsb->opp_count - 7;
+ svsb->volt[turn_pt] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[turn_pt + 1] ~ volt[j - 1] by interpolate */
+ for (i = turn_pt + 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[turn_pt],
+ svsb->freq_pct[j],
+ svsb->volt[turn_pt],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] + volt[j] ~ volt[turn_pt - 1] */
+ j = turn_pt - 7;
+ svsb->volt[0] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[1] ~ volt[j - 1] by interpolate */
+ for (i = 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[0],
+ svsb->freq_pct[j],
+ svsb->volt[0],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] ~ volt[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ }
+ }
+
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ }
+
+ for (i = opp_start; i < opp_stop; i++)
+ if (svsb->volt_flags & SVSB_REMOVE_DVTFIXED_VOLT)
+ svsb->volt[i] -= svsb->dvt_fixed;
+}
+
+static void svs_set_bank_freq_pct_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *freq_pct, freq_pct74 = 0, freq_pct30 = 0;
+ u32 b_sft, shift_byte = 0, turn_pt;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ if (svsb->opp_dfreq[i] <= svsb->turn_freq_base) {
+ svsb->turn_pt = i;
+ break;
+ }
+ }
+
+ turn_pt = svsb->turn_pt;
+
+ /* Target is to fill out freq_pct74 / freq_pct30 by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * If we don't handle this situation,
+ * SVSB_HIGH's FREQPCT74 / FREQPCT30 would keep "0"
+ * and this leads SVSB_LOW to work abnormally.
+ */
+ if (turn_pt == 0)
+ freq_pct30 = svsb->freq_pct[0];
+
+ /* freq_pct[0] ~ freq_pct[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /*
+ * freq_pct[turn_pt] +
+ * freq_pct[opp_count - 7] ~ freq_pct[opp_count -1]
+ */
+ freq_pct30 = svsb->freq_pct[turn_pt];
+ shift_byte++;
+ j = svsb->opp_count - 7;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * freq_pct[0] +
+ * freq_pct[turn_pt - 7] ~ freq_pct[turn_pt - 1]
+ */
+ freq_pct30 = svsb->freq_pct[0];
+ shift_byte++;
+ j = turn_pt - 7;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* freq_pct[turn_pt] ~ freq_pct[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ }
+
+ svs_writel_relaxed(svsp, freq_pct74, FREQPCT74);
+ svs_writel_relaxed(svsp, freq_pct30, FREQPCT30);
+}
+
static void svs_get_bank_volts_v2(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -1174,6 +1420,25 @@ static int svs_init02(struct svs_platform *svsp)
}
}
+ /*
+ * 2-line high/low bank update its corresponding opp voltages only.
+ * Therefore, we sync voltages from opp for high/low bank voltages
+ * consistency.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ if (svs_sync_bank_volts_from_opp(svsb)) {
+ dev_err(svsb->dev, "sync volt fail\n");
+ return -EPERM;
+ }
+ }
+ }
+
return 0;
}
@@ -1218,6 +1483,7 @@ static int svs_suspend(struct device *dev)
struct svs_platform *svsp = dev_get_drvdata(dev);
struct svs_bank *svsb;
unsigned long flags;
+ int ret;
u32 idx;
for (idx = 0; idx < svsp->bank_max; idx++) {
@@ -1235,6 +1501,12 @@ static int svs_suspend(struct device *dev)
svs_adjust_pm_opp_volts(svsb);
}
+ ret = reset_control_assert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot assert reset %d\n", ret);
+ return ret;
+ }
+
clk_disable_unprepare(svsp->main_clk);
return 0;
@@ -1251,6 +1523,12 @@ static int svs_resume(struct device *dev)
return ret;
}
+ ret = reset_control_deassert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot deassert reset %d\n", ret);
+ return ret;
+ }
+
ret = svs_init02(svsp);
if (ret)
return ret;
@@ -1284,7 +1562,12 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
svsb->name = "SVSB_CCI";
break;
case SVSB_GPU:
- svsb->name = "SVSB_GPU";
+ if (svsb->type == SVSB_HIGH)
+ svsb->name = "SVSB_GPU_HIGH";
+ else if (svsb->type == SVSB_LOW)
+ svsb->name = "SVSB_GPU_LOW";
+ else
+ svsb->name = "SVSB_GPU";
break;
default:
dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
@@ -1357,6 +1640,85 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
return 0;
}
+static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct nvmem_cell *cell;
+ u32 idx, i, vmin, golden_temp;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[9]) {
+ dev_notice(svsp->dev, "svs_efuse[9] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ vmin = (svsp->efuse[19] >> 4) & GENMASK(1, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (vmin == 0x1)
+ svsb->vmin = 0x1e;
+
+ if (svsb->type == SVSB_LOW) {
+ svsb->mtdes = svsp->efuse[10] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[10] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[10] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17]) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 8) & GENMASK(7, 0);
+ } else if (svsb->type == SVSB_HIGH) {
+ svsb->mtdes = svsp->efuse[9] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[9] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[9] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 24) & GENMASK(7, 0);
+ }
+
+ svsb->vmax += svsb->dvt_fixed;
+ }
+
+ /* Thermal efuse parsing */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR_OR_NULL(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse[i] != 0)
+ break;
+
+ if (i == svsp->tefuse_max)
+ golden_temp = 50; /* All thermal efuse data are 0 */
+ else
+ golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = 500;
+ svsb->bts = (((500 * golden_temp + 250460) / 1000) - 25) * 4;
+ }
+
+ return true;
+}
+
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
@@ -1642,6 +2004,39 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
return dev;
}
+static int svs_mt8192_platform_probe(struct svs_platform *svsp)
+{
+ struct device *dev;
+ struct svs_bank *svsb;
+ u32 idx;
+
+ svsp->rst = devm_reset_control_get_optional(svsp->dev, "svs_rst");
+ if (IS_ERR(svsp->rst))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsp->rst),
+ "cannot get svs reset control\n");
+
+ dev = svs_add_device_link(svsp, "lvts");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get lvts device\n");
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->type == SVSB_HIGH)
+ svsb->opp_dev = svs_add_device_link(svsp, "mali");
+ else if (svsb->type == SVSB_LOW)
+ svsb->opp_dev = svs_get_subsys_device(svsp, "mali");
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
struct device *dev;
@@ -1681,6 +2076,61 @@ static int svs_mt8183_platform_probe(struct svs_platform *svsp)
return 0;
}
+static struct svs_bank svs_mt8192_banks[] = {
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_LOW,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT,
+ .mode_support = SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 688000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x1,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0100,
+ .int_st = BIT(0),
+ .ctl0 = 0x00540003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_HIGH,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .tzone_name = "gpu1",
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT |
+ SVSB_MON_VOLT_IGNORE,
+ .mode_support = SVSB_MODE_INIT02 | SVSB_MODE_MON,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 902000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x6,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0101,
+ .int_st = BIT(1),
+ .ctl0 = 0x00540003,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 7,
+ },
+};
+
static struct svs_bank svs_mt8183_banks[] = {
{
.sw_id = SVSB_CPU_LITTLE,
@@ -1785,6 +2235,16 @@ static struct svs_bank svs_mt8183_banks[] = {
},
};
+static const struct svs_platform_data svs_mt8192_platform_data = {
+ .name = "mt8192-svs",
+ .banks = svs_mt8192_banks,
+ .efuse_parsing = svs_mt8192_efuse_parsing,
+ .probe = svs_mt8192_platform_probe,
+ .irqflags = IRQF_TRIGGER_HIGH,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8192_banks),
+};
+
static const struct svs_platform_data svs_mt8183_platform_data = {
.name = "mt8183-svs",
.banks = svs_mt8183_banks,
@@ -1797,6 +2257,9 @@ static const struct svs_platform_data svs_mt8183_platform_data = {
static const struct of_device_id svs_of_match[] = {
{
+ .compatible = "mediatek,mt8192-svs",
+ .data = &svs_mt8192_platform_data,
+ }, {
.compatible = "mediatek,mt8183-svs",
.data = &svs_mt8183_platform_data,
}, {
--
2.18.0
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
mt8192 SVS GPU uses 2-line (high/low bank) HW architecture to provide
bank voltages. High bank helps update higher frequency's voltage
and low bank helps update lower frequency's voltage.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 473 ++++++++++++++++++++++++++++++++-
1 file changed, 468 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index aa0665725339..606a00a2e57d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -24,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -35,6 +36,10 @@
#define SVSB_CCI BIT(2)
#define SVSB_GPU BIT(3)
+/* svs bank 2-line type */
+#define SVSB_LOW BIT(8)
+#define SVSB_HIGH BIT(9)
+
/* svs bank mode support */
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
@@ -45,6 +50,8 @@
#define SVSB_INIT01_PD_REQ BIT(0)
#define SVSB_INIT01_VOLT_IGNORE BIT(1)
#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+#define SVSB_MON_VOLT_IGNORE BIT(16)
+#define SVSB_REMOVE_DVTFIXED_VOLT BIT(24)
/* svs bank register common configuration */
#define SVSB_DET_MAX 0xffff
@@ -63,7 +70,9 @@
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
+#define BITS8 8
#define MAX_OPP_ENTRIES 16
+#define REG_BYTES 4
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
#define SVSB_TEMP_LOWER_BOUND 0xb2
@@ -250,6 +259,7 @@ static const u32 svs_regs_v2[] = {
* @main_clk: main clock for svs bank
* @pbank: svs bank pointer needing to be protected by spin_lock section
* @banks: svs banks that svs platform supports
+ * @rst: svs platform reset control
* @efuse_parsing: svs platform efuse parsing function pointer
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
@@ -267,6 +277,7 @@ struct svs_platform {
struct clk *main_clk;
struct svs_bank *pbank;
struct svs_bank *banks;
+ struct reset_control *rst;
bool (*efuse_parsing)(struct svs_platform *svsp);
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
@@ -307,6 +318,7 @@ struct svs_platform_data {
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
+ * @turn_freq_base: refenrece frequency for 2-line turn point
* @vboot: voltage request for bank init01 only
* @opp_dfreq: default opp frequency table
* @opp_dvolt: default opp voltage table
@@ -342,6 +354,8 @@ struct svs_platform_data {
* @mtdes: svs efuse data
* @dcbdet: svs efuse data
* @dcmdet: svs efuse data
+ * @turn_pt: 2-line turn point tells which opp_volt calculated by high/low bank
+ * @type: bank type to represent it is 2-line (high/low) bank or 1-line bank
*
* Svs bank will generate suitalbe voltages by below general math equation
* and provide these voltages to opp voltage table.
@@ -366,6 +380,7 @@ struct svs_bank {
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
+ u32 turn_freq_base;
u32 vboot;
u32 opp_dfreq[MAX_OPP_ENTRIES];
u32 opp_dvolt[MAX_OPP_ENTRIES];
@@ -401,6 +416,8 @@ struct svs_bank {
u32 mtdes;
u32 dcbdet;
u32 dcmdet;
+ u32 turn_pt;
+ u32 type;
};
static u32 percent(u32 numerator, u32 denominator)
@@ -436,13 +453,59 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
return (svsb_volt * svsb_volt_step) + svsb_volt_base;
}
+static u32 svs_opp_volt_to_bank_volt(u32 opp_u_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (opp_u_volt - svsb_volt_base) / svsb_volt_step;
+}
+
+static int svs_sync_bank_volts_from_opp(struct svs_bank *svsb)
+{
+ struct dev_pm_opp *opp;
+ u32 i, opp_u_volt;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ true);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %u (%ld)\n",
+ svsb->opp_dfreq[i], PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ opp_u_volt = dev_pm_opp_get_voltage(opp);
+ svsb->volt[i] = svs_opp_volt_to_bank_volt(opp_u_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
int ret = -EPERM, tzone_temp = 0;
- u32 i, svsb_volt, opp_volt, temp_voffset = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0, opp_start, opp_stop;
mutex_lock(&svsb->lock);
+ /*
+ * 2-line bank updates its corresponding opp volts.
+ * 1-line bank updates all opp volts.
+ */
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ } else {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
+
/* Get thermal effect */
if (svsb->phase == SVSB_PHASE_MON) {
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
@@ -457,10 +520,16 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
temp_voffset += svsb->tzone_htemp_voffset;
else if (tzone_temp <= svsb->tzone_ltemp)
temp_voffset += svsb->tzone_ltemp_voffset;
+
+ /* 2-line bank update all opp volts when running mon mode */
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
}
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
- for (i = 0; i < svsb->opp_count; i++) {
+ for (i = opp_start; i < opp_stop; i++) {
switch (svsb->phase) {
case SVSB_PHASE_ERROR:
opp_volt = svsb->opp_dvolt[i];
@@ -623,9 +692,11 @@ static int svs_status_debug_show(struct seq_file *m, void *v)
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
if (ret)
- seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ seq_printf(m, "%s: temperature ignore, turn_pt = %u\n",
+ svsb->name, svsb->turn_pt);
else
- seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+ seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
+ svsb->name, tzone_temp, svsb->turn_pt);
for (i = 0; i < svsb->opp_count; i++) {
opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
@@ -731,6 +802,181 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
return DIV_ROUND_UP(vx, 100);
}
+static void svs_get_bank_volts_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *vop, vop74, vop30, turn_pt = svsb->turn_pt;
+ u32 b_sft, shift_byte = 0, opp_start = 0, opp_stop = 0;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ if (svsb->phase == SVSB_PHASE_MON &&
+ svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
+ return;
+
+ vop74 = svs_readl_relaxed(svsp, VOP74);
+ vop30 = svs_readl_relaxed(svsp, VOP30);
+
+ /* Target is to set svsb->volt[] by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] ~ volt[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] + volt[j] ~ volt[opp_count - 1] */
+ j = svsb->opp_count - 7;
+ svsb->volt[turn_pt] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[turn_pt + 1] ~ volt[j - 1] by interpolate */
+ for (i = turn_pt + 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[turn_pt],
+ svsb->freq_pct[j],
+ svsb->volt[turn_pt],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] + volt[j] ~ volt[turn_pt - 1] */
+ j = turn_pt - 7;
+ svsb->volt[0] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[1] ~ volt[j - 1] by interpolate */
+ for (i = 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[0],
+ svsb->freq_pct[j],
+ svsb->volt[0],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] ~ volt[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ }
+ }
+
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ }
+
+ for (i = opp_start; i < opp_stop; i++)
+ if (svsb->volt_flags & SVSB_REMOVE_DVTFIXED_VOLT)
+ svsb->volt[i] -= svsb->dvt_fixed;
+}
+
+static void svs_set_bank_freq_pct_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *freq_pct, freq_pct74 = 0, freq_pct30 = 0;
+ u32 b_sft, shift_byte = 0, turn_pt;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ if (svsb->opp_dfreq[i] <= svsb->turn_freq_base) {
+ svsb->turn_pt = i;
+ break;
+ }
+ }
+
+ turn_pt = svsb->turn_pt;
+
+ /* Target is to fill out freq_pct74 / freq_pct30 by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * If we don't handle this situation,
+ * SVSB_HIGH's FREQPCT74 / FREQPCT30 would keep "0"
+ * and this leads SVSB_LOW to work abnormally.
+ */
+ if (turn_pt == 0)
+ freq_pct30 = svsb->freq_pct[0];
+
+ /* freq_pct[0] ~ freq_pct[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /*
+ * freq_pct[turn_pt] +
+ * freq_pct[opp_count - 7] ~ freq_pct[opp_count -1]
+ */
+ freq_pct30 = svsb->freq_pct[turn_pt];
+ shift_byte++;
+ j = svsb->opp_count - 7;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * freq_pct[0] +
+ * freq_pct[turn_pt - 7] ~ freq_pct[turn_pt - 1]
+ */
+ freq_pct30 = svsb->freq_pct[0];
+ shift_byte++;
+ j = turn_pt - 7;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* freq_pct[turn_pt] ~ freq_pct[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ }
+
+ svs_writel_relaxed(svsp, freq_pct74, FREQPCT74);
+ svs_writel_relaxed(svsp, freq_pct30, FREQPCT30);
+}
+
static void svs_get_bank_volts_v2(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -1174,6 +1420,25 @@ static int svs_init02(struct svs_platform *svsp)
}
}
+ /*
+ * 2-line high/low bank update its corresponding opp voltages only.
+ * Therefore, we sync voltages from opp for high/low bank voltages
+ * consistency.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ if (svs_sync_bank_volts_from_opp(svsb)) {
+ dev_err(svsb->dev, "sync volt fail\n");
+ return -EPERM;
+ }
+ }
+ }
+
return 0;
}
@@ -1218,6 +1483,7 @@ static int svs_suspend(struct device *dev)
struct svs_platform *svsp = dev_get_drvdata(dev);
struct svs_bank *svsb;
unsigned long flags;
+ int ret;
u32 idx;
for (idx = 0; idx < svsp->bank_max; idx++) {
@@ -1235,6 +1501,12 @@ static int svs_suspend(struct device *dev)
svs_adjust_pm_opp_volts(svsb);
}
+ ret = reset_control_assert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot assert reset %d\n", ret);
+ return ret;
+ }
+
clk_disable_unprepare(svsp->main_clk);
return 0;
@@ -1251,6 +1523,12 @@ static int svs_resume(struct device *dev)
return ret;
}
+ ret = reset_control_deassert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot deassert reset %d\n", ret);
+ return ret;
+ }
+
ret = svs_init02(svsp);
if (ret)
return ret;
@@ -1284,7 +1562,12 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
svsb->name = "SVSB_CCI";
break;
case SVSB_GPU:
- svsb->name = "SVSB_GPU";
+ if (svsb->type == SVSB_HIGH)
+ svsb->name = "SVSB_GPU_HIGH";
+ else if (svsb->type == SVSB_LOW)
+ svsb->name = "SVSB_GPU_LOW";
+ else
+ svsb->name = "SVSB_GPU";
break;
default:
dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
@@ -1357,6 +1640,85 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
return 0;
}
+static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct nvmem_cell *cell;
+ u32 idx, i, vmin, golden_temp;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[9]) {
+ dev_notice(svsp->dev, "svs_efuse[9] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ vmin = (svsp->efuse[19] >> 4) & GENMASK(1, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (vmin == 0x1)
+ svsb->vmin = 0x1e;
+
+ if (svsb->type == SVSB_LOW) {
+ svsb->mtdes = svsp->efuse[10] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[10] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[10] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17]) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 8) & GENMASK(7, 0);
+ } else if (svsb->type == SVSB_HIGH) {
+ svsb->mtdes = svsp->efuse[9] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[9] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[9] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 24) & GENMASK(7, 0);
+ }
+
+ svsb->vmax += svsb->dvt_fixed;
+ }
+
+ /* Thermal efuse parsing */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR_OR_NULL(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse[i] != 0)
+ break;
+
+ if (i == svsp->tefuse_max)
+ golden_temp = 50; /* All thermal efuse data are 0 */
+ else
+ golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = 500;
+ svsb->bts = (((500 * golden_temp + 250460) / 1000) - 25) * 4;
+ }
+
+ return true;
+}
+
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
@@ -1642,6 +2004,39 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
return dev;
}
+static int svs_mt8192_platform_probe(struct svs_platform *svsp)
+{
+ struct device *dev;
+ struct svs_bank *svsb;
+ u32 idx;
+
+ svsp->rst = devm_reset_control_get_optional(svsp->dev, "svs_rst");
+ if (IS_ERR(svsp->rst))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsp->rst),
+ "cannot get svs reset control\n");
+
+ dev = svs_add_device_link(svsp, "lvts");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get lvts device\n");
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->type == SVSB_HIGH)
+ svsb->opp_dev = svs_add_device_link(svsp, "mali");
+ else if (svsb->type == SVSB_LOW)
+ svsb->opp_dev = svs_get_subsys_device(svsp, "mali");
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
struct device *dev;
@@ -1681,6 +2076,61 @@ static int svs_mt8183_platform_probe(struct svs_platform *svsp)
return 0;
}
+static struct svs_bank svs_mt8192_banks[] = {
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_LOW,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT,
+ .mode_support = SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 688000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x1,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0100,
+ .int_st = BIT(0),
+ .ctl0 = 0x00540003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_HIGH,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .tzone_name = "gpu1",
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT |
+ SVSB_MON_VOLT_IGNORE,
+ .mode_support = SVSB_MODE_INIT02 | SVSB_MODE_MON,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 902000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x6,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0101,
+ .int_st = BIT(1),
+ .ctl0 = 0x00540003,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 7,
+ },
+};
+
static struct svs_bank svs_mt8183_banks[] = {
{
.sw_id = SVSB_CPU_LITTLE,
@@ -1785,6 +2235,16 @@ static struct svs_bank svs_mt8183_banks[] = {
},
};
+static const struct svs_platform_data svs_mt8192_platform_data = {
+ .name = "mt8192-svs",
+ .banks = svs_mt8192_banks,
+ .efuse_parsing = svs_mt8192_efuse_parsing,
+ .probe = svs_mt8192_platform_probe,
+ .irqflags = IRQF_TRIGGER_HIGH,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8192_banks),
+};
+
static const struct svs_platform_data svs_mt8183_platform_data = {
.name = "mt8183-svs",
.banks = svs_mt8183_banks,
@@ -1797,6 +2257,9 @@ static const struct svs_platform_data svs_mt8183_platform_data = {
static const struct of_device_id svs_of_match[] = {
{
+ .compatible = "mediatek,mt8192-svs",
+ .data = &svs_mt8192_platform_data,
+ }, {
.compatible = "mediatek,mt8183-svs",
.data = &svs_mt8183_platform_data,
}, {
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
@ 2022-05-16 0:43 ` Roger Lu
0 siblings, 0 replies; 71+ messages in thread
From: Roger Lu @ 2022-05-16 0:43 UTC (permalink / raw)
To: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
mt8192 SVS GPU uses 2-line (high/low bank) HW architecture to provide
bank voltages. High bank helps update higher frequency's voltage
and low bank helps update lower frequency's voltage.
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/mediatek/mtk-svs.c | 473 ++++++++++++++++++++++++++++++++-
1 file changed, 468 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index aa0665725339..606a00a2e57d 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -24,6 +24,7 @@
#include <linux/pm_opp.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -35,6 +36,10 @@
#define SVSB_CCI BIT(2)
#define SVSB_GPU BIT(3)
+/* svs bank 2-line type */
+#define SVSB_LOW BIT(8)
+#define SVSB_HIGH BIT(9)
+
/* svs bank mode support */
#define SVSB_MODE_ALL_DISABLE 0
#define SVSB_MODE_INIT01 BIT(1)
@@ -45,6 +50,8 @@
#define SVSB_INIT01_PD_REQ BIT(0)
#define SVSB_INIT01_VOLT_IGNORE BIT(1)
#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
+#define SVSB_MON_VOLT_IGNORE BIT(16)
+#define SVSB_REMOVE_DVTFIXED_VOLT BIT(24)
/* svs bank register common configuration */
#define SVSB_DET_MAX 0xffff
@@ -63,7 +70,9 @@
#define SVSB_RUNCONFIG_DEFAULT 0x80000000
/* svs bank related setting */
+#define BITS8 8
#define MAX_OPP_ENTRIES 16
+#define REG_BYTES 4
#define SVSB_DC_SIGNED_BIT BIT(15)
#define SVSB_DET_CLK_EN BIT(31)
#define SVSB_TEMP_LOWER_BOUND 0xb2
@@ -250,6 +259,7 @@ static const u32 svs_regs_v2[] = {
* @main_clk: main clock for svs bank
* @pbank: svs bank pointer needing to be protected by spin_lock section
* @banks: svs banks that svs platform supports
+ * @rst: svs platform reset control
* @efuse_parsing: svs platform efuse parsing function pointer
* @probe: svs platform probe function pointer
* @irqflags: svs platform irq settings flags
@@ -267,6 +277,7 @@ struct svs_platform {
struct clk *main_clk;
struct svs_bank *pbank;
struct svs_bank *banks;
+ struct reset_control *rst;
bool (*efuse_parsing)(struct svs_platform *svsp);
int (*probe)(struct svs_platform *svsp);
unsigned long irqflags;
@@ -307,6 +318,7 @@ struct svs_platform_data {
* @pm_runtime_enabled_count: bank pm runtime enabled count
* @mode_support: bank mode support.
* @freq_base: reference frequency for bank init
+ * @turn_freq_base: refenrece frequency for 2-line turn point
* @vboot: voltage request for bank init01 only
* @opp_dfreq: default opp frequency table
* @opp_dvolt: default opp voltage table
@@ -342,6 +354,8 @@ struct svs_platform_data {
* @mtdes: svs efuse data
* @dcbdet: svs efuse data
* @dcmdet: svs efuse data
+ * @turn_pt: 2-line turn point tells which opp_volt calculated by high/low bank
+ * @type: bank type to represent it is 2-line (high/low) bank or 1-line bank
*
* Svs bank will generate suitalbe voltages by below general math equation
* and provide these voltages to opp voltage table.
@@ -366,6 +380,7 @@ struct svs_bank {
u32 pm_runtime_enabled_count;
u32 mode_support;
u32 freq_base;
+ u32 turn_freq_base;
u32 vboot;
u32 opp_dfreq[MAX_OPP_ENTRIES];
u32 opp_dvolt[MAX_OPP_ENTRIES];
@@ -401,6 +416,8 @@ struct svs_bank {
u32 mtdes;
u32 dcbdet;
u32 dcmdet;
+ u32 turn_pt;
+ u32 type;
};
static u32 percent(u32 numerator, u32 denominator)
@@ -436,13 +453,59 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
return (svsb_volt * svsb_volt_step) + svsb_volt_base;
}
+static u32 svs_opp_volt_to_bank_volt(u32 opp_u_volt, u32 svsb_volt_step,
+ u32 svsb_volt_base)
+{
+ return (opp_u_volt - svsb_volt_base) / svsb_volt_step;
+}
+
+static int svs_sync_bank_volts_from_opp(struct svs_bank *svsb)
+{
+ struct dev_pm_opp *opp;
+ u32 i, opp_u_volt;
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+ svsb->opp_dfreq[i],
+ true);
+ if (IS_ERR(opp)) {
+ dev_err(svsb->dev, "cannot find freq = %u (%ld)\n",
+ svsb->opp_dfreq[i], PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+
+ opp_u_volt = dev_pm_opp_get_voltage(opp);
+ svsb->volt[i] = svs_opp_volt_to_bank_volt(opp_u_volt,
+ svsb->volt_step,
+ svsb->volt_base);
+ dev_pm_opp_put(opp);
+ }
+
+ return 0;
+}
+
static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
{
int ret = -EPERM, tzone_temp = 0;
- u32 i, svsb_volt, opp_volt, temp_voffset = 0;
+ u32 i, svsb_volt, opp_volt, temp_voffset = 0, opp_start, opp_stop;
mutex_lock(&svsb->lock);
+ /*
+ * 2-line bank updates its corresponding opp volts.
+ * 1-line bank updates all opp volts.
+ */
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ } else {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
+
/* Get thermal effect */
if (svsb->phase == SVSB_PHASE_MON) {
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
@@ -457,10 +520,16 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb)
temp_voffset += svsb->tzone_htemp_voffset;
else if (tzone_temp <= svsb->tzone_ltemp)
temp_voffset += svsb->tzone_ltemp_voffset;
+
+ /* 2-line bank update all opp volts when running mon mode */
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ opp_start = 0;
+ opp_stop = svsb->opp_count;
+ }
}
/* vmin <= svsb_volt (opp_volt) <= default opp voltage */
- for (i = 0; i < svsb->opp_count; i++) {
+ for (i = opp_start; i < opp_stop; i++) {
switch (svsb->phase) {
case SVSB_PHASE_ERROR:
opp_volt = svsb->opp_dvolt[i];
@@ -623,9 +692,11 @@ static int svs_status_debug_show(struct seq_file *m, void *v)
ret = thermal_zone_get_temp(svsb->tzd, &tzone_temp);
if (ret)
- seq_printf(m, "%s: temperature ignore\n", svsb->name);
+ seq_printf(m, "%s: temperature ignore, turn_pt = %u\n",
+ svsb->name, svsb->turn_pt);
else
- seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+ seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
+ svsb->name, tzone_temp, svsb->turn_pt);
for (i = 0; i < svsb->opp_count; i++) {
opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
@@ -731,6 +802,181 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
return DIV_ROUND_UP(vx, 100);
}
+static void svs_get_bank_volts_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *vop, vop74, vop30, turn_pt = svsb->turn_pt;
+ u32 b_sft, shift_byte = 0, opp_start = 0, opp_stop = 0;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ if (svsb->phase == SVSB_PHASE_MON &&
+ svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
+ return;
+
+ vop74 = svs_readl_relaxed(svsp, VOP74);
+ vop30 = svs_readl_relaxed(svsp, VOP30);
+
+ /* Target is to set svsb->volt[] by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] ~ volt[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] + volt[j] ~ volt[opp_count - 1] */
+ j = svsb->opp_count - 7;
+ svsb->volt[turn_pt] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[turn_pt + 1] ~ volt[j - 1] by interpolate */
+ for (i = turn_pt + 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[turn_pt],
+ svsb->freq_pct[j],
+ svsb->volt[turn_pt],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /* volt[0] + volt[j] ~ volt[turn_pt - 1] */
+ j = turn_pt - 7;
+ svsb->volt[0] = vop30 & GENMASK(7, 0);
+ shift_byte++;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+
+ /* volt[1] ~ volt[j - 1] by interpolate */
+ for (i = 1; i < j; i++)
+ svsb->volt[i] = interpolate(svsb->freq_pct[0],
+ svsb->freq_pct[j],
+ svsb->volt[0],
+ svsb->volt[j],
+ svsb->freq_pct[i]);
+ } else if (svsb->type == SVSB_LOW) {
+ /* volt[turn_pt] ~ volt[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ vop = (shift_byte < REG_BYTES) ? &vop30 :
+ &vop74;
+ svsb->volt[i] = (*vop >> b_sft) & GENMASK(7, 0);
+ shift_byte++;
+ }
+ }
+ }
+
+ if (svsb->type == SVSB_HIGH) {
+ opp_start = 0;
+ opp_stop = svsb->turn_pt;
+ } else if (svsb->type == SVSB_LOW) {
+ opp_start = svsb->turn_pt;
+ opp_stop = svsb->opp_count;
+ }
+
+ for (i = opp_start; i < opp_stop; i++)
+ if (svsb->volt_flags & SVSB_REMOVE_DVTFIXED_VOLT)
+ svsb->volt[i] -= svsb->dvt_fixed;
+}
+
+static void svs_set_bank_freq_pct_v3(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb = svsp->pbank;
+ u32 i, j, *freq_pct, freq_pct74 = 0, freq_pct30 = 0;
+ u32 b_sft, shift_byte = 0, turn_pt;
+ u32 middle_index = (svsb->opp_count / 2);
+
+ for (i = 0; i < svsb->opp_count; i++) {
+ if (svsb->opp_dfreq[i] <= svsb->turn_freq_base) {
+ svsb->turn_pt = i;
+ break;
+ }
+ }
+
+ turn_pt = svsb->turn_pt;
+
+ /* Target is to fill out freq_pct74 / freq_pct30 by algorithm */
+ if (turn_pt < middle_index) {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * If we don't handle this situation,
+ * SVSB_HIGH's FREQPCT74 / FREQPCT30 would keep "0"
+ * and this leads SVSB_LOW to work abnormally.
+ */
+ if (turn_pt == 0)
+ freq_pct30 = svsb->freq_pct[0];
+
+ /* freq_pct[0] ~ freq_pct[turn_pt - 1] */
+ for (i = 0; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /*
+ * freq_pct[turn_pt] +
+ * freq_pct[opp_count - 7] ~ freq_pct[opp_count -1]
+ */
+ freq_pct30 = svsb->freq_pct[turn_pt];
+ shift_byte++;
+ j = svsb->opp_count - 7;
+ for (i = j; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ } else {
+ if (svsb->type == SVSB_HIGH) {
+ /*
+ * freq_pct[0] +
+ * freq_pct[turn_pt - 7] ~ freq_pct[turn_pt - 1]
+ */
+ freq_pct30 = svsb->freq_pct[0];
+ shift_byte++;
+ j = turn_pt - 7;
+ for (i = j; i < turn_pt; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ } else if (svsb->type == SVSB_LOW) {
+ /* freq_pct[turn_pt] ~ freq_pct[opp_count - 1] */
+ for (i = turn_pt; i < svsb->opp_count; i++) {
+ b_sft = BITS8 * (shift_byte % REG_BYTES);
+ freq_pct = (shift_byte < REG_BYTES) ?
+ &freq_pct30 : &freq_pct74;
+ *freq_pct |= (svsb->freq_pct[i] << b_sft);
+ shift_byte++;
+ }
+ }
+ }
+
+ svs_writel_relaxed(svsp, freq_pct74, FREQPCT74);
+ svs_writel_relaxed(svsp, freq_pct30, FREQPCT30);
+}
+
static void svs_get_bank_volts_v2(struct svs_platform *svsp)
{
struct svs_bank *svsb = svsp->pbank;
@@ -1174,6 +1420,25 @@ static int svs_init02(struct svs_platform *svsp)
}
}
+ /*
+ * 2-line high/low bank update its corresponding opp voltages only.
+ * Therefore, we sync voltages from opp for high/low bank voltages
+ * consistency.
+ */
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (!(svsb->mode_support & SVSB_MODE_INIT02))
+ continue;
+
+ if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+ if (svs_sync_bank_volts_from_opp(svsb)) {
+ dev_err(svsb->dev, "sync volt fail\n");
+ return -EPERM;
+ }
+ }
+ }
+
return 0;
}
@@ -1218,6 +1483,7 @@ static int svs_suspend(struct device *dev)
struct svs_platform *svsp = dev_get_drvdata(dev);
struct svs_bank *svsb;
unsigned long flags;
+ int ret;
u32 idx;
for (idx = 0; idx < svsp->bank_max; idx++) {
@@ -1235,6 +1501,12 @@ static int svs_suspend(struct device *dev)
svs_adjust_pm_opp_volts(svsb);
}
+ ret = reset_control_assert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot assert reset %d\n", ret);
+ return ret;
+ }
+
clk_disable_unprepare(svsp->main_clk);
return 0;
@@ -1251,6 +1523,12 @@ static int svs_resume(struct device *dev)
return ret;
}
+ ret = reset_control_deassert(svsp->rst);
+ if (ret) {
+ dev_err(svsp->dev, "cannot deassert reset %d\n", ret);
+ return ret;
+ }
+
ret = svs_init02(svsp);
if (ret)
return ret;
@@ -1284,7 +1562,12 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
svsb->name = "SVSB_CCI";
break;
case SVSB_GPU:
- svsb->name = "SVSB_GPU";
+ if (svsb->type == SVSB_HIGH)
+ svsb->name = "SVSB_GPU_HIGH";
+ else if (svsb->type == SVSB_LOW)
+ svsb->name = "SVSB_GPU_LOW";
+ else
+ svsb->name = "SVSB_GPU";
break;
default:
dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id);
@@ -1357,6 +1640,85 @@ static int svs_bank_resource_setup(struct svs_platform *svsp)
return 0;
}
+static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
+{
+ struct svs_bank *svsb;
+ struct nvmem_cell *cell;
+ u32 idx, i, vmin, golden_temp;
+
+ for (i = 0; i < svsp->efuse_max; i++)
+ if (svsp->efuse[i])
+ dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+ i, svsp->efuse[i]);
+
+ if (!svsp->efuse[9]) {
+ dev_notice(svsp->dev, "svs_efuse[9] = 0x0?\n");
+ return false;
+ }
+
+ /* Svs efuse parsing */
+ vmin = (svsp->efuse[19] >> 4) & GENMASK(1, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (vmin == 0x1)
+ svsb->vmin = 0x1e;
+
+ if (svsb->type == SVSB_LOW) {
+ svsb->mtdes = svsp->efuse[10] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[10] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[10] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17]) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 8) & GENMASK(7, 0);
+ } else if (svsb->type == SVSB_HIGH) {
+ svsb->mtdes = svsp->efuse[9] & GENMASK(7, 0);
+ svsb->bdes = (svsp->efuse[9] >> 16) & GENMASK(7, 0);
+ svsb->mdes = (svsp->efuse[9] >> 24) & GENMASK(7, 0);
+ svsb->dcbdet = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+ svsb->dcmdet = (svsp->efuse[17] >> 24) & GENMASK(7, 0);
+ }
+
+ svsb->vmax += svsb->dvt_fixed;
+ }
+
+ /* Thermal efuse parsing */
+ cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+ if (IS_ERR_OR_NULL(cell)) {
+ dev_err(svsp->dev, "no \"t-calibration-data\"? %ld\n",
+ PTR_ERR(cell));
+ return false;
+ }
+
+ svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_max);
+ if (IS_ERR(svsp->tefuse)) {
+ dev_err(svsp->dev, "cannot read thermal efuse: %ld\n",
+ PTR_ERR(svsp->tefuse));
+ nvmem_cell_put(cell);
+ return false;
+ }
+
+ svsp->tefuse_max /= sizeof(u32);
+ nvmem_cell_put(cell);
+
+ for (i = 0; i < svsp->tefuse_max; i++)
+ if (svsp->tefuse[i] != 0)
+ break;
+
+ if (i == svsp->tefuse_max)
+ golden_temp = 50; /* All thermal efuse data are 0 */
+ else
+ golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+ svsb->mts = 500;
+ svsb->bts = (((500 * golden_temp + 250460) / 1000) - 25) * 4;
+ }
+
+ return true;
+}
+
static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
{
struct svs_bank *svsb;
@@ -1642,6 +2004,39 @@ static struct device *svs_add_device_link(struct svs_platform *svsp,
return dev;
}
+static int svs_mt8192_platform_probe(struct svs_platform *svsp)
+{
+ struct device *dev;
+ struct svs_bank *svsb;
+ u32 idx;
+
+ svsp->rst = devm_reset_control_get_optional(svsp->dev, "svs_rst");
+ if (IS_ERR(svsp->rst))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsp->rst),
+ "cannot get svs reset control\n");
+
+ dev = svs_add_device_link(svsp, "lvts");
+ if (IS_ERR(dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(dev),
+ "failed to get lvts device\n");
+
+ for (idx = 0; idx < svsp->bank_max; idx++) {
+ svsb = &svsp->banks[idx];
+
+ if (svsb->type == SVSB_HIGH)
+ svsb->opp_dev = svs_add_device_link(svsp, "mali");
+ else if (svsb->type == SVSB_LOW)
+ svsb->opp_dev = svs_get_subsys_device(svsp, "mali");
+
+ if (IS_ERR(svsb->opp_dev))
+ return dev_err_probe(svsp->dev, PTR_ERR(svsb->opp_dev),
+ "failed to get OPP device for bank %d\n",
+ idx);
+ }
+
+ return 0;
+}
+
static int svs_mt8183_platform_probe(struct svs_platform *svsp)
{
struct device *dev;
@@ -1681,6 +2076,61 @@ static int svs_mt8183_platform_probe(struct svs_platform *svsp)
return 0;
}
+static struct svs_bank svs_mt8192_banks[] = {
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_LOW,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT,
+ .mode_support = SVSB_MODE_INIT02,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 688000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x1,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0100,
+ .int_st = BIT(0),
+ .ctl0 = 0x00540003,
+ },
+ {
+ .sw_id = SVSB_GPU,
+ .type = SVSB_HIGH,
+ .set_freq_pct = svs_set_bank_freq_pct_v3,
+ .get_volts = svs_get_bank_volts_v3,
+ .tzone_name = "gpu1",
+ .volt_flags = SVSB_REMOVE_DVTFIXED_VOLT |
+ SVSB_MON_VOLT_IGNORE,
+ .mode_support = SVSB_MODE_INIT02 | SVSB_MODE_MON,
+ .opp_count = MAX_OPP_ENTRIES,
+ .freq_base = 902000000,
+ .turn_freq_base = 688000000,
+ .volt_step = 6250,
+ .volt_base = 400000,
+ .vmax = 0x60,
+ .vmin = 0x1a,
+ .age_config = 0x555555,
+ .dc_config = 0x1,
+ .dvt_fixed = 0x6,
+ .vco = 0x18,
+ .chk_shift = 0x87,
+ .core_sel = 0x0fff0101,
+ .int_st = BIT(1),
+ .ctl0 = 0x00540003,
+ .tzone_htemp = 85000,
+ .tzone_htemp_voffset = 0,
+ .tzone_ltemp = 25000,
+ .tzone_ltemp_voffset = 7,
+ },
+};
+
static struct svs_bank svs_mt8183_banks[] = {
{
.sw_id = SVSB_CPU_LITTLE,
@@ -1785,6 +2235,16 @@ static struct svs_bank svs_mt8183_banks[] = {
},
};
+static const struct svs_platform_data svs_mt8192_platform_data = {
+ .name = "mt8192-svs",
+ .banks = svs_mt8192_banks,
+ .efuse_parsing = svs_mt8192_efuse_parsing,
+ .probe = svs_mt8192_platform_probe,
+ .irqflags = IRQF_TRIGGER_HIGH,
+ .regs = svs_regs_v2,
+ .bank_max = ARRAY_SIZE(svs_mt8192_banks),
+};
+
static const struct svs_platform_data svs_mt8183_platform_data = {
.name = "mt8183-svs",
.banks = svs_mt8183_banks,
@@ -1797,6 +2257,9 @@ static const struct svs_platform_data svs_mt8183_platform_data = {
static const struct of_device_id svs_of_match[] = {
{
+ .compatible = "mediatek,mt8192-svs",
+ .data = &svs_mt8192_platform_data,
+ }, {
.compatible = "mediatek,mt8183-svs",
.data = &svs_mt8183_platform_data,
}, {
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-17 10:04 ` Chen-Yu Tsai
-1 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-17 10:04 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
I've updated my branch to include all the latest versions of the relevant
patch series:
- anx7625 DPI bus type series v2 (so the display works)
- MT8183 thermal series v9 (this seems to have been overlooked by the
maintainer)
- MTK SVS driver series v25
- devfreq: cpu based scaling support to passive governor series v5
- MTK CCI devfreq series v4
- MT8183 cpufreq series v7
- Additional WIP patches for panfrost MTK devfreq
ChenYu
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-17 10:04 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-17 10:04 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
I've updated my branch to include all the latest versions of the relevant
patch series:
- anx7625 DPI bus type series v2 (so the display works)
- MT8183 thermal series v9 (this seems to have been overlooked by the
maintainer)
- MTK SVS driver series v25
- devfreq: cpu based scaling support to passive governor series v5
- MTK CCI devfreq series v4
- MT8183 cpufreq series v7
- Additional WIP patches for panfrost MTK devfreq
ChenYu
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-17 10:04 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-17 10:04 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
I've updated my branch to include all the latest versions of the relevant
patch series:
- anx7625 DPI bus type series v2 (so the display works)
- MT8183 thermal series v9 (this seems to have been overlooked by the
maintainer)
- MTK SVS driver series v25
- devfreq: cpu based scaling support to passive governor series v5
- MTK CCI devfreq series v4
- MT8183 cpufreq series v7
- Additional WIP patches for panfrost MTK devfreq
ChenYu
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-17 10:04 ` Chen-Yu Tsai
(?)
@ 2022-05-17 22:59 ` Kevin Hilman
-1 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-17 22:59 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>
>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> which calculates suitable SVS bank voltages to OPP voltage table.
>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>
>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>
>> Change since v24:
>> - Rebase to Linux 5.18-rc6
>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>
>> Test in below environment:
>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> HW: mt8183-Krane
>>
>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>
> I've updated my branch to include all the latest versions of the relevant
> patch series:
>
> - anx7625 DPI bus type series v2 (so the display works)
> - MT8183 thermal series v9 (this seems to have been overlooked by the
> maintainer)
> - MTK SVS driver series v25
> - devfreq: cpu based scaling support to passive governor series v5
> - MTK CCI devfreq series v4
> - MT8183 cpufreq series v7
> - Additional WIP patches for panfrost MTK devfreq
Thanks for preparing an integration branch Chen-Yu.
I'm testing this on mt8183-pumpkin with one patch to add the CCI
regulator[1], and the defconfig you posted in a previous rev of this
series, but the CCI driver still causes a fault on boot[2] on my
platform.
I mentioned in earlier reviews that I think there's potentially a race
between CCI and SVS loading since they are co-dependent. My hunch is
that this is still not being handled properly.
Kevin
[1]
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index af0abadca803..59822a283ba2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -384,6 +384,10 @@ &mfg {
domain-supply = <&mt6358_vgpu_reg>;
};
+&cci {
+ proc-supply = <&mt6358_vproc12_reg>;
+};
+
&cpu0 {
proc-supply = <&mt6358_vproc12_reg>;
};
[2]
[...]
[ 0.439273] mtk-msdc 11230000.mmc: using lookup tables for GPIO lookup
[ 0.439276] mtk-msdc 11230000.mmc: No GPIO consumer wp found
[ 0.445542] ------------[ cut here ]------------
[ 0.445554] WARNING: CPU: 0 PID: 1 at drivers/devfreq/governor_passive.c:339 devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445577] Modules linked in:
[ 0.445587] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc6-next-20220516-12233-ged53129ed440-dirty #71 653f6e79e530940612a5c2dd77876f403a48161d
[ 0.445596] Hardware name: Pumpkin MT8183 (DT)
[ 0.445600] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.445606] pc : devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445614] lr : devfreq_passive_event_handler+0x1a0/0x2d8
[ 0.445621] sp : ffffffc00808ba90
[ 0.445623] x29: ffffffc00808ba90 x28: ffffff80033e8d80 x27: 0000000000000000
[ 0.445633] x26: ffffffc009522218 x25: ffffff800335a7b8 x24: ffffffc009522420
[ 0.445642] x23: ffffff8002606410 x22: 0000000000000004 x21: ffffff800335a780
[ 0.445651] x20: ffffff8003216000 x19: 00000000fffffdfb x18: 00000000a662b0a1
[ 0.445661] x17: 0000000000000001 x16: 0000000100000000 x15: 0000000100000001
[ 0.445670] x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000004
[ 0.445679] x11: 0000000000000001 x10: 0000000000000bb0 x9 : ffffffc008b0e8e8
[ 0.445688] x8 : ffffff8001e1ac90 x7 : 00000000c0000000 x6 : 0000000000000000
[ 0.445696] x5 : ffffff80033909d8 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.445705] x2 : 0000000000000008 x1 : 0000000000000008 x0 : 00000000ffffffea
[ 0.445715] Call trace:
[ 0.445718] devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445726] devfreq_add_device+0x498/0x534
[ 0.445734] devm_devfreq_add_device+0x6c/0xb8
[ 0.445740] mtk_ccifreq_probe+0x384/0x418
[ 0.445748] platform_probe+0x70/0xc0
[ 0.445756] really_probe+0x14c/0x288
[ 0.445761] __driver_probe_device+0xc8/0xe0
[ 0.445767] driver_probe_device+0x4c/0xe4
[ 0.445772] __driver_attach+0xe8/0xf8
[ 0.445777] bus_for_each_dev+0x78/0xc4
[ 0.445786] driver_attach+0x2c/0x38
[ 0.445791] bus_add_driver+0x178/0x1c0
[ 0.445795] driver_register+0xbc/0xf4
[ 0.445801] __platform_driver_register+0x30/0x3c
[ 0.445807] mtk_ccifreq_platdrv_init+0x24/0x30
[ 0.445817] do_one_initcall+0xa0/0x1f8
[ 0.445824] kernel_init_freeable+0x288/0x2a8
[ 0.445831] kernel_init+0x2c/0x130
[ 0.445838] ret_from_fork+0x10/0x20
[ 0.445844] ---[ end trace 0000000000000000 ]---
[ 0.445853] mtk-ccifreq cci: devfreq_add_device: Unable to start governor for the device
[ 0.449511] ------------[ cut here ]------------
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-17 22:59 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-17 22:59 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>
>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> which calculates suitable SVS bank voltages to OPP voltage table.
>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>
>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>
>> Change since v24:
>> - Rebase to Linux 5.18-rc6
>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>
>> Test in below environment:
>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> HW: mt8183-Krane
>>
>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>
> I've updated my branch to include all the latest versions of the relevant
> patch series:
>
> - anx7625 DPI bus type series v2 (so the display works)
> - MT8183 thermal series v9 (this seems to have been overlooked by the
> maintainer)
> - MTK SVS driver series v25
> - devfreq: cpu based scaling support to passive governor series v5
> - MTK CCI devfreq series v4
> - MT8183 cpufreq series v7
> - Additional WIP patches for panfrost MTK devfreq
Thanks for preparing an integration branch Chen-Yu.
I'm testing this on mt8183-pumpkin with one patch to add the CCI
regulator[1], and the defconfig you posted in a previous rev of this
series, but the CCI driver still causes a fault on boot[2] on my
platform.
I mentioned in earlier reviews that I think there's potentially a race
between CCI and SVS loading since they are co-dependent. My hunch is
that this is still not being handled properly.
Kevin
[1]
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index af0abadca803..59822a283ba2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -384,6 +384,10 @@ &mfg {
domain-supply = <&mt6358_vgpu_reg>;
};
+&cci {
+ proc-supply = <&mt6358_vproc12_reg>;
+};
+
&cpu0 {
proc-supply = <&mt6358_vproc12_reg>;
};
[2]
[...]
[ 0.439273] mtk-msdc 11230000.mmc: using lookup tables for GPIO lookup
[ 0.439276] mtk-msdc 11230000.mmc: No GPIO consumer wp found
[ 0.445542] ------------[ cut here ]------------
[ 0.445554] WARNING: CPU: 0 PID: 1 at drivers/devfreq/governor_passive.c:339 devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445577] Modules linked in:
[ 0.445587] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc6-next-20220516-12233-ged53129ed440-dirty #71 653f6e79e530940612a5c2dd77876f403a48161d
[ 0.445596] Hardware name: Pumpkin MT8183 (DT)
[ 0.445600] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.445606] pc : devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445614] lr : devfreq_passive_event_handler+0x1a0/0x2d8
[ 0.445621] sp : ffffffc00808ba90
[ 0.445623] x29: ffffffc00808ba90 x28: ffffff80033e8d80 x27: 0000000000000000
[ 0.445633] x26: ffffffc009522218 x25: ffffff800335a7b8 x24: ffffffc009522420
[ 0.445642] x23: ffffff8002606410 x22: 0000000000000004 x21: ffffff800335a780
[ 0.445651] x20: ffffff8003216000 x19: 00000000fffffdfb x18: 00000000a662b0a1
[ 0.445661] x17: 0000000000000001 x16: 0000000100000000 x15: 0000000100000001
[ 0.445670] x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000004
[ 0.445679] x11: 0000000000000001 x10: 0000000000000bb0 x9 : ffffffc008b0e8e8
[ 0.445688] x8 : ffffff8001e1ac90 x7 : 00000000c0000000 x6 : 0000000000000000
[ 0.445696] x5 : ffffff80033909d8 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.445705] x2 : 0000000000000008 x1 : 0000000000000008 x0 : 00000000ffffffea
[ 0.445715] Call trace:
[ 0.445718] devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445726] devfreq_add_device+0x498/0x534
[ 0.445734] devm_devfreq_add_device+0x6c/0xb8
[ 0.445740] mtk_ccifreq_probe+0x384/0x418
[ 0.445748] platform_probe+0x70/0xc0
[ 0.445756] really_probe+0x14c/0x288
[ 0.445761] __driver_probe_device+0xc8/0xe0
[ 0.445767] driver_probe_device+0x4c/0xe4
[ 0.445772] __driver_attach+0xe8/0xf8
[ 0.445777] bus_for_each_dev+0x78/0xc4
[ 0.445786] driver_attach+0x2c/0x38
[ 0.445791] bus_add_driver+0x178/0x1c0
[ 0.445795] driver_register+0xbc/0xf4
[ 0.445801] __platform_driver_register+0x30/0x3c
[ 0.445807] mtk_ccifreq_platdrv_init+0x24/0x30
[ 0.445817] do_one_initcall+0xa0/0x1f8
[ 0.445824] kernel_init_freeable+0x288/0x2a8
[ 0.445831] kernel_init+0x2c/0x130
[ 0.445838] ret_from_fork+0x10/0x20
[ 0.445844] ---[ end trace 0000000000000000 ]---
[ 0.445853] mtk-ccifreq cci: devfreq_add_device: Unable to start governor for the device
[ 0.449511] ------------[ cut here ]------------
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-17 22:59 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-17 22:59 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>
>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> which calculates suitable SVS bank voltages to OPP voltage table.
>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>
>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>
>> Change since v24:
>> - Rebase to Linux 5.18-rc6
>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>
>> Test in below environment:
>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> HW: mt8183-Krane
>>
>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>
> I've updated my branch to include all the latest versions of the relevant
> patch series:
>
> - anx7625 DPI bus type series v2 (so the display works)
> - MT8183 thermal series v9 (this seems to have been overlooked by the
> maintainer)
> - MTK SVS driver series v25
> - devfreq: cpu based scaling support to passive governor series v5
> - MTK CCI devfreq series v4
> - MT8183 cpufreq series v7
> - Additional WIP patches for panfrost MTK devfreq
Thanks for preparing an integration branch Chen-Yu.
I'm testing this on mt8183-pumpkin with one patch to add the CCI
regulator[1], and the defconfig you posted in a previous rev of this
series, but the CCI driver still causes a fault on boot[2] on my
platform.
I mentioned in earlier reviews that I think there's potentially a race
between CCI and SVS loading since they are co-dependent. My hunch is
that this is still not being handled properly.
Kevin
[1]
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index af0abadca803..59822a283ba2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -384,6 +384,10 @@ &mfg {
domain-supply = <&mt6358_vgpu_reg>;
};
+&cci {
+ proc-supply = <&mt6358_vproc12_reg>;
+};
+
&cpu0 {
proc-supply = <&mt6358_vproc12_reg>;
};
[2]
[...]
[ 0.439273] mtk-msdc 11230000.mmc: using lookup tables for GPIO lookup
[ 0.439276] mtk-msdc 11230000.mmc: No GPIO consumer wp found
[ 0.445542] ------------[ cut here ]------------
[ 0.445554] WARNING: CPU: 0 PID: 1 at drivers/devfreq/governor_passive.c:339 devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445577] Modules linked in:
[ 0.445587] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc6-next-20220516-12233-ged53129ed440-dirty #71 653f6e79e530940612a5c2dd77876f403a48161d
[ 0.445596] Hardware name: Pumpkin MT8183 (DT)
[ 0.445600] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.445606] pc : devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445614] lr : devfreq_passive_event_handler+0x1a0/0x2d8
[ 0.445621] sp : ffffffc00808ba90
[ 0.445623] x29: ffffffc00808ba90 x28: ffffff80033e8d80 x27: 0000000000000000
[ 0.445633] x26: ffffffc009522218 x25: ffffff800335a7b8 x24: ffffffc009522420
[ 0.445642] x23: ffffff8002606410 x22: 0000000000000004 x21: ffffff800335a780
[ 0.445651] x20: ffffff8003216000 x19: 00000000fffffdfb x18: 00000000a662b0a1
[ 0.445661] x17: 0000000000000001 x16: 0000000100000000 x15: 0000000100000001
[ 0.445670] x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000004
[ 0.445679] x11: 0000000000000001 x10: 0000000000000bb0 x9 : ffffffc008b0e8e8
[ 0.445688] x8 : ffffff8001e1ac90 x7 : 00000000c0000000 x6 : 0000000000000000
[ 0.445696] x5 : ffffff80033909d8 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.445705] x2 : 0000000000000008 x1 : 0000000000000008 x0 : 00000000ffffffea
[ 0.445715] Call trace:
[ 0.445718] devfreq_passive_event_handler+0x1a4/0x2d8
[ 0.445726] devfreq_add_device+0x498/0x534
[ 0.445734] devm_devfreq_add_device+0x6c/0xb8
[ 0.445740] mtk_ccifreq_probe+0x384/0x418
[ 0.445748] platform_probe+0x70/0xc0
[ 0.445756] really_probe+0x14c/0x288
[ 0.445761] __driver_probe_device+0xc8/0xe0
[ 0.445767] driver_probe_device+0x4c/0xe4
[ 0.445772] __driver_attach+0xe8/0xf8
[ 0.445777] bus_for_each_dev+0x78/0xc4
[ 0.445786] driver_attach+0x2c/0x38
[ 0.445791] bus_add_driver+0x178/0x1c0
[ 0.445795] driver_register+0xbc/0xf4
[ 0.445801] __platform_driver_register+0x30/0x3c
[ 0.445807] mtk_ccifreq_platdrv_init+0x24/0x30
[ 0.445817] do_one_initcall+0xa0/0x1f8
[ 0.445824] kernel_init_freeable+0x288/0x2a8
[ 0.445831] kernel_init+0x2c/0x130
[ 0.445838] ret_from_fork+0x10/0x20
[ 0.445844] ---[ end trace 0000000000000000 ]---
[ 0.445853] mtk-ccifreq cci: devfreq_add_device: Unable to start governor for the device
[ 0.449511] ------------[ cut here ]------------
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-17 22:59 ` Kevin Hilman
(?)
@ 2022-05-18 0:03 ` Kevin Hilman
-1 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-18 0:03 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Kevin Hilman <khilman@kernel.org> writes:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>
>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>
>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>
>>> Change since v24:
>>> - Rebase to Linux 5.18-rc6
>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>
>>> Test in below environment:
>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>> HW: mt8183-Krane
>>>
>>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>>
>> I've updated my branch to include all the latest versions of the relevant
>> patch series:
>>
>> - anx7625 DPI bus type series v2 (so the display works)
>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> maintainer)
>> - MTK SVS driver series v25
>> - devfreq: cpu based scaling support to passive governor series v5
>> - MTK CCI devfreq series v4
>> - MT8183 cpufreq series v7
>> - Additional WIP patches for panfrost MTK devfreq
>
> Thanks for preparing an integration branch Chen-Yu.
>
> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> regulator[1], and the defconfig you posted in a previous rev of this
> series, but the CCI driver still causes a fault on boot[2] on my
> platform.
>
> I mentioned in earlier reviews that I think there's potentially a race
> between CCI and SVS loading since they are co-dependent. My hunch is
> that this is still not being handled properly.
Ah, actually it's crashing when I try to boot the platform with
`maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
unstable upstream with the 2nd cluster enabled.)
The CCI driver should be a bit more robust about detecting
available/online CPUs
If I boot with both clusters, I see SVS probing[1], and I see CCI
doing transitions[2]
Kevin
[1]
# dmesg |grep -i svs
[ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
[ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
[ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
[ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
[ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
[ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
[ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
[ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
[ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
[ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
[ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
[ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
[ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
[ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
[ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
[ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
[ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
[ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
[ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
[ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
[ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
[ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
[ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
[2]
# cat /sys/class/devfreq/cci/trans_stat
From : To
: 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
* 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
Total transition : 1810
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 0:03 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-18 0:03 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Kevin Hilman <khilman@kernel.org> writes:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>
>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>
>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>
>>> Change since v24:
>>> - Rebase to Linux 5.18-rc6
>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>
>>> Test in below environment:
>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>> HW: mt8183-Krane
>>>
>>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>>
>> I've updated my branch to include all the latest versions of the relevant
>> patch series:
>>
>> - anx7625 DPI bus type series v2 (so the display works)
>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> maintainer)
>> - MTK SVS driver series v25
>> - devfreq: cpu based scaling support to passive governor series v5
>> - MTK CCI devfreq series v4
>> - MT8183 cpufreq series v7
>> - Additional WIP patches for panfrost MTK devfreq
>
> Thanks for preparing an integration branch Chen-Yu.
>
> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> regulator[1], and the defconfig you posted in a previous rev of this
> series, but the CCI driver still causes a fault on boot[2] on my
> platform.
>
> I mentioned in earlier reviews that I think there's potentially a race
> between CCI and SVS loading since they are co-dependent. My hunch is
> that this is still not being handled properly.
Ah, actually it's crashing when I try to boot the platform with
`maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
unstable upstream with the 2nd cluster enabled.)
The CCI driver should be a bit more robust about detecting
available/online CPUs
If I boot with both clusters, I see SVS probing[1], and I see CCI
doing transitions[2]
Kevin
[1]
# dmesg |grep -i svs
[ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
[ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
[ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
[ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
[ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
[ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
[ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
[ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
[ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
[ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
[ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
[ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
[ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
[ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
[ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
[ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
[ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
[ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
[ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
[ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
[ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
[ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
[ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
[2]
# cat /sys/class/devfreq/cci/trans_stat
From : To
: 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
* 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
Total transition : 1810
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 0:03 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-18 0:03 UTC (permalink / raw)
To: Chen-Yu Tsai, Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Kevin Hilman <khilman@kernel.org> writes:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>
>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>
>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>
>>> Change since v24:
>>> - Rebase to Linux 5.18-rc6
>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>
>>> Test in below environment:
>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>> HW: mt8183-Krane
>>>
>>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>>
>> I've updated my branch to include all the latest versions of the relevant
>> patch series:
>>
>> - anx7625 DPI bus type series v2 (so the display works)
>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> maintainer)
>> - MTK SVS driver series v25
>> - devfreq: cpu based scaling support to passive governor series v5
>> - MTK CCI devfreq series v4
>> - MT8183 cpufreq series v7
>> - Additional WIP patches for panfrost MTK devfreq
>
> Thanks for preparing an integration branch Chen-Yu.
>
> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> regulator[1], and the defconfig you posted in a previous rev of this
> series, but the CCI driver still causes a fault on boot[2] on my
> platform.
>
> I mentioned in earlier reviews that I think there's potentially a race
> between CCI and SVS loading since they are co-dependent. My hunch is
> that this is still not being handled properly.
Ah, actually it's crashing when I try to boot the platform with
`maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
unstable upstream with the 2nd cluster enabled.)
The CCI driver should be a bit more robust about detecting
available/online CPUs
If I boot with both clusters, I see SVS probing[1], and I see CCI
doing transitions[2]
Kevin
[1]
# dmesg |grep -i svs
[ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
[ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
[ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
[ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
[ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
[ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
[ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
[ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
[ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
[ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
[ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
[ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
[ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
[ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
[ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
[ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
[ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
[ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
[ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
[ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
[ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
[ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
[ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
[2]
# cat /sys/class/devfreq/cci/trans_stat
From : To
: 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
* 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
Total transition : 1810
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-05-18 2:57 ` Rex-BC Chen
-1 siblings, 0 replies; 71+ messages in thread
From: Rex-BC Chen @ 2022-05-18 2:57 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, 2022-05-16 at 08:43 +0800, Roger Lu wrote:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table
> voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device
> by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to
> make sure probe/suspend callback priority.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which
> step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's
> power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this
> patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5]
> https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler:
> VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler:
> VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler:
> VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler:
> VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler:
> VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler:
> VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler:
> VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler:
> VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46,
> freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f,
> freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d,
> freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39,
> freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38,
> freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34,
> freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30,
> freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c,
> freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28,
> freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23,
> freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20,
> freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a,
> freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23,
> freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18,
> freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27,
> freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25,
> freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23,
> freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22,
> freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20,
> freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f,
> freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d,
> freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c,
> freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a,
> freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19,
> freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17,
> freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17,
> freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16,
> freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16,
> freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14,
> freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14,
> freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399
> +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
Hello Matthias,
Gentle remind for svs series.
Roger tests 8183 svs done using Chen-Yu's branch and it's based on 5.18
next.
Tested on 8183 Chromepad - Krane.
Thanks for your big support!
BRs,
Rex
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 2:57 ` Rex-BC Chen
0 siblings, 0 replies; 71+ messages in thread
From: Rex-BC Chen @ 2022-05-18 2:57 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, 2022-05-16 at 08:43 +0800, Roger Lu wrote:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table
> voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device
> by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to
> make sure probe/suspend callback priority.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which
> step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's
> power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this
> patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5]
> https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler:
> VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler:
> VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler:
> VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler:
> VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler:
> VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler:
> VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler:
> VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler:
> VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46,
> freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f,
> freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d,
> freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39,
> freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38,
> freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34,
> freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30,
> freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c,
> freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28,
> freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23,
> freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20,
> freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a,
> freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23,
> freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18,
> freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27,
> freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25,
> freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23,
> freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22,
> freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20,
> freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f,
> freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d,
> freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c,
> freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a,
> freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19,
> freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17,
> freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17,
> freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16,
> freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16,
> freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14,
> freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14,
> freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399
> +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
Hello Matthias,
Gentle remind for svs series.
Roger tests 8183 svs done using Chen-Yu's branch and it's based on 5.18
next.
Tested on 8183 Chromepad - Krane.
Thanks for your big support!
BRs,
Rex
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 2:57 ` Rex-BC Chen
0 siblings, 0 replies; 71+ messages in thread
From: Rex-BC Chen @ 2022-05-18 2:57 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, 2022-05-16 at 08:43 +0800, Roger Lu wrote:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table
> voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device
> by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to
> make sure probe/suspend callback priority.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which
> step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's
> power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this
> patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5]
> https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler:
> VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler:
> VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler:
> VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler:
> VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler:
> VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler:
> VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler:
> VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler:
> VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46,
> freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f,
> freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d,
> freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39,
> freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38,
> freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34,
> freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30,
> freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c,
> freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28,
> freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23,
> freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20,
> freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a,
> freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23,
> freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b,
> freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49,
> freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45,
> freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43,
> freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40,
> freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f,
> freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c,
> freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b,
> freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37,
> freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34,
> freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f,
> freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c,
> freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27,
> freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22,
> freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d,
> freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18,
> freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27,
> freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25,
> freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23,
> freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22,
> freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20,
> freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f,
> freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d,
> freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c,
> freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a,
> freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19,
> freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17,
> freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17,
> freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16,
> freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16,
> freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14,
> freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14,
> freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399
> +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
Hello Matthias,
Gentle remind for svs series.
Roger tests 8183 svs done using Chen-Yu's branch and it's based on 5.18
next.
Tested on 8183 Chromepad - Krane.
Thanks for your big support!
BRs,
Rex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-18 0:03 ` Kevin Hilman
(?)
@ 2022-05-18 4:17 ` Chen-Yu Tsai
-1 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-18 4:17 UTC (permalink / raw)
To: Kevin Hilman, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>
> Kevin Hilman <khilman@kernel.org> writes:
>
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>
> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>
> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>
> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>
> >>> Change since v24:
> >>> - Rebase to Linux 5.18-rc6
> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>
> >>> Test in below environment:
> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>> HW: mt8183-Krane
> >>>
> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> >>
> >> I've updated my branch to include all the latest versions of the relevant
> >> patch series:
> >>
> >> - anx7625 DPI bus type series v2 (so the display works)
> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >> maintainer)
> >> - MTK SVS driver series v25
> >> - devfreq: cpu based scaling support to passive governor series v5
> >> - MTK CCI devfreq series v4
> >> - MT8183 cpufreq series v7
> >> - Additional WIP patches for panfrost MTK devfreq
> >
> > Thanks for preparing an integration branch Chen-Yu.
> >
> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
> > regulator[1], and the defconfig you posted in a previous rev of this
> > series, but the CCI driver still causes a fault on boot[2] on my
> > platform.
> >
> > I mentioned in earlier reviews that I think there's potentially a race
> > between CCI and SVS loading since they are co-dependent. My hunch is
> > that this is still not being handled properly.
>
> Ah, actually it's crashing when I try to boot the platform with
> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> unstable upstream with the 2nd cluster enabled.)
>
> The CCI driver should be a bit more robust about detecting
> available/online CPUs
This all seems to be handled in the devfreq passive governor.
And presumably we'd like to have CCI devfreq running even if just one
core was booted.
Added Chanwoo for more ideas.
ChenYu
> If I boot with both clusters, I see SVS probing[1], and I see CCI
> doing transitions[2]
>
> Kevin
>
>
> [1]
> # dmesg |grep -i svs
> [ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
> [ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
> [ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
> [ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
> [ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
> [ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
> [ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
> [ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
> [ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
> [ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
> [ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
> [ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
> [ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
> [ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
> [ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
> [ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
> [ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
> [ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
> [ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
> [ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
> [ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
> [ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
> [ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
>
> [2]
> # cat /sys/class/devfreq/cci/trans_stat
> From : To
> : 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
> 273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
> 338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
> 403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
> 463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
> 546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
> * 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
> 689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
> 767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
> 845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
> 871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
> 923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
> 962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
> 1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
> 1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
> 1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
> 1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
> Total transition : 1810
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 4:17 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-18 4:17 UTC (permalink / raw)
To: Kevin Hilman, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>
> Kevin Hilman <khilman@kernel.org> writes:
>
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>
> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>
> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>
> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>
> >>> Change since v24:
> >>> - Rebase to Linux 5.18-rc6
> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>
> >>> Test in below environment:
> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>> HW: mt8183-Krane
> >>>
> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> >>
> >> I've updated my branch to include all the latest versions of the relevant
> >> patch series:
> >>
> >> - anx7625 DPI bus type series v2 (so the display works)
> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >> maintainer)
> >> - MTK SVS driver series v25
> >> - devfreq: cpu based scaling support to passive governor series v5
> >> - MTK CCI devfreq series v4
> >> - MT8183 cpufreq series v7
> >> - Additional WIP patches for panfrost MTK devfreq
> >
> > Thanks for preparing an integration branch Chen-Yu.
> >
> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
> > regulator[1], and the defconfig you posted in a previous rev of this
> > series, but the CCI driver still causes a fault on boot[2] on my
> > platform.
> >
> > I mentioned in earlier reviews that I think there's potentially a race
> > between CCI and SVS loading since they are co-dependent. My hunch is
> > that this is still not being handled properly.
>
> Ah, actually it's crashing when I try to boot the platform with
> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> unstable upstream with the 2nd cluster enabled.)
>
> The CCI driver should be a bit more robust about detecting
> available/online CPUs
This all seems to be handled in the devfreq passive governor.
And presumably we'd like to have CCI devfreq running even if just one
core was booted.
Added Chanwoo for more ideas.
ChenYu
> If I boot with both clusters, I see SVS probing[1], and I see CCI
> doing transitions[2]
>
> Kevin
>
>
> [1]
> # dmesg |grep -i svs
> [ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
> [ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
> [ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
> [ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
> [ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
> [ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
> [ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
> [ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
> [ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
> [ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
> [ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
> [ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
> [ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
> [ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
> [ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
> [ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
> [ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
> [ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
> [ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
> [ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
> [ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
> [ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
> [ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
>
> [2]
> # cat /sys/class/devfreq/cci/trans_stat
> From : To
> : 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
> 273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
> 338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
> 403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
> 463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
> 546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
> * 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
> 689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
> 767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
> 845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
> 871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
> 923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
> 962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
> 1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
> 1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
> 1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
> 1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
> Total transition : 1810
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-18 4:17 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-18 4:17 UTC (permalink / raw)
To: Kevin Hilman, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>
> Kevin Hilman <khilman@kernel.org> writes:
>
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>
> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>
> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>
> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>
> >>> Change since v24:
> >>> - Rebase to Linux 5.18-rc6
> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>
> >>> Test in below environment:
> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>> HW: mt8183-Krane
> >>>
> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> >>
> >> I've updated my branch to include all the latest versions of the relevant
> >> patch series:
> >>
> >> - anx7625 DPI bus type series v2 (so the display works)
> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >> maintainer)
> >> - MTK SVS driver series v25
> >> - devfreq: cpu based scaling support to passive governor series v5
> >> - MTK CCI devfreq series v4
> >> - MT8183 cpufreq series v7
> >> - Additional WIP patches for panfrost MTK devfreq
> >
> > Thanks for preparing an integration branch Chen-Yu.
> >
> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
> > regulator[1], and the defconfig you posted in a previous rev of this
> > series, but the CCI driver still causes a fault on boot[2] on my
> > platform.
> >
> > I mentioned in earlier reviews that I think there's potentially a race
> > between CCI and SVS loading since they are co-dependent. My hunch is
> > that this is still not being handled properly.
>
> Ah, actually it's crashing when I try to boot the platform with
> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> unstable upstream with the 2nd cluster enabled.)
>
> The CCI driver should be a bit more robust about detecting
> available/online CPUs
This all seems to be handled in the devfreq passive governor.
And presumably we'd like to have CCI devfreq running even if just one
core was booted.
Added Chanwoo for more ideas.
ChenYu
> If I boot with both clusters, I see SVS probing[1], and I see CCI
> doing transitions[2]
>
> Kevin
>
>
> [1]
> # dmesg |grep -i svs
> [ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
> [ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
> [ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
> [ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
> [ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
> [ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
> [ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
> [ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
> [ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
> [ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
> [ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
> [ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
> [ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
> [ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
> [ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
> [ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
> [ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
> [ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
> [ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
> [ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
> [ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
> [ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
> [ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
>
> [2]
> # cat /sys/class/devfreq/cci/trans_stat
> From : To
> : 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
> 273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
> 338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
> 403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
> 463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
> 546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
> * 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
> 689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
> 767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
> 845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
> 871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
> 923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
> 962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
> 1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
> 1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
> 1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
> 1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
> Total transition : 1810
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-18 4:17 ` Chen-Yu Tsai
(?)
@ 2022-05-19 18:25 ` Kevin Hilman
-1 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-19 18:25 UTC (permalink / raw)
To: Chen-Yu Tsai, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent. My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.
Well, that's the initial crash. But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.
> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.
Yes, I assume so also.
> Added Chanwoo for more ideas.
OK, thanks.
Kevin
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-19 18:25 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-19 18:25 UTC (permalink / raw)
To: Chen-Yu Tsai, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent. My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.
Well, that's the initial crash. But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.
> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.
Yes, I assume so also.
> Added Chanwoo for more ideas.
OK, thanks.
Kevin
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-19 18:25 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-19 18:25 UTC (permalink / raw)
To: Chen-Yu Tsai, cw00.choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent. My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.
Well, that's the initial crash. But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.
> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.
Yes, I assume so also.
> Added Chanwoo for more ideas.
OK, thanks.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-19 18:25 ` Kevin Hilman
(?)
@ 2022-05-20 1:54 ` Chanwoo Choi
-1 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 1:54 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin, Chen-Yu,
On 5/20/22 3:25 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>
>>> Kevin Hilman <khilman@kernel.org> writes:
>>>
>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>
>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>
>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>
>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>
>>>>>> Change since v24:
>>>>>> - Rebase to Linux 5.18-rc6
>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>
>>>>>> Test in below environment:
>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>> HW: mt8183-Krane
>>>>>>
>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>
>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>> patch series:
>>>>>
>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>> maintainer)
>>>>> - MTK SVS driver series v25
>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>> - MTK CCI devfreq series v4
>>>>> - MT8183 cpufreq series v7
>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>
>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>
>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>> platform.
>>>>
>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>> that this is still not being handled properly.
>>>
>>> Ah, actually it's crashing when I try to boot the platform with
>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>> unstable upstream with the 2nd cluster enabled.)
This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
on devfreq passive governor.
If the cpufreq drivers are not probed before of probing cci devfreq driver
with passive governor, passive governor shows this warning message.
Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
in order to get 'struct cpufreq_policy'[2].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
[2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
But, as I knew, this message might not stop the kernel. Just show the warning
message and then return -EPROBE_DEFER error. It means that maybe try to
probe the cci devfreq driver on late time of kernel booting
and then will be working. But, I need the full kernel booting log
and the booting sequence of between cpufreq and cci devfreq driver.
In order to fix your issue, could you share the full booting log?
And if possible, please explain the more detailed something about this.
>>>
>>> The CCI driver should be a bit more robust about detecting
>>> available/online CPUs
>>
>> This all seems to be handled in the devfreq passive governor.
>
> Well, that's the initial crash. But the SVS driver will also go through
> its svs_mt8183_banks[] array (including both big & little clusters) and
> try to init SVS, so presumably that will have some problems also if only
> one cluster is enabled.
>
>> And presumably we'd like to have CCI devfreq running even if just one
>> core was booted.
>
> Yes, I assume so also.
>
>> Added Chanwoo for more ideas.
>
> OK, thanks.
>
> Kevin
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 1:54 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 1:54 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin, Chen-Yu,
On 5/20/22 3:25 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>
>>> Kevin Hilman <khilman@kernel.org> writes:
>>>
>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>
>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>
>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>
>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>
>>>>>> Change since v24:
>>>>>> - Rebase to Linux 5.18-rc6
>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>
>>>>>> Test in below environment:
>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>> HW: mt8183-Krane
>>>>>>
>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>
>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>> patch series:
>>>>>
>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>> maintainer)
>>>>> - MTK SVS driver series v25
>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>> - MTK CCI devfreq series v4
>>>>> - MT8183 cpufreq series v7
>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>
>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>
>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>> platform.
>>>>
>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>> that this is still not being handled properly.
>>>
>>> Ah, actually it's crashing when I try to boot the platform with
>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>> unstable upstream with the 2nd cluster enabled.)
This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
on devfreq passive governor.
If the cpufreq drivers are not probed before of probing cci devfreq driver
with passive governor, passive governor shows this warning message.
Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
in order to get 'struct cpufreq_policy'[2].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
[2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
But, as I knew, this message might not stop the kernel. Just show the warning
message and then return -EPROBE_DEFER error. It means that maybe try to
probe the cci devfreq driver on late time of kernel booting
and then will be working. But, I need the full kernel booting log
and the booting sequence of between cpufreq and cci devfreq driver.
In order to fix your issue, could you share the full booting log?
And if possible, please explain the more detailed something about this.
>>>
>>> The CCI driver should be a bit more robust about detecting
>>> available/online CPUs
>>
>> This all seems to be handled in the devfreq passive governor.
>
> Well, that's the initial crash. But the SVS driver will also go through
> its svs_mt8183_banks[] array (including both big & little clusters) and
> try to init SVS, so presumably that will have some problems also if only
> one cluster is enabled.
>
>> And presumably we'd like to have CCI devfreq running even if just one
>> core was booted.
>
> Yes, I assume so also.
>
>> Added Chanwoo for more ideas.
>
> OK, thanks.
>
> Kevin
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 1:54 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 1:54 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin, Chen-Yu,
On 5/20/22 3:25 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>
>>> Kevin Hilman <khilman@kernel.org> writes:
>>>
>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>
>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>
>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>
>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>
>>>>>> Change since v24:
>>>>>> - Rebase to Linux 5.18-rc6
>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>
>>>>>> Test in below environment:
>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>> HW: mt8183-Krane
>>>>>>
>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>
>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>> patch series:
>>>>>
>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>> maintainer)
>>>>> - MTK SVS driver series v25
>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>> - MTK CCI devfreq series v4
>>>>> - MT8183 cpufreq series v7
>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>
>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>
>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>> platform.
>>>>
>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>> that this is still not being handled properly.
>>>
>>> Ah, actually it's crashing when I try to boot the platform with
>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>> unstable upstream with the 2nd cluster enabled.)
This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
on devfreq passive governor.
If the cpufreq drivers are not probed before of probing cci devfreq driver
with passive governor, passive governor shows this warning message.
Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
in order to get 'struct cpufreq_policy'[2].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
[2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
But, as I knew, this message might not stop the kernel. Just show the warning
message and then return -EPROBE_DEFER error. It means that maybe try to
probe the cci devfreq driver on late time of kernel booting
and then will be working. But, I need the full kernel booting log
and the booting sequence of between cpufreq and cci devfreq driver.
In order to fix your issue, could you share the full booting log?
And if possible, please explain the more detailed something about this.
>>>
>>> The CCI driver should be a bit more robust about detecting
>>> available/online CPUs
>>
>> This all seems to be handled in the devfreq passive governor.
>
> Well, that's the initial crash. But the SVS driver will also go through
> its svs_mt8183_banks[] array (including both big & little clusters) and
> try to init SVS, so presumably that will have some problems also if only
> one cluster is enabled.
>
>> And presumably we'd like to have CCI devfreq running even if just one
>> core was booted.
>
> Yes, I assume so also.
>
>> Added Chanwoo for more ideas.
>
> OK, thanks.
>
> Kevin
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-20 1:54 ` Chanwoo Choi
(?)
@ 2022-05-20 2:42 ` Chen-Yu Tsai
-1 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-20 2:42 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin, Chen-Yu,
>
> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>
> >>> Kevin Hilman <khilman@kernel.org> writes:
> >>>
> >>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>
> >>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>
> >>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>
> >>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>
> >>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>
> >>>>>> Change since v24:
> >>>>>> - Rebase to Linux 5.18-rc6
> >>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>
> >>>>>> Test in below environment:
> >>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>> HW: mt8183-Krane
> >>>>>>
> >>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>
> >>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>> patch series:
> >>>>>
> >>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>> maintainer)
> >>>>> - MTK SVS driver series v25
> >>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>> - MTK CCI devfreq series v4
> >>>>> - MT8183 cpufreq series v7
> >>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>
> >>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>
> >>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>> platform.
> >>>>
> >>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>> that this is still not being handled properly.
> >>>
> >>> Ah, actually it's crashing when I try to boot the platform with
> >>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>> unstable upstream with the 2nd cluster enabled.)
>
> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> on devfreq passive governor.
>
> If the cpufreq drivers are not probed before of probing cci devfreq driver
> with passive governor, passive governor shows this warning message.
> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> in order to get 'struct cpufreq_policy'[2].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>
> But, as I knew, this message might not stop the kernel. Just show the warning
> message and then return -EPROBE_DEFER error. It means that maybe try to
> probe the cci devfreq driver on late time of kernel booting
> and then will be working. But, I need the full kernel booting log
> and the booting sequence of between cpufreq and cci devfreq driver.
Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
of panicking in developers' minds. :p
> In order to fix your issue, could you share the full booting log?
> And if possible, please explain the more detailed something about this.
The shortened version is that on an 8 core system, with maxcpus=4,
only the first four cores are booted and have cpufreq associated.
I've not actually used this mechanism, so I don't really know what
happens if the other cores are brought up later with hotplug. Is
cpufreq expected to attach to them?
Maybe Kevin can add some more details.
ChenYu
> >>>
> >>> The CCI driver should be a bit more robust about detecting
> >>> available/online CPUs
> >>
> >> This all seems to be handled in the devfreq passive governor.
> >
> > Well, that's the initial crash. But the SVS driver will also go through
> > its svs_mt8183_banks[] array (including both big & little clusters) and
> > try to init SVS, so presumably that will have some problems also if only
> > one cluster is enabled.
> >
> >> And presumably we'd like to have CCI devfreq running even if just one
> >> core was booted.
> >
> > Yes, I assume so also.
> >
> >> Added Chanwoo for more ideas.
> >
> > OK, thanks.
> >
> > Kevin
>
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 2:42 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-20 2:42 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin, Chen-Yu,
>
> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>
> >>> Kevin Hilman <khilman@kernel.org> writes:
> >>>
> >>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>
> >>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>
> >>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>
> >>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>
> >>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>
> >>>>>> Change since v24:
> >>>>>> - Rebase to Linux 5.18-rc6
> >>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>
> >>>>>> Test in below environment:
> >>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>> HW: mt8183-Krane
> >>>>>>
> >>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>
> >>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>> patch series:
> >>>>>
> >>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>> maintainer)
> >>>>> - MTK SVS driver series v25
> >>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>> - MTK CCI devfreq series v4
> >>>>> - MT8183 cpufreq series v7
> >>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>
> >>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>
> >>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>> platform.
> >>>>
> >>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>> that this is still not being handled properly.
> >>>
> >>> Ah, actually it's crashing when I try to boot the platform with
> >>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>> unstable upstream with the 2nd cluster enabled.)
>
> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> on devfreq passive governor.
>
> If the cpufreq drivers are not probed before of probing cci devfreq driver
> with passive governor, passive governor shows this warning message.
> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> in order to get 'struct cpufreq_policy'[2].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>
> But, as I knew, this message might not stop the kernel. Just show the warning
> message and then return -EPROBE_DEFER error. It means that maybe try to
> probe the cci devfreq driver on late time of kernel booting
> and then will be working. But, I need the full kernel booting log
> and the booting sequence of between cpufreq and cci devfreq driver.
Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
of panicking in developers' minds. :p
> In order to fix your issue, could you share the full booting log?
> And if possible, please explain the more detailed something about this.
The shortened version is that on an 8 core system, with maxcpus=4,
only the first four cores are booted and have cpufreq associated.
I've not actually used this mechanism, so I don't really know what
happens if the other cores are brought up later with hotplug. Is
cpufreq expected to attach to them?
Maybe Kevin can add some more details.
ChenYu
> >>>
> >>> The CCI driver should be a bit more robust about detecting
> >>> available/online CPUs
> >>
> >> This all seems to be handled in the devfreq passive governor.
> >
> > Well, that's the initial crash. But the SVS driver will also go through
> > its svs_mt8183_banks[] array (including both big & little clusters) and
> > try to init SVS, so presumably that will have some problems also if only
> > one cluster is enabled.
> >
> >> And presumably we'd like to have CCI devfreq running even if just one
> >> core was booted.
> >
> > Yes, I assume so also.
> >
> >> Added Chanwoo for more ideas.
> >
> > OK, thanks.
> >
> > Kevin
>
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 2:42 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-20 2:42 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin, Chen-Yu,
>
> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> > Chen-Yu Tsai <wenst@chromium.org> writes:
> >
> >> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>
> >>> Kevin Hilman <khilman@kernel.org> writes:
> >>>
> >>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>
> >>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>
> >>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>
> >>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>
> >>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>
> >>>>>> Change since v24:
> >>>>>> - Rebase to Linux 5.18-rc6
> >>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>
> >>>>>> Test in below environment:
> >>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>> HW: mt8183-Krane
> >>>>>>
> >>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>
> >>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>> patch series:
> >>>>>
> >>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>> maintainer)
> >>>>> - MTK SVS driver series v25
> >>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>> - MTK CCI devfreq series v4
> >>>>> - MT8183 cpufreq series v7
> >>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>
> >>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>
> >>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>> platform.
> >>>>
> >>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>> that this is still not being handled properly.
> >>>
> >>> Ah, actually it's crashing when I try to boot the platform with
> >>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>> unstable upstream with the 2nd cluster enabled.)
>
> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> on devfreq passive governor.
>
> If the cpufreq drivers are not probed before of probing cci devfreq driver
> with passive governor, passive governor shows this warning message.
> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> in order to get 'struct cpufreq_policy'[2].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>
> But, as I knew, this message might not stop the kernel. Just show the warning
> message and then return -EPROBE_DEFER error. It means that maybe try to
> probe the cci devfreq driver on late time of kernel booting
> and then will be working. But, I need the full kernel booting log
> and the booting sequence of between cpufreq and cci devfreq driver.
Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
of panicking in developers' minds. :p
> In order to fix your issue, could you share the full booting log?
> And if possible, please explain the more detailed something about this.
The shortened version is that on an 8 core system, with maxcpus=4,
only the first four cores are booted and have cpufreq associated.
I've not actually used this mechanism, so I don't really know what
happens if the other cores are brought up later with hotplug. Is
cpufreq expected to attach to them?
Maybe Kevin can add some more details.
ChenYu
> >>>
> >>> The CCI driver should be a bit more robust about detecting
> >>> available/online CPUs
> >>
> >> This all seems to be handled in the devfreq passive governor.
> >
> > Well, that's the initial crash. But the SVS driver will also go through
> > its svs_mt8183_banks[] array (including both big & little clusters) and
> > try to init SVS, so presumably that will have some problems also if only
> > one cluster is enabled.
> >
> >> And presumably we'd like to have CCI devfreq running even if just one
> >> core was booted.
> >
> > Yes, I assume so also.
> >
> >> Added Chanwoo for more ideas.
> >
> > OK, thanks.
> >
> > Kevin
>
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-20 2:42 ` Chen-Yu Tsai
(?)
@ 2022-05-20 3:12 ` Chanwoo Choi
-1 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 3:12 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
OK. I'll use dev_warn() instead of WARN_ON.
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
>>
>>
>> --
>> Best Regards,
>> Chanwoo Choi
>> Samsung Electronics
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 3:12 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 3:12 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
OK. I'll use dev_warn() instead of WARN_ON.
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
>>
>>
>> --
>> Best Regards,
>> Chanwoo Choi
>> Samsung Electronics
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 3:12 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 3:12 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
OK. I'll use dev_warn() instead of WARN_ON.
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
>>
>>
>> --
>> Best Regards,
>> Chanwoo Choi
>> Samsung Electronics
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-20 2:42 ` Chen-Yu Tsai
(?)
@ 2022-05-20 10:20 ` Chanwoo Choi
-1 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 10:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin,
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
I tested the passive governor with my temporary test code
on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
[Sequence of cpufreq/devfreq driver]
1. Turn on all cpus
2. Probed cpufreq driver
3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
In my test case, there are no warning message during kernel booting.
Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
temporary devfreq driver receives the notfication and then
calculate the target frequency of devfreq device by iterating online cpu.
If there are any h/w constraints on your case, please let me know.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 10:20 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 10:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin,
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
I tested the passive governor with my temporary test code
on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
[Sequence of cpufreq/devfreq driver]
1. Turn on all cpus
2. Probed cpufreq driver
3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
In my test case, there are no warning message during kernel booting.
Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
temporary devfreq driver receives the notfication and then
calculate the target frequency of devfreq device by iterating online cpu.
If there are any h/w constraints on your case, please let me know.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-20 10:20 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-20 10:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Hi Kevin,
On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin, Chen-Yu,
>>
>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>
>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>
>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>
>>>>>>>> Change since v24:
>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>
>>>>>>>> Test in below environment:
>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>> HW: mt8183-Krane
>>>>>>>>
>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>
>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>> patch series:
>>>>>>>
>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>> maintainer)
>>>>>>> - MTK SVS driver series v25
>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>> - MTK CCI devfreq series v4
>>>>>>> - MT8183 cpufreq series v7
>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>
>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>
>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>> platform.
>>>>>>
>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>> that this is still not being handled properly.
>>>>>
>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>> unstable upstream with the 2nd cluster enabled.)
>>
>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> on devfreq passive governor.
>>
>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> with passive governor, passive governor shows this warning message.
>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> in order to get 'struct cpufreq_policy'[2].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>
>> But, as I knew, this message might not stop the kernel. Just show the warning
>> message and then return -EPROBE_DEFER error. It means that maybe try to
>> probe the cci devfreq driver on late time of kernel booting
>> and then will be working. But, I need the full kernel booting log
>> and the booting sequence of between cpufreq and cci devfreq driver.
>
> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> of panicking in developers' minds. :p
>
>> In order to fix your issue, could you share the full booting log?
>> And if possible, please explain the more detailed something about this.
>
> The shortened version is that on an 8 core system, with maxcpus=4,
> only the first four cores are booted and have cpufreq associated.
> I've not actually used this mechanism, so I don't really know what
> happens if the other cores are brought up later with hotplug. Is
> cpufreq expected to attach to them?
>
> Maybe Kevin can add some more details.
>
>
> ChenYu
>
>
>>>>>
>>>>> The CCI driver should be a bit more robust about detecting
>>>>> available/online CPUs
>>>>
>>>> This all seems to be handled in the devfreq passive governor.
>>>
>>> Well, that's the initial crash. But the SVS driver will also go through
>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>> try to init SVS, so presumably that will have some problems also if only
>>> one cluster is enabled.
>>>
>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>> core was booted.
>>>
>>> Yes, I assume so also.
>>>
>>>> Added Chanwoo for more ideas.
>>>
>>> OK, thanks.
>>>
>>> Kevin
I tested the passive governor with my temporary test code
on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
[Sequence of cpufreq/devfreq driver]
1. Turn on all cpus
2. Probed cpufreq driver
3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
In my test case, there are no warning message during kernel booting.
Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
temporary devfreq driver receives the notfication and then
calculate the target frequency of devfreq device by iterating online cpu.
If there are any h/w constraints on your case, please let me know.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-20 10:20 ` Chanwoo Choi
(?)
@ 2022-05-24 6:17 ` Chen-Yu Tsai
-1 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-24 6:17 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin,
>
> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
> >>
> >> Hi Kevin, Chen-Yu,
> >>
> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>
> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>>>
> >>>>> Kevin Hilman <khilman@kernel.org> writes:
> >>>>>
> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>>>
> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>>>
> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>>>
> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>>>
> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>>>
> >>>>>>>> Change since v24:
> >>>>>>>> - Rebase to Linux 5.18-rc6
> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>>>
> >>>>>>>> Test in below environment:
> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>>>> HW: mt8183-Krane
> >>>>>>>>
> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>>>
> >>>>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>>>> patch series:
> >>>>>>>
> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>>>> maintainer)
> >>>>>>> - MTK SVS driver series v25
> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>>>> - MTK CCI devfreq series v4
> >>>>>>> - MT8183 cpufreq series v7
> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>>>
> >>>>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>>>
> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>>>> platform.
> >>>>>>
> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>>>> that this is still not being handled properly.
> >>>>>
> >>>>> Ah, actually it's crashing when I try to boot the platform with
> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>>>> unstable upstream with the 2nd cluster enabled.)
> >>
> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> >> on devfreq passive governor.
> >>
> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
> >> with passive governor, passive governor shows this warning message.
> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> >> in order to get 'struct cpufreq_policy'[2].
> >>
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
> >>
> >> But, as I knew, this message might not stop the kernel. Just show the warning
> >> message and then return -EPROBE_DEFER error. It means that maybe try to
> >> probe the cci devfreq driver on late time of kernel booting
> >> and then will be working. But, I need the full kernel booting log
> >> and the booting sequence of between cpufreq and cci devfreq driver.
> >
> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> > of panicking in developers' minds. :p
> >
> >> In order to fix your issue, could you share the full booting log?
> >> And if possible, please explain the more detailed something about this.
> >
> > The shortened version is that on an 8 core system, with maxcpus=4,
> > only the first four cores are booted and have cpufreq associated.
> > I've not actually used this mechanism, so I don't really know what
> > happens if the other cores are brought up later with hotplug. Is
> > cpufreq expected to attach to them?
> >
> > Maybe Kevin can add some more details.
> >
> >
> > ChenYu
> >
> >
> >>>>>
> >>>>> The CCI driver should be a bit more robust about detecting
> >>>>> available/online CPUs
> >>>>
> >>>> This all seems to be handled in the devfreq passive governor.
> >>>
> >>> Well, that's the initial crash. But the SVS driver will also go through
> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
> >>> try to init SVS, so presumably that will have some problems also if only
> >>> one cluster is enabled.
> >>>
> >>>> And presumably we'd like to have CCI devfreq running even if just one
> >>>> core was booted.
> >>>
> >>> Yes, I assume so also.
> >>>
> >>>> Added Chanwoo for more ideas.
> >>>
> >>> OK, thanks.
> >>>
> >>> Kevin
>
>
> I tested the passive governor with my temporary test code
> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>
>
> [Sequence of cpufreq/devfreq driver]
> 1. Turn on all cpus
> 2. Probed cpufreq driver
> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>
> In my test case, there are no warning message during kernel booting.
> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
> temporary devfreq driver receives the notfication and then
> calculate the target frequency of devfreq device by iterating online cpu.
>
> If there are any h/w constraints on your case, please let me know.
Could you run your system with maxcpus=4 added to your cmdline?
This is what Kevin was running.
The current result is that the latter four cores aren't booted, so no
cpufreq tied to them, and the passive governor will fail to get their
cpufreq_policy. As mentioned before, the code path used to have a
WARN_ON(). Now it's a dev_warn(). It will still fail initialization
though.
We're wondering if devfreq passive governor should be made to work
even if not all cpu cores are available when it probes.
Regards
ChenYu
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-24 6:17 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-24 6:17 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin,
>
> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
> >>
> >> Hi Kevin, Chen-Yu,
> >>
> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>
> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>>>
> >>>>> Kevin Hilman <khilman@kernel.org> writes:
> >>>>>
> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>>>
> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>>>
> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>>>
> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>>>
> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>>>
> >>>>>>>> Change since v24:
> >>>>>>>> - Rebase to Linux 5.18-rc6
> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>>>
> >>>>>>>> Test in below environment:
> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>>>> HW: mt8183-Krane
> >>>>>>>>
> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>>>
> >>>>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>>>> patch series:
> >>>>>>>
> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>>>> maintainer)
> >>>>>>> - MTK SVS driver series v25
> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>>>> - MTK CCI devfreq series v4
> >>>>>>> - MT8183 cpufreq series v7
> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>>>
> >>>>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>>>
> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>>>> platform.
> >>>>>>
> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>>>> that this is still not being handled properly.
> >>>>>
> >>>>> Ah, actually it's crashing when I try to boot the platform with
> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>>>> unstable upstream with the 2nd cluster enabled.)
> >>
> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> >> on devfreq passive governor.
> >>
> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
> >> with passive governor, passive governor shows this warning message.
> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> >> in order to get 'struct cpufreq_policy'[2].
> >>
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
> >>
> >> But, as I knew, this message might not stop the kernel. Just show the warning
> >> message and then return -EPROBE_DEFER error. It means that maybe try to
> >> probe the cci devfreq driver on late time of kernel booting
> >> and then will be working. But, I need the full kernel booting log
> >> and the booting sequence of between cpufreq and cci devfreq driver.
> >
> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> > of panicking in developers' minds. :p
> >
> >> In order to fix your issue, could you share the full booting log?
> >> And if possible, please explain the more detailed something about this.
> >
> > The shortened version is that on an 8 core system, with maxcpus=4,
> > only the first four cores are booted and have cpufreq associated.
> > I've not actually used this mechanism, so I don't really know what
> > happens if the other cores are brought up later with hotplug. Is
> > cpufreq expected to attach to them?
> >
> > Maybe Kevin can add some more details.
> >
> >
> > ChenYu
> >
> >
> >>>>>
> >>>>> The CCI driver should be a bit more robust about detecting
> >>>>> available/online CPUs
> >>>>
> >>>> This all seems to be handled in the devfreq passive governor.
> >>>
> >>> Well, that's the initial crash. But the SVS driver will also go through
> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
> >>> try to init SVS, so presumably that will have some problems also if only
> >>> one cluster is enabled.
> >>>
> >>>> And presumably we'd like to have CCI devfreq running even if just one
> >>>> core was booted.
> >>>
> >>> Yes, I assume so also.
> >>>
> >>>> Added Chanwoo for more ideas.
> >>>
> >>> OK, thanks.
> >>>
> >>> Kevin
>
>
> I tested the passive governor with my temporary test code
> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>
>
> [Sequence of cpufreq/devfreq driver]
> 1. Turn on all cpus
> 2. Probed cpufreq driver
> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>
> In my test case, there are no warning message during kernel booting.
> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
> temporary devfreq driver receives the notfication and then
> calculate the target frequency of devfreq device by iterating online cpu.
>
> If there are any h/w constraints on your case, please let me know.
Could you run your system with maxcpus=4 added to your cmdline?
This is what Kevin was running.
The current result is that the latter four cores aren't booted, so no
cpufreq tied to them, and the passive governor will fail to get their
cpufreq_policy. As mentioned before, the code path used to have a
WARN_ON(). Now it's a dev_warn(). It will still fail initialization
though.
We're wondering if devfreq passive governor should be made to work
even if not all cpu cores are available when it probes.
Regards
ChenYu
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-24 6:17 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-05-24 6:17 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Kevin Hilman, Roger Lu, Matthias Brugger, Enric Balletbo Serra,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>
> Hi Kevin,
>
> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
> >>
> >> Hi Kevin, Chen-Yu,
> >>
> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>
> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
> >>>>>
> >>>>> Kevin Hilman <khilman@kernel.org> writes:
> >>>>>
> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
> >>>>>>
> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
> >>>>>>>>
> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
> >>>>>>>>
> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
> >>>>>>>>
> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
> >>>>>>>>
> >>>>>>>> Change since v24:
> >>>>>>>> - Rebase to Linux 5.18-rc6
> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
> >>>>>>>>
> >>>>>>>> Test in below environment:
> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> >>>>>>>> HW: mt8183-Krane
> >>>>>>>>
> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
> >>>>>>>
> >>>>>>> I've updated my branch to include all the latest versions of the relevant
> >>>>>>> patch series:
> >>>>>>>
> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
> >>>>>>> maintainer)
> >>>>>>> - MTK SVS driver series v25
> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
> >>>>>>> - MTK CCI devfreq series v4
> >>>>>>> - MT8183 cpufreq series v7
> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
> >>>>>>
> >>>>>> Thanks for preparing an integration branch Chen-Yu.
> >>>>>>
> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
> >>>>>> platform.
> >>>>>>
> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
> >>>>>> that this is still not being handled properly.
> >>>>>
> >>>>> Ah, actually it's crashing when I try to boot the platform with
> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
> >>>>> unstable upstream with the 2nd cluster enabled.)
> >>
> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
> >> on devfreq passive governor.
> >>
> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
> >> with passive governor, passive governor shows this warning message.
> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
> >> in order to get 'struct cpufreq_policy'[2].
> >>
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
> >>
> >> But, as I knew, this message might not stop the kernel. Just show the warning
> >> message and then return -EPROBE_DEFER error. It means that maybe try to
> >> probe the cci devfreq driver on late time of kernel booting
> >> and then will be working. But, I need the full kernel booting log
> >> and the booting sequence of between cpufreq and cci devfreq driver.
> >
> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
> > of panicking in developers' minds. :p
> >
> >> In order to fix your issue, could you share the full booting log?
> >> And if possible, please explain the more detailed something about this.
> >
> > The shortened version is that on an 8 core system, with maxcpus=4,
> > only the first four cores are booted and have cpufreq associated.
> > I've not actually used this mechanism, so I don't really know what
> > happens if the other cores are brought up later with hotplug. Is
> > cpufreq expected to attach to them?
> >
> > Maybe Kevin can add some more details.
> >
> >
> > ChenYu
> >
> >
> >>>>>
> >>>>> The CCI driver should be a bit more robust about detecting
> >>>>> available/online CPUs
> >>>>
> >>>> This all seems to be handled in the devfreq passive governor.
> >>>
> >>> Well, that's the initial crash. But the SVS driver will also go through
> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
> >>> try to init SVS, so presumably that will have some problems also if only
> >>> one cluster is enabled.
> >>>
> >>>> And presumably we'd like to have CCI devfreq running even if just one
> >>>> core was booted.
> >>>
> >>> Yes, I assume so also.
> >>>
> >>>> Added Chanwoo for more ideas.
> >>>
> >>> OK, thanks.
> >>>
> >>> Kevin
>
>
> I tested the passive governor with my temporary test code
> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>
>
> [Sequence of cpufreq/devfreq driver]
> 1. Turn on all cpus
> 2. Probed cpufreq driver
> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>
> In my test case, there are no warning message during kernel booting.
> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
> temporary devfreq driver receives the notfication and then
> calculate the target frequency of devfreq device by iterating online cpu.
>
> If there are any h/w constraints on your case, please let me know.
Could you run your system with maxcpus=4 added to your cmdline?
This is what Kevin was running.
The current result is that the latter four cores aren't booted, so no
cpufreq tied to them, and the passive governor will fail to get their
cpufreq_policy. As mentioned before, the code path used to have a
WARN_ON(). Now it's a dev_warn(). It will still fail initialization
though.
We're wondering if devfreq passive governor should be made to work
even if not all cpu cores are available when it probes.
Regards
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-24 6:17 ` Chen-Yu Tsai
(?)
@ 2022-05-25 22:07 ` Kevin Hilman
-1 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-25 22:07 UTC (permalink / raw)
To: Chen-Yu Tsai, Chanwoo Choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin,
>>
>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>> >>
>> >> Hi Kevin, Chen-Yu,
>> >>
>> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>
>> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>> >>>>>
>> >>>>> Kevin Hilman <khilman@kernel.org> writes:
>> >>>>>
>> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>>>>
>> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>>>>>>
>> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>>>>>>
>> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>>>>>>
>> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>>>>>>
>> >>>>>>>> Change since v24:
>> >>>>>>>> - Rebase to Linux 5.18-rc6
>> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>>>>>>
>> >>>>>>>> Test in below environment:
>> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>>>>>>> HW: mt8183-Krane
>> >>>>>>>>
>> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>> >>>>>>>
>> >>>>>>> I've updated my branch to include all the latest versions of the relevant
>> >>>>>>> patch series:
>> >>>>>>>
>> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >>>>>>> maintainer)
>> >>>>>>> - MTK SVS driver series v25
>> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>> >>>>>>> - MTK CCI devfreq series v4
>> >>>>>>> - MT8183 cpufreq series v7
>> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
>> >>>>>>
>> >>>>>> Thanks for preparing an integration branch Chen-Yu.
>> >>>>>>
>> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>> >>>>>> platform.
>> >>>>>>
>> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
>> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>> >>>>>> that this is still not being handled properly.
>> >>>>>
>> >>>>> Ah, actually it's crashing when I try to boot the platform with
>> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> >>>>> unstable upstream with the 2nd cluster enabled.)
>> >>
>> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> >> on devfreq passive governor.
>> >>
>> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> >> with passive governor, passive governor shows this warning message.
>> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> >> in order to get 'struct cpufreq_policy'[2].
>> >>
>> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>> >>
>> >> But, as I knew, this message might not stop the kernel. Just show the warning
>> >> message and then return -EPROBE_DEFER error. It means that maybe try to
>> >> probe the cci devfreq driver on late time of kernel booting
>> >> and then will be working. But, I need the full kernel booting log
>> >> and the booting sequence of between cpufreq and cci devfreq driver.
>> >
>> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>> > of panicking in developers' minds. :p
>> >
>> >> In order to fix your issue, could you share the full booting log?
>> >> And if possible, please explain the more detailed something about this.
>> >
>> > The shortened version is that on an 8 core system, with maxcpus=4,
>> > only the first four cores are booted and have cpufreq associated.
>> > I've not actually used this mechanism, so I don't really know what
>> > happens if the other cores are brought up later with hotplug. Is
>> > cpufreq expected to attach to them?
>> >
>> > Maybe Kevin can add some more details.
>> >
>> >
>> > ChenYu
>> >
>> >
>> >>>>>
>> >>>>> The CCI driver should be a bit more robust about detecting
>> >>>>> available/online CPUs
>> >>>>
>> >>>> This all seems to be handled in the devfreq passive governor.
>> >>>
>> >>> Well, that's the initial crash. But the SVS driver will also go through
>> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
>> >>> try to init SVS, so presumably that will have some problems also if only
>> >>> one cluster is enabled.
>> >>>
>> >>>> And presumably we'd like to have CCI devfreq running even if just one
>> >>>> core was booted.
>> >>>
>> >>> Yes, I assume so also.
>> >>>
>> >>>> Added Chanwoo for more ideas.
>> >>>
>> >>> OK, thanks.
>> >>>
>> >>> Kevin
>>
>>
>> I tested the passive governor with my temporary test code
>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>
>>
>> [Sequence of cpufreq/devfreq driver]
>> 1. Turn on all cpus
>> 2. Probed cpufreq driver
>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>
>> In my test case, there are no warning message during kernel booting.
>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>> temporary devfreq driver receives the notfication and then
>> calculate the target frequency of devfreq device by iterating online cpu.
>>
>> If there are any h/w constraints on your case, please let me know.
>
> Could you run your system with maxcpus=4 added to your cmdline?
> This is what Kevin was running.
>
> The current result is that the latter four cores aren't booted, so no
> cpufreq tied to them, and the passive governor will fail to get their
> cpufreq_policy. As mentioned before, the code path used to have a
> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
> though.
>
> We're wondering if devfreq passive governor should be made to work
> even if not all cpu cores are available when it probes.
For info, here is a boot log[1] from mt8183-pumpkin board where I'm
testing Chen-Yu's lastest integration branch.
As Chen-Yu said, the part that makes it trigger the warn is disabling
some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
on the kernel command line.
Kevin
[1] https://termbin.com/zidi
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-25 22:07 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-25 22:07 UTC (permalink / raw)
To: Chen-Yu Tsai, Chanwoo Choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin,
>>
>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>> >>
>> >> Hi Kevin, Chen-Yu,
>> >>
>> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>
>> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>> >>>>>
>> >>>>> Kevin Hilman <khilman@kernel.org> writes:
>> >>>>>
>> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>>>>
>> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>>>>>>
>> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>>>>>>
>> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>>>>>>
>> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>>>>>>
>> >>>>>>>> Change since v24:
>> >>>>>>>> - Rebase to Linux 5.18-rc6
>> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>>>>>>
>> >>>>>>>> Test in below environment:
>> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>>>>>>> HW: mt8183-Krane
>> >>>>>>>>
>> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>> >>>>>>>
>> >>>>>>> I've updated my branch to include all the latest versions of the relevant
>> >>>>>>> patch series:
>> >>>>>>>
>> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >>>>>>> maintainer)
>> >>>>>>> - MTK SVS driver series v25
>> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>> >>>>>>> - MTK CCI devfreq series v4
>> >>>>>>> - MT8183 cpufreq series v7
>> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
>> >>>>>>
>> >>>>>> Thanks for preparing an integration branch Chen-Yu.
>> >>>>>>
>> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>> >>>>>> platform.
>> >>>>>>
>> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
>> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>> >>>>>> that this is still not being handled properly.
>> >>>>>
>> >>>>> Ah, actually it's crashing when I try to boot the platform with
>> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> >>>>> unstable upstream with the 2nd cluster enabled.)
>> >>
>> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> >> on devfreq passive governor.
>> >>
>> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> >> with passive governor, passive governor shows this warning message.
>> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> >> in order to get 'struct cpufreq_policy'[2].
>> >>
>> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>> >>
>> >> But, as I knew, this message might not stop the kernel. Just show the warning
>> >> message and then return -EPROBE_DEFER error. It means that maybe try to
>> >> probe the cci devfreq driver on late time of kernel booting
>> >> and then will be working. But, I need the full kernel booting log
>> >> and the booting sequence of between cpufreq and cci devfreq driver.
>> >
>> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>> > of panicking in developers' minds. :p
>> >
>> >> In order to fix your issue, could you share the full booting log?
>> >> And if possible, please explain the more detailed something about this.
>> >
>> > The shortened version is that on an 8 core system, with maxcpus=4,
>> > only the first four cores are booted and have cpufreq associated.
>> > I've not actually used this mechanism, so I don't really know what
>> > happens if the other cores are brought up later with hotplug. Is
>> > cpufreq expected to attach to them?
>> >
>> > Maybe Kevin can add some more details.
>> >
>> >
>> > ChenYu
>> >
>> >
>> >>>>>
>> >>>>> The CCI driver should be a bit more robust about detecting
>> >>>>> available/online CPUs
>> >>>>
>> >>>> This all seems to be handled in the devfreq passive governor.
>> >>>
>> >>> Well, that's the initial crash. But the SVS driver will also go through
>> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
>> >>> try to init SVS, so presumably that will have some problems also if only
>> >>> one cluster is enabled.
>> >>>
>> >>>> And presumably we'd like to have CCI devfreq running even if just one
>> >>>> core was booted.
>> >>>
>> >>> Yes, I assume so also.
>> >>>
>> >>>> Added Chanwoo for more ideas.
>> >>>
>> >>> OK, thanks.
>> >>>
>> >>> Kevin
>>
>>
>> I tested the passive governor with my temporary test code
>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>
>>
>> [Sequence of cpufreq/devfreq driver]
>> 1. Turn on all cpus
>> 2. Probed cpufreq driver
>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>
>> In my test case, there are no warning message during kernel booting.
>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>> temporary devfreq driver receives the notfication and then
>> calculate the target frequency of devfreq device by iterating online cpu.
>>
>> If there are any h/w constraints on your case, please let me know.
>
> Could you run your system with maxcpus=4 added to your cmdline?
> This is what Kevin was running.
>
> The current result is that the latter four cores aren't booted, so no
> cpufreq tied to them, and the passive governor will fail to get their
> cpufreq_policy. As mentioned before, the code path used to have a
> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
> though.
>
> We're wondering if devfreq passive governor should be made to work
> even if not all cpu cores are available when it probes.
For info, here is a boot log[1] from mt8183-pumpkin board where I'm
testing Chen-Yu's lastest integration branch.
As Chen-Yu said, the part that makes it trigger the warn is disabling
some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
on the kernel command line.
Kevin
[1] https://termbin.com/zidi
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-25 22:07 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-05-25 22:07 UTC (permalink / raw)
To: Chen-Yu Tsai, Chanwoo Choi
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
Chen-Yu Tsai <wenst@chromium.org> writes:
> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>
>> Hi Kevin,
>>
>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>> > On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>> >>
>> >> Hi Kevin, Chen-Yu,
>> >>
>> >> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>> >>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>
>> >>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>> >>>>>
>> >>>>> Kevin Hilman <khilman@kernel.org> writes:
>> >>>>>
>> >>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>> >>>>>>
>> >>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>>>>>>
>> >>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>>>>>>
>> >>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>>>>>>
>> >>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>>>>>>
>> >>>>>>>> Change since v24:
>> >>>>>>>> - Rebase to Linux 5.18-rc6
>> >>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>>>>>>
>> >>>>>>>> Test in below environment:
>> >>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>>>>>>> HW: mt8183-Krane
>> >>>>>>>>
>> >>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>> >>>>>>>
>> >>>>>>> I've updated my branch to include all the latest versions of the relevant
>> >>>>>>> patch series:
>> >>>>>>>
>> >>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>> >>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >>>>>>> maintainer)
>> >>>>>>> - MTK SVS driver series v25
>> >>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>> >>>>>>> - MTK CCI devfreq series v4
>> >>>>>>> - MT8183 cpufreq series v7
>> >>>>>>> - Additional WIP patches for panfrost MTK devfreq
>> >>>>>>
>> >>>>>> Thanks for preparing an integration branch Chen-Yu.
>> >>>>>>
>> >>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> >>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>> >>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>> >>>>>> platform.
>> >>>>>>
>> >>>>>> I mentioned in earlier reviews that I think there's potentially a race
>> >>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>> >>>>>> that this is still not being handled properly.
>> >>>>>
>> >>>>> Ah, actually it's crashing when I try to boot the platform with
>> >>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> >>>>> unstable upstream with the 2nd cluster enabled.)
>> >>
>> >> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>> >> on devfreq passive governor.
>> >>
>> >> If the cpufreq drivers are not probed before of probing cci devfreq driver
>> >> with passive governor, passive governor shows this warning message.
>> >> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>> >> in order to get 'struct cpufreq_policy'[2].
>> >>
>> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>> >>
>> >> But, as I knew, this message might not stop the kernel. Just show the warning
>> >> message and then return -EPROBE_DEFER error. It means that maybe try to
>> >> probe the cci devfreq driver on late time of kernel booting
>> >> and then will be working. But, I need the full kernel booting log
>> >> and the booting sequence of between cpufreq and cci devfreq driver.
>> >
>> > Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>> > of panicking in developers' minds. :p
>> >
>> >> In order to fix your issue, could you share the full booting log?
>> >> And if possible, please explain the more detailed something about this.
>> >
>> > The shortened version is that on an 8 core system, with maxcpus=4,
>> > only the first four cores are booted and have cpufreq associated.
>> > I've not actually used this mechanism, so I don't really know what
>> > happens if the other cores are brought up later with hotplug. Is
>> > cpufreq expected to attach to them?
>> >
>> > Maybe Kevin can add some more details.
>> >
>> >
>> > ChenYu
>> >
>> >
>> >>>>>
>> >>>>> The CCI driver should be a bit more robust about detecting
>> >>>>> available/online CPUs
>> >>>>
>> >>>> This all seems to be handled in the devfreq passive governor.
>> >>>
>> >>> Well, that's the initial crash. But the SVS driver will also go through
>> >>> its svs_mt8183_banks[] array (including both big & little clusters) and
>> >>> try to init SVS, so presumably that will have some problems also if only
>> >>> one cluster is enabled.
>> >>>
>> >>>> And presumably we'd like to have CCI devfreq running even if just one
>> >>>> core was booted.
>> >>>
>> >>> Yes, I assume so also.
>> >>>
>> >>>> Added Chanwoo for more ideas.
>> >>>
>> >>> OK, thanks.
>> >>>
>> >>> Kevin
>>
>>
>> I tested the passive governor with my temporary test code
>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>
>>
>> [Sequence of cpufreq/devfreq driver]
>> 1. Turn on all cpus
>> 2. Probed cpufreq driver
>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>
>> In my test case, there are no warning message during kernel booting.
>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>> temporary devfreq driver receives the notfication and then
>> calculate the target frequency of devfreq device by iterating online cpu.
>>
>> If there are any h/w constraints on your case, please let me know.
>
> Could you run your system with maxcpus=4 added to your cmdline?
> This is what Kevin was running.
>
> The current result is that the latter four cores aren't booted, so no
> cpufreq tied to them, and the passive governor will fail to get their
> cpufreq_policy. As mentioned before, the code path used to have a
> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
> though.
>
> We're wondering if devfreq passive governor should be made to work
> even if not all cpu cores are available when it probes.
For info, here is a boot log[1] from mt8183-pumpkin board where I'm
testing Chen-Yu's lastest integration branch.
As Chen-Yu said, the part that makes it trigger the warn is disabling
some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
on the kernel command line.
Kevin
[1] https://termbin.com/zidi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-25 22:07 ` Kevin Hilman
(?)
@ 2022-05-31 5:55 ` Chanwoo Choi
-1 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-31 5:55 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/26/22 7:07 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>
>>> Hi Kevin,
>>>
>>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>>>> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>>>
>>>>> Hi Kevin, Chen-Yu,
>>>>>
>>>>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>>>>
>>>>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>>>>
>>>>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>>>>
>>>>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>>>>
>>>>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>>>>
>>>>>>>>>>> Change since v24:
>>>>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>>>>
>>>>>>>>>>> Test in below environment:
>>>>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>>>>> HW: mt8183-Krane
>>>>>>>>>>>
>>>>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>>>>
>>>>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>>>>> patch series:
>>>>>>>>>>
>>>>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>>>>> maintainer)
>>>>>>>>>> - MTK SVS driver series v25
>>>>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>>>>> - MTK CCI devfreq series v4
>>>>>>>>>> - MT8183 cpufreq series v7
>>>>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>>>>
>>>>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>>>>
>>>>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>>>>> that this is still not being handled properly.
>>>>>>>>
>>>>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>>>>> unstable upstream with the 2nd cluster enabled.)
>>>>>
>>>>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>>>>> on devfreq passive governor.
>>>>>
>>>>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>>>>> with passive governor, passive governor shows this warning message.
>>>>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>>>>> in order to get 'struct cpufreq_policy'[2].
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>>>>
>>>>> But, as I knew, this message might not stop the kernel. Just show the warning
>>>>> message and then return -EPROBE_DEFER error. It means that maybe try to
>>>>> probe the cci devfreq driver on late time of kernel booting
>>>>> and then will be working. But, I need the full kernel booting log
>>>>> and the booting sequence of between cpufreq and cci devfreq driver.
>>>>
>>>> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>>>> of panicking in developers' minds. :p
>>>>
>>>>> In order to fix your issue, could you share the full booting log?
>>>>> And if possible, please explain the more detailed something about this.
>>>>
>>>> The shortened version is that on an 8 core system, with maxcpus=4,
>>>> only the first four cores are booted and have cpufreq associated.
>>>> I've not actually used this mechanism, so I don't really know what
>>>> happens if the other cores are brought up later with hotplug. Is
>>>> cpufreq expected to attach to them?
>>>>
>>>> Maybe Kevin can add some more details.
>>>>
>>>>
>>>> ChenYu
>>>>
>>>>
>>>>>>>>
>>>>>>>> The CCI driver should be a bit more robust about detecting
>>>>>>>> available/online CPUs
>>>>>>>
>>>>>>> This all seems to be handled in the devfreq passive governor.
>>>>>>
>>>>>> Well, that's the initial crash. But the SVS driver will also go through
>>>>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>>>>> try to init SVS, so presumably that will have some problems also if only
>>>>>> one cluster is enabled.
>>>>>>
>>>>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>>>>> core was booted.
>>>>>>
>>>>>> Yes, I assume so also.
>>>>>>
>>>>>>> Added Chanwoo for more ideas.
>>>>>>
>>>>>> OK, thanks.
>>>>>>
>>>>>> Kevin
>>>
>>>
>>> I tested the passive governor with my temporary test code
>>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>>
>>>
>>> [Sequence of cpufreq/devfreq driver]
>>> 1. Turn on all cpus
>>> 2. Probed cpufreq driver
>>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>>
>>> In my test case, there are no warning message during kernel booting.
>>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>>> temporary devfreq driver receives the notfication and then
>>> calculate the target frequency of devfreq device by iterating online cpu.
>>>
>>> If there are any h/w constraints on your case, please let me know.
>>
>> Could you run your system with maxcpus=4 added to your cmdline?
>> This is what Kevin was running.
>>
>> The current result is that the latter four cores aren't booted, so no
>> cpufreq tied to them, and the passive governor will fail to get their
>> cpufreq_policy. As mentioned before, the code path used to have a
>> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
>> though.
>>
>> We're wondering if devfreq passive governor should be made to work
>> even if not all cpu cores are available when it probes.
>
> For info, here is a boot log[1] from mt8183-pumpkin board where I'm
> testing Chen-Yu's lastest integration branch.
>
> As Chen-Yu said, the part that makes it trigger the warn is disabling
> some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
> on the kernel command line.
>
> Kevin
>
> [1] https://protect2.fireeye.com/v1/url?k=05bb8eea-64309bc5-05ba05a5-74fe485cbfe7-9281bdbd13e5cf90&q=1&e=8ab47ff1-daee-4db3-a26d-6fc652568a44&u=https%3A%2F%2Ftermbin.com%2Fzidi
>
>
When using 'maxcpus=' on my test board, I got the warning message.
I'm fixing it and then send the patch. Thanks for the test.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-31 5:55 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-31 5:55 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/26/22 7:07 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>
>>> Hi Kevin,
>>>
>>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>>>> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>>>
>>>>> Hi Kevin, Chen-Yu,
>>>>>
>>>>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>>>>
>>>>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>>>>
>>>>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>>>>
>>>>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>>>>
>>>>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>>>>
>>>>>>>>>>> Change since v24:
>>>>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>>>>
>>>>>>>>>>> Test in below environment:
>>>>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>>>>> HW: mt8183-Krane
>>>>>>>>>>>
>>>>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>>>>
>>>>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>>>>> patch series:
>>>>>>>>>>
>>>>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>>>>> maintainer)
>>>>>>>>>> - MTK SVS driver series v25
>>>>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>>>>> - MTK CCI devfreq series v4
>>>>>>>>>> - MT8183 cpufreq series v7
>>>>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>>>>
>>>>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>>>>
>>>>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>>>>> that this is still not being handled properly.
>>>>>>>>
>>>>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>>>>> unstable upstream with the 2nd cluster enabled.)
>>>>>
>>>>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>>>>> on devfreq passive governor.
>>>>>
>>>>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>>>>> with passive governor, passive governor shows this warning message.
>>>>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>>>>> in order to get 'struct cpufreq_policy'[2].
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>>>>
>>>>> But, as I knew, this message might not stop the kernel. Just show the warning
>>>>> message and then return -EPROBE_DEFER error. It means that maybe try to
>>>>> probe the cci devfreq driver on late time of kernel booting
>>>>> and then will be working. But, I need the full kernel booting log
>>>>> and the booting sequence of between cpufreq and cci devfreq driver.
>>>>
>>>> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>>>> of panicking in developers' minds. :p
>>>>
>>>>> In order to fix your issue, could you share the full booting log?
>>>>> And if possible, please explain the more detailed something about this.
>>>>
>>>> The shortened version is that on an 8 core system, with maxcpus=4,
>>>> only the first four cores are booted and have cpufreq associated.
>>>> I've not actually used this mechanism, so I don't really know what
>>>> happens if the other cores are brought up later with hotplug. Is
>>>> cpufreq expected to attach to them?
>>>>
>>>> Maybe Kevin can add some more details.
>>>>
>>>>
>>>> ChenYu
>>>>
>>>>
>>>>>>>>
>>>>>>>> The CCI driver should be a bit more robust about detecting
>>>>>>>> available/online CPUs
>>>>>>>
>>>>>>> This all seems to be handled in the devfreq passive governor.
>>>>>>
>>>>>> Well, that's the initial crash. But the SVS driver will also go through
>>>>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>>>>> try to init SVS, so presumably that will have some problems also if only
>>>>>> one cluster is enabled.
>>>>>>
>>>>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>>>>> core was booted.
>>>>>>
>>>>>> Yes, I assume so also.
>>>>>>
>>>>>>> Added Chanwoo for more ideas.
>>>>>>
>>>>>> OK, thanks.
>>>>>>
>>>>>> Kevin
>>>
>>>
>>> I tested the passive governor with my temporary test code
>>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>>
>>>
>>> [Sequence of cpufreq/devfreq driver]
>>> 1. Turn on all cpus
>>> 2. Probed cpufreq driver
>>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>>
>>> In my test case, there are no warning message during kernel booting.
>>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>>> temporary devfreq driver receives the notfication and then
>>> calculate the target frequency of devfreq device by iterating online cpu.
>>>
>>> If there are any h/w constraints on your case, please let me know.
>>
>> Could you run your system with maxcpus=4 added to your cmdline?
>> This is what Kevin was running.
>>
>> The current result is that the latter four cores aren't booted, so no
>> cpufreq tied to them, and the passive governor will fail to get their
>> cpufreq_policy. As mentioned before, the code path used to have a
>> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
>> though.
>>
>> We're wondering if devfreq passive governor should be made to work
>> even if not all cpu cores are available when it probes.
>
> For info, here is a boot log[1] from mt8183-pumpkin board where I'm
> testing Chen-Yu's lastest integration branch.
>
> As Chen-Yu said, the part that makes it trigger the warn is disabling
> some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
> on the kernel command line.
>
> Kevin
>
> [1] https://protect2.fireeye.com/v1/url?k=05bb8eea-64309bc5-05ba05a5-74fe485cbfe7-9281bdbd13e5cf90&q=1&e=8ab47ff1-daee-4db3-a26d-6fc652568a44&u=https%3A%2F%2Ftermbin.com%2Fzidi
>
>
When using 'maxcpus=' on my test board, I got the warning message.
I'm fixing it and then send the patch. Thanks for the test.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-05-31 5:55 ` Chanwoo Choi
0 siblings, 0 replies; 71+ messages in thread
From: Chanwoo Choi @ 2022-05-31 5:55 UTC (permalink / raw)
To: Kevin Hilman, Chen-Yu Tsai
Cc: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel, Fan Chen,
Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang, Rex-BC Chen (陳柏辰)
On 5/26/22 7:07 AM, Kevin Hilman wrote:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Fri, May 20, 2022 at 5:53 PM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>
>>> Hi Kevin,
>>>
>>> On 5/20/22 11:42 AM, Chen-Yu Tsai wrote:
>>>> On Fri, May 20, 2022 at 9:28 AM Chanwoo Choi <cw00.choi@samsung.com> wrote:
>>>>>
>>>>> Hi Kevin, Chen-Yu,
>>>>>
>>>>> On 5/20/22 3:25 AM, Kevin Hilman wrote:
>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>
>>>>>>> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>>>>>>>
>>>>>>>> Kevin Hilman <khilman@kernel.org> writes:
>>>>>>>>
>>>>>>>>> Chen-Yu Tsai <wenst@chromium.org> writes:
>>>>>>>>>
>>>>>>>>>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>>>>>>>>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>>>>>>>>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>>>>>>>>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>>>>>>>>>
>>>>>>>>>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>>>>>>>>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>>>>>>>>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>>>>>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>>>>>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>>>>>>>>>
>>>>>>>>>>> Change since v24:
>>>>>>>>>>> - Rebase to Linux 5.18-rc6
>>>>>>>>>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>>>>>>>>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>>>>>>>>>
>>>>>>>>>>> Test in below environment:
>>>>>>>>>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>>>>>>>>>> HW: mt8183-Krane
>>>>>>>>>>>
>>>>>>>>>>> [4] https://protect2.fireeye.com/v1/url?k=847bae75-e5f0bb43-847a253a-000babff9b5d-0b6f42041b9dea1d&q=1&e=37a26c43-8564-4808-9701-dc76d1ebbb27&u=https%3A%2F%2Fgithub.com%2Fwens%2Flinux%2Fcommits%2Fmt8183-cpufreq-cci-svs-test
>>>>>>>>>>
>>>>>>>>>> I've updated my branch to include all the latest versions of the relevant
>>>>>>>>>> patch series:
>>>>>>>>>>
>>>>>>>>>> - anx7625 DPI bus type series v2 (so the display works)
>>>>>>>>>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>>>>>>>>>> maintainer)
>>>>>>>>>> - MTK SVS driver series v25
>>>>>>>>>> - devfreq: cpu based scaling support to passive governor series v5
>>>>>>>>>> - MTK CCI devfreq series v4
>>>>>>>>>> - MT8183 cpufreq series v7
>>>>>>>>>> - Additional WIP patches for panfrost MTK devfreq
>>>>>>>>>
>>>>>>>>> Thanks for preparing an integration branch Chen-Yu.
>>>>>>>>>
>>>>>>>>> I'm testing this on mt8183-pumpkin with one patch to add the CCI
>>>>>>>>> regulator[1], and the defconfig you posted in a previous rev of this
>>>>>>>>> series, but the CCI driver still causes a fault on boot[2] on my
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> I mentioned in earlier reviews that I think there's potentially a race
>>>>>>>>> between CCI and SVS loading since they are co-dependent. My hunch is
>>>>>>>>> that this is still not being handled properly.
>>>>>>>>
>>>>>>>> Ah, actually it's crashing when I try to boot the platform with
>>>>>>>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>>>>>>>> unstable upstream with the 2nd cluster enabled.)
>>>>>
>>>>> This warning message is printed by 'WARN_ON(cpufreq_passive_unregister_notifier(devfreq))'
>>>>> on devfreq passive governor.
>>>>>
>>>>> If the cpufreq drivers are not probed before of probing cci devfreq driver
>>>>> with passive governor, passive governor shows this warning message.
>>>>> Because passive governor with CPUFREQ_PARENT_DEV depends on the cpufreq driver
>>>>> in order to get 'struct cpufreq_policy'[2].
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n339
>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/tree/drivers/devfreq/governor_passive.c?h=devfreq-testing#n282
>>>>>
>>>>> But, as I knew, this message might not stop the kernel. Just show the warning
>>>>> message and then return -EPROBE_DEFER error. It means that maybe try to
>>>>> probe the cci devfreq driver on late time of kernel booting
>>>>> and then will be working. But, I need the full kernel booting log
>>>>> and the booting sequence of between cpufreq and cci devfreq driver.
>>>>
>>>> Maybe just use a standard dev_warn() instead? WARN_ON causes all sorts
>>>> of panicking in developers' minds. :p
>>>>
>>>>> In order to fix your issue, could you share the full booting log?
>>>>> And if possible, please explain the more detailed something about this.
>>>>
>>>> The shortened version is that on an 8 core system, with maxcpus=4,
>>>> only the first four cores are booted and have cpufreq associated.
>>>> I've not actually used this mechanism, so I don't really know what
>>>> happens if the other cores are brought up later with hotplug. Is
>>>> cpufreq expected to attach to them?
>>>>
>>>> Maybe Kevin can add some more details.
>>>>
>>>>
>>>> ChenYu
>>>>
>>>>
>>>>>>>>
>>>>>>>> The CCI driver should be a bit more robust about detecting
>>>>>>>> available/online CPUs
>>>>>>>
>>>>>>> This all seems to be handled in the devfreq passive governor.
>>>>>>
>>>>>> Well, that's the initial crash. But the SVS driver will also go through
>>>>>> its svs_mt8183_banks[] array (including both big & little clusters) and
>>>>>> try to init SVS, so presumably that will have some problems also if only
>>>>>> one cluster is enabled.
>>>>>>
>>>>>>> And presumably we'd like to have CCI devfreq running even if just one
>>>>>>> core was booted.
>>>>>>
>>>>>> Yes, I assume so also.
>>>>>>
>>>>>>> Added Chanwoo for more ideas.
>>>>>>
>>>>>> OK, thanks.
>>>>>>
>>>>>> Kevin
>>>
>>>
>>> I tested the passive governor with my temporary test code
>>> on odroid-xu3 which contains the big.LITTLE cluster (Octa-core).
>>>
>>>
>>> [Sequence of cpufreq/devfreq driver]
>>> 1. Turn on all cpus
>>> 2. Probed cpufreq driver
>>> 3. Probed devfreq driver using passive governor with CPUFREQ_PARENT_DEV
>>>
>>> In my test case, there are no warning message during kernel booting.
>>> Also when scaling the cpu frequency of cpus of big.LITTLE clusters,
>>> temporary devfreq driver receives the notfication and then
>>> calculate the target frequency of devfreq device by iterating online cpu.
>>>
>>> If there are any h/w constraints on your case, please let me know.
>>
>> Could you run your system with maxcpus=4 added to your cmdline?
>> This is what Kevin was running.
>>
>> The current result is that the latter four cores aren't booted, so no
>> cpufreq tied to them, and the passive governor will fail to get their
>> cpufreq_policy. As mentioned before, the code path used to have a
>> WARN_ON(). Now it's a dev_warn(). It will still fail initialization
>> though.
>>
>> We're wondering if devfreq passive governor should be made to work
>> even if not all cpu cores are available when it probes.
>
> For info, here is a boot log[1] from mt8183-pumpkin board where I'm
> testing Chen-Yu's lastest integration branch.
>
> As Chen-Yu said, the part that makes it trigger the warn is disabling
> some of the CPUs *at boot time*. In this case, I'm passing `maxcpus=4`
> on the kernel command line.
>
> Kevin
>
> [1] https://protect2.fireeye.com/v1/url?k=05bb8eea-64309bc5-05ba05a5-74fe485cbfe7-9281bdbd13e5cf90&q=1&e=8ab47ff1-daee-4db3-a26d-6fc652568a44&u=https%3A%2F%2Ftermbin.com%2Fzidi
>
>
When using 'maxcpus=' on my test board, I got the warning message.
I'm fixing it and then send the patch. Thanks for the test.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-06-06 10:05 ` Chen-Yu Tsai
-1 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-06-06 10:05 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-06-06 10:05 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-06-06 10:05 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-06-06 10:05 ` Chen-Yu Tsai
0 siblings, 0 replies; 71+ messages in thread
From: Chen-Yu Tsai @ 2022-06-06 10:05 UTC (permalink / raw)
To: Roger Lu
Cc: Matthias Brugger, Enric Balletbo Serra, Kevin Hilman,
Rob Herring, Nicolas Boichat, Stephen Boyd, Philipp Zabel,
Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-16 0:43 ` Roger Lu
(?)
@ 2022-06-08 9:33 ` Kevin Hilman
-1 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-06-08 9:33 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Roger Lu <roger.lu@mediatek.com> writes:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
Tested-by: Kevin Hilman <khilman@baylibre.com>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-06-08 9:33 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-06-08 9:33 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Roger Lu <roger.lu@mediatek.com> writes:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
Tested-by: Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-06-08 9:33 ` Kevin Hilman
0 siblings, 0 replies; 71+ messages in thread
From: Kevin Hilman @ 2022-06-08 9:33 UTC (permalink / raw)
To: Roger Lu, Matthias Brugger, Enric Balletbo Serra, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
Roger Lu, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-pm, Project_Global_Chrome_Upstream_Group,
Guenter Roeck, Jia-wei Chang
Roger Lu <roger.lu@mediatek.com> writes:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
Tested-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
2022-05-16 0:43 ` Roger Lu
@ 2022-06-17 8:53 ` Matthias Brugger
-1 siblings, 0 replies; 71+ messages in thread
From: Matthias Brugger @ 2022-06-17 8:53 UTC (permalink / raw)
To: Roger Lu, Enric Balletbo Serra, Kevin Hilman, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On 16/05/2022 02:43, Roger Lu wrote:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
Whole series applied to v5.19-next/soc and v5.19-next/dts64
Thanks to all people involved!
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
@ 2022-06-17 8:53 ` Matthias Brugger
0 siblings, 0 replies; 71+ messages in thread
From: Matthias Brugger @ 2022-06-17 8:53 UTC (permalink / raw)
To: Roger Lu, Enric Balletbo Serra, Kevin Hilman, Rob Herring,
Nicolas Boichat, Stephen Boyd, Philipp Zabel
Cc: Fan Chen, Charles Yang, Angus Lin, Mark Rutland, Nishanth Menon,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
linux-pm, Project_Global_Chrome_Upstream_Group, Guenter Roeck,
Jia-wei Chang
On 16/05/2022 02:43, Roger Lu wrote:
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculates suitable SVS bank voltages to OPP voltage table.
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
Whole series applied to v5.19-next/soc and v5.19-next/dts64
Thanks to all people involved!
>
> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>
> Change since v24:
> - Rebase to Linux 5.18-rc6
> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>
> Test in below environment:
> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
> HW: mt8183-Krane
>
> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
> [5] https://patchwork.kernel.org/project/linux-pm/patch/20210820095206.30981-1-ben.tseng@mediatek.com
>
> Boots up log:
> [ 4.447369] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x02f3010b
> [ 4.447623] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x151f2830~0x363a4046, DC:0x02f90141
> [ 4.447872] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x141a232b~0x30363d42, DC:0x02ed00d5
> [ 4.448119] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416171a~0x1d202327, DC:0x02f7012f
> [ 4.448239] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1b252d35~0x3a3e4349, DC:0x02f30000
> [ 4.448343] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1c262f37~0x3d41474d, DC:0x02f90000
> [ 4.448400] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1b212a32~0x373d4449, DC:0x02ed0000
> [ 4.448499] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x1618191c~0x1f222529, DC:0x02f70000
>
> SVS commands log:
> localhost ~ # cat /sys/kernel/debug/svs/*/*
> init2
> SVSB_CCI: temperature ignore, turn_pt = 0
> opp_freq[00]: 1196000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1144000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 96
> opp_freq[02]: 1092000000, opp_volt[02]: 937500, svsb_volt[02]: 0x46, freq_pct[02]: 92
> opp_freq[03]: 1027000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 86
> opp_freq[04]: 962000000, opp_volt[04]: 893750, svsb_volt[04]: 0x3f, freq_pct[04]: 81
> opp_freq[05]: 923000000, opp_volt[05]: 881250, svsb_volt[05]: 0x3d, freq_pct[05]: 78
> opp_freq[06]: 871000000, opp_volt[06]: 856250, svsb_volt[06]: 0x39, freq_pct[06]: 73
> opp_freq[07]: 845000000, opp_volt[07]: 850000, svsb_volt[07]: 0x38, freq_pct[07]: 71
> opp_freq[08]: 767000000, opp_volt[08]: 825000, svsb_volt[08]: 0x34, freq_pct[08]: 65
> opp_freq[09]: 689000000, opp_volt[09]: 800000, svsb_volt[09]: 0x30, freq_pct[09]: 58
> opp_freq[10]: 624000000, opp_volt[10]: 775000, svsb_volt[10]: 0x2c, freq_pct[10]: 53
> opp_freq[11]: 546000000, opp_volt[11]: 750000, svsb_volt[11]: 0x28, freq_pct[11]: 46
> opp_freq[12]: 463000000, opp_volt[12]: 718750, svsb_volt[12]: 0x23, freq_pct[12]: 39
> opp_freq[13]: 403000000, opp_volt[13]: 700000, svsb_volt[13]: 0x20, freq_pct[13]: 34
> opp_freq[14]: 338000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 29
> opp_freq[15]: 273000000, opp_volt[15]: 650000, svsb_volt[15]: 0x1a, freq_pct[15]: 23
> init2
> SVSB_CPU_BIG: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 1050000, svsb_volt[00]: 0x59, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 1025000, svsb_volt[01]: 0x57, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 1000000, svsb_volt[02]: 0x53, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 975000, svsb_volt[03]: 0x50, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 950000, svsb_volt[04]: 0x4d, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 931250, svsb_volt[05]: 0x4c, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 912500, svsb_volt[06]: 0x49, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 900000, svsb_volt[07]: 0x47, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 875000, svsb_volt[08]: 0x43, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 850000, svsb_volt[09]: 0x40, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 825000, svsb_volt[10]: 0x3b, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 800000, svsb_volt[11]: 0x38, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 775000, svsb_volt[12]: 0x32, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 750000, svsb_volt[13]: 0x2d, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 725000, svsb_volt[14]: 0x28, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 700000, svsb_volt[15]: 0x23, freq_pct[15]: 40
> init2
> SVSB_CPU_LITTLE: temperature ignore, turn_pt = 0
> opp_freq[00]: 1989000000, opp_volt[00]: 968750, svsb_volt[00]: 0x4b, freq_pct[00]: 100
> opp_freq[01]: 1924000000, opp_volt[01]: 956250, svsb_volt[01]: 0x49, freq_pct[01]: 97
> opp_freq[02]: 1846000000, opp_volt[02]: 931250, svsb_volt[02]: 0x45, freq_pct[02]: 93
> opp_freq[03]: 1781000000, opp_volt[03]: 918750, svsb_volt[03]: 0x43, freq_pct[03]: 90
> opp_freq[04]: 1716000000, opp_volt[04]: 900000, svsb_volt[04]: 0x40, freq_pct[04]: 87
> opp_freq[05]: 1677000000, opp_volt[05]: 893750, svsb_volt[05]: 0x3f, freq_pct[05]: 85
> opp_freq[06]: 1625000000, opp_volt[06]: 875000, svsb_volt[06]: 0x3c, freq_pct[06]: 82
> opp_freq[07]: 1586000000, opp_volt[07]: 868750, svsb_volt[07]: 0x3b, freq_pct[07]: 80
> opp_freq[08]: 1508000000, opp_volt[08]: 843750, svsb_volt[08]: 0x37, freq_pct[08]: 76
> opp_freq[09]: 1417000000, opp_volt[09]: 825000, svsb_volt[09]: 0x34, freq_pct[09]: 72
> opp_freq[10]: 1326000000, opp_volt[10]: 793750, svsb_volt[10]: 0x2f, freq_pct[10]: 67
> opp_freq[11]: 1248000000, opp_volt[11]: 775000, svsb_volt[11]: 0x2c, freq_pct[11]: 63
> opp_freq[12]: 1131000000, opp_volt[12]: 743750, svsb_volt[12]: 0x27, freq_pct[12]: 57
> opp_freq[13]: 1014000000, opp_volt[13]: 712500, svsb_volt[13]: 0x22, freq_pct[13]: 51
> opp_freq[14]: 910000000, opp_volt[14]: 681250, svsb_volt[14]: 0x1d, freq_pct[14]: 46
> opp_freq[15]: 793000000, opp_volt[15]: 650000, svsb_volt[15]: 0x18, freq_pct[15]: 40
> mon mode
> SVSB_GPU: temperature = 33492, turn_pt = 0
> opp_freq[00]: 800000000, opp_volt[00]: 743750, svsb_volt[00]: 0x27, freq_pct[00]: 100
> opp_freq[01]: 743000000, opp_volt[01]: 731250, svsb_volt[01]: 0x25, freq_pct[01]: 93
> opp_freq[02]: 698000000, opp_volt[02]: 718750, svsb_volt[02]: 0x23, freq_pct[02]: 88
> opp_freq[03]: 653000000, opp_volt[03]: 712500, svsb_volt[03]: 0x22, freq_pct[03]: 82
> opp_freq[04]: 620000000, opp_volt[04]: 700000, svsb_volt[04]: 0x20, freq_pct[04]: 78
> opp_freq[05]: 580000000, opp_volt[05]: 693750, svsb_volt[05]: 0x1f, freq_pct[05]: 73
> opp_freq[06]: 540000000, opp_volt[06]: 681250, svsb_volt[06]: 0x1d, freq_pct[06]: 68
> opp_freq[07]: 500000000, opp_volt[07]: 675000, svsb_volt[07]: 0x1c, freq_pct[07]: 63
> opp_freq[08]: 460000000, opp_volt[08]: 662500, svsb_volt[08]: 0x1a, freq_pct[08]: 58
> opp_freq[09]: 420000000, opp_volt[09]: 656250, svsb_volt[09]: 0x19, freq_pct[09]: 53
> opp_freq[10]: 400000000, opp_volt[10]: 643750, svsb_volt[10]: 0x17, freq_pct[10]: 50
> opp_freq[11]: 380000000, opp_volt[11]: 643750, svsb_volt[11]: 0x17, freq_pct[11]: 48
> opp_freq[12]: 360000000, opp_volt[12]: 637500, svsb_volt[12]: 0x16, freq_pct[12]: 45
> opp_freq[13]: 340000000, opp_volt[13]: 637500, svsb_volt[13]: 0x16, freq_pct[13]: 43
> opp_freq[14]: 320000000, opp_volt[14]: 625000, svsb_volt[14]: 0x14, freq_pct[14]: 40
> opp_freq[15]: 300000000, opp_volt[15]: 625000, svsb_volt[15]: 0x14, freq_pct[15]: 38
>
> Roger Lu (7):
> [v25,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
> [v25,2/7] arm64: dts: mt8183: add svs device information
> [v25,3/7] soc: mediatek: SVS: introduce MTK SVS engine
> [v25,4/7] soc: mediatek: SVS: add monitor mode
> [v25,5/7] soc: mediatek: SVS: add debug commands
> [v25,6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
> [v25,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
>
> .../bindings/soc/mediatek/mtk-svs.yaml | 91 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 +
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-svs.c | 2399 +++++++++++++++++
> 5 files changed, 2517 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2022-06-17 8:58 UTC | newest]
Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-16 0:43 [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 2/7] arm64: dts: mt8183: add svs device information Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 5/7] soc: mediatek: SVS: add debug commands Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-17 10:04 ` [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Chen-Yu Tsai
2022-05-17 10:04 ` Chen-Yu Tsai
2022-05-17 10:04 ` Chen-Yu Tsai
2022-05-17 22:59 ` Kevin Hilman
2022-05-17 22:59 ` Kevin Hilman
2022-05-17 22:59 ` Kevin Hilman
2022-05-18 0:03 ` Kevin Hilman
2022-05-18 0:03 ` Kevin Hilman
2022-05-18 0:03 ` Kevin Hilman
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-19 18:25 ` Kevin Hilman
2022-05-19 18:25 ` Kevin Hilman
2022-05-19 18:25 ` Kevin Hilman
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-25 22:07 ` Kevin Hilman
2022-05-25 22:07 ` Kevin Hilman
2022-05-25 22:07 ` Kevin Hilman
2022-05-31 5:55 ` Chanwoo Choi
2022-05-31 5:55 ` Chanwoo Choi
2022-05-31 5:55 ` Chanwoo Choi
2022-05-18 2:57 ` Rex-BC Chen
2022-05-18 2:57 ` Rex-BC Chen
2022-05-18 2:57 ` Rex-BC Chen
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-08 9:33 ` Kevin Hilman
2022-06-08 9:33 ` Kevin Hilman
2022-06-08 9:33 ` Kevin Hilman
2022-06-17 8:53 ` Matthias Brugger
2022-06-17 8:53 ` Matthias Brugger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.