ARM: OMAP3+: VCVP mapping fixes to get DVFS working
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working
Quoted 86 lines · Enric Balletbo Serra
2014-10-17 14:35 GMT+02:00 Tero Kristo <[email protected]>:
Quoted 85 lines · Enric Balletbo Serra
Quoted 84 lines
2014-10-17 7:55 GMT+02:00 Tero Kristo <[email protected]>:
Quoted 57 lines · Enric Balletbo Serra
Quoted 44 lines
Hi,
2014-10-10 16:06 GMT+02:00 Tero Kristo <[email protected]>:
Quoted 19 lines
Hi,
Seems like MPU DVFS does not scale the voltages currently with DT boot, due to missing mapping between regulator -> VCVP. Fixed this by adding support for platform data in the TWL regulator DT case + adding platform
data quirk for the same. This same already works in the legacy boot, the
platform data is passed fine.Tested on omap3-beagle by measuring the MPU voltage rail.
OMAP4+ platforms do not currently register DVFS regulator, so this set by
itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc. for OMAP4460.)Quoted 7 lines
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.htmlTony proposed in the IRC apply this patch series in order to solve the following error messages with kernel 3.17
[ 2.522949] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [ 2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva [ 2.541564] omap2_set_init_voltage: unable to find boot up OPP for vdd_core [ 2.551208] omap2_set_init_voltage: unable to set vdd_coreQuoted 3 lines
I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but should these patches solve these errors ? Did you resolve these errors on your Beagleboard ?
These prints are caused by something else: namely the fact that beagleboard
rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and quelches out the warning prints.Quoted 6 lines
This should be fixed by modifying the OPP tables under the dtsi files, however the nasty thing is not all beagleboards support 720MHz OPP. You either need to specify a dts file for beagle-revC4 or do some kernel magic
to manually disable the 720MHz OPP on non-supported boards.Adding and modifying some printk looks the problem is because it can't find the device opp.
[ 2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp [ 2.542755] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva (clk = dpll1_ck - freq = 600000000) [ 2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva[ 2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't find device opp [ 2.573333] omap2_set_init_voltage: unable to find boot up OPP for vdd_core (clk = l3_ick - freq = 200000000) [ 2.584442] omap2_set_init_voltage: unable to set vdd_coreThe
of_init_opp_tablewho reads the 'operating-points" from dtb is called after. Should be called before?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
[ 2.592834] cpu cpu0: of_init_opp_table: init_opp_tableWhat is the board revision you got? Looks like it boots up at 600/200MHz.
Well, about board revision I'm using IGEPv2 not Beagleboard. And my board should be able to run up to 1GHz. Is 1GHz supported ?
Oh I see. Kernel doesn't support anything above 600MHz yet for OMAP3, as none of the OPPs have kernel data.
Quoted 8 lines
Quoted 7 lines
You can also try tweaking around the tables under
opp3xxx_data.c, not sure if these are initialized in the correct order either. However, the lack of these tables and the warnings mentioned do not prevent cpufreq from working, cpufreq is dependant on the DT tables. That being said, I am not sure if the legacy OPP tables are even needed anymore on DT boot...
Quoted 4 lines
Right, I've checked and cpufreq seems to work. Does this means that following call is not needed anymore ?
arch/arm/mach-omap2/opp3xxx_data.c:171:omap_device_initcall(omap3_opp_init);
That is still needed, as some boards do not have DT data for them. That initializes the legacy OPPs in that case.
-Tero