ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
brolin has quit [Ping timeout: 480 seconds]
<maz>
I'm running 6.3++ on my mini with mass storage on the USB-A ports, and it works just fine.
brolin has joined #asahi-dev
eiln has joined #asahi-dev
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
gabuscus has quit []
benpoulson has joined #asahi-dev
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
benpoulson has quit [Ping timeout: 480 seconds]
elvishjerricco has joined #asahi-dev
gabuscus has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
_rudi1 is now known as _rudi
elvishjerricco has joined #asahi-dev
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
elvishjerricco has quit [Read error: Connection reset by peer]
brolin has joined #asahi-dev
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
<marcan>
if I had to guess this is a bad interaction between a change in 6.3 and that very specific USB device
<marcan>
could even be a firmware bug in the device itself that just coincidentally is getting hit now
<marcan>
one of the things we changed in 6.3 is cpuidle, so it could even be just a random timing difference
<marcan>
the logs just sound like the device itself is resetting, there's no actual errors
<marcan>
I don't see any suspicious commits in usb core or xhci
<marcan>
if I could repro it locally I could outright use a USB analyzer but...
greguu has joined #asahi-dev
sjg has quit [Read error: Connection reset by peer]
msteffen has quit [Read error: Connection reset by peer]
sjg has joined #asahi-dev
jbowen has quit [Write error: connection closed]
msteffen has joined #asahi-dev
joshtaylor has quit [Read error: Connection reset by peer]
<povik>
and the same DART will get resumed because of ADMAC, which shares it
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi-dev
<jannau>
we might want DL_FLAG_RPM_ACTIVE for every device. I suppose that fixes sio
cafebabe has quit [Quit: Connection closed for inactivity]
<jannau>
after checking Documentation/driver-api/device_link.rst
<povik>
that would fix it, but my understanding is DL_FLAG_RPM_ACTIVE would keep the DART up even for devices that do support runtime PM and are suspended
<povik>
i am surprised it doesn't work as is, that the device link to a consumer not supporting runtime PM doesn't prevent the DART from suspending implicitly
<jannau>
"DL_FLAG_RPM_ACTIVE can be specified to runtime resume the supplier and prevent it from suspending before the consumer is runtime suspended."
<povik>
aha.
<povik>
i only read the text above device_link_add
<povik>
which wasn't as clear
<povik>
the qualifier before that makes me a little uneasy though: 'Two other flags are specifically targeted at use cases where the device
<povik>
link is added from the consumer's ``->probe`` callback:'
<povik>
but maybe it does work as we need
<jannau>
apple_dart_probe_device() is called from the driver core before the consumer's probe callback
<povik>
yeah
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
maz has joined #asahi-dev
bps2 has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
abd has joined #asahi-dev
gladiac has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
is dcp the only thing rn that is firmware version dependent?
<marcan>
and GPU
<marcan>
and some stuff in the ADT bindings but only m1n1 cares about that
<ChaosPrincess>
right, and we are about to support 13.3 firmwares soon(tm)?
<marcan>
correct
<ChaosPrincess>
cool
<marcan>
lina: argh :(
<marcan>
I'll take a look
<ChaosPrincess>
will we have a path to update 12.3 machines to newer versions?
<marcan>
once it's useful, yes
<marcan>
initially only the new machines will get 13.3
<ChaosPrincess>
im sorta maybe looking at another ip block that may end up being firmware dependent
<ChaosPrincess>
idk for sure yet, but seems to be
<_jannau_>
there goes my plan to support dcpext only on 13.3 or later (more out of annoyance than difficulty to support both)
<marcan>
_jannau_: dcpext would be a very good reason to call it useful
cylm_ has joined #asahi-dev
<marcan>
what I mean is that we'll probably release in O(1-2 weeks) for M2 Pro/Max only
<marcan>
I don't expect dcpext to be done by then :p
<_jannau_>
not sure, it seems to work fine ignoring type-c/atc-phy. I'm currently down to tipd behaves differently on every other connect but at least consistently
<kettenis>
I should have some time to get u-boot in releasable shape next week
<marcan>
still need to fix oslog but if you're bored: for MTP, we need to allocate oslog out of the end of the sram region in the DT
<_jannau_>
but yes, 1-2 weeks is not enough time to test it on other systems and fix issues
<marcan>
instead of RAM
<marcan>
since that sticks in linux, and forwarding RAM mappings is a major PITA
balrog has quit [Quit: Bye]
<marcan>
also the size field extends down 12 more bits in the message, the DVA isn't as large as we thought
<marcan>
size is in bytes
<marcan>
(not 4k pages)
<kettenis>
that makes more sense
<marcan>
there's plenty of space at the end of SRAM so it's perfectly fine to steal some space for oslog there IMO
<kettenis>
you're going to change the linux driver to do that?
jbowen has quit []
<marcan>
the linux driver doesn't have to do anything :)
<marcan>
since it never chainloads anything else and will inherit that from u-boot if chainloaded
jbowen has joined #asahi-dev
<kettenis>
ah, ok
<marcan>
(need to fix the size field though, just that)
<_jannau_>
it would make sense allocate from sram on linux as well so that the behavior between us booting with chainload/HV and user install with u-boot is consistent
<ChaosPrincess>
what does sram mean in this context? s=static or s=shared?
<marcan>
both I guess?
<ChaosPrincess>
s=static sounds expensive
<marcan>
_jannau_: doesn't make much of a difference though
<marcan>
ChaosPrincess: eh, it's 1MB
<marcan>
I mean I guess it could be eDRAM but I don't know if they do that
balrog has joined #asahi-dev
gordonfreeman has joined #asahi-dev
<gordonfreeman>
hello! I'm trying to move the single step handler of m1n1 from py to c. single stepping is ok, but I couldn't handle the SSTEP_LOWER exception which comes after stepping.
<gordonfreeman>
I'm actually moving the py code to c verbatim. The issue in the python comment in handle_step happens in C, too: "not sure why MDSCR_EL1.SS needs to be disabled here but otherwise if also SPSR.SS=0 no instruction will be executed after eret and instead a debug exception is generated again"
<gordonfreeman>
what I currently do in handle_step C version is: u64 mdscr_el1 = BIT(15); // MDE=1 msr(MDSCR_EL1, mdscr_el1); return true;
<gordonfreeman>
this prevents the debug exception generation but also the kernel panics after the first handling.
<gordonfreeman>
Am I missing something?
<povik>
jannau: reading further in drivers/base/core.c and power/runtime.c that ACTIVE flag indeed looks like what we want
<mkurz>
marcan: you say "...release in O(1-2 weeks) for M2 Pro/Max only...", are there also plans to release the gpu/mesa fixes for m1 pro/max as well soon? Thanks!
gladiac has quit [Quit: k thx bye]
<sven>
marcan: well, I technically have about two weeks of overtime that I can take as vacation now :D
<sven>
probably won’t do that because I’d go crazy fighting against the atcphy and typec mess for two weeks to get dcpext working ;)
<jannau>
sven: do I remember correctly that you got at some point TimingElements with empty ColorModes for dcpext? do you remember what caused that? I see that currently on 13.3
<sven>
yeah, that was when the dptx dance was incorrect
<sven>
I didn’t know about the dcp->ap calls then iirc
<jannau>
hmm, those are still coming through and the identifiers should be correct but I guess some message could have changed as well
<sven>
is that on a m1?
<jannau>
and there is still the sub header version increased to 4 and possibly 2 additional bytes of padding in the epic cmd header