Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #75622 > unrolled thread

Bug#1012881: linux: ti soc cpufreq not working

Started byYu-Tung Chang <mtwget@gmail.com>
First post2022-06-16 12:30 +0200
Last post2022-06-23 10:40 +0200
Articles 12 — 3 participants

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-16 12:30 +0200
    Processed: Re: Bug#1012881: linux: ti soc cpufreq not working "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-06-16 17:00 +0200
    Bug#1012881: linux: ti soc cpufreq not working Diederik de Haas <didi.debian@cknow.org> - 2022-06-16 17:00 +0200
    Bug#1012881: linux: ti soc cpufreq not working Diederik de Haas <didi.debian@cknow.org> - 2022-06-20 13:10 +0200
      Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-20 14:00 +0200
      Bug#1012881: linux: ti soc cpufreq not working Diederik de Haas <didi.debian@cknow.org> - 2022-06-22 16:30 +0200
        Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-23 10:20 +0200
    Processed: Re: Bug#1012881: linux: ti soc cpufreq not working "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-06-22 16:30 +0200
    Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-23 10:20 +0200
      Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-23 10:30 +0200
        Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-23 10:40 +0200
          Bug#1012881: linux: ti soc cpufreq not working Yu-Tung Chang <mtwget@gmail.com> - 2022-06-23 10:40 +0200

#75622 — Bug#1012881: linux: ti soc cpufreq not working

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-16 12:30 +0200
SubjectBug#1012881: linux: ti soc cpufreq not working
Message-ID<EyUVb-5aEe-1@gated-at.bofh.it>
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.

[toc] | [next] | [standalone]

#75628 — Processed: Re: Bug#1012881: linux: ti soc cpufreq not working

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2022-06-16 17:00 +0200
SubjectProcessed: Re: Bug#1012881: linux: ti soc cpufreq not working
Message-ID<EyZ8t-5d0g-5@gated-at.bofh.it>
In reply to#75622
Processing control commands:

> tag -1 moreinfo
Bug #1012881 [linux-image-armmp] linux: ti soc cpufreq not working
Added tag(s) moreinfo.

-- 
1012881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#75629

FromDiederik de Haas <didi.debian@cknow.org>
Date2022-06-16 17:00 +0200
Message-ID<EyZ8t-5d0g-1@gated-at.bofh.it>
In reply to#75622

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

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.

Can you explain ('more') what the actual issue is?

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.
I can ofc be wrong.

[toc] | [prev] | [next] | [standalone]

#75685

FromDiederik de Haas <didi.debian@cknow.org>
Date2022-06-20 13:10 +0200
Message-ID<EAns6-62s0-3@gated-at.bofh.it>
In reply to#75622

[Multipart message — attachments visible in raw view] — view raw

Always send your replies to the bug report!

[This is therefor just a forward to that bug report]

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
> 
> Yu-Tung Chang <mtwget@gmail.com> 于2022年6月20日周一 16:03写道：
> 
> > https://lore.kernel.org/linux-arm-kernel/51433693.2@ti.com/T/
> > 
> > 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.
> > > 
> > > Diederik de Haas <didi.debian@cknow.org> 于2022年6月16日周四 22:50写道：
> > > 
> > > > Control: tag -1 moreinfo
> > > > 
> > > > 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.
> > > > 
> > > > Can you explain ('more') what the actual issue is?
> > > > 
> > > > 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.
> > > > I can ofc be wrong.

[toc] | [prev] | [next] | [standalone]

#75689

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-20 14:00 +0200
Message-ID<EAoet-62H5-1@gated-at.bofh.it>
In reply to#75685
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

Diederik de Haas <didi.debian@cknow.org> 于2022年6月20日周一 19:00写道：
>
> Always send your replies to the bug report!
>
> [This is therefor just a forward to that bug report]
>
> 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
> >
> > Yu-Tung Chang <mtwget@gmail.com> 于2022年6月20日周一 16:03写道：
> >
> > > https://lore.kernel.org/linux-arm-kernel/51433693.2@ti.com/T/
> > >
> > > 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.
> > > >
> > > > Diederik de Haas <didi.debian@cknow.org> 于2022年6月16日周四 22:50写道：
> > > >
> > > > > Control: tag -1 moreinfo
> > > > >
> > > > > 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.
> > > > >
> > > > > Can you explain ('more') what the actual issue is?
> > > > >
> > > > > 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.
> > > > > I can ofc be wrong.
>

[toc] | [prev] | [next] | [standalone]

#75727

FromDiederik de Haas <didi.debian@cknow.org>
Date2022-06-22 16:30 +0200
Message-ID<EB9wJ-6v4C-7@gated-at.bofh.it>
In reply to#75685

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#75735

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-23 10:20 +0200
Message-ID<EBqed-6Fc5-3@gated-at.bofh.it>
In reply to#75727
Diederik de Haas <didi.debian@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/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.
>
But after "make omap2plus_defconfig", ARM_TI_CPUFREQ in .config will
be enabled, while ARM_OMAP2PLUS_CPUFREQ will not.
> 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).

[toc] | [prev] | [next] | [standalone]

#75728 — Processed: Re: Bug#1012881: linux: ti soc cpufreq not working

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2022-06-22 16:30 +0200
SubjectProcessed: Re: Bug#1012881: linux: ti soc cpufreq not working
Message-ID<EB9wJ-6v4C-5@gated-at.bofh.it>
In reply to#75622
Processing control commands:

> tag -1 help
Bug #1012881 [src:linux] linux: ti soc cpufreq not working
Added tag(s) help.

-- 
1012881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#75734

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-23 10:20 +0200
Message-ID<EBqed-6Fc5-1@gated-at.bofh.it>
In reply to#75622
Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:08写道：
>
> Diederik de Haas <didi.debian@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/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.
> >
> 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.
> >
> > 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).

[toc] | [prev] | [next] | [standalone]

#75736

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-23 10:30 +0200
Message-ID<EBqnT-6Ffk-5@gated-at.bofh.it>
In reply to#75734
Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:12写道：
>
> Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:08写道：
> >
> > Diederik de Haas <didi.debian@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/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.
> > >
> > 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.
> > > 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).

[toc] | [prev] | [next] | [standalone]

#75737

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-23 10:40 +0200
Message-ID<EBqxz-6FiI-1@gated-at.bofh.it>
In reply to#75736
Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:21写道：
>
> Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:12写道：
> >
> > Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:08写道：
> > >
> > > Diederik de Haas <didi.debian@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/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.
> > > >
> > > 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).

[toc] | [prev] | [next] | [standalone]

#75738

FromYu-Tung Chang <mtwget@gmail.com>
Date2022-06-23 10:40 +0200
Message-ID<EBqxA-6FiI-5@gated-at.bofh.it>
In reply to#75737
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 <mtwget@gmail.com> 于2022年6月23日周四 16:27写道：
>
> Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:21写道：
> >
> > Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:12写道：
> > >
> > > Yu-Tung Chang <mtwget@gmail.com> 于2022年6月23日周四 16:08写道：
> > > >
> > > > Diederik de Haas <didi.debian@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/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.
> > > > >
> > > > 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).

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web