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
Created attachment 102061 [details] kernel config
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
I think this should be assigned to linux-omap instead of cpufreq btw.
Thanks for the update. It's good to know that you guys are working on it!
(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.
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?
(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.
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?
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/).
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.
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".
yes - we just hit stage 1 -> got in clock nodes. next stage will be to get cpufreq in, etc..
Well, at least it still boots and make the thermal sensor available -- that already something :)
just for the record - seeing it closed - we are not yet fully operational for 1.2GHz.
I don't know why it was closed, reopening it. @Lan: I never stated that this was fixed.
Sorry. I mix this with Bug 58551. Can the bug 58551 be closed?
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
Abandoning, since I don't own the device anymore.
Was this ever properly resolved?