Re: [PATCH v24 0/7] soc: mediatek: SVS: introduce MTK SVS
From: Chen-Yu Tsai
Date: Tue Apr 26 2022 - 03:16:05 EST
On Fri, Apr 22, 2022 at 11:38 PM Matthias Brugger
> On 22/04/2022 04:24, Roger Lu wrote:
> > Hi Kevin,
> > On Thu, 2022-04-21 at 12:41 -0700, Kevin Hilman wrote:
> >> Hi Roger,
> >> Roger Lu <roger.lu@xxxxxxxxxxxx> writes:
> >>> On Wed, 2022-04-20 at 16:22 -0700, Kevin Hilman wrote:
> >> [...]
> >>>> That being said, it would be really nice to see an integration tree
> >>>> where this was all tested on mainline (e.g. v5.17, or v5.18-rc)
> >>>> For example, I can apply this to v5.18-rc2 and boot on my mt8183-pumpkin
> >>>> board, it fails to probe because there is no CCI node in the upstream
> >>>> mt8183.dtsi.
> >>>> I'm assuming this series is also not very useful without the CPUfreq
> >>>> series from Rex, so being able to test this, CCI and CPUfreq together on
> >>>> MT8183 on a mainline kernel would be very helpful.
> >>>> Kevin
> >>>> 
> >>>> [ 0.573332] mtk-svs 1100b000.svs: cannot find cci node
> >>>> [ 0.574061] mtk-svs 1100b000.svs: error -ENODEV: svs platform probe
> >>>> fail
> >>> Just share. I've tested this series on below two platforms and it works as
> >>> expected.
> >>> - mt8183-Krane (kernel-v5.10)
> >>> - mt8192-Hayato (kernel-v5.4)
> >> Unfortunately testing on v5.4 and v5.10 with lots of other additional
> >> out-of-tree patches does not give much confidence that this series works
> >> with upstream, especially when I've given a few reasons why it will not
> >> work uptream.
> >> The examples I gave above for CCI and CPUs/cluster disable are good
> >> examples, but another one I forgot to mention is the dependency on Mali.
> >> The SVS driver will never probe because it also depens on a "mali" node,
> >> which doesn't exist upstream either (but panfrost does, and acutually
> >> loads/probes fine on v5.17/v5.18) so this should be fixed to work with
> >> upstream panfrost.
> >> IMO, in order for this to be merged upstream, it should at least have
> >> some basic validation with upstream, and so far I have not even been
> >> able to make it successfuly probe. To do that, you will need to either
> >> provide a list of the dependencies for testing this with mainline
> >> (e.g. CCI series, CPUfreq series, any DT changes), or even better, an
> >> integration tree based on recent mainline (e.g. v5.17 stable, or
> >> v5.18-rc) which shows all the patches (in addition to this series) used
> >> to validate this on mainline.
> > No problem. We'll find a machine that can be run correctly with recent mainline
> > (e.g. v5.17 stable, or v5.18-rc) and add patches (CCI series + CPUfreq series +
> > any DT changes) to test this SVS series. Thanks very much.
> Thanks Roger. I'll wait until this got tested with upstream Linux, before I will
> apply all the patches.
I've put together an integration test branch:
This branch is based on next-20220422 and includes the following series:
- ANX7625 DPI support v2
- MTK SVS v24
- MTK cpufreq v4
- PM / devfreq core patches from
PM / devfreq: Export devfreq_get_freq_range symbol within devfreq
PM / devfreq: Add cpu based scaling support to passive governor
PM / devfreq: passive: Reduce duplicate code when passive_devfreq case
PM / devfreq: passive: Update frequency when start governor
- CCI devfreq v2
And some patches of my own to fix some errors. See the last handful of
patches including and after the fixup! one.
This was tested on Juniper (Acer Chromebook Spin 311) that has MT8183.
Looking at the mcu_*_sel clocks from /sys/kernel/debug/clk/clk_summary ,
it does seem like things are happening, though I'm not sure how to
thoroughly test this, especially SVS.
Hope this unblocks things for everyone involved.