16:15 <eiln> aop brought up for real

16:15 <eiln> [iorep] report!

16:15 <eiln> > 04:0x80000000000000 (TYPE=0x8)

16:15 <eiln> < 00:0x70000000000020

16:15 <eiln> [mgmt] IOP power state is now 0x20

16:15 <eiln> starting to understand mailbox now

16:15 <eiln> we're not even at the aop part yet (stacktraces say AppleA7IOP). added support for splitting endpoint bitmap init into top/bottom half (LAST=0, BASE=1, MORE=1) to even boot it

16:16 <eiln> sleep time for me.. zz

16:16 <j`ey> eiln: what's the difference between what you/povik had before and now? why is it real?

16:19 <eiln> j`ey: the version 2 days ago hacked around hw registers to boot it ("boot" being CPU state RUN=1, nothing else), which I realized was not right at all

16:19 <eiln> this time the syslog endpoints are all initialized too

16:20 <j`ey> eiln: ah neat :)

16:20 <j`ey> so really up like the other coprocs

16:22 <eiln> yeah so it now works the same way as dcp

16:23 <eiln> (same as in same api)

20:19 <Lyude> totally understand if this is a bit too far in history for anyone to remember, but I've been trying to go through asahi's commit log history to figure out what I need to pull in to get a skeleton DRM driver started to come up with an API for modesetting drivers in rust - and I'm mainly wondering if anyone might be able to help explain some commits that just don't seem to compile on

20:19 <Lyude> their own? currently looking at 2ade72f135b722691ff4729bdedb9f67e4d2bb49 ("drm/gem-shmem: Export VM ops functions") where going to that commit and trying to build fails with: https://dpaste.org/zix0E

20:19 <Lyude> Anyone have any idea why that might be?

20:20 <Lyude> I've looked all over and I can't seem to find any kind of implementation for raw()

20:32 <janneg> Lyude: I think you want 4250f95b214f3d285f8b2b3722cb3d8b46fc14f0 which has now "bindings::drm_gem_object_init(dev.raw_mut(), "

20:32 <Lyude> (looked a bit closer, I'm now guessing that since the context raw() is called from expects a mut and a later patch ends up changing that to raw_mut() - perhaps raw_mut() was called raw() at some point and just didn't get renamed in that patch?)

20:33 <Lyude> janneg: yeah I noticed that - just wasn't sure where the original raw() came from and whether I was missing a patch down the line :P

20:34 <Lyude> i'm a bit too used to kernel trees where almost every commit compiles, there's a couple of spots in asahi's commit history where that isn't the case

20:36 <j`ey> Lyude: that should be the case for upstreamed stuff

20:37 <Lyude> I figured as much :). currently focusing on downstream since there's a number of things that haven't been upstreamed yet that we need (and hope to help actually get upstream for y'all)

20:40 <janneg> Lyude: I think especially fixes necessary after newly released rust versions are out of order. as for Device.raw/raw_mut I think that was changed based on review comments and either not fixed or in other branches squashed into the commit as fixup

20:40 <Lyude> makes sense

22:42 <Lyude> I've got a bad question to ask: does anyone here have a setup for cross-compiling asahi's kernel tree on an x86_64 system, such that I can still use rust-analyzer for autocompletion on said x86_64 system? is this maybe not as terrifying to setup as it sounds?

23:14 <janneg> I think most of us are now using apple silicon systems for native compilation. I'm not sure if lina has ever gotten rust-analyzer to work in the kernel (or was that something else)