From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
krzk@kernel.org, robh+dt@kernel.org, vireshk@kernel.org,
devicetree@vger.kernel.org, kgene@kernel.org,
pankaj.dubey@samsung.com, linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
b.zolnierkie@samsung.com
Subject: Re: [PATCH v2 0/9] Exynos Adaptive Supply Voltage support
Date: Fri, 9 Aug 2019 17:58:57 +0200 [thread overview]
Message-ID: <562dd2e7-2b24-8492-d1c1-2dc4973f07be@samsung.com> (raw)
In-Reply-To: <20190725022343.p7lqalrh5svxvtu2@vireshk-i7>
Hi Viresh,
On 7/25/19 04:23, Viresh Kumar wrote:
> On 24-07-19, 15:10, Marek Szyprowski wrote:
>> On 2019-07-23 04:04, Viresh Kumar wrote:
>>> On 18-07-19, 16:30, Sylwester Nawrocki wrote:
>>>> This is second iteration of patch series adding ASV (Adaptive Supply
>>>> Voltage) support for Exynos SoCs. The first one can be found at:
>>>> https://lore.kernel.org/lkml/20190404171735.12815-1-s.nawrocki@samsung.com
>>>>
>>>> The main changes comparing to the first (RFC) version are:
>>>> - moving ASV data tables from DT to the driver,
>>>> - converting the chipid and the ASV drivers to use regmap,
>>>> - converting the ASV driver to proper platform driver.
>>>>
>>>> I tried the opp-supported-hw bitmask approach as in the Qualcomm CPUFreq
>>>> DT bindings but it resulted in too many OPPs and DT nodes, around 200
>>>> per CPU cluster. So the ASV OPP tables are now in the ASV driver, as in
>>>> downstream kernels.
>>>
>>> Hmm. Can you explain why do you have so many OPPs? How many
>>> frequencies do you actually support per cluster and what all varies
>>> per frequency based on hw ? How many hw version do u have ?
>>
>> For big cores there are 20 frequencies (2100MHz .. 200MHz). Each SoC
>> might belong to one of the 3 production 'sets' and each set contains 14
>> so called 'asv groups', which assign the certain voltage values for each
>> of those 20 frequencies (the lower asv group means lower voltage needed
>> for given frequency).
>
> There is another property which might be useful in this case:
> "opp-microvolt-<name>" and then you can use API
> dev_pm_opp_set_prop_name() to choose which voltage value to apply to
> all OPPs.
Thank you for your suggestions.
For some Exynos SoC variants the algorithm of selecting CPU voltage supply
is a bit more complex than just selecting a column in the frequency/voltage
matrix, i.e. selecting a set of voltage values for whole frequency range.
Frequency range could be divided into sub-ranges and to each such a sub-range
part of different column could be assigned, depending on data fused in
the CHIPID block registers.
We could create OPP node for each frequency and specify all needed voltages
as a list of "opp-microvolt-<name>" properties but apart from the fact that
it would have been quite many properties, e.g. 42 (3 tables * 14 columns),
only for some SoC types the dev_pm_opp_set_prop_name() approach could be
used. We would need to be able to set opp-microvolt-* property name
separately for each frequency (OPP).
Probably most future proof would be a DT binding where we could still
re-create those Exynos-specific ASV tables from DT. For example add named
opp-microvolt-* properties or something similar to hold rows of each ASV
table. But that conflicts with "operating-points-v2" binding, where
multiple OPP voltage values are described by just named properties and
multiple entries correspond to min/target/max.
opp_table0 {
compatible = "...", "operating-points-v2";
opp-shared;
opp-2100000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <...>;
opp-microvolt-t1 = <1362500>, <1350000>, ....;
opp-microvolt-t2 = <1362500>, <1360000>, ....;
opp-microvolt-t3 = <1362500>, <1340000>, ....;
};
...
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <...>;
opp-microvolt-t1 = <900000>, <900000>, ....;
opp-microvolt-t2 = <900000>, <900000>, ....;
opp-microvolt-t3 = <900000>, <900000>, ....;
};
};
I might be missing some information now on how those Exynos ASV tables
are used on other SoCs that would need to be supported.
There will be even more data to include when adding support for the Body
Bias voltage, for each CPU supply voltage we could possibly have
corresponding Body Bias voltage.
--
Thanks,
Sylwester
next prev parent reply other threads:[~2019-08-09 15:59 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190718143117eucas1p1e534b9075d10fbbbe427c66192205eb1@eucas1p1.samsung.com>
2019-07-18 14:30 ` [PATCH v2 0/9] Exynos Adaptive Supply Voltage support Sylwester Nawrocki
[not found] ` <CGME20190718143127eucas1p13b1e2c98d270140a87f09562ef46c9a3@eucas1p1.samsung.com>
2019-07-18 14:30 ` [PATCH v2 1/9] soc: samsung: Add exynos chipid driver support Sylwester Nawrocki
2019-07-23 12:57 ` Krzysztof Kozlowski
2019-07-23 14:10 ` Bartlomiej Zolnierkiewicz
2019-07-24 10:47 ` Krzysztof Kozlowski
2019-08-08 12:07 ` Sylwester Nawrocki
[not found] ` <CGME20190718143128eucas1p2677ae16d229dddcd9a0db8084f0da5cf@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API Sylwester Nawrocki
2019-07-23 13:01 ` Krzysztof Kozlowski
2019-08-08 12:07 ` Sylwester Nawrocki
[not found] ` <CGME20190718143130eucas1p26f2058f47eb2f4020e1ddbf1619d1ac8@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver Sylwester Nawrocki
2019-07-23 13:38 ` Krzysztof Kozlowski
2019-08-08 12:07 ` Sylwester Nawrocki
2019-08-08 12:31 ` Krzysztof Kozlowski
2019-08-08 12:48 ` Robin Murphy
2019-08-08 13:14 ` Krzysztof Kozlowski
[not found] ` <CGME20190718143131eucas1p2e1afc9fe816fff52ee4d12e0979eeb4c@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 4/9] ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS Sylwester Nawrocki
[not found] ` <CGME20190718143132eucas1p2afecae86f2ef17aa8a4a99df8ffa47d9@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 5/9] ARM64: " Sylwester Nawrocki
[not found] ` <CGME20190718143134eucas1p2aed09e2171d0d2d6b916dddac3637017@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 6/9] ARM: EXYNOS: Enable exynos-asv driver " Sylwester Nawrocki
[not found] ` <CGME20190718143135eucas1p2da5b7842b35327c60667064184619a9f@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 7/9] soc: samsung: Update the CHIP ID DT binding documentation Sylwester Nawrocki
[not found] ` <CGME20190718143136eucas1p2cedfe5ed5e8e6316e82b30a565dc4855@eucas1p2.samsung.com>
2019-07-18 14:30 ` [PATCH v2 8/9] ARM: dts: Add "syscon" compatible string to chipid node Sylwester Nawrocki
[not found] ` <CGME20190718143138eucas1p127542c4cb8416cee9af6a95f4bc98366@eucas1p1.samsung.com>
2019-07-18 14:30 ` [PATCH v2 9/9] ARM: dts: Add samsung,asv-bin property for odroidxu3-lite Sylwester Nawrocki
2019-07-23 2:04 ` [PATCH v2 0/9] Exynos Adaptive Supply Voltage support Viresh Kumar
2019-07-24 13:10 ` Marek Szyprowski
2019-07-25 2:23 ` Viresh Kumar
2019-08-09 15:58 ` Sylwester Nawrocki [this message]
2019-08-19 9:09 ` Viresh Kumar
2019-08-19 10:06 ` Viresh Kumar
2019-08-19 11:16 ` Sylwester Nawrocki
2019-08-19 11:25 ` Viresh Kumar
2019-08-19 13:39 ` Sylwester Nawrocki
2019-08-20 3:01 ` Viresh Kumar
2019-08-20 9:03 ` Sylwester Nawrocki
2019-08-20 9:21 ` Viresh Kumar
2019-09-04 12:37 ` Sylwester Nawrocki
2019-09-05 5:01 ` Viresh Kumar
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=562dd2e7-2b24-8492-d1c1-2dc4973f07be@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pankaj.dubey@samsung.com \
--cc=robh+dt@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).