<tomeu>
but enough seems to be powered on by mainline if we are able to read the GPU version ID
guillaume_g has joined #panfrost
pH5 has quit [Quit: bye]
<narmstrong>
tomeu: the same were needed in kbased for midgard, but midgard works like a charm with the same error at probe
<narmstrong>
tomeu: so I assume it will be ok
<tomeu>
hmm, but the gpu reset seems to fail when we come out of runtime suspend
<tomeu>
[ 221.938800] panfrost ffe40000.gpu: gpu soft reset timed out
<tomeu>
[ 221.939913] panfrost ffe40000.gpu: error powering up gpu
<tomeu>
anyway, soon will try to use the gpu and we'll see what happens
<narmstrong>
tomeu: erf, looks bad
<tomeu>
robmur01: any ideas on what could be wrong in mainline?
<narmstrong>
tomeu: I asked amlogic about what was the integration issue with midgard and bifrost, they didn't answer me....
<narmstrong>
I thought midgard would need some custom fixup, but nop
<tomeu>
maybe Arm will know :)
<narmstrong>
I hoped bifrost either
<narmstrong>
the weird stuff they use is Mali_WrReg(GPU_CONTROL_REG(PWR_KEY), 0x2968A819); and Mali_WrReg(GPU_CONTROL_REG(PWR_OVERRIDE1), 0xfff | (0x20<<16));
<narmstrong>
and they power on all the cores manually
<narmstrong>
I suspect the HW controller power control is broken on amlogic socs, but do we use it on mainline ?
pH5 has joined #panfrost
<tomeu>
narmstrong: yeah, doesn't seem to be fully powered on, because I get "AS_ACTIVE bit stuck" as soon as I try to submit a job
<tomeu>
and it complains about the GPU ID not matching
<tomeu>
ERROR: The DDK (built for 0x70030000 r0p0 status range [0..15]) is not compatible with this Mali GPU device, /dev/mali0 detected as 0x7212 r0p0 status 0.
<alyssa>
Meow.
<tomeu>
guess 0x70030000 is supposed to be a (weird) GPU ID?
<tomeu>
narmstrong: chewitt: working great, thanks!
<chewitt>
there's probably a better way to fix that, but fingers crossed some clever folks figure out Bifrost support and render mali_kbase irrelevant :)
<tomeu>
chewitt: I just hacked add_mm_counter out from kbase :p
<narmstrong>
At some point I stopped hacking mali_kbase for mainline, hoping it will be dropped shortly !
<tomeu>
narmstrong: I think gbm should be enough, for glmark2 at the start, and for deqp for the rest :)
<chewitt>
I have G31 gbm-wayland blobs somewhere too .. or can email Amlogic to get them
<tomeu>
narmstrong: that's cool, have been thinking lately about how much it must suck for people that SBC and STB vendors provide only such old android versions
<tomeu>
narmstrong: and wondered if we could have a generic device definition in fdo, whcih would only target mainline ABIs
<narmstrong>
tomeu: it will be even cooler with panfrost
<tomeu>
chewitt: I get the same, but afterwards I'm able to submit jobs
<tomeu>
and then I get faults
<chewitt>
ahh, ok
<tomeu>
may be good to check in kbase whether they also check the value of those registers or not
<tomeu>
because if they do, then maybe we are missing something in the init sequence
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
buzzmarshall has joined #panfrost
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
yann has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
<jstultz>
tomeu: probably need to prove it out first. the generic one rob did was really cool, but there was a lot of non-generic bits that had to be configured, which the google devs didn't really go for.
<jstultz>
tomeu: audio for example, which uses upstream interfaces for the most part, all need custom hals to handle how everything is routed for each device. qcom wifi always needs some userland help, etc.
yann has quit [Ping timeout: 255 seconds]
pH5 has quit [Quit: bye]
<robher>
jstultz: have things improved much? vendor only builds perhaps?
yann has joined #panfrost
<jstultz>
robher: not really.. the google devices sort of nest a bunch of common dir to share device config where they can, so everything isn't duplicated, but its also harder to track where the device config bits actually are.
<jstultz>
tomeu: so back to your question - something on fdo initially might be best. graphics, wifi, bt, usb should all be able to be generically targeted, but finding boards that supports all those generic targets might be tough
nerdboy has joined #panfrost
robmur01_ has joined #panfrost
<robmur01_>
tomeu: do you have "drm/panfrost: Remove core stack power management" in your kernel?
<robmur01_>
IIRC without that you always get the "error powering up gpu" condition in bifrost, although it's benign
guillaume_g has quit [Quit: Konversation terminated!]
pH5 has joined #panfrost
<chewitt>
kmscube attempts to open kms_swrast
raster has joined #panfrost
<janrinze>
How is the work on G72 going? Any chance we can test something on the HiKey970?
stikonas has joined #panfrost
davidlt has quit [Ping timeout: 240 seconds]
raster has quit [Quit: Gettin' stinky!]
<HdkR>
janrinze: Major work for Bifrost is just now coming up. Code emission isn't even to a state that it can be considered working
<janrinze>
HdkR: if there is anything i can do to test or help out, let me know.
<anarsoul>
I don't think there's anything you want to test yet
<alyssa>
jstultz: rk3288/rk3399 generic is probably a good bet?
<alyssa>
(note i haven't been following too closely, very all over the place rn)
<alyssa>
following IRC I mean
vstehle has joined #panfrost
<jstultz>
alyssa: yea, that one would probably be good (though I don't know about the bt/wifi on the board), but its just a small set of devices that wouldn't need some non-generic userland bits