Chen-Yu Tsai <wenst@xxxxxxxxxxxx> writes: > On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@xxxxxxxxxxxx> 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 ]------------
