From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Viresh Kumar <viresh.kumar@linaro.org>, Tony Lindgren <tony@atomide.com>
Cc: "Benoît Cousson" <bcousson@baylibre.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Adam Ford" <aford173@gmail.com>,
"André Roth" <neolynx@gmail.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux-OMAP <linux-omap@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
kernel@pyra-handheld.com
Subject: Re: [RFC v2 1/3] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
Date: Fri, 6 Sep 2019 22:46:49 +0200 [thread overview]
Message-ID: <1ED2450A-A445-42B8-8956-58A53F15DBE2@goldelico.com> (raw)
In-Reply-To: <20190906030158.leuumg7rwsvowwfx@vireshk-i7>
Hi,
> Am 06.09.2019 um 05:01 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 05-09-19, 07:32, Tony Lindgren wrote:
>> * H. Nikolaus Schaller <hns@goldelico.com> [190904 08:54]:
>>> This adds code and tables to read the silicon revision and
>>> eFuse (speed binned / 720 MHz grade) bits for selecting
>>> opp-v2 table entries.
>>>
>>> Since these bits are not always part of the syscon register
>>> range (like for am33xx, am43, dra7), we add code to directly
>>> read the register values using ioremap() if syscon access fails.
>>
>> This is nice :) Seems to work for me based on a quick test
>> on at least omap36xx.
>>
>> Looks like n900 produces the following though:
>>
>> core: _opp_supported_by_regulators: OPP minuV: 1270000 maxuV: 1270000, not supported by regulator
>> cpu cpu0: _opp_add: OPP not supported by regulators (550000000)
>
> That's a DT thing I believe where the voltage doesn't fit what the
> regulator can support.
I can confirm this on BeagleBoard C2:
root@gta04:~# dmesg|fgrep -i opp
[ 2.347442] core: _opp_supported_by_regulators: OPP minuV: 1270000 maxuV: 1270000, not supported by regulator
[ 2.359222] cpu cpu0: _opp_add: OPP not supported by regulators (550000000)
[ 2.580993] omap2_set_init_voltage: unable to find boot up OPP for vdd_core
root@gta04:~#
>
>> But presumably that can be further patched.
Well, the opp-v1 table also has this voltage point:
/* OMAP343x/OMAP35xx variants OPP1-5 */
operating-points = <
/* kHz uV */
125000 975000
250000 1075000
500000 1200000
550000 1270000
600000 1350000
>;
This is OPP4 which is recommended by OMAP3530 data sheet to be 1.27V +/- 5%
Data sheet of tps65950 says
• VDD1: 1.2-A, buck DC/DC converter (VOUT = 0.6 V to 1.45 V, in steps of 12.5 mV)
This means 1270 mV is not a "step" and rejected by the twl4030 driver.
Maybe nobody did notice yet because the opp-v1 drivers did not warn...
The closest value to 1.27V is 0.6V + 54 * 12.5mV is 1.275V
So let's also change the OPP4 to 1275000 uV in the opp-v2 table.
BR and thanks,
Nikolaus
next prev parent reply other threads:[~2019-09-06 20:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 8:53 [RFC v2 0/3] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits H. Nikolaus Schaller
2019-09-04 8:53 ` [RFC v2 1/3] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx H. Nikolaus Schaller
2019-09-05 14:32 ` Tony Lindgren
2019-09-06 3:01 ` Viresh Kumar
2019-09-06 20:46 ` H. Nikolaus Schaller [this message]
2019-09-07 6:34 ` H. Nikolaus Schaller
2019-09-07 7:19 ` [Letux-kernel] " Andreas Kemnade
2019-09-06 3:04 ` Viresh Kumar
2019-09-06 15:49 ` Tony Lindgren
2019-09-04 8:53 ` [RFC v2 2/3] ARM: dts: replace opp-v1 tables by opp-v2 " H. Nikolaus Schaller
2019-09-04 8:53 ` [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx H. Nikolaus Schaller
2019-09-05 14:27 ` Tony Lindgren
2019-09-06 7:53 ` H. Nikolaus Schaller
2019-09-06 15:47 ` Tony Lindgren
2019-09-06 17:08 ` H. Nikolaus Schaller
2019-09-06 17:15 ` H. Nikolaus Schaller
2019-09-06 17:24 ` Tony Lindgren
2019-09-06 17:50 ` H. Nikolaus Schaller
2019-09-06 17:55 ` H. Nikolaus Schaller
2019-09-05 5:03 ` [RFC v2 0/3] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits Viresh Kumar
2019-09-05 14:33 ` Tony Lindgren
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=1ED2450A-A445-42B8-8956-58A53F15DBE2@goldelico.com \
--to=hns@goldelico.com \
--cc=aford173@gmail.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pyra-handheld.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=neolynx@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.