<sven>
i've also found some more register pokes and macos polling for something when bringing up usb3. I guess those can be used to replace that myster msleep(500); in atcphy_configure_pipehandler
<sven>
and those maybe also explain why it sometimes takes ~5 seconds between plug insertion and "new SuperSpeed USB device"
<sven>
*mystery
King_InuYasha has joined #asahi-dev
<_jannau_>
nice, should rebase cleanly.
<sven>
yeah, it just showed me a bunch of commits and I didn’t feel like going through them because i don’t have much time today
<_jannau_>
you say superspeed device initialization takes just sometimes 5 seconds? on t6001 I can't remember seeing it ever not taking 5 seconds and assumed that was a side effect of the reset
<sven>
hrm, maybe I was confused when I was multi tasking today and it also always took 5s
<sven>
but it‘s ~5 seconds between after xhci is up and running
<sven>
-between
MajorBiscuit has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
nicolas17 has joined #asahi-dev
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
nyx_o has quit [Ping timeout: 480 seconds]
veloek has quit [Remote host closed the connection]
<jannau>
sven: good and bad news: usb3 device is always detected as susper speed devices and probing is fast; it's not detected on the first connect (at all) and after two connections the port is half dead, hub is initialized but no device is detected (m1 ultra)
<jannau>
port doesn't recover after using an usb-c/dp adapter
<sven>
usb/DP makes sense, that probably first comes up as usb only and only then as usb/dp and there’s a usb role switch transition missing
<sven>
the other part is weird :/
<sven>
it’s been very stable here when I tested it
<nicolas17>
tpw_rules: all six Xcode 14.0 betas + 14.0 final + 14.0.1 final = 57GB of .xip files, each of which takes like 10 minutes to extract, in part because of the compression, in part because it has to write 500k small files to the filesystem, ~20GB each once extracted
<nicolas17>
xcode-14.0-all.dwarfs = 18GB, and you just mount it
<nicolas17>
I'm in love with this tool thx for recommending it :P only missing macOS fuse support
<sven>
jannau: can you check what happens if you always configure the pipehandler for usb3? I think I forgot to commit that hack :/
<sven>
iirc I hardcoded that in usb3_set_mode
<sven>
I think the correct fix is to first set the usb role to none and then do the mux set from tipd but that’s a bit annoying to implement
<jannau>
looks like it might be random and it is most of the time broken
<sven>
Even with fixing the pipehandler to usb3
<sven>
?
<jannau>
no, not tested yet
<nicolas17>
I helped test a patch on M2 and it was a pain because I didn't even know how to compile the kernel and configure grub to use it, now that I figured it all out I feel like I want to test more
<sven>
hrm, but that pipehandler hack shouldn’t change the first connection after boot :/
<sven>
I’m traveling for $work until thursday, I’ll look into those other magic pokes afterwards
<jannau>
still most of the time or always broken
<sven>
weird
<sven>
it was very stable on t8103 here
<jannau>
atcphy1 works okay-ish under hv/atc.py, first time still doesn't work and it runs after ~10 connects into "MMIO: R.4 PIPEHANDLER_LOCK_ACK = 0x0 (LOCK_EN=0)" loops
<sven>
huh. I’ll check once I’m back home if I forgot to commit anything else :(
<sven>
especially the first time should always work
<sven>
does it just not recognize the device at all?
<jannau>
is "tunable tunable_CIO_CIO3PLL_TOP not found" expected? I see tunable_CIO3PLL_TOP in the ADT
<sven>
I think some tunable only exists for t6k
<jannau>
i.e. without the double CIO
<jannau>
this is t6002
<sven>
uh. that doesn’t sounds correct
<sven>
-s
<sven>
hrm, or maybe it is
<sven>
that is the only tunable where I have required = false
jluthra has quit [Remote host closed the connection]
<jannau>
tunable_CIO_CIO3PLL_TOP seems to be t8103 only