Bug 58541

Summary: [pandaboard] cpu frequency limitation
Product: Platform Specific/Hardware Reporter: Tobias Jakobi (liquid.acid)
Component: ARMAssignee: linux-arm-kernel (linux-arm-kernel)
Status: RESOLVED OBSOLETE    
Severity: normal CC: bgamari, emailgrant, jcsduncan2011, nm, tianyu.lan, tony
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.9.3 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg output after boot
kernel config

Description Tobias Jakobi 2013-05-20 14:31:25 UTC
Created attachment 102051 [details]
dmesg output after boot

Hello,

the ARMv7 in the Pandaboard ES (OMAP4460) should support a maximum frequency of around 1.2GHz.

However it looks like that it's currently limited to 920MHz.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:
350000 700000 920000

Even worse:

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 
699977

Greets,
Tobias
Comment 1 Tobias Jakobi 2013-05-20 14:33:08 UTC
Created attachment 102061 [details]
kernel config
Comment 2 Nishanth Menon 2013-05-20 19:48:16 UTC
This is correct - *ONLY* 920MHz will be supported by default without AVS Class 1.5, Adaptive Body Bias(ABB) support enabled. ABB and AVS class 1.5 is mandatory for frequencies 1.2GHz and 1.5GHz to be enabled.

For PandaBoard ES, we also have additional constraint. MPU voltage is supplied by TPS62391 PMIC chip which can only be controlled from I2C_SR.

we DONOT have any form of support for pmic control over i2c_sr.

Current status:
a) ABB support - currently blocked due to lack of clock node support in OF.
   i) ABB driver support and DTS conversion: http://marc.info/?l=linux-omap&m=136751559523901&w=2
   ii) Clock node support preventing this from being merged in: http://marc.info/?t=136804008400001&r=1&w=2
b) TPS62361 support and hence voltage control over i2c_sr -> to be posted in linux-omap mailing list this week - https://github.com/nmenon/linux-2.6-playground/commits/devel/vc-vp-regulator has the prelim patches undergoing TI internal review.

In short - this was never a feature that k.org had support till date.

For full conversion, see the overview steps I posted here: https://plus.google.com/u/0/112464029509057661457/posts/gvyZQcNieoq
Comment 3 Nishanth Menon 2013-05-20 19:49:58 UTC
I think this should be assigned to linux-omap instead of cpufreq btw.
Comment 4 Tobias Jakobi 2013-05-20 20:58:16 UTC
Thanks for the update. It's good to know that you guys are working on it!
Comment 5 Lan Tianyu 2013-05-29 02:47:25 UTC
(In reply to comment #3)
> I think this should be assigned to linux-omap instead of cpufreq btw.
Not find linux-omap category. So reassign to platform-specific/arm.
Comment 6 Tobias Jakobi 2013-10-16 23:41:07 UTC
Now on 3.12-rc5. I can see that the ABB regulat code was merged. However I still seem to be limited to the 700MHz maximum clock.

What is even worse, I can't even activate cpufreq support in the kernel (I started from scratch / omap2plus_defconfig). The kernel still boots then, but locks ups somewhere in the middle (before reaching init).

@Nishanth: Can you perhaps comment on what is currently supposed to work?
Comment 7 Nishanth Menon 2013-10-17 14:08:50 UTC
(In reply to Tobias Jakobi from comment #6)
> Now on 3.12-rc5. I can see that the ABB regulat code was merged. However I
> still seem to be limited to the 700MHz maximum clock.
> 
> What is even worse, I can't even activate cpufreq support in the kernel (I
> started from scratch / omap2plus_defconfig). The kernel still boots then,
> but locks ups somewhere in the middle (before reaching init).

Yes, there is atleast 1 patch queued to fix that ->
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts

With this, at 3.13-rc1 we will have reliable boot with DTS.

> 
> @Nishanth: Can you perhaps comment on what is currently supposed to work?
At this point in 3.13-rc1 expectation is just boot. Cpufreq can only be supported once our clock nodes are available. See:
- http://marc.info/?t=138009899400001&r=1&w=2 -> clock node dts discussion
- after which we need to get http://marc.info/?l=linux-omap&m=138193814208474&w=2 merged.

(hopefully 3.14-rc1)

Once these two are done, then comes the hard part:
a) need to provide a generic voltage transition sequencer for all cpufreq/devfreq drivers -> I just started looking at it.
b) introduce ABB dts nodes and hook the ABB regulator along with regular stuff - this takes care of all non-omap4 platforms
c) introduce VC/VP regulator - same as in comment #2 -> this finally enables DVFS for OMAP4460 PandaBoard-ES.
Comment 8 Tobias Jakobi 2013-10-27 02:27:57 UTC
Thanks a lot for the update!

With the "1 patch queued", do you mean this one?
"ARM: dts: omap4-panda-es: Do not reset gpio1" (https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.13/dts&id=c1bac171c4f203101611110869bd2511c8153974)

I assume this can't be applied on top of 3.12-rc6, but depends on some more patches?
Comment 9 Tobias Jakobi 2013-11-28 23:14:14 UTC
Retested with 3.13-rc1. While I can now enable cpufreq in the kernel config (the boot process doesn't lock up at least), I don't see cpufreq loaded at all though (there is no 'cpufreq' node in /sys/devices/system/cpu/cpu0/).
Comment 10 Nishanth Menon 2014-01-30 21:42:05 UTC
ok. i think we should have clock nodes with 3.14-rc1 since it has now been merged to master. you will also need to cherry-pick http://marc.info/?l=linux-omap&m=139101963410506&w=2 -> still pending.
Comment 11 Tobias Jakobi 2014-02-02 21:04:07 UTC
I'm currently on mainline tip with the patches from above applied. The system boots and I finally have thermal_zone0 in /sys/class/thermal, which I assume is the bandgap sensor of the SoC.

However no cpufreq nodes are created in /sys/devices/system/cpu/cpu{0,1}.

Also, omapconf says "All Smart-Reflex Modules disabled".
Comment 12 Nishanth Menon 2014-02-03 15:43:58 UTC
yes - we just hit stage 1 -> got in clock nodes. next stage will be to get cpufreq in, etc..
Comment 13 Tobias Jakobi 2014-02-06 12:16:22 UTC
Well, at least it still boots and make the thermal sensor available -- that already something :)
Comment 14 Nishanth Menon 2014-03-14 07:10:05 UTC
just for the record - seeing it closed - we are not yet fully operational for 1.2GHz.
Comment 15 Tobias Jakobi 2014-03-14 08:38:14 UTC
I don't know why it was closed, reopening it.

@Lan: I never stated that this was fixed.
Comment 16 Lan Tianyu 2014-03-14 08:52:57 UTC
Sorry. I mix this with Bug 58551. Can the bug 58551 be closed?
Comment 17 Nishanth Menon 2014-03-18 13:57:23 UTC
update: b) -> http://marc.info/?l=linux-omap&m=139421513212619&w=2 (ABB regulator dts nodes).

a) debate ongoing with Mark Brown and Mike Turquette here: http://marc.info/?t=139275563700007&r=1&w=2 (full series): http://marc.info/?l=linux-kernel&m=139275560531711&w=2
Comment 18 Tobias Jakobi 2014-10-11 20:37:23 UTC
Abandoning, since I don't own the device anymore.
Comment 19 Chris Duncan 2016-02-26 11:29:02 UTC
Was this ever properly resolved?