| Message ID | 20220127150615.v2.12.I3a5c7f21ecd8221b42c2dbcd618386bce7b3e9a6@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rk3399: Clean up and enable DDR DVFS | expand |
On Thu, Jan 27, 2022 at 6:17 PM Brian Norris <briannorris@chromium.org> wrote: > > From: Lin Huang <hl@rock-chips.com> > > Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY > Interface) nodes on gru boards so we can support DDR DVFS. > > Signed-off-by: Lin Huang <hl@rock-chips.com> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> > Signed-off-by: Gaël PORTAY <gael.portay@collabora.com> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > Signed-off-by: Brian Norris <briannorris@chromium.org> > Updates since the old series: > > - reordered alphabetically by phandle name, per style > - drop a ton of deprecated/unused properties > - add required center-supply for scarlet > - add new *_idle_dis_freq properties > - drop the lowest (200 MHz) OPP; this was never stabilized for > production > - bump the voltage (0.9V -> 0.925V) for the highest OPP on Chromebook > models; later (tablet) models were more stable, with a fixed DDR > regulator > - bump odt_dis_freq to 666 MHz; early versions used 333 MHz, but > stabilization efforts landed on 666 MHz for production > > --- > > Changes in v2: > - Adapt to new properties > > Changes in v1: > This was part of a previous series, at: > https://lore.kernel.org/r/20210308233858.24741-3-daniel.lezcano@linaro.org > I've picked up a bunch of changes and fixes, so I've restarted the patch > series numbering. Good Morning, I'm trying to bring this series over to rockpro64 (and eventually the pinephone-pro) and am running into some snags. Essentially, anytime a transition happens, the board locks up. I've disabled the extra power save disable flags and adjusted the OPPs for rockpro64's power. Transitions anywhere from the default 800mhz cause a lock. I'm digging deeper, but I'm hoping you can answer some questions in the meantime: 1. Does this require something from firmware that isn't available on Mainline ATF? (AKA special firmware to the Chromebook line) 2. If not, do you have any recommendations off the top of your head? Thanks, Peter Geis > > .../dts/rockchip/rk3399-gru-chromebook.dtsi | 7 +++++ > .../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 12 ++++++++ > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 28 +++++++++++++++++++ > .../boot/dts/rockchip/rk3399-op1-opp.dtsi | 25 +++++++++++++++++ > 4 files changed, 72 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > index 9b2c679f5eca..cc8950046d94 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > @@ -234,6 +234,13 @@ &cdn_dp { > extcon = <&usbc_extcon0>, <&usbc_extcon1>; > }; > > +&dmc { > + center-supply = <&ppvar_centerlogic>; > + rockchip,pd-idle-dis-freq-hz = <800000000>; > + rockchip,sr-idle-dis-freq-hz = <800000000>; > + rockchip,sr-mc-gate-idle-dis-freq-hz = <800000000>; > +}; > + > &edp { > status = "okay"; > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > index a9817b3d7edc..913d845eb51a 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > @@ -391,6 +391,18 @@ &cru { > <400000000>; > }; > > +/* The center supply is fixed to .9V on scarlet */ > +&dmc { > + center-supply = <&pp900_s0>; > +}; > + > +/* We don't need .925 V for 928 MHz on scarlet */ > +&dmc_opp_table { > + opp03 { > + opp-microvolt = <900000>; > + }; > +}; > + > &gpio0 { > gpio-line-names = /* GPIO0 A 0-7 */ > "CLK_32K_AP", > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > index 162f08bca0d4..23bfba86daab 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > @@ -373,6 +373,34 @@ &cru { > <200000000>; > }; > > +&dfi { > + status = "okay"; > +}; > + > +&dmc { > + status = "okay"; > + > + rockchip,pd-idle-ns = <160>; > + rockchip,sr-idle-ns = <10240>; > + rockchip,sr-mc-gate-idle-ns = <40960>; > + rockchip,srpd-lite-idle-ns = <61440>; > + rockchip,standby-idle-ns = <81920>; > + > + rockchip,ddr3_odt_dis_freq = <666000000>; > + rockchip,lpddr3_odt_dis_freq = <666000000>; > + rockchip,lpddr4_odt_dis_freq = <666000000>; > + > + rockchip,sr-mc-gate-idle-dis-freq-hz = <1000000000>; > + rockchip,srpd-lite-idle-dis-freq-hz = <0>; > + rockchip,standby-idle-dis-freq-hz = <928000000>; > +}; > + > +&dmc_opp_table { > + opp03 { > + opp-suspend; > + }; > +}; > + > &emmc_phy { > status = "okay"; > }; > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi > index 2180e0f75003..6e29e74f6fc6 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi > @@ -110,6 +110,27 @@ opp05 { > opp-microvolt = <1075000>; > }; > }; > + > + dmc_opp_table: dmc_opp_table { > + compatible = "operating-points-v2"; > + > + opp00 { > + opp-hz = /bits/ 64 <400000000>; > + opp-microvolt = <900000>; > + }; > + opp01 { > + opp-hz = /bits/ 64 <666000000>; > + opp-microvolt = <900000>; > + }; > + opp02 { > + opp-hz = /bits/ 64 <800000000>; > + opp-microvolt = <900000>; > + }; > + opp03 { > + opp-hz = /bits/ 64 <928000000>; > + opp-microvolt = <925000>; > + }; > + }; > }; > > &cpu_l0 { > @@ -136,6 +157,10 @@ &cpu_b1 { > operating-points-v2 = <&cluster1_opp>; > }; > > +&dmc { > + operating-points-v2 = <&dmc_opp_table>; > +}; > + > &gpu { > operating-points-v2 = <&gpu_opp_table>; > }; > -- > 2.35.0.rc0.227.g00780c9af4-goog > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Peter, On Fri, Mar 4, 2022 at 6:47 AM Peter Geis <pgwipeout@gmail.com> wrote: > I'm trying to bring this series over to rockpro64 (and eventually the > pinephone-pro) and am running into some snags. Dumb question: is DDR DVFS supported on these systems in the "production" (vendor kernel? I'm not really familiar with these devices) software? I partly ask, because while I didn't do some of this first-hand, I'm aware that it was a real ordeal to get things stabilized (e.g., getting all the timings right; communicating the right details from bootloader to ATF; etc.), so if no one did these things in the first place, it's probably difficult to get working now just by guessing. But if it works on a customized kernel, then that's a different story. > Essentially, anytime a transition happens, the board locks up. > I've disabled the extra power save disable flags and adjusted the OPPs > for rockpro64's power. > Transitions anywhere from the default 800mhz cause a lock. > > I'm digging deeper, but I'm hoping you can answer some questions in > the meantime: > 1. Does this require something from firmware that isn't available on > Mainline ATF? (AKA special firmware to the Chromebook line) I don't know precisely. Chromebooks track mainline ATF, but somewhere before initial product launch, each platform gets its own firmware branch. On that firmware branch, we still try to stay in sync with mainline to some extent (e.g., submit to mainline and cherry-pick to branch), but it's not guaranteed. Anyway, you can inspect our code here: https://chromium.googlesource.com/chromiumos/third_party/arm-trusted-firmware/+log/refs/heads/firmware-gru-8785.B https://chromium.googlesource.com/chromiumos/third_party/coreboot/+log/refs/heads/firmware-gru-8785.B Brian
Hello again Peter, On Fri, Mar 4, 2022 at 6:47 AM Peter Geis <pgwipeout@gmail.com> wrote: > Transitions anywhere from the default 800mhz cause a lock. > > I'm digging deeper, but I'm hoping you can answer some questions in > the meantime: > 1. Does this require something from firmware that isn't available on > Mainline ATF? (AKA special firmware to the Chromebook line) > 2. If not, do you have any recommendations off the top of your head? I may have a better answer for you now. In the intervening time period, I've discovered a potentially-relevant bug, involving interactions between the kernel power-domain driver and ATF. See this series for my current fixes: https://lore.kernel.org/linux-rockchip/20220406014842.2771799-1-briannorris@chromium.org/ [RFC PATCH 0/2] rockchip / devfreq: Coordinate DRAM controller resources between ATF and kernel If that happens to help you (it may help, for instance, if your system was toggling NPLL off/on like mine was; it also may help if you're hitting a race on PMU_BUS_IDLE_REQ like noticed in patch 1), I'd love your feedback there. It's still possible your problems are completely unrelated though. Regards, Brian
On Tue, Apr 5, 2022 at 10:05 PM Brian Norris <briannorris@chromium.org> wrote: > > Hello again Peter, > > On Fri, Mar 4, 2022 at 6:47 AM Peter Geis <pgwipeout@gmail.com> wrote: > > Transitions anywhere from the default 800mhz cause a lock. > > > > I'm digging deeper, but I'm hoping you can answer some questions in > > the meantime: > > 1. Does this require something from firmware that isn't available on > > Mainline ATF? (AKA special firmware to the Chromebook line) > > 2. If not, do you have any recommendations off the top of your head? > > I may have a better answer for you now. In the intervening time > period, I've discovered a potentially-relevant bug, involving > interactions between the kernel power-domain driver and ATF. See this > series for my current fixes: > > https://lore.kernel.org/linux-rockchip/20220406014842.2771799-1-briannorris@chromium.org/ > [RFC PATCH 0/2] rockchip / devfreq: Coordinate DRAM controller > resources between ATF and kernel > > If that happens to help you (it may help, for instance, if your system > was toggling NPLL off/on like mine was; it also may help if you're > hitting a race on PMU_BUS_IDLE_REQ like noticed in patch 1), I'd love > your feedback there. > > It's still possible your problems are completely unrelated though. Thank you, that is certainly possible to be the problem here as well. I won't have time to test them till this weekend, but you can count on my feedback as soon as I get the time to do so. > > Regards, > Brian
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi index 9b2c679f5eca..cc8950046d94 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi @@ -234,6 +234,13 @@ &cdn_dp { extcon = <&usbc_extcon0>, <&usbc_extcon1>; }; +&dmc { + center-supply = <&ppvar_centerlogic>; + rockchip,pd-idle-dis-freq-hz = <800000000>; + rockchip,sr-idle-dis-freq-hz = <800000000>; + rockchip,sr-mc-gate-idle-dis-freq-hz = <800000000>; +}; + &edp { status = "okay"; diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi index a9817b3d7edc..913d845eb51a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi @@ -391,6 +391,18 @@ &cru { <400000000>; }; +/* The center supply is fixed to .9V on scarlet */ +&dmc { + center-supply = <&pp900_s0>; +}; + +/* We don't need .925 V for 928 MHz on scarlet */ +&dmc_opp_table { + opp03 { + opp-microvolt = <900000>; + }; +}; + &gpio0 { gpio-line-names = /* GPIO0 A 0-7 */ "CLK_32K_AP", diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi index 162f08bca0d4..23bfba86daab 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi @@ -373,6 +373,34 @@ &cru { <200000000>; }; +&dfi { + status = "okay"; +}; + +&dmc { + status = "okay"; + + rockchip,pd-idle-ns = <160>; + rockchip,sr-idle-ns = <10240>; + rockchip,sr-mc-gate-idle-ns = <40960>; + rockchip,srpd-lite-idle-ns = <61440>; + rockchip,standby-idle-ns = <81920>; + + rockchip,ddr3_odt_dis_freq = <666000000>; + rockchip,lpddr3_odt_dis_freq = <666000000>; + rockchip,lpddr4_odt_dis_freq = <666000000>; + + rockchip,sr-mc-gate-idle-dis-freq-hz = <1000000000>; + rockchip,srpd-lite-idle-dis-freq-hz = <0>; + rockchip,standby-idle-dis-freq-hz = <928000000>; +}; + +&dmc_opp_table { + opp03 { + opp-suspend; + }; +}; + &emmc_phy { status = "okay"; }; diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi index 2180e0f75003..6e29e74f6fc6 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi @@ -110,6 +110,27 @@ opp05 { opp-microvolt = <1075000>; }; }; + + dmc_opp_table: dmc_opp_table { + compatible = "operating-points-v2"; + + opp00 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <900000>; + }; + opp01 { + opp-hz = /bits/ 64 <666000000>; + opp-microvolt = <900000>; + }; + opp02 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <900000>; + }; + opp03 { + opp-hz = /bits/ 64 <928000000>; + opp-microvolt = <925000>; + }; + }; }; &cpu_l0 { @@ -136,6 +157,10 @@ &cpu_b1 { operating-points-v2 = <&cluster1_opp>; }; +&dmc { + operating-points-v2 = <&dmc_opp_table>; +}; + &gpu { operating-points-v2 = <&gpu_opp_table>; };