From: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, Roger Lu <roger.lu@mediatek.com>
Cc: "Matthias Brugger" <matthias.bgg@gmail.com>,
"Enric Balletbo Serra" <eballetbo@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Nicolas Boichat" <drinkcat@google.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Fan Chen" <fan.chen@mediatek.com>,
"Charles Yang" <Charles.Yang@mediatek.com>,
"Angus Lin" <Angus.Lin@mediatek.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Nishanth Menon" <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
"Guenter Roeck" <linux@roeck-us.net>,
"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Tue, 17 May 2022 17:03:40 -0700 [thread overview]
Message-ID: <7hy1yzbtb7.fsf@baylibre.com> (raw)
In-Reply-To: <7h4k1ndaui.fsf@baylibre.com>
Kevin Hilman <khilman@kernel.org> writes:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>
>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>
>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>
>>> Change since v24:
>>> - Rebase to Linux 5.18-rc6
>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>
>>> Test in below environment:
>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>> HW: mt8183-Krane
>>>
>>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>>
>> I've updated my branch to include all the latest versions of the relevant
>> patch series:
>>
>> - anx7625 DPI bus type series v2 (so the display works)
>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> maintainer)
>> - MTK SVS driver series v25
>> - devfreq: cpu based scaling support to passive governor series v5
>> - MTK CCI devfreq series v4
>> - MT8183 cpufreq series v7
>> - Additional WIP patches for panfrost MTK devfreq
>
> Thanks for preparing an integration branch Chen-Yu.
>
> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> regulator[1], and the defconfig you posted in a previous rev of this
> series, but the CCI driver still causes a fault on boot[2] on my
> platform.
>
> I mentioned in earlier reviews that I think there's potentially a race
> between CCI and SVS loading since they are co-dependent. My hunch is
> that this is still not being handled properly.
Ah, actually it's crashing when I try to boot the platform with
`maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
unstable upstream with the 2nd cluster enabled.)
The CCI driver should be a bit more robust about detecting
available/online CPUs
If I boot with both clusters, I see SVS probing[1], and I see CCI
doing transitions[2]
Kevin
[1]
# dmesg |grep -i svs
[ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
[ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
[ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
[ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
[ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
[ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
[ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
[ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
[ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
[ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
[ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
[ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
[ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
[ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
[ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
[ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
[ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
[ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
[ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
[ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
[ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
[ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
[ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
[2]
# cat /sys/class/devfreq/cci/trans_stat
From : To
: 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
* 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
Total transition : 1810
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, Roger Lu <roger.lu@mediatek.com>
Cc: "Matthias Brugger" <matthias.bgg@gmail.com>,
"Enric Balletbo Serra" <eballetbo@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Nicolas Boichat" <drinkcat@google.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Fan Chen" <fan.chen@mediatek.com>,
"Charles Yang" <Charles.Yang@mediatek.com>,
"Angus Lin" <Angus.Lin@mediatek.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Nishanth Menon" <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
"Guenter Roeck" <linux@roeck-us.net>,
"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Tue, 17 May 2022 17:03:40 -0700 [thread overview]
Message-ID: <7hy1yzbtb7.fsf@baylibre.com> (raw)
In-Reply-To: <7h4k1ndaui.fsf@baylibre.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, Roger Lu <roger.lu@mediatek.com>
Cc: "Matthias Brugger" <matthias.bgg@gmail.com>,
"Enric Balletbo Serra" <eballetbo@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Nicolas Boichat" <drinkcat@google.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Fan Chen" <fan.chen@mediatek.com>,
"Charles Yang" <Charles.Yang@mediatek.com>,
"Angus Lin" <Angus.Lin@mediatek.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Nishanth Menon" <nm@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group@mediatek.com,
"Guenter Roeck" <linux@roeck-us.net>,
"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Tue, 17 May 2022 17:03:40 -0700 [thread overview]
Message-ID: <7hy1yzbtb7.fsf@baylibre.com> (raw)
In-Reply-To: <7h4k1ndaui.fsf@baylibre.com>
Kevin Hilman <khilman@kernel.org> writes:
> Chen-Yu Tsai <wenst@chromium.org> writes:
>
>> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>>>
>>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>>> which calculates suitable SVS bank voltages to OPP voltage table.
>>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>>>
>>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>>>
>>> Change since v24:
>>> - Rebase to Linux 5.18-rc6
>>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>>>
>>> Test in below environment:
>>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>>> HW: mt8183-Krane
>>>
>>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>>
>> I've updated my branch to include all the latest versions of the relevant
>> patch series:
>>
>> - anx7625 DPI bus type series v2 (so the display works)
>> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> maintainer)
>> - MTK SVS driver series v25
>> - devfreq: cpu based scaling support to passive governor series v5
>> - MTK CCI devfreq series v4
>> - MT8183 cpufreq series v7
>> - Additional WIP patches for panfrost MTK devfreq
>
> Thanks for preparing an integration branch Chen-Yu.
>
> I'm testing this on mt8183-pumpkin with one patch to add the CCI
> regulator[1], and the defconfig you posted in a previous rev of this
> series, but the CCI driver still causes a fault on boot[2] on my
> platform.
>
> I mentioned in earlier reviews that I think there's potentially a race
> between CCI and SVS loading since they are co-dependent. My hunch is
> that this is still not being handled properly.
Ah, actually it's crashing when I try to boot the platform with
`maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
unstable upstream with the 2nd cluster enabled.)
The CCI driver should be a bit more robust about detecting
available/online CPUs
If I boot with both clusters, I see SVS probing[1], and I see CCI
doing transitions[2]
Kevin
[1]
# dmesg |grep -i svs
[ 0.739298] mtk-svs 1100b000.svs: M_HW_RES0: 0x00120090
[ 0.739315] mtk-svs 1100b000.svs: M_HW_RES1: 0xa6fdfb5b
[ 0.739318] mtk-svs 1100b000.svs: M_HW_RES2: 0x47cb47cb
[ 0.739321] mtk-svs 1100b000.svs: M_HW_RES3: 0xa6fdfb5b
[ 0.739324] mtk-svs 1100b000.svs: M_HW_RES4: 0xa6fde4ad
[ 0.739326] mtk-svs 1100b000.svs: M_HW_RES5: 0x47f84b80
[ 0.739328] mtk-svs 1100b000.svs: M_HW_RES6: 0xa6fd87a6
[ 0.739331] mtk-svs 1100b000.svs: M_HW_RES7: 0xa6fddf4a
[ 0.739333] mtk-svs 1100b000.svs: M_HW_RES8: 0x4bf84be5
[ 0.739335] mtk-svs 1100b000.svs: M_HW_RES9: 0xa6fd3267
[ 0.739338] mtk-svs 1100b000.svs: M_HW_RES14: 0x9696d5ab
[ 0.739340] mtk-svs 1100b000.svs: M_HW_RES15: 0x015a0015
[ 0.739343] mtk-svs 1100b000.svs: M_HW_RES16: 0xa6fdf05d
[ 0.739345] mtk-svs 1100b000.svs: M_HW_RES17: 0x47f847e5
[ 0.739347] mtk-svs 1100b000.svs: M_HW_RES18: 0xa6fdc240
[ 0.741890] SVSB_CPU_LITTLE: svs_init01_isr_handler: VDN74~30:0x141c242a~0x2f32373c, DC:0x0316ff30
[ 0.742165] SVSB_CPU_BIG: svs_init01_isr_handler: VDN74~30:0x141e262e~0x33373c42, DC:0x031aff50
[ 0.742431] SVSB_CCI: svs_init01_isr_handler: VDN74~30:0x13192128~0x2d31383c, DC:0x0314ff20
[ 0.742696] SVSB_GPU: svs_init01_isr_handler: VDN74~30:0x1416181a~0x1d202428, DC:0x030efef0
[ 0.742875] SVSB_CPU_LITTLE: svs_init02_isr_handler: VOP74~30:0x1d252c33~0x373b3f45, DC:0x031600d0
[ 0.742989] SVSB_CPU_BIG: svs_init02_isr_handler: VOP74~30:0x1d262e36~0x3b3f444a, DC:0x031a00b0
[ 0.743060] SVSB_CCI: svs_init02_isr_handler: VOP74~30:0x1c222a31~0x353a4045, DC:0x031400e0
[ 0.743176] SVSB_GPU: svs_init02_isr_handler: VOP74~30:0x181a1c1e~0x2125282c, DC:0x030e0110
[2]
# cat /sys/class/devfreq/cci/trans_stat
From : To
: 273000000 338000000 403000000 463000000 546000000 624000000 689000000 767000000 845000000 871000000 923000000 9620000001027000000109200000011440000001196000000 time(ms)
273000000: 0 77 11 10 34 8 6 8 3 3 0 0 4 1 2 12 135675
338000000: 90 0 32 4 7 2 1 0 0 0 0 0 0 0 0 2 664
403000000: 20 45 0 35 7 2 0 0 0 0 0 0 0 0 0 0 509
463000000: 13 7 53 0 46 4 1 1 1 2 0 1 2 0 0 1 568
546000000: 12 5 10 63 0 55 3 3 3 1 3 2 8 3 1 35 858
* 624000000: 4 0 2 10 50 0 49 1 1 0 0 1 3 2 0 7 407
689000000: 6 1 0 2 18 36 0 47 5 3 1 0 1 0 0 10 388
767000000: 2 1 0 3 5 11 42 0 35 4 1 1 2 0 1 23 486
845000000: 3 0 0 0 1 0 9 27 0 37 8 1 0 0 2 23 290
871000000: 2 0 0 1 0 0 3 9 19 0 29 5 1 1 1 12 179
923000000: 0 0 0 0 0 2 2 7 10 13 0 31 1 1 0 4 154
962000000: 0 0 0 0 0 1 0 4 3 4 14 0 27 1 0 2 123
1027000000: 2 0 0 1 2 2 3 2 1 1 7 11 0 24 2 1 182
1092000000: 1 0 0 0 3 2 0 1 2 0 0 1 5 0 25 5 123
1144000000: 2 0 0 0 0 0 0 0 2 0 1 1 2 7 0 38 193
1196000000: 22 2 1 3 34 6 11 21 26 15 7 1 3 5 19 0 1621
Total transition : 1810
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-18 0:03 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 0:43 [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 2/7] arm64: dts: mt8183: add svs device information Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 5/7] soc: mediatek: SVS: add debug commands Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-16 0:43 ` Roger Lu
2022-05-17 10:04 ` [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Chen-Yu Tsai
2022-05-17 10:04 ` Chen-Yu Tsai
2022-05-17 10:04 ` Chen-Yu Tsai
2022-05-17 22:59 ` Kevin Hilman
2022-05-17 22:59 ` Kevin Hilman
2022-05-17 22:59 ` Kevin Hilman
2022-05-18 0:03 ` Kevin Hilman [this message]
2022-05-18 0:03 ` Kevin Hilman
2022-05-18 0:03 ` Kevin Hilman
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-18 4:17 ` Chen-Yu Tsai
2022-05-19 18:25 ` Kevin Hilman
2022-05-19 18:25 ` Kevin Hilman
2022-05-19 18:25 ` Kevin Hilman
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 1:54 ` Chanwoo Choi
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 2:42 ` Chen-Yu Tsai
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 3:12 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-20 10:20 ` Chanwoo Choi
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-24 6:17 ` Chen-Yu Tsai
2022-05-25 22:07 ` Kevin Hilman
2022-05-25 22:07 ` Kevin Hilman
2022-05-25 22:07 ` Kevin Hilman
2022-05-31 5:55 ` Chanwoo Choi
2022-05-31 5:55 ` Chanwoo Choi
2022-05-31 5:55 ` Chanwoo Choi
2022-05-18 2:57 ` Rex-BC Chen
2022-05-18 2:57 ` Rex-BC Chen
2022-05-18 2:57 ` Rex-BC Chen
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-08 9:33 ` Kevin Hilman
2022-06-08 9:33 ` Kevin Hilman
2022-06-08 9:33 ` Kevin Hilman
2022-06-17 8:53 ` Matthias Brugger
2022-06-17 8:53 ` Matthias Brugger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hy1yzbtb7.fsf@baylibre.com \
--to=khilman@kernel.org \
--cc=Angus.Lin@mediatek.com \
--cc=Charles.Yang@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@google.com \
--cc=eballetbo@gmail.com \
--cc=fan.chen@mediatek.com \
--cc=jia-wei.chang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=nm@ti.com \
--cc=p.zabel@pengutronix.de \
--cc=rex-bc.chen@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=roger.lu@mediatek.com \
--cc=sboyd@kernel.org \
--cc=wenst@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.