[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1012881: linux: ti soc cpufreq not working



Control: tag -1 help

On Monday, 20 June 2022 10:09:45 CEST Yu-Tung Chang wrote:
> https://lore.kernel.org/linux-arm-kernel/51433693.2@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 <mtwget@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.

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.

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).

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: