From: nm@ti•com (Nishanth Menon)
To: linux-arm-kernel@lists•infradead.org
Subject: [REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working
Date: Fri, 17 Oct 2014 08:54:09 -0500 [thread overview]
Message-ID: <54411F81.6040309@ti.com> (raw)
In-Reply-To: <CAFqH_52u-q44sqUPiU-r+RO6QM2W2kKpM=VkBGcT=33U1_15FA@mail.gmail.com>
On 10/17/2014 07:48 AM, Enric Balletbo Serra wrote:
> 2014-10-17 14:35 GMT+02:00 Tero Kristo <t-kristo@ti•com>:
>> On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote:
>>>
>>> 2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti•com>:
>>>>
>>>> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti•com>:
>>>>>>
>>>>>>
>>>>>> 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.)
>>>>>>
>>>>>> -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.html
>>>>>
>>>>>
>>>>>
>>>>> Tony 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_core
>>>>>
>>>>> 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.
>>>>
>>>> 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_core
>>>
>>>
>>> The of_init_opp_table who reads the 'operating-points" from dtb is
>>> called after. Should be called before?
>>>
>>> [ 2.592834] cpu cpu0: of_init_opp_table: init_opp_table
>>>
>>
>> What 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 ?
NO. 1GHz cannot not be supported by the chip until we have avs
class1.5 and ABB integrated into a proper cpufreq/dvfs solution.
we have tried multiple times in upstream to present a solution
you are welcome to read up on
https://bugzilla.kernel.org/show_bug.cgi?id=58541 to see why similar
frequency was not enabled on omap4 (as an example).
>
>> 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...
>>
>
> 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);
only after we have pure DT only boot for OMAP3. we are supposed to
support legacy mode for omap3 as well for now.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2014-10-17 13:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 14:06 [REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working Tero Kristo
2014-10-10 14:06 ` [REPOST PATCH 1/2] ARM: OMAP3+: TWL: add support for mapping platform data via pdata-quirks Tero Kristo
2014-11-07 15:22 ` Mark Brown
2014-11-07 17:13 ` Tero Kristo
2014-10-10 14:06 ` [REPOST PATCH 2/2] regulator: twl: use platform data in the DT based boot also Tero Kristo
2014-10-16 14:21 ` [REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working Enric Balletbo Serra
2014-10-17 5:55 ` Tero Kristo
2014-10-17 11:55 ` Enric Balletbo Serra
2014-10-17 12:35 ` Tero Kristo
2014-10-17 12:48 ` Enric Balletbo Serra
2014-10-17 13:54 ` Nishanth Menon [this message]
2014-10-17 13:56 ` Tero Kristo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54411F81.6040309@ti.com \
--to=nm@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox