ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
al3xtjames has quit [Quit: Ping timeout (120 seconds)]
al3xtjames has joined #asahi
<alyssa> j_ey: yeah I was trying to fit things into 280 chars
* steev notifies buzzfeed that alyssa is tweeting again
kettenis has quit [Ping timeout: 480 seconds]
<alyssa> snrkt
<alyssa> social media is silly.
<alyssa> robinp: What about ?
<robinp> just your fame :P
<alyssa> Linux famous != Famous 😉
kettenis has joined #asahi
<alyssa> I've been saying "just a few more min of display driver and then i'll do school" all day
<alyssa> I guess I better actually do school now..
<klange> Don't skip school. The paper they give you can be really useful even if the other bits aren't.
<alyssa> 🎓
Gues__________________________ has joined #asahi
Gues__________________________ has left #asahi [#asahi]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
<marcan> can confirm
yuyichao has joined #asahi
<sven> you can skip school and still get that paper though :)
<klange> I skipped quite a few classes in my uni days and almost didn't get the paper because of it, would not recommend doing too much of that.
<chadmed> yeah i skipped tons of classes in my first stint in undergrad, not great
analoq has joined #asahi
quarkyalice_ has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
analoq_ has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
<sven> skipped lots of classes during my bsc and msc, still got a phd in the end. now i wouldn't necessarily recommend it but i'd do it again this way
<marcan> I think I only went to like 5 classes for Computer Architecture, still got an A
<marcan> ... but not all professors are cool with that kind of approach
<sven> yeah
<sven> really depends on the class and prof tbh
<marcan> sven: so you forgot how CRCs work, right?
<sven> :D
<sven> yup
<marcan> figured
<sven> they are complicated maths ofc!
skali has joined #asahi
skali has quit []
marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<marcan> registered #asahi-stream for the stream chat
<chadmed> the woman that ran my uni's anatomical sciences department is insane. she designs her assessments to be as inconvenient and convoluted as possible such that they require you to simply have knowledge outside of the curriculum. she admitted in her first lecture that she deliberately does this to make our grades worse as a "reality check"
<chadmed> i do not know why such people are allowed to become educators, or allowed to stay in those positions once their stupid bs has been outed
<chadmed> wishing i actually did computer science as my undergrad now, but even then the unis in my city have terrible compsci degrees. one is basically just bachelor of oracle db and the other is just bachelor of web development. no one i know who graduated from either actually did ANY computer science. i think one uni has a course where you have to show that you can use ssh to pass but thats about it
<marcan> streaming shortly: https://youtu.be/zE6N3JfVJu8 (chat on #asahi-stream please)
<JTL> chadmed: wow wtf
<JTL> that sounds pretty terrible
<chadmed> yeah suffice it to say i have not enjoyed my undergrad much at all mostly on account of this woman. sucks doubly hard because in order to progress to med school here you need to have certain grades in her courses and she knows that
<chadmed> oh well such is life
OliverGraff[m] has joined #asahi
OliverGraff[m] is now known as ograff
x56 has quit [Quit: Ôž-Ôž]
x56 has joined #asahi
aleasto has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
rethematrix[m] has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
j_ey has quit [Quit: leaving]
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
notjoey has joined #asahi
chadmed has quit [Remote host closed the connection]
notjoey has quit [Quit: WeeChat 3.2]
tomtastic_ has joined #asahi
tomtastic has quit [Ping timeout: 480 seconds]
obflv[m] has joined #asahi
chadmed has joined #asahi
j_ey_ has joined #asahi
j_ey_ has left #asahi [#asahi]
j_ey has joined #asahi
<j_ey> (is my connection working? having trouble with SSL)
<chadmed> i can see your messages fine
<j_ey> thx
<landscape15[m]> Do you need to set permissive security also for the main OS drive? Sometimes i get some errors with bputil.
<j_ey> marcan: cherry-picked the new clock gate code, and it works with the keyboard patches I have
<sven> marcan: how did this ever work for you? i get serrors unless i fix that line to map it as nonposted
<sven> but once i fix that line it boots all the way to nvme
<j_ey> I have to look back at the _np details.. but that was only for certain memory regions right? not all mmio?
<sven> pcie doesn't need it, the rest does
<sven> uh. maybe the second stage translation made it nonposted
<j_ey> Im also running under the hv
<kettenis> I think it is a probe ordering thing
<kettenis> if syscon gets probed first it uses devm_ioremap() which does the right thing
<sven> oh, fun.
<sven> good catch
<kettenis> this is a bug in the syscon driver of course
<j_ey> is probe order defined by BT order?
<j_ey> *DT
<kettenis> on openbsd it is
afwolfe has joined #asahi
afwolfe has quit []
yuyichao has quit [Ping timeout: 480 seconds]
<marcan> sven: that is... a good question.
<marcan> wait hold on
<marcan> hypervisor!
<marcan> the stage2 translation hides the nonposted problem I bet
<marcan> (or the probe order thing?)
<marcan> oh you also said that :p
<marcan> anyway I'll fix that
<j_ey> also m1n1's 017f050fffb8f426eafe65b6a24d71fdc16131f7 reboots my m1 and kills the python side for me
<j_ey> Im hoping someone else can test soon
<maz> marcan: has anyone documented the ESR values reported for an IMPDEF SError?
<marcan> don't think so
<marcan> j_ey: are you sure you're syncing python and C?
<marcan> I changed the prototype for that call
<marcan> remember to chainload etc
<j_ey> I will double check in a bit, but im pretty sure I had
<maz> marcan: I can trigger one almost at will from a KVM guest: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=hack/m1-pcie-v2&id=2c9981b6a289354c22989e70cef0e51b9e632091
<marcan> maz: bahaha nice hack
<marcan> also I really need to get the kernel to dump the L2C stuff from apple
<marcan> yeah that :)
<marcan> honestly I'd love to upstream that if it'll fly
<maz> marcan: I suspect that it happens at the point where we turn the MMU off between the EFI stub and the kernel proper.
<sven> that patch is mostly just c&p from m1n1 fwiw
<marcan> maz: sounds like a cache thing
<maz> marcan: or TLBs.
<marcan> yeah
<maz> sven: thanks, I'll give that a go and see what or reports (though that will probably be just more random numbers we can't make sense of).
<marcan> I did poke around *those* bits
<maz> s/or/it/
<marcan> sven: so er, any why it boots for you and not me? :p
<marcan> *any idea
<sven> i hope it's not some rtkit firmware differences :/
<sven> can you printk the messages it sends/receives through the mailbox?
<marcan> I'm on 12.0 fwiw
<marcan> sure
<alyssa> what are we trying to boot?
<marcan> and AIUI this firmware is not macos-tied, so if the update broke it we were doing something wrong to begin with
<marcan> alyssa: ANS
<sven> is the guest RAM just translated 1:1 for the 2nd stage?
<alyssa> Ah!
<marcan> alyssa: btw, linux runs on the HV with vUART now, convenient for testing
<marcan> sven: yes
<alyssa> marcan: oh, awesome
<marcan> also I wrote a clock driver
<alyssa> marcan: bringing up display driver without UART was real "fun", since adding the disp0 DART to the dt automatically caused the screen to go black on boot :-p
<marcan> I think it's pretty enough to have a chance at upstream, I'll probably throw it over the fence soon, once we verify it works with all the bits and pieces so far
<alyssa> (My hack workaround was to swap out the disp0 dart for the dispext0 dart etc)
<marcan> lol
<marcan> yeah it'd do that :p
<alyssa> but hey now we have double buffering and 99% of the code will be reused for DCP 🤷
<marcan> sven: fwiw, please add more debug to this whole thing
<marcan> the usual dev_dbg stuff etc
<sven> sure
<marcan> debugging ASC/RTKit stuff is going to be a massive PITA without it, sane debug should be part of the driver forever
<marcan> (just not enabled by default)
<marcan> same with all the GPU/DCP/etc stuff
<marcan> anything talking to firmware needs piles of debug we can just toggle on
<marcan> will make life much easier
<alyssa> marcan: btw, where is your branch with mainlinable clock gate?
<marcan> sven: btw, is there a reason the mbox driver is gpl2 only?
<alyssa> would like to rebase my downstream on it
<sven> marcan: probably because i copy/pasted that from somewhere else
<marcan> alyssa: clk/new
<alyssa> thx
<alyssa> I think I have corellium's driver? or was it sven's one with the commit message "WIP"? or....
<marcan> bindings are a lie, it's not like actually upstream-ready git wise
<alyssa> yeah will do that rebase :-p
<marcan> but the basic driver idea should be
<marcan> you're going to have to change your DT to the new format :p
<alyssa> that's fine
jbowen has joined #asahi
<alyssa> the PCIe DT is still being fought over upstream
<maz> alyssa: it look OK. I'm respining the MSI side of it.
<kettenis> we need to trick maz into looking at robh's and mine latest musings
<maz> kettenis: it didn't look too bad last time I checked. at least, that's a (semi) universal way of describing a range.
<kettenis> maz: i'll see if I can beat some yaml into shape then
<marcan> maz: ok, so not that kind of SError at all
<maz> kettenis: cool, thanks for that.
<marcan> (those are empty)
<kettenis> maz: you'd be happy with a msi-controller.yaml that defines the controller side of things?
<marcan> I guess then there's another cause register, probably ESR itself then, or one of the impdef regs
<maz> kettenis: that'd be great.
<marcan> maz: you're in uncharted territory then :)
<alyssa> maz: good luck :>
<maz> marcan: yup, that's what I thought. the ESR always has the same IMPDEF value 0xbf40100a. it triggers exactly once per VM boot (every time the guest reboots as well).
<alyssa> maz: BTW, not sure if you noticed but the msi-addr is passed in the Apple device tree
<alyssa> I guess this means it could change from Apple SoC to Apple SoC?
<maz> alyssa: I did notice, but I doubt there is anything HW-dependent behind this address.
<marcan> maz: for fabric/etc stuff I get 0xbe000000, so very different
<alyssa> nod
<marcan> smells like yours is coming from the core itself
<kettenis> we can pick any (32-bit) address we want it seems
<maz> marcan: yup, which is why I'm thinking of TLBs.
<marcan> yup
<marcan> sven: so it gets the hello, sends the helloack, then crickets
<sven> what's the exact hello packet?
<marcan> [ 0.039277] apple-mailbox 23e408000.mbox: > TX 0060000000000020 00000000
<marcan> [ 0.039410] apple-compat-mailbox 23e400000.mbox: RTkit: waiting for boot
<marcan> [ 0.039539] apple-mailbox 23e408000.mbox: < RX 00100000000c000b 00000000
<marcan> [ 0.039734] apple-mailbox 23e408000.mbox: > TX 00200000000c000b 00000000
<sven> ah yes
<sven> new version
<sven> c000b vs. b000b
<sven> that's either the protocl or the rtkit version afaik
<marcan> sure, but ANS is part of SFR and has to be backwards compatible
<marcan> so we're doing something wrong if an update broke it
<marcan> it's not like DCP
<sven> try to reply with with b000b instead of just replying with that it sent you
<marcan> good point
<j_ey> sven: excuse me
<marcan> yup it boots
<kettenis> maybe c000b means it supports protocol versions between 11 and 12?
<sven> yeah, figured as much
<marcan> interesting, so that's backwards compat on the copro side
<marcan> wonder what macos does
<marcan> [ 0.191999] nvme0n1: p1 p2 p3 p4 p5 p6 p7
<sven> yup, looks good
<marcan> let me hvtrace this on macos 12, see what changed
<marcan> [ASCTracer@/arm-io/ans] [management] <0x1(HELLO) 00100000000c000b (TYPE=0x1)
<marcan> [ASCTracer@/arm-io/ans] [management] >0x2(HELLO_ACK) 00200000000c000c (TYPE=0x2)
<marcan> that's starting to sound like lower, higher supported versions
<marcan> and you're supposed to pick one
<marcan> nice, trying to boot 12.0 beta3 kernel on 12.0 beta5 firmware yields:
<marcan> panic(cpu 0 caller 0xfffffe0014dc288c): GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 - agx_background(2)
<marcan> I guess that's *another* firmware with compat issues. hopefully not as insane as DCP though.
<alyssa> Womp womp.
<marcan> [ASCTracer@/arm-io/ans] [syslog] <0x1(GetBuf) 0010400000000000 (TYPE=0x1, UNK1=0x4, DVA=0x0)
<marcan> [ASCTracer@/arm-io/ans] [syslog] >0x1(GetBuf_Ack) 0010400823d90000 (TYPE=0x1, UNK1=0x4, DVA=0x823d90000)
<marcan> I saw UNK1=3 before, I wonder what that field is...
<sven> marcan: yeah, it's [min, max] version
<sven> and UNK1 is size in uhh.. 16k pages i think
<alyssa> the field doesn't exist it's just a horror film trope that whenever you think about it the number goes up by one and when the field overflows something ominous happens
<marcan> I was thinking size, but I thought it was just one page
<sven> or maybe 4k pages actually
<marcan> unless they just... allocate more than they need
<marcan> ohh that would make sense
<sven> it's in 4kpages
<sven> see my horrible rtkit.c :P
<marcan> 3 and 4 would both round to one 16k page
<kettenis> the version range suggest that at some point they may break backwards compatibility
<kettenis> but at least we can tell!
<marcan> they can't
<marcan> not for this
<marcan> that would break old macOS versions forever
<marcan> they get to play fast and loose with this crap with DCP and AGX and a few others, but ANS, SEP, SMC and friends have to be backwards compatible forever
<alyssa> foreverrrrr
<alyssa> marcan: i'm curious why DCP/AGX are different from SMC?
<marcan> SMC, ANS, SEP firmware is part of SFR
<marcan> that means there is one true version and it only ever rolls forward
<marcan> it is not part of the iBoot2 bundle
<alyssa> Ooh
<marcan> I mean think about it, downgrading firmware on your *SSD* would be a terrible idea for your data
<marcan> same with your, you know, secure enclave (for security)
<marcan> and SMC is low level enough to be in the same boat
<alyssa> jokes on you my data are just clones of giant foss projects and fanfiction
PedroArajo[m] has joined #asahi
PedroArajo[m] has left #asahi [#asahi]
<j_ey> marcan: ok, the vuart is working better now. Dunno what happened before (I know I was chainloading.. but *shrug*)
<j_ey> only thing is that I get a ton of ????? whenever I try type anything
<marcan> that's weird
<j_ey> I didnt set a baudrate with picocom
<marcan> it shouldn't matter for this
<marcan> sven: pushed version negotiation to the nvme branch
<marcan> nvme/wip-clocks
<kettenis> I'll need to do that in u-boot as well
<kettenis> at least we've figured out another bit of the protocol ;)
<marcan> pushed it for the python stuff in m1n1 too
<marcan> fwiw DCP says [12,12], which sounds like the version number is a general RTKit thing, not anything specific to each device
<marcan> no idea what changed between 11 and 12 yet :)
chadmed has quit [Ping timeout: 480 seconds]
<marcan> sven: wanna run with this for a bit while I work on i2c?
<marcan> also it's starting to sound like I should be dumping a proper rootfs on my nvme, finally...
<sven> nvme has been pretty stable for me fwiw
<sven> i've been using that with a real rootfs for quite a while now
<marcan> cool!
<sven> still needs cleanup etc., but the mailbox is almost ready imho
<sven> and i kinda want to wait until i cleanup rtkit until alyssa tortures it with DCP and we actually know what we need there
<marcan> sure
<marcan> sven: can you check that the of_iomap thing fixes your ioremap issue?
<marcan> I want to fire that one off asap
<sven> my fix was literally the same diff ;)
<sven> so yeah, it works
<marcan> cool
<marcan> arnd: apparently you're the maintainer, so you've got mail :)
jeffmiw has joined #asahi
jeremiah has quit [Ping timeout: 480 seconds]
<hramrach> /buffer 4
<alyssa> sven: DCP is a nontraditional method of torture
<alyssa> marcan: can y'all CC me on m1 patches? thanks :)
<marcan> ah, sure
<alyssa> (I guess I could add myself as "R: " on the asahi maintainers entry)
<marcan> feel free
<marcan> didn't bother CCing anyone other than the get_maintainers stuff for that ioremap thing since it's beyond trivial
<sven> as evidence by both of us writing the exact same patch :-)
<sven> *evidenced
<alyssa> marcan: trivial or not, I'd like to be aware of all m1 related patches so I can collect fixes on my downstream
<marcan> yeah :p
<alyssa> (obviously I'd get it on the next linux-next rebase but still)
<marcan> alyssa: I'm still going to do that devel branch thing, might spend some time on that tomorrow before i2c
<marcan> so you probably want to go off of that (and anything upstreamed should end up there first)
<sven> alyssa: DCP is just there to prepare you for AGX :>
<marcan> sven: is the smc bring-up required for nvme to work properly?
<sven> marcan: nope
<sven> that's was just there because i wanted to test the shmem MMIO thing it does
<marcan> ack
<sven> it's also nice because it spams the syslog every time you press the power button
<marcan> heh
<alyssa> it's a good smoke test!
<alyssa> marcan: It's not entirely clear to me how an automated devel branch would work TBH
chadmed has joined #asahi
<marcan> people push to feature branches and they get automatically merged into a branch, a la linux-next
<alyssa> and how are conflicts resolved?
<alyssa> and what if a branch gets respun for a v2/v3/v4/..?
<alyssa> linux-next works because, AFAIU, it's overwhelmingly patches that will land in mainline as-is
<alyssa> already through the review battery, not bleeding edge
<marcan> conflicts aren't resolved; largely we should be touching different subsystems, the only pain point I foresee is the devicetree
<alyssa> sven: here have a name drop, you'll be able to get your non-bobsledding achievements on WP in no time 😋 https://www.theregister.com/2021/08/23/gnome_asahi_linux/
<alyssa> marcan: device tree conflcits have been intense IME
<marcan> especially at *this* stage
<marcan> things will settle down a bit soon enough though
<marcan> we're working through common code (clocks, mailbox)
<marcan> the merge branch would also be rewritten, so respins would just get reapplied
<alyssa> I hope so..
* alyssa shrugs
<alyssa> I thought it through and came to the conclusion that manually rebasing would be less work than trying to automate, but I wouldn't mind being proved wrong.
<marcan> I mean you'll still want to rebase as you work, the main thing is we have a weirdo dependency chain in some places and this would let us point people at one place instead
<marcan> but it might make more sense to do it manually, maybe I should just make it a weekly thing or something
<marcan> might keep me on top of things
jeremiah has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<alyssa> marcan: i mean, that's why I started doing the date branches
<alyssa> I can point people to 20210823 and oh that's literally the kernel i'm dogfooding today
<alyssa> (okay actually my m1 is off right now but shh)
stelleg[m] has joined #asahi
jbowen has quit [Read error: Connection reset by peer]
jbowen has joined #asahi
jeremiah has quit [Ping timeout: 480 seconds]
<maz> marcan: the SError seems to be triggered by this sorry excuse for a vGIC. thankfully, we can repurpose the ThunderX hacks, which seem to do a reasonable job at hiding the HW issues.
<alyssa> :D
<maz> I wonder if Apple hired the same HW designer who fscked it up the first time.
<alyssa> lol
<alyssa> maz: Out of curiousity what's your interest in KVM?
<j_ey> you mean outside of being the maintainer? :P
<maz> alyssa: I only spent 10 years of my life writing KVM for arm64. no big deal.
<j_ey> and the next ten on pKVM :P
<alyssa> j_ey: ah!
<alyssa> maz: ....To be fair, I think my question only applies 10x more now 😋
<maz> alyssa: writing a full blown hypervisor is similar to writing a CPU. I guess this satisfies my HW inclination enough that I don't have to write any RTL...
<alyssa> I can respect that 😁
<hramrach> the ting is that linux-next is manually resolved. There tends to be no linux-next on weekends if you look closely
jeremiah has joined #asahi
jeffmiw has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #asahi
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
jeffmiw has joined #asahi
erincandescent has quit [Remote host closed the connection]
erincandescent has joined #asahi
shaman_br[m] has joined #asahi
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
yuyichao has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
* nico_32 is watching a replay of today marcan stream
<nico_32> current position: the multi parent clock
<j_ey> turns out marcan doesnt think that's needed
<nico_32> i was telling myself: is he going to implement a stp-like algo
<jeffmiw> Trying to look at spi/kbd interrupt and transfer stuff, I see accesses to sio and dart-sio, I understand that dart-sio should do some address translation of some sort(iommu like), but no clue on what sio is. Any one haveing any idea on how to look at them and interpret what there are doing ?
<j_ey> jeffmiw: I have been using the spi/kb patches without the DART code
<j_ey> so Im not sure what that's doing
<alyssa> j_ey: the DART code already landed in linux-next though, rebase more 😉
<j_ey> alyssa: I know I know!
jbowen has quit [Ping timeout: 480 seconds]
<j_ey> jeffmiw: I think the dart sio.. might be something unrelated? there appears to be an sio that looks like a coprocessor
<j_ey> sio { .. compatible = [iop,ascwrap-v4] .. }
<alyssa> Oof
<alyssa> how many ASCs are there T_T
<alyssa> ("9." "Thanks cptn obvious")
<alyssa> 8 if you ignore the second dcp
<j_ey> 8 from a quick ..
<jeffmiw> j_ey: may be unrelated ..
<jeffmiw> my understanding of the spi/kb patches are they are not using the interrupt and doing polling, so I was trying to better understand the interrupt mechanism
<jeffmiw> it seems I still have some work before figuring this out :)
<j_ey> hm device-type = dSPI..
<pipcet[m]> audio, maybe?
<j_ey> jeffmiw: im pretty sure the keyboard stuff is interrupts..
<jeffmiw> ah ok
<jeffmiw> I was seeing the sio like a dma specialized for serial but this is pure speculation :)
<j_ey> apple_spimc_irq for the actual spi irq and applespi_gpioirq_isr for the part in the keyboard driver
<alyssa> SSPI
<jeffmiw> j_ey: thx, I will check this
<jeffmiw> alyssa: what is SSPI ?
<alyssa> j_ey: are you in #asahi-re ..?
<j_ey> dunno
<j_ey> yes i am now
<j_ey> jeffmiw: are you looking at the corellium patches
<j_ey> ?
<pipcet[m]> jeffmiw; is it at all possible you've got audio feedback for keystrokes enabled? because audio would make sense, IMHO...
<jeffmiw> I was looking at the ones from amw : https://github.com/amworsley/AsahiLinux/tree/asahi-keyboard
<j_ey> pipcet[m]: I was thinking there was some confusion because spi has an clk_sio and stuff..
<jeffmiw> amw branch included some of the corellium patches as far as I understood
<j_ey> yeah
<j_ey> jeffmiw: all the ones that say 'Stan-Corellium' :)
<jeffmiw> yeah, not sure if they are all the ones you referred to by "corellium patches"
<jeffmiw> pipcet: not hearing any sound, just hitting enter or spacebar in a terminal window
jeremiah has quit [Quit: leaving]
<sven> fwiw, dart-sio is special and either needs full bypass mode or someone to reverse engineer how DAPF actually works and set that one up
<sven> it's used for at least the aes engine
<sven> and spi probably doesn't support DMA
<sven> otherwise it would have an iommu-mapper in the ADT
jbowen has joined #asahi
<j_ey> makes sense
<sven> they *could* do something crazy like have that co-processor drive the SPI controller and then DMA the results back but uhhh.... that would surprise me
<jeffmiw> what those the dma-channels mean in the spi3 adt ? spi3 { .... dma-channels = ....}
<j_ey> hm good point
<sven> ... did they actually do the thing i just mentioned and called crazy?
<j_ey> spi3 has dma-parent = 134, which is sio-dma
jbowen has quit [Quit: leaving]
<jeffmiw> may be they need to do this "crazy" thing not for the keypad but because of the touchpad: touchpad will need more data volume and speed than the keypad for sure, and from a power it may be better to use a dma than cpu cycles for that ...
<sven> hrm, the co-processor would uses those cpu cycles then
desairc has joined #asahi
jeffmiw has quit [Ping timeout: 480 seconds]
<alyssa> sven: still possibly higher power consumption for the copro to do ld/st/ld/st/ld/st than a hw dma block
aleasto has quit [Quit: Konversation terminated!]
desairc has quit [Quit: desairc]
desairc has joined #asahi
skoobasteeve_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
skoobasteeve has joined #asahi
skoobasteeve has quit []
skoobasteeve has joined #asahi
<marcan> j_ey: because they get ORed with the sw IRQs and you wouldn't want to IRQ flood the guest
<marcan> maz: ha