mbox series

[v25,0/7] soc: mediatek: SVS: introduce MTK SVS

Message ID 20220516004311.18358-1-roger.lu@mediatek.com (mailing list archive)
Headers show
Series soc: mediatek: SVS: introduce MTK SVS | expand

Message

Roger Lu May 16, 2022, 12:43 a.m. UTC
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

Comments

Chen-Yu Tsai May 17, 2022, 10:04 a.m. UTC | #1
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
Kevin Hilman May 17, 2022, 10:59 p.m. UTC | #2
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 ]------------
Kevin Hilman May 18, 2022, 12:03 a.m. UTC | #3
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
Rex-BC Chen (陳柏辰) May 18, 2022, 2:57 a.m. UTC | #4
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
Chen-Yu Tsai May 18, 2022, 4:17 a.m. UTC | #5
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
Kevin Hilman May 19, 2022, 6:25 p.m. UTC | #6
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
Chanwoo Choi May 20, 2022, 1:54 a.m. UTC | #7
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
Chen-Yu Tsai May 20, 2022, 2:42 a.m. UTC | #8
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
Chanwoo Choi May 20, 2022, 3:12 a.m. UTC | #9
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
> 
>
Chanwoo Choi May 20, 2022, 10:20 a.m. UTC | #10
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.
Chen-Yu Tsai May 24, 2022, 6:17 a.m. UTC | #11
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
Kevin Hilman May 25, 2022, 10:07 p.m. UTC | #12
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
Chanwoo Choi May 31, 2022, 5:55 a.m. UTC | #13
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.
Chen-Yu Tsai June 6, 2022, 10:05 a.m. UTC | #14
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>
Kevin Hilman June 8, 2022, 9:33 a.m. UTC | #15
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>
Matthias Brugger June 17, 2022, 8:53 a.m. UTC | #16
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
> 
>