00:26 <mearon> btw, archlinuxarm provides a mainline kernel for kevin

00:26 <mearon> I'm using it and it's running fine

00:26 <mearon> (but I have a light workload / simple use case only)

01:04 <Lyude> alyssa: you have a kevin right?

01:18 <HdkR> Lyude: Zero devices running mainline

01:19 <HdkR> The XU4 is probably the closest to mainline that I have

01:45 <Lyude> hm

02:06 <Lyude> alyssa: got an example of a typical gpu address for a jc?

03:16 <Lyude> oh-found where we're passing it the address it's faulting at

03:17 <Lyude> https://paste.fedoraproject.org/paste/P3wedwJu11xqp9BD5EvsTw (line numbers probably slightly off since i've got some debugging printfs in there)

03:37 <alyssa> Lyude: erm, no, the header is definitely the same

03:37 <alyssa> panwrap is just spitting back what we send; they're using the same hardware

03:38 <alyssa> If panwrap is seeing junk, we're sending junk

03:38 <alyssa> And I'm positive the header is the same, since it's same between T6xx and T860 ;)

03:38 <alyssa> Lyude: I do have a kevin

03:39 <alyssa> But I'm skeptical of the level of fine of "running fine"

03:39 <alyssa> mearon: How's audio support?

03:40 <alyssa> Lyude: It'll be junk because of the mmap issue

03:40 <alyssa> We're saying the GPU address we want to use is actually the cookie address

03:41 <alyssa> Except the cookie isn't mapped to anything, it's just a place value

03:41 <alyssa> (The panfrost_memory gpu has the cookie there)

03:41 <alyssa> And then we're uploading and using that as the base

03:41 <alyssa> So it's like if you we're 1024 bytes on the stack

03:41 <alyssa> And we're setting jc to 0xDEADBEEF + 1024

03:41 <alyssa> The memory allocator doesn't care; the hardware and panwrap do ;P

03:41 <alyssa> So the issue is isolated to allocate_slab; you need to have real addresses for both CPU and GPU

03:42 <alyssa> mmap does the gap. I don't know the new kernel so I can't tell you what changed

03:42 <alyssa> I know they've changed how they do mmap a dozen times so

04:25 <Lyude> alyssa: i was just about to come back to the computer and tell you that lol

04:25 <Lyude> erm-about the mmap failing

04:26 <Lyude> but yeah, i was about top go see what the kernel mmap function is actually doing

04:26 <alyssa> Oops? :P

04:26 <Lyude> at the very least it does seem like the gpu is working

04:28 <Lyude> and i think I figured out the weird SHAREABILITY issue when the GPU turns on is probably just us not clearing some kind of state in the platform code, which means the GPU just kind of comes up and probably fires off spurious interrupts until the kbase driver resets the GPU

04:29 <Lyude> which makes sense because the platform code i have is kind of hacked up right now :s

04:29 <Lyude> so now just to figure out what mmap is doing

04:36 <Lyude> alyssa: what's the kbase api version on your machine again?

05:27 <Lyude> oh HEY :D [21791.489854] mali d00c0000.gpu: error detected from slot 0, job status 0x00000058 (DATA_INVALID_FAULT)

05:27 <Lyude> progress

05:31 <alyssa> That _is_ progress!

05:31 <alyssa> kbase api is, uh,

05:55 <TheKit> can Panfrost still be tested with kernel driver from Mali and XShm output?

05:56 <Lyude> TheKit: yes, if you have the right mali_kbase version

05:56 <Lyude> right now i'm working on getting it workig on the latest r27 release

05:56 <TheKit> before it worked back in august or september, I think

05:56 <Lyude> if it worked for you back then then it should still work

05:56 <TheKit> but I see screenshot from Weston - was it run on X or there is support for buffer sharing now?

05:57 <Lyude> i think it is still on X

05:57 <Lyude> or rather-yes, it is

06:03 <Lyude> https://gitlab.freedesktop.org/lyudess/panfrost-mesa/tree/wip/mali-uapi-update <- alyssa

06:04 <Lyude> also; do you have any idea what the invalid data might be coming from?

08:00 <tomeu> robclark: I think we are still undecided on whether to have a single kernel driver for utgard and midgard/bitfrost

08:08 <tomeu> Lyude: you aren't using the devicetree platform?

08:09 <tomeu> I think that, with MR #1 and a DT that complies with the mainline gpu bindings, things should just work

08:09 <tomeu> without any code changes

10:19 <mearon> alyssa: audio is the only thinng I haven't gotten to work yet (since it's not very important for me)

10:19 <mearon> I forgot about that

10:19 <mearon> all the other stuff, I can't remember anything being difficult / not working OOTB, OTOH

12:30 <robclark> tomeu, well, I guess the biggest question is whether the same uapi for cmd submission would work for both or not? I'd assume a single driver would get you some amount of re-use..

13:23 <tomeu> anybody knows under which conditions KBASE_IOCTL_JOB_SUBMIT wouldn't return?

16:35 <Lyude> tomeu: it doesn't-but i'm fairly sure I know the reason why

16:40 <Lyude> tomeu: have you managed to get any working demos on your panfrost setup yet?

21:52 <Ashy> so the rockpro64 has not yet been mainlined right?

21:53 <Ashy> i can't find any mention of it in torvalds tree

21:54 <anarsoul|2> Ashy: it's in linux/arch/arm64/boot/dts/rockchip

21:54 <anarsoul|2> rk3399-rockpro64.dts

21:56 <Ashy> oh cool

21:56 <Ashy> dunno how i missed that

21:59 <Ashy> ok i'm gonna order one then

22:00 <anarsoul|2> Ashy: well, not everything is supported yet

22:00 <anarsoul|2> I'm not sure if HDMI is working

22:01 <anarsoul|2> ask on #linux-rockchip what's missing for rk3399 in mainline

22:01 <Ashy> that's ok i know it's a work in progress

22:05 <Ashy> long term plan is to learn me some kernel dev for great good

22:06 <Ashy> oh if hdmi isnt working, how's the edp support?

22:06 <Ashy> i have an old thinkpad panel that looks to be 30pin edp