[PATCH] drm/panfrost: Add AArch64 page table format support

[Rob Herring]

On Wed, May 29, 2019 at 10:38 AM Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>
> On Wed, 29 May 2019 at 15:00, Robin Murphy <robin.murphy at arm.com> wrote:
> >
> > Hi Tomeu, Rob,
> >
> > On 28/05/2019 08:03, Tomeu Vizoso wrote:
> > > Robin, Steven,
> > >
> > > would you or someone else at Arm be able to run the IGT tests [0] on
> > > 5.2-rc2 with this patch on top?
> > >
> > > I don't have any hw with Bifrost and am not planning to work on the
> > > userspace any time soon, but I think it would be good to at least
> > > check that the kernel doesn't have any obvious bugs.
> >
> > I've managed to cobble something together which appears to sort-of-work,
> > although I don't have the knowledge, time or patience to dive down the
> > rabbit-hole of getting a working Arm DDK driver to actually prove the
> > setup. The immediate observation is that I get a lot of this:
> >
> > [  305.602001] panfrost 6e000000.gpu: error powering up gpu
> >
> > Which appears to stem from the poking of STACK_PWRON_LO. Judging by
> > CONFIG_MALI_CORESTACK in kbase, maybe we shouldn't always be going there
> > anyway (Steve probably knows more, but is away for a few weeks ATM).
> >
> > I can't make much sense of the IGT output, but trying
> > "scripts/run-tests.sh -t panfrost" (because I also don't have the
> > patience to watch it skip through all ~63,000 tests...) seems pretty
> > much consistent with or without this patch.
>
> Oops, sorry about that. It would have been sufficient to directly run
> these executables:
>
> tests/panfrost_gem_new
> tests/panfrost_get_param
> tests/panfrost_prime
> tests/panfrost_submit
>
> > Same for trying kmscube with
> > mesa/master; that produces lots of job errors:
> >
> > [   42.409568] panfrost 6e000000.gpu: js fault, js=0,
> > status=DATA_INVALID_FAULT, head=0x2400b00, tail=0x2400b00
> > [   42.419380] panfrost 6e000000.gpu: gpu sched timeout, js=0,
> > status=0x58, head=0x2400b00, tail=0x2400b00, sched_job=00000000d17b91
> >
> > rather than MMU faults either way, so at least this change doesn't seem
> > to present any significant regression.
>
> That sounds pretty good to me. We know that the cmdstream and compiler
> aren't ready yet for Bifrost.
>
> > It looks like without this patch
> > we end up using AS_TRANSCFG_ADRMODE_LEGACY, which presumably means
> > exactly what it sounds like, although whether that's sufficiently
> > reliable I don't know; those kinds of backwards-compatibility features
> > do have a habit of eventually disappearing, and what I've tried so far
> > is certainly not the latest and greatest.
>
> One for Rob when he's back, I think  :)

I wouldn't have expected AS_TRANSCFG_ADRMODE_LEGACY to work and if it
did it was by chance. So I don't think it is something we want to
support.

Rob