I checked the 5.10 version of linux-image-armmp, the cpufreq of am335x can work normally, so there should be a problem with the upstream.
Yu-Tung Chang <mtw...@gmail.com> 于2022年6月23日周四 16:27写道： > > Yu-Tung Chang <mtw...@gmail.com> 于2022年6月23日周四 16:21写道： > > > > Yu-Tung Chang <mtw...@gmail.com> 于2022年6月23日周四 16:12写道： > > > > > > Yu-Tung Chang <mtw...@gmail.com> 于2022年6月23日周四 16:08写道： > > > > > > > > Diederik de Haas <didi.deb...@cknow.org> 于2022年6月22日周三 22:17写道： > > > > > > > > > > Control: tag -1 help > > > > > > > > > > On Monday, 20 June 2022 10:09:45 CEST Yu-Tung Chang wrote: > > > > > > https://lore.kernel.org/linux-arm-kernel/5143369...@ti.com/T/ > > > > > > https://www.spinics.net/lists/linux-omap/msg138794.html > > > > > > > > > > > > Read the link above, ARM_OMAP2PLUS_CPUFREQ is not available for DT > > > > > > Boot Systems and has been deprecated > > > > > > > > > > The 1st link is from 2013 and is quite inconclusive. It talks about > > > > > changes > > > > > which should be implemented in a v2 of the patch set. > > > > > And a *plan* to convert all boards to use DT. > > > > > > > > > > The reply to the 2nd link is this: > > > > > "Hmm I thought we should be only using CONFIG_ARM_TI_CPUFREQ > > > > > with device tree only booting? What's missing from that to > > > > > be able to drop ARM_OMAP2PLUS_CPUFREQ?" > > > > > > > > > > And then it stops. > > > > > So while it seems to (somewhat) agree with you, it's still > > > > > inconclusive. > > > > > > > > > > The fact that ARM_OMAP2PLUS_CPUFREQ is still present in 5.19-rc3 > > > > > shows that > > > > > the 'conversion process' has not been implemented or at least > > > > > finished. > > > > > > > > > > If you're right and ARM_OMAP2PLUS_CPUFREQ should be deleted, then > > > > > that should > > > > > (first) happen upstream. > > > > > > > > > > > > Yu-Tung Chang <mtw...@gmail.com> 于2022年6月20日周一 16:02写道： > > > > > > > > > > > > > > I am doing further testing, It is now certain that > > > > > > > ARM_OMAP2PLUS_CPUFREQ > > > > > > > is not set in arch/arm/configs/omap2plus_defconfig. > > > > > > > > > > That is true. That file has the following line: > > > > > # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set > > > > > > > > > > It doesn't have ARM_TI_CPUFREQ at all though. > > > > > > > > > > > > > On Thursday, 16 June 2022 12:16:46 CEST Yu-Tung Chang wrote: > > > > > > > > > Package: linux-image-armmp > > > > > > > > > Version: 5.18.0-1 > > > > > > > > > > > > > > > > > > enable omap2plus_cpufreq causes ti_cpufreq to not work, and > > > > > > > > > omap2plus_cpufreq is no longer used in linux. > > > > > > > > > > It may be deprecated, according to you, but it is still present in the > > > > > 5.19-rc3 source code, so "is no longer used in linux" seems to be > > > > > false. > > > > > > > > > > > > > I went looking in (upstream)'s code and what I could find was > > > > > > > > this: > > > > > > > > > > > > > > > > ~/dev/kernel.org/linux$ grep -A4 "config ARM_OMAP2PLUS_CPUFREQ" > > > > > > > > drivers/cpufreq/Kconfig.arm > > > > > > > > config ARM_OMAP2PLUS_CPUFREQ > > > > > > > > > > > > > > > > bool "TI OMAP2+" > > > > > > > > depends on ARCH_OMAP2PLUS > > > > > > > > default ARCH_OMAP2PLUS > > > > > > > > > > > > > > > > ~/dev/kernel.org/linux$ grep -A11 "config ARM_TI_CPUFREQ" > > > > > > > > drivers/cpufreq/Kconfig.arm > > > > > > > > config ARM_TI_CPUFREQ > > > > > > > > > > > > > > > > bool "Texas Instruments CPUFreq support" > > > > > > > > depends on ARCH_OMAP2PLUS > > > > > > > > default ARCH_OMAP2PLUS > > > > > > > > help > > > > > > > > > > > > > > > > This driver enables valid OPPs on the running platform > > > > > > > > based on values contained within the SoC in use. > > > > > > > > Enable this in order to use the cpufreq-dt driver on > > > > > > > > all > > > > > > > > Texas Instruments platforms that provide dt based > > > > > > > > operating-points-v2 tables with opp-supported-hw > > > > > > > > data provided. Required for cpufreq support on AM335x, > > > > > > > > AM437x, DRA7x, and AM57x platforms. > > > > > > > > > > > > > > > > I interpreted your bug report as they would be mutually > > > > > > > > exclusive, > > > > > > > > but that's far from what _I_ understand of the above Kconfig > > > > > > > > options. > > > > > > > > > > Both modules 'depend on' and 'default to the value of' ARCH_OMAP2PLUS. > > > > > If those modules indeed prevent each others working, then it would > > > > > help if > > > > > those symbols weren't 'bool', but 'tristate' so that they can be > > > > > build as > > > > > module and then one can load one and blacklist the other. > > > > > That is also something that upstream should decide. > > > > > > > > > But after "make omap2plus_defconfig", ARM_TI_CPUFREQ in .config will > > > > be enabled, while ARM_OMAP2PLUS_CPUFREQ will not. > > > Although I found no explicit dependencies in the source tree. > > > > > While what you said about omap2plus_defconfig is true, Debian doesn't > > > > > use that > > > > > file but has ~ 1 config file for all armhf boards. > > > > > > > > > > From ``debian/config/armhf/config`` the > > > > > ``arch/arm/mach-omap2/Kconfig`` section: > > > > > # CONFIG_ARCH_OMAP2 is not set > > > > > CONFIG_ARCH_OMAP3=y > > > > > CONFIG_ARCH_OMAP4=y > > > > > CONFIG_SOC_OMAP5=y > > > > > > > > > > (salsa commit 12d6bf86b56d72f1f6f7765aa5174c63879ab1f5 may be > > > > > relevant too) > > > > > > > > > > I don't know if it's *possible* to disable ARM_OMAP2PLUS_CPUFREQ in > > > > > Debian and > > > > > if so, whether it is *desirable* as it may break other boards (then > > > > > you have). > > > > > > > > > > Furthermore, it seems to me that various upstream work is needed if > > > > > ARM_OMAP2PLUS_CPUFREQ is indeed deprecated and should be removed. > > > > > > > mainline commit 49ded525d4486dc97fc965858bf3ddf245463670 shows that > > omap-cpufreq will only be used in non device tree boot. > It is also clearly stated that these two drivers can coexist, so I think there > may be a problem with the code for the coexistence of device tree boot > and non-device tree boot. > > > > > I don't know what's possible and/or desirable (or how to go further > > > > > from here, > > > > > so I'm tagging it 'help' so that hopefully one of the actual > > > > > maintainers takes > > > > > a look at this and decides how to progress (if so).
