On Wed, May 29, 2019 at 10:38 AM Tomeu Vizoso <tomeu@xxxxxxxxxxxxxxx> wrote: > > On Wed, 29 May 2019 at 15:00, Robin Murphy <robin.murphy@xxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
