Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table

["Clément Péron" <peron.clem@gmail.com>]

Hi Maxime and All,

On Sat, 4 Jul 2020 at 16:56, Clément Péron <peron.clem@gmail.com> wrote:
>
> Hi Maxime,
>
> On Sat, 4 Jul 2020 at 14:13, Maxime Ripard <maxime@cerno.tech> 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@gmail.com>
> >
> > 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