Hi Maxime and All, On Sat, 4 Jul 2020 at 16:56, Clément Péron <peron.clem@xxxxxxxxx> wrote: > > Hi Maxime, > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > > > Hi, > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > Add an Operating Performance Points table for the GPU to > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > The voltage range is set with minival voltage set to the target > > > and the maximal voltage set to 1.2V. This allow DVFS framework to > > > work properly on board with fixed regulator. > > > > > > Signed-off-by: Clément Péron <peron.clem@xxxxxxxxx> > > > > That patch seems reasonable, why shouldn't we merge it? > > I didn't test it a lot and last time I did, some frequencies looked unstable. > https://lore.kernel.org/patchwork/cover/1239739/ > > This series adds regulator support to Panfrost devfreq, I will send a > new one if DVFS on the H6 GPU is stable. > > I got this running glmark2 last time > # glmark2-es2-drm > ======================================================= > glmark2 2017.07 > ======================================================= > OpenGL Information > GL_VENDOR: Panfrost > GL_RENDERER: Mali T720 (Panfrost) > GL_VERSION: OpenGL ES 2.0 Mesa 20.0.5 > ======================================================= > > [ 93.550063] panfrost 1800000.gpu: GPU Fault 0x00000088 (UNKNOWN) at > 0x0000000080117100 > [ 94.045401] panfrost 1800000.gpu: gpu sched timeout, js=0, > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > sched_job=00000000e3c2132f > > [ 328.871070] panfrost 1800000.gpu: Unhandled Page fault in AS0 at VA > 0x0000000000000000 > [ 328.871070] Reason: TODO > [ 328.871070] raw fault status: 0xAA0003C2 > [ 328.871070] decoded fault status: SLAVE FAULT > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > [ 328.871070] access type 0x3: WRITE > [ 328.871070] source id 0xAA00 > [ 329.373327] panfrost 1800000.gpu: gpu sched timeout, js=1, > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > sched_job=000000007ac31097 > [ 329.386527] panfrost 1800000.gpu: js fault, js=0, > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > [ 329.396293] panfrost 1800000.gpu: gpu sched timeout, js=0, > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > sched_job=0000000004c90381 > [ 329.411521] panfrost 1800000.gpu: Unhandled Page fault in AS0 at VA > 0x0000000000000000 > [ 329.411521] Reason: TODO > [ 329.411521] raw fault status: 0xAA0003C2 > [ 329.411521] decoded fault status: SLAVE FAULT > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > [ 329.411521] access type 0x3: WRITE > [ 329.411521] source id 0xAA00 Just to keep a track of this issue. Piotr Oniszczuk give more test and seems to be software related: https://www.spinics.net/lists/dri-devel/msg264279.html Ondrej gave a great explanation about a possible origin of this issue: https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 20:12 <megi> looks like gpu pll on H6 is NKMP clock, and those are implemented in such a way in mainline that they are prone to overshooting the frequency during output divider reduction 20:13 <megi> so disabling P divider may help 20:13 <megi> or fixing the dividers 20:14 <megi> and just allowing N to change 20:22 <megi> hmm, I haven't looked at this for quite some time, but H6 BSP way of setting PLL factors actually makes the most sense out of everything I've seen/tested so far 20:23 <megi> it waits for lock not after setting NK factors, but after reducing the M factor (pre-divider) 20:24 <megi> I might as well re-run my CPU PLL tester with this algorithm, to see if it fixes the lockups 20:26 <megi> it makes sense to wait for PLL to stabilize "after" changing all the factors that actually affect the VCO, and not just some of them 20:27 <megi> warpme_: ^ 20:28 <megi> it may be the same thing that plagues the CPU PLL rate changes at runtime Regards, Clement > > Regards, > Clement > > > > > > --- > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80 ++++++++++++++++++++ > > > 1 file changed, 80 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > > index 8f514a2169aa..a69f9e09a829 100644 > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi > > > @@ -174,6 +174,7 @@ gpu: gpu@1800000 { > > > clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>; > > > clock-names = "core", "bus"; > > > resets = <&ccu RST_BUS_GPU>; > > > + operating-points-v2 = <&gpu_opp_table>; > > > #cooling-cells = <2>; > > > status = "disabled"; > > > }; > > > @@ -1036,4 +1037,83 @@ map0 { > > > }; > > > }; > > > }; > > > + > > > + gpu_opp_table: gpu-opp-table { > > > + compatible = "operating-points-v2"; > > > + > > > + opp@216000000 { > > > + opp-hz = /bits/ 64 <216000000>; > > > + opp-microvolt = <810000 810000 1200000>; > > > + }; > > > > All those nodes will create DTC warnings though. > > > > Maxime _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
