[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJKOXPfFZL8q9hM1vPsLq+Qxe-gMz4c8j0jgFKfdf5qs68MTmA@mail.gmail.com>
Date: Wed, 17 Jul 2019 12:15:37 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Lukasz Luba <l.luba@...tner.samsung.com>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>, linux-clk@...r.kernel.org,
mturquette@...libre.com, sboyd@...nel.org,
Bartłomiej Żołnierkiewicz
<b.zolnierkie@...sung.com>, kgene@...nel.org, mark.rutland@....com,
robh+dt@...nel.org, Chanwoo Choi <cw00.choi@...sung.com>,
kyungmin.park@...sung.com, Andrzej Hajda <a.hajda@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
s.nawrocki@...sung.com, myungjoo.ham@...sung.com
Subject: Re: [PATCH v1 27/50] ARM: dts: exynos: align bus_wcore OPPs in Exynos5420
On Mon, 15 Jul 2019 at 14:44, Lukasz Luba <l.luba@...tner.samsung.com> wrote:
>
> This is the most important bus in the Exynos5x SoC. The whole communication
> inside SoC does through that bus (apart from direct requests from CCI to
> DRAM controller). It is also modeled as a master bus in devfreq framework.
> It is also the only one OPP table throughout other buses which has voltage
> values. The devfreq software controls the speed of that bus and other
> buses. The other buses follows the rate of the master. There is only one
> regulator. The old lowest OPP had pair 925mV, 84MHz which is enough for
s/lowest/slowest/
> this frequency. However, due to the fact that the other buses follows the
> WCORE bus by taking the OPP from their table with the same id, e.g. opp02,
> the children frequency should be stable with the set voltage.
> It could cause random faults very hard to debug.
> Thus, the patch removes the lowest OPP to make other buses' lowest OPPs
s/lowest/slowest/
> working. The new lowest OPP has voltage high enough for buses working up
> to 333MHz. It also changes the frequencies of the OPPs to align them to
> PLL value such that it is possible to set them using only a divider without
> reprogramming OPP.
Reprogramming OPP? What is it?
> Reprogramming the PLL was not set, so the real frequency
I understood from the previous that reprogramming the OPP (PLL?) was
happening... Please rephrase entire sentence.
BR,
Krzysztof
> values were not the one from the OPP table, which could confuse the
> governor algorithms which relay on OPP speed values making the system to
> behave weird.
>
> Signed-off-by: Lukasz Luba <l.luba@...tner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index f8c36ff0d4c3..a355c76af5a5 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -1107,22 +1107,18 @@
> compatible = "operating-points-v2";
>
> opp00 {
> - opp-hz = /bits/ 64 <84000000>;
> - opp-microvolt = <925000>;
> + opp-hz = /bits/ 64 <150000000>;
> + opp-microvolt = <950000>;
> };
> opp01 {
> - opp-hz = /bits/ 64 <111000000>;
> + opp-hz = /bits/ 64 <200000000>;
> opp-microvolt = <950000>;
> };
> opp02 {
> - opp-hz = /bits/ 64 <222000000>;
> + opp-hz = /bits/ 64 <300000000>;
> opp-microvolt = <950000>;
> };
> opp03 {
> - opp-hz = /bits/ 64 <333000000>;
> - opp-microvolt = <950000>;
> - };
> - opp04 {
> opp-hz = /bits/ 64 <400000000>;
> opp-microvolt = <987500>;
> };
> --
> 2.17.1
>
Powered by blists - more mailing lists