00:05 <jekstrand> alyssa: Feel free to voulenteer me for anything you want to see sit undone for months or years. I have infinite backlog space, especially if you consider things I entirely forgot to still be in my backlog. :D

00:09 <alyssa> Alas

00:11 <jekstrand> Remember; I had 1023 unmerged branches when I started preparing to leave Intel. (-:

00:11 <HdkR> So really you just need someone to manage merging your code :P

00:11 <alyssa> So close to a nice round number

00:11 <jekstrand> It is. I was actually kind-of dissapointed there wasn't one more.

00:12 <icecream95> alyssa: It seems like getting the CSF registers from kbase might be difficult after all.. I guess I'll need to add a new ioctl to map the dummy_firmware_interface struct?

00:14 <icecream95> Hopefully the csf code is similar enough that it doesn't matter that I'm using the NO_MALI version

00:14 <icecream95> 1 file changed, 216 insertions(+), 1219 deletions(-)

00:18 <icecream95> Most of the deleted code in the firmware_no_mali.c is related to loading firmware, so that shouldn't be too much of a problm

00:19 <alyssa> I haven't looked at this in any detail

00:59 <icecream95> Maybe it's better to use a new magic VA similar to the 0x41000 value

02:47 <icecream95> Oops.. did I just find a memory corruption bug in kbase? It only occurs with NO_MALI and on module unload, so I guess that it isn't *that* serious

02:48 <icecream95> I'll just change it to a leak for now, it's only half a meg..

02:50 <icecream95> I can't load in a new kbase module, so I guess I can't do more Valhall today

11:04 <rasterman> cphealy: i see hessed finally replied. he's given you the reply i suspected you'd get ... unless you plan to tell them to go away with the mali ddk and switch to panfrost, i am wondering what i can do to help? the gpu group are their own vertical stack and make their own business decisions ... so i'm relatively limited.