GC300 2D unit won't work with GC2000 3D disabled on MMP3

[Lubomir Rintel]

On Tue, Dec 01, 2020 at 03:28:05PM +0100, Lucas Stach wrote:
> Am Dienstag, den 01.12.2020, 14:49 +0100 schrieb Lubomir Rintel:
> > On Tue, Dec 01, 2020 at 11:33:36AM +0100, Lucas Stach wrote:
> > > Hi Lubomir,
> > > 
> > > Am Montag, den 30.11.2020, 18:07 +0100 schrieb Lubomir Rintel:
> > > > Hello,
> > > > 
> > > > (adding Ivan to Cc, since he brought the issue up privately. Ivan,
> > > > etnaviv@ is a moderated list, please subscribe if you're going to
> > > > reply.)
> > > > 
> > > > I'm wondering if anyone can help me understand what is going with
> > > > Vivante
> > > > GC300 on a MMP3 and find a reasonable fix. MMP3 has these two GPU
> > > > cores:
> > > > 
> > > >   [    2.142545] etnaviv-gpu d420d000.gpu: model: GC2000, revision:
> > > > 5026
> > > >   [    2.154468] etnaviv-gpu d420f000.gpu: model: GC300, revision: 4634
> > > >   [    2.166808] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv
> > > > on minor 0
> > > > 
> > > > Currently, clients that try to use the GC300 2D unit -- libdrm's
> > > > etnaviv_2d
> > > > test or the xorg-x11-drv-armada ddx on a MMP3 don't work and etnaviv
> > > > complains:
> > > > 
> > > >   [  295.077770] etnaviv-gpu d420d000.gpu: recover hung GPU!
> > > > 
> > > > That is, until the clock that's supposedly for the GC2000 3D unit are
> > > > turned on. Then things work fine.
> > > 
> > > I believe the above splat is with the etnaviv_2d_test? This test is
> > > broken in that it will just pick the first GPU core (in your case the
> > > GC2000) instead of looking for a core with 2D capabilities. Submitting
> > > 2D jobs into the 3D GPU will do nothing or hang the GPU, depending on
> > > the specific GPU generation.
> > 
> > Yes,
> > 
> > With core=0 the output is:
> > 
> >   etnaviv-gpu d420d000.gpu: recover hung GPU!
> > 
> > If I change the test to set core=1, I get two extra lines:
> > 
> >   etnaviv-gpu d420f000.gpu: recover hung GPU!
> >   etnaviv-gpu d420f000.gpu: GPU failed to reset: FE not idle, 3D not idle, 2D not idle
> >   etnaviv-gpu d420f000.gpu: GPU not yet idle, mask: 0x00000000
> 
> Okay, this looks at least somewhat like what I would expect with a
> missing clock.
> 
> As GPU cores are normally fully independent, I guess your understanding
> of the clock tree in the SoC isn't fully correct. Is it possible that
> GC3D_AXICLK_EN really is a clock source for both the 2D and 3D GPU core
> AXI interfaces?

It's certainly possible.

I don't know if there's a way to check that. There's zero documentation
-- all I got is the tree I got from Dell for the MMP3 kernels they ship
[1] and the OLPC tree [2] which has the same defines plus the reset
bits.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp3-dell-ariel.git/tree/arch/arm/mach-mmp/clock-mmp3.c#n1106
[2] http://dev.laptop.org/git/olpc-kernel/tree/arch/arm/mach-mmp/clock-dt.c?h=arm-3.5#n197

The clocks in both kernels don't have any useful granularity; they just
enable and disable everything in one go.

> > > I don't know exactly what the armada driver is doing, IIRC it properly
> > > looks for a 2D GPU core.
> > 
> > It seems to. It logs this line:
> > 
> >   [  1275.130] (--) armada(0): Vivante GC300 GPU revision 4634 (etnaviv) 2d PE2.0
> > 
> > The kernel output is:
> > 
> >   etnaviv-gpu d420f000.gpu: recover hung GPU!
> >   etnaviv-gpu d420f000.gpu: GPU failed to reset: FE not idle, 3D not idle, 2D not idle
> >   etnaviv-gpu d420f000.gpu: recover hung GPU!
> >   etnaviv-gpu d420f000.gpu: GPU failed to reset: FE not idle, 3D not idle, 2D not idle
> >   etnaviv-gpu d420f000.gpu: recover hung GPU!
> > 
> > > Is the symptom the same if the 2d_test is fixed to submit into the
> > > right GPU core?
> > 
> > See above.
> > 
> > Note that if I force the clock on the test succeeds (and the result is
> > correct) with either core=0 or core=1.
> 
> So you get the green rectangles in the picture even with core=0? That
> would be very unexpected.

No. I'm stupid. Sorry. I got some "clever" patches on top of the test that
messed up the results. I've hopefully fixed that now, sent them to the list.

So yeah, with the clocks on, it behaves as you'd expect -- fail on 3D
core and success on 2D one.

> >  I don't know if both cores are 2D
> > capable; I have no idea how to tell. Here the feature words are:
> > 
> >   core=0 ETNA_GPU_FEATURES_0 = 0xe0286cad
> >   core=0 ETNA_GPU_FEATURES_1 = 0xcb799eff
> >   core=0 ETNA_GPU_FEATURES_2 = 0x2e13b2d9
> >   core=0 ETNA_GPU_FEATURES_3 = 0x02000000
> > 
> >   core=1 ETNA_GPU_FEATURES_0 = 0xe02c7eca
> >   core=1 ETNA_GPU_FEATURES_1 = 0xe1399fff
> >   core=1 ETNA_GPU_FEATURES_2 = 0x2e13b219
> >   core=1 ETNA_GPU_FEATURES_3 = 0x00010000
> 
> 2D pipe is bit 9 in the FEATURE_0 register, so only the 2nd core claims
> to support 2D commands, as expected.
> 
> Regards,
> Lucas

Thanks
Lubo