alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
jolan has quit [Quit: leaving]
yann has quit [Ping timeout: 260 seconds]
stikonas has quit [Remote host closed the connection]
jolan has joined #panfrost
toggleton has quit [Ping timeout: 265 seconds]
kaspter has quit [Quit: kaspter]
kaspter has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
nerdboy has quit [Ping timeout: 260 seconds]
icecream95 has joined #panfrost
NeuroScr has joined #panfrost
marcodiego has quit [Quit: Leaving]
kaspter has quit [Read error: Connection reset by peer]
NeuroScr has quit [Quit: NeuroScr]
kaspter has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
icecrea105 has joined #panfrost
icecream95 has quit [Ping timeout: 268 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
NeuroScr has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
davidlt has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
icecrea105 has quit [Quit: leaving]
icecream95 has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
davidlt has quit [Ping timeout: 265 seconds]
<tomeu> [ 13.406082] panfrost ffe40000.gpu: clock rate = 799999987
<tomeu> [ 13.419507] panfrost ffe40000.gpu: mali-g52 id 0x7212 major 0x0 minor 0x0 status 0x0
<tomeu> [ 13.410534] panfrost ffe40000.gpu: ffe40000.gpu supply mali not found, using dummy regulator
<tomeu> [ 13.426573] panfrost ffe40000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
<tomeu> [ 13.435773] panfrost ffe40000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
<tomeu> [ 13.435777] panfrost ffe40000.gpu: shader_present=0x3 l2_present=0x1
<tomeu> [ 13.438768] panfrost ffe40000.gpu: error powering up gpu
<tomeu> narmstrong: any ideas?
mias has joined #panfrost
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #panfrost
yann has joined #panfrost
<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
mixfix41 has joined #panfrost
<narmstrong> tomeu: I tried to implement their stuff on panfrost for midgard, maybe you can have a try... https://github.com/superna9999/linux/commit/4ac25315460ac2a92cd30aad5675f73c55428a9b (it needs to be adapted)
<chewitt> narmstrong: I tested https://github.com/chewitt/linux/commit/e34cd04b3e5a8f925b89c4d5de8a5dacc802c963 but no difference to what you posted ^ earlier
<chewitt> "panfrost ffe40000.gpu: clock rate = 799999987" clock looks like an odd value?
<tomeu> narmstrong: chewitt: that patch works here
<tomeu> not 100% sure everythign is powered up correctly as nothing works, but at least I get now normal faults
<narmstrong> tomeu: nice to read, I can clean it and rebase on master
<chewitt> all I did was change the compatible in the patch, and add https://github.com/chewitt/linux/commit/8b9d182d51f9856e13c5bac272d36792aa946cbb to the driver so it probes
icecream95 has quit [Ping timeout: 258 seconds]
toggleton has joined #panfrost
chewitt has quit [Quit: Adios!]
chewitt has joined #panfrost
raster has joined #panfrost
karolherbst has quit [Ping timeout: 240 seconds]
karolherbst has joined #panfrost
<alyssa> narmstrong: that patch is scary :p
<tomeu> chewitt: narmstrong: do you know of a kbase for dvalin forward ported to recent kernels
<tomeu> ?
<alyssa> (what exactly is dvalin? is that mali-g52 specifically or other malis too?)
<narmstrong> It’s missing fixes for >5.4
<tomeu> thanks!
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #panfrost
<narmstrong> alyssa: dvalin is the codename amlogic uses
<tomeu> narmstrong: got it to build, but I'm getting this now on probe:
<tomeu> [ 45.558762] reset reset-controller@1004 (ID: 20) is not acquired
<alyssa> narmstrong: For specifically Mali-G52?
<tomeu> alyssa: apparently no, because I tried with the libmali for dvalin from https://github.com/hardkernel/buildroot_linux_amlogic_meson_mali/find/aml64_buildroot_master
<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?
<robher> tomeu: It's in there. There may be fewer issues because kbase has *all* issues while we only put issues affecting kernel code in the kernel.
<robher> So mesa needs it's own list.
<chewitt> tomeu: https://github.com/LibreELEC/mali-bifrost <= working on 5.6-rcX
<tomeu> damn, I was 17 days late :)
<chewitt> ^ this works with the G31/G52 in Amlogic hardware
<chewitt> ahh.. our blobs are GBM only, no Wayland support, for those you need the files from HardKernel
<narmstrong> Wayland is only for G52, we don't have Wayland blobs for G32
yann has quit [Remote host closed the connection]
<tomeu> ah, that blob seems to work here with a surfaceless context
<tomeu> thanks!
<tomeu> will try that other kbase
<tomeu> wonder why hardkernel are stuck with fbdev-only blobs
<narmstrong> because hardkernel sucks
<narmstrong> alyssa: they seems to use dvalin for g31, and gondul for g52
<tomeu> chewitt: you don't have a link error due to add_mm_counter wanting mm_trace_rss_stat?
<tomeu> ERROR: "mm_trace_rss_stat" [/home/tomeu/panfrost-prefix/source/mali-bifrost/driver/product/kernel/drivers/gpu/arm/midgard/mali_kbase.ko] undefined!
<chewitt> ahh.. there's a commit for that
davidlt has joined #panfrost
<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> well, I have tried kmscube only
davidlt has quit [Ping timeout: 255 seconds]
<narmstrong> I'm pretty sure @chewitt tested kodi aswell :-p
<chewitt> this is what I see http://ix.io/2e7a
<chewitt> but that's with mesa HEAD and current kernel driver
<narmstrong> tomeu: we have a zorking AOSP with linux 5.4 on Khadas VIM3L if you want more than GBM
<chewitt> or do I need to be choosing someone's branch
<chewitt> I have gbm-wayland blobs somewhere .. the original ones I got from HK I think
<narmstrong> this one should work, but I haven't tested it myself...
<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> so DRM, V4L2, Mesa, etc
<chewitt> tomeu: have you done anything more than this for the driver? https://github.com/chewitt/linux/commit/8b9d182d51f9856e13c5bac272d36792aa946cbb
<narmstrong> tomeu: it would be great to have on fd.o, but today we have it on google repos (https://android.googlesource.com/device/amlogic/yukawa/)
<tomeu> like what robh used to do when at linaro, but the next step, as upstram AOSP is moving towards mainline as well
<chewitt> I'm wondering why yours works and mine errors
<chewitt> only difference is that I'm using a G31 device not G52
<tomeu> chewitt: also drm/panfrost: add support for custom soft-reset on Amlogic GXM
<narmstrong> yeah and google is moving to close-to-upstream linux kernel
<tomeu> narmstrong: do you think your aosp device could be the base to such an effort? or better to start frmo zero?
<tomeu> chewitt: so if the compatible strings match your hw, then I don't knoww hat could be :/
<chewitt> I'll switch to a G52 device
<narmstrong> tomeu: it definitely could, it would need a cleanup from the yukawa project, but it could be good generic base for upstream-based AOSP
<narmstrong> the only non-genereic stuff is gralloc and the libMali
<tomeu> awesome, so many pieces have fallen into place, would be a pity not to provide people with aosp images :)
<narmstrong> with panfrost, mesa and robher's gralloc, it will be generic
<tomeu> nice
<tomeu> at some point we should look at codec2 and how it uses v4l2 as well
<tomeu> I saw such an implementation in google's git
<narmstrong> yeah, don't look at it for now, it's really in bad shape
* robher runs away
<tomeu> jstultz: do you think having such an effort at fdo would make sense? or maybe better at aosp's repo?
<tomeu> it could be the base for a proper spurv device as well :)
<narmstrong> we (baylibre) would love to have a shared device/generic/sbc on google repo with someone from google taking gerrit patches
<robher> narmstrong: Feel free to use for inspiration: https://github.com/robherring/generic_device
<tomeu> robher: I got the impression that it's more complex that needed because it allowed for people to choose their own HALs
<tomeu> I was thinking that this would have a single set of HALs, targetting mainline only
<narmstrong> tomeu: yeah, we thought we would only need a few files for yukawa, but AOSP needs a countless of useless files...
<narmstrong> and it's even worse with .bp
<narmstrong> robher: indeed, could be a good start point
<robher> tomeu: that was the goal too, but the reality at the time was not possible.
<tomeu> also, the countless of useless files changes with each version :p
<tomeu> robher: yeah, was just thinking that maybe this time we wouldn't need the kconfig stuff
<chewitt> same on a g52 device http://ix.io/2e7d
<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
robmur01_ has quit [Ping timeout: 240 seconds]
<chewitt> robmur01_: confirmed that picking https://patchwork.kernel.org/patch/11325689/ prevents that error message
<chewitt> from dmesg: http://ix.io/2e7W
cwabbott has quit [Quit: cwabbott]
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
pH5 has quit [Quit: -_-]
NeuroScr has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
nerdboy has quit [Ping timeout: 240 seconds]