<urjaman>
didnt test yet, but these flags were what my ftrace pointed at (and that's how i found the fixed version from github search :P)
<urjaman>
mk, after that you get a "Oops - undefined instruction" at pl330_prep_slave_fifo when you try to do audio ...
<urjaman>
gotta look into it more later
<urjaman>
(i'm just getting confirmation of my general distaste for .0 kernels...)
_whitelogger has joined #panfrost
pH5 has joined #panfrost
BenG83 has joined #panfrost
BenG83 has quit [Remote host closed the connection]
BenG83 has joined #panfrost
pH5 has quit [Quit: bye]
hipboi has joined #panfrost
hipboi has quit [Quit: This computer has gone to sleep]
rhyskidd has joined #panfrost
<urjaman>
okay, so (effectively) reverting that original patch makes the sound work, so ... not anything that was done to the pl330 to blame (even if it is broken in some way)
<urjaman>
i think i'm done with this, maybe i should just put out an email saying that it is broken :P
<hanetzer>
thoughts: add a meson option to mesa whether to use the 'upstream' mali_kbase ioctl definitions vs 'from scratch' ones from mesa?
<urjaman>
this is a question for when we have support for both :P
<urjaman>
and yeah i did send out that email (after trying to look for any duplicates) announcing that sound driver fail :P
<urjaman>
and it was again rockchip themselves breaking their own stuff (same as with the usb thing)...
<Lyude>
hanetzer: I think that is a good idea this time around
<Lyude>
I only did the from scratch ones last time because things were such a mess
<Lyude>
but that isn't the case with the headers I looked at
<Lyude>
but we'll need to actually implement that API first
<Lyude>
also; i wouldn't use a meson option for that
<Lyude>
it probably should be one or the other, unless we're planning on supporting both ump and the new uapi
<Lyude>
hanetzer: did you make any progress getting panfrost to run on your device?
<urjaman>
<Lyude>
agreed
<urjaman>
oh lol sorry :P
<urjaman>
i think hanetzer managed to build it in a way where it tries to run? :P (it's not really working on 32-bit T7xx things atm)
<urjaman>
anyways i also have a setup that gets to the point where it "notices" the kernel API is wrong (have an ARM mali_kbase built etc), so if you do work on that i can help test
<Lyude>
urjaman: I've got it running myself actually; at least I've got it to the point that the kernel rejects it
<Lyude>
which should be all I need (thanks amlogic :)
<urjaman>
yeah i think that's the same point (the version ioctl fails since different structure or whatever) as where I am
<urjaman>
but anyways meant that if you start working on that (on T8xx i think on the amlogic thing? :P) i can also verify that whatever you do also works on T7xx
<Lyude>
ahhh, cool!
<urjaman>
basically i want to make it work again on T7xx, but would rather not unnecessarily debug the old mali_kbase :p
<Lyude>
i mean it should
<Lyude>
I'm hoping that we will have this working all the way back to the T6xx
<Lyude>
i am also going to poke some people too to see if I can get my hands on some armv7hf systems that can run mainline kernels
<urjaman>
yeah should be possible easily enough, just hasnt been tested in many months so i expect something to be broken (32-bit vs 64-bit, etc) :P