<chadmed>
they sound significantly better than the previous lot to me but im really sick atm so would like a second opinion from someone who can hear properly :P
<marcan>
_jannau_: not sure if same problem but there was a bug there
<chadmed>
jannau: is this for UCM? i figured out what we needed to change for pipewire a while ago but i cant remember what :/
<marcan>
yeah, PA UCM had a bad codepath/interaction in the hotplug case with hardware volume controls
<marcan>
I don't really care about PA in the long term but we need to carry this fix around for now at least
<marcan>
(and hopefully upstream will take the PR)
weitcis has quit [Quit: Konversation terminated!]
<chadmed>
iirc for pw it was some syntax thing in the speaker detection block that caused it to just give up entirely on parsing the profiles. let me see if i still have it somewhere and can test it against 0.3.60
<marcan>
kettenis_: should I send the M2 MTP stuff to u-boot upstream?
<bluetail>
chadmed may be unrelated but I fixed my pipewire not working with installing wireplumber-git from the AUR
<chadmed>
jannau: this hotplug thing fixed with 0.3.60 right? with pro audio disabled switch-on-hotplug works with no headset mic now
<_jannau_>
compatible is fine for now. I used the soc specific ones because I saw different behavior for DP on t6001
<_jannau_>
chadmed: yes
<chadmed>
yeah cool, i wonder if we can get it to work with pro audio
<_jannau_>
ony tested on devices without speakers
<sven>
DP still kinda worked with just the t8103 compatible so it's fine to have that as a fallback
<sven>
and what was different on t6000?
<sven>
I still have some hardcoded values for some registers that actually come from $somewhere
<chadmed>
it needs to work with pro audio because we cant apply DSP to the speakers otherwise. i think thats more of a DE thing though since in pro audio mode pipewire just exposes everything everywhere all at once
<sven>
(for DP, not for USB3)
<marcan>
I don't see the existing driver doing anything different for t6k
<marcan>
DP only?
<sven>
i'm pretty sure there are no differences for USB3
<_jannau_>
yes, DP only
<sven>
the hardcoded values are DP only, yes
<marcan>
worth having the compatible just for that then, even if it's "a bit broken"
<sven>
I don't think the code for t6k is actually different, iirc it doesn't overload the dp functions
<marcan>
but then !t8103 have to come first in the match table once you add data fields to those
<marcan>
to make sure they override it
<sven>
yeah
<sven>
i'm still mostly sure it's just some if (some_magic_register & some_magic_bit) do_what_looks_like_t6k_stuff
<sven>
so it's not t6k vs t8103 but actually something that has to be done on both
<marcan>
ah, yeah
<marcan>
override some reads and see if it affects things?
<sven>
yeah, it's still on my TODO list ;)
<sven>
if you look at the DP function you'll also see quite a few hardcoded values
<sven>
but none of that code is triggered right now with usb3-only fwiw
<_jannau_>
sven: did you add LN_AUSPMA_RX_TOP_PMAFSM after the initial version?
<sven>
yes
<sven>
I missed that originally
<_jannau_>
ok, that was the extra thing I saw
<_jannau_>
setting LN_AUSPMA_RX_TOP_PMAFSM_PCS_OV
<sven>
:D
<sven>
it does that on t8103 as well if you switch to USB3+DP or DP-only
<povik>
what a mouthful
<sven>
it's already shortened from what XNU calls it
<sven>
most of the phy regs come in pairs. you have WHATEVER and WHATEVER_OV
<sven>
you need to set the _OV to actually override the signal
<_jannau_>
the hardcoded values are not SoC specific but seems to be device specific. my mac mini used different values than sven's
<marcan>
more fuses?
<sven>
yeah, i'll just have to figure out where it gets them from eventually. chances are it's just some of the previous MMIO reads
<sven>
the whole driver started with literally everything hardcoded
<sven>
I just didn't get around to those values yet
<sven>
there are also three or so writel left which just configure an entire register to some constant value
<sven>
need to split that up into individual bits as well. just some busywork with the HV and XNU's debug log
<marcan>
jannau: merged the changes & pushed asahi-wip
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-dev
joske has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
<joske>
marcan: there's a stray g in Error: arch/arm64/boot/dts/apple/t8103.dtsi:38.5-6 syntax error in latest asahi-wip
<marcan>
where did that come from...
<marcan>
fixed
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit []
capta1nt0ad has joined #asahi-dev
joske has quit [Remote host closed the connection]
<marcan>
kettenis_: confirmed that uboot works with atcphy now (tagged & package in asahi-dev)
mps_ has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
mps has quit [Ping timeout: 480 seconds]
digicyc has joined #asahi-dev
leafpawz has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
bisko has joined #asahi-dev
<sven>
marcan: have you ever dumped the cd321x firmware when looking into those USB PD commands?
<sven>
i need to figure out some interrupt bits (mode discovery completed, etc.) which might be easier by just looking at the fw
<marcan>
the external firmware is just patches/addons; I never dumped the ROM
<marcan>
I assume the ROM is also different from the standard one (that's what makes it a special partno)
<sven>
yeah, that's what I assume as well
<sven>
I saw those addons but they're more or less useless without the ROM
<marcan>
I think someone said you can dump it with SWD
<marcan>
but that requires hardware haxx
<sven>
ugh. it's a pity apple had to move around essentially all interrupt bits. the rest matches up very nicely
<kettenis_>
marcan: upstreaming MTP would be good, but it would probably be easier if we upstream the dt bindings first
<marcan>
though I think there's an SWD mode for the sideband pins but I'm not sure if it's SWD for the chip itself or passthrough to the SoC
<sven>
the original TPS chips also have some external flash read commands and it wouldn't surprise me if there's also hidden "read RAM" commands. but those don't exist anymore on the apple variant
<sven>
oh well, let's see what I can figure out by just poking those chips and observing the interrupt status
<marcan>
also I just realized there are *4* cortex-M3s in the M1 Pro/Max DCP lol
<sven>
not surprised that happens after suspend/resume
<marcan>
LED, LTM, BLM, APT
<sven>
that's part of a slightly fragile setup that orders dwc3 shutdown vs. mux shutdown
<sven>
it works as long as nothing unexpected like suspend/resume happens :D
Major_Biscuit has joined #asahi-dev
Dcow_ has joined #asahi-dev
cylm has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
Dcow has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
c10l1 has quit []
c10l has joined #asahi-dev
<marcan>
sven: not sure if some recent change fixed suspend/resume on atcphy or it's just due to me running on the hypervisor, but it actually works now?
<marcan>
well, it still resets devices but at least it comes back
mps_ is now known as mps
<sven>
probably atcphy being unstable as usual if you don't do certain things in just the right order
<sven>
without suspend/resume that's guaranteed
<sven>
without suspend/resume you can probably hit some edge cases it doesn't like
<sven>
*with
<sven>
usually as long as first dwc3 shuts down and then atcphy and as long as first atcphy is configured again and only then dwc3 starts everything should work
<sven>
I need to rework the way that order is ensured for altmode anyway and I'll see how to enforce it with suspend as well
<sven>
I don't really know without looking at the code how exactly the resume part is triggered
<sven>
but I guess what might happen is dwc3 shutdown -> pipehandler to dummy -> resume -> pipehandler to usb3 -> dwc3 init and it may not like that without a atcphy reinit inbetween
<sven>
plus maybe tipd also triggers something? dunno
<sven>
at least whatever happens doesn't break it without a reboot. getting *that* correct was truly annoying
<marcan>
sven: okay yeah it works only sometimes
<marcan>
I get the [ 33.679950] phy-apple-atc b03000000.phy: pipehandler lock not acked, this type-c port is probably dead until the next reboot.
<sven>
yeah, as expected
<sven>
yup, that message is a bit older when that was still true :D
<sven>
probably makes sense to change it to something like "you'll probably have to replug the connector to make it work"
<marcan>
ok, fixed the dcp suspend/resume issue (solution: actually use the DRM suspend/resume helpers which work properly, instead of open-coding something broken :p)
<jannau>
I wasn't aware that there was an issue but I haven't tested dcp suspend/resume much
<marcan>
you get a black screen on j314/j316 at least, until a DPMS cycle
<marcan>
(xorg)
<marcan>
(wouldn't be surprised if wayland works)
<marcan>
(because it actually triggers swaps)
<marcan>
there was also a ton of warning spew from locked DARTs
<sven>
i would be disappointed that wouldn't be happening on -edge!
<marcan>
I think that's the worst of the suspend/resume issues since sometimes there's no good way to get back the screen
<sven>
+if
millenialhacker has joined #asahi-dev
<sven>
like, where's the fun if nothing breaks in something called bleeding edge :D
<marcan>
would be nice if we can fix the atcphy ordering too, but that can wait until after release
<marcan>
which at this point is going to be next week
<marcan>
(could do it on the weekend, but let's optimize for the media cycle shall we...)
<sven>
lol
<sven>
i probably won't get around to fixing suspend/resume but you can probably hack it by issuing tps_disconnect in the tipd suspend handler and tps_connect in the resume handler
<marcan>
lol
<jannau>
I should see to wire up the pointer plane then X11 would do swaps on pointer movement (that's for after the release)
<sven>
that tipd thing is doing a lot of the heavy lifting for us :D
<marcan>
well, I don't think you're *supposed* to actually trigger a connect/disconnect, I think devices are supposed to survive a suspend/resume to some extent? though right now dwc3 dies anyway so I'm guessing that's the first thing to fix there
<sven>
dwc3 definitely shuts down on suspend
<sven>
i'm re-using that code to also shut it down when switching to USB_ROLE_NONE
<marcan>
yeah and doesn't come back on resume clean
<marcan>
(this has always been like that on usb2; it does not happen on the PCI controllers)
<sven>
maybe I misremember but I think dwc3 actually removes the xhci device on suspend
<marcan>
on macos?
<jannau>
next dcp TODO item is m2 support which might be a single digit of line changes in dcp and more dart changes
<marcan>
yup
<sven>
if (!PMSG_IS_AUTO(msg) && !device_may_wakeup(dwc->dev)) {
<sven>
dwc3_core_exit(dwc);
<sven>
ah.. so that's what linux does on suspend
<marcan>
ummmm does that kill the whole thing?
<sven>
dwc3_core_exit does that, yes
<marcan>
oh god why is this driver/hardware so broken
<sven>
core_exit also asserts the hard reset line
<marcan>
*sigh*
<sven>
<sven> i probably won't get around to fixing suspend/resume but you can probably hack it by issuing tps_disconnect in the tipd suspend handler and tps_connect in the resume handler
<sven>
:>
<sven>
maybe just setting device_may_wakeup and/or PMSG_IS_AUTO just skips that
<sven>
who knows
<sven>
core_exit also calls into atcphy to shut down
<sven>
so if you manage to skip dwc3_core_exit we might be good
millenialhacker has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
<marcan>
sven: I think that whole codepath is bullshit. you are not supposed to go off resetting host controllers during suspend.
<marcan>
xHCI already has a defined protocol for going into suspend, and you can certainly put the parent device into low-power mode but definitely not do a full reset
<sven>
I'm willing to bet that is done to work around a quirk on some random hardware
<marcan>
it's supposed to continue to track connect/disconnect events during suspend so the kernel can know whether a device was removed to decide how to re-enumerate it
<marcan>
there is a hack in the kernel to work around the current situation, but it has to be manually enabled and has lovely failure cases like "if you suspend, remove a USB drive, insert an identical one, and resume, and it doesn't have a serial number, your filesystem will explode"
<marcan>
(because it can't know it's a different drive)
<sven>
just look for some of the recent dwc3 threads in linux-usb
<sven>
there's e.g. some intel platform that breaks if they probe extcon at the wrong time (lol)
<marcan>
...
<sven>
there are also two separate ways it orders xhci_init and phy_set_mode
<sven>
i'd expect set_mode followed by xhci init
<marcan>
also you can't identify reconnects via tipd since they could happen purely on the USB side (e.g. if you're using a type A adapter cable)
<marcan>
so you *have* to keep dwc3 working to at least detect hub events
<sven>
but that also breaks some intel platform
<sven>
it really would not surprise me if that "reset everything on suspend" is to workaround more crap like that
<sven>
i'd try to just always make that if with !device_may_wakeup(dwc->dev) false in the suspend and resume functions
<sven>
if that block is skipped it also won't call into atcphy so it should just survive as well
<sven>
ah, wait, it'll hit the DWC3_GCTL_PRTCAP_OTG path anyway
<sven>
replace if (PMSG_IS_AUTO(msg)) with if(true) and it might just survive
<sven>
(after case DWC3_GCTL_PRTCAP_OTG:)
as400 has quit [Remote host closed the connection]
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
Cyrinux has quit []
Cyrinux has joined #asahi-dev
<marcan>
sven: ok so there are several problems here. nuking those codepaths *and* keeping the power domains up avoids the dwc3 error, but the devices still disconnect.
<marcan>
so that's probably a phy or tipd issue?
<marcan>
to dwc3 it just looks like a disconnect/connect
<sven>
hrm, probably
<sven>
so dwc3 survives?
<marcan>
if I keep the PDs up and comment out those dumb reset codepaths, yes
<marcan>
however, macOS *does* power down the dwc3 power domains on sleep. Haven't tested what they do for USBMS (the only real problem case where you can't afford to do blind reconnects)
<marcan>
so there must be a way to do that with recovery, while maintaining port state
<sven>
hrm, tipd shouldn't issue any mux_set so atcphy should survive as well I think
<sven>
unless tipd calls that tps6598x_disconnect it'll leave atcphy alone
<sven>
and if dwc3 survives it'll also leave atcphy alone
<marcan>
maybe it's the phy rpm
<marcan>
let me drop that too
<marcan>
ah but atcphy doesn't even do rpm
<sven>
maybe also try trace_atc.py and see what happens on suspend
millenialhacker has joined #asahi-dev
<marcan>
sven: nothing
<sven>
yeah, that's what I expected. dunno why dwc3 sees a disconnect then :/
<marcan>
sven: it could be this is just broken in dwc3
<marcan>
I mean the xHCI core does the standard xHCI sleep stuff including save state and such
<marcan>
I guess we need to figure out what macOS does
<sven>
true. given how broken hotplug is on these machines anyway that also wouldn't surprise me
<marcan>
(could be it just works around it with the moral equivalent of that hack I mentioned earlier)
<marcan>
but for that we need to make the hypervisor survive suspend/resume cycles which ugh
<sven>
that doesn't sound like fun
kazuki_ has quit [Quit: Konversation terminated!]
millenialhacker has quit [Ping timeout: 480 seconds]
<marcan>
sven: so from what I see tracing the xHCI registers, it puts the port into suspend state properly, but then on the way out it just refuses to come out of suspend and it eventually resets it
<sven>
ugh
<sven>
maybe the resume needs some additional phy interaction?
<sven>
i guess we really need to take a look at what macos does to do this properly :/
<alyssa>
sven: good morning
<alyssa>
*reads backlog*
<alyssa>
...nope!
alyssa has quit [Quit: leaving]
<sven>
:D
xcpy0 has quit [Remote host closed the connection]
<marcan>
sven: I think I give up on this for now
<marcan>
I'm going to do another merge/tag/build with the dcp suspend fixes
<sven>
yeah, it doesn’t really break anything. people who use -edge may just have to reconnect usb devices once it comes out of suspend
<marcan>
well, it's not great if you have USB mass storage devices
<marcan>
or anything actually running like USB sound cards or capture cards
<marcan>
*cough* my streaming setup *cough*
<marcan>
but then again, once I do switch (when lina gets OBS running properly...) the machines are quiet enough I don't need to suspend it
<sven>
sure, but it’s called -edge for a reason :p
<sven>
i wouldn’t want to ship this to users who expect this to work
<mps>
this is new tag asahi-6.1-rc5-11?
* mps
wants to test
<sven>
but bleeding edge with a disclaimer what happens to usb on suspend sounds fine with me tbh
<mps>
nice, screen 'comes back' after resume now, on m1pro macbook
maria has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
cylm has quit [Quit: WeeChat 3.6]
<marcan>
yes, I just fixed that
<marcan>
it's on asahi-dev
digicyc2 has joined #asahi-dev
digicyc has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
leafpaw has joined #asahi-dev
digicyc2 has quit [Ping timeout: 480 seconds]
maria has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
leafpaw has quit [Remote host closed the connection]
leafpaw has joined #asahi-dev
leafpawz has joined #asahi-dev
leafpaw has quit [Ping timeout: 480 seconds]
amarioguy2 has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
<sven>
ugh… guess I’m back to rebooting the soc when trying to bring cio up *sigh*
* jannau
imagines how annoying that would be without *vdmtool
<sven>
nah, cio is nice enough to do the reboot for me
<sven>
apparently because I messed up and brought down atcphy while acio was still running
<sven>
it really doesn’t like that
<sven>
it probably even saves me a second or so compared to running vdmtool this way :D
amarioguy2 has joined #asahi-dev
trsohmers has quit [Ping timeout: 480 seconds]
trsohmers has joined #asahi-dev
xcpy0 has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
amarioguy2 has joined #asahi-dev
Axenntio has joined #asahi-dev
millenialhacker has joined #asahi-dev
Axenntio has quit [Read error: Connection reset by peer]
as400 has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
nicolas17 has quit [Ping timeout: 480 seconds]
<jannau>
looks like atcphy might broke interfacing with m1n1. I'm getting https://paste.debian.net/1261051/ on boot of a device with m1n1 in proxymode
<sven>
that warn_on essentially means dwc3 did now shut down
<sven>
was this a disconnect when dwc3 was in device mode?
<sven>
s/now/not/
<jannau>
not sure, the both systems were long connected (both running linux) and I noticed the repeated error only after several disconnects/reboots of the m1n1 system
amarioguy2 has quit [Ping timeout: 480 seconds]
<sven>
uh, so this was in the host machine?
<sven>
*on
<jannau>
yes
millenialhacker has joined #asahi-dev
<sven>
that’s weird. that shouldn’t be any different than disconnecting any other device
<robher>
jannau: humm, I guess I need a USB C to A cable. asahi-wip (6.1-rc1 based) from about a month ago boots but USB is deferred (presumably a new dependency in the DT missing the driver). The current asahi-wip with edge config does not.
<jannau>
robher: current asahi-wip gained a type-c phy driver, dwc3 in the current devicetree references that but 6.1-rc1 misses the driver
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
<robher>
jannau: Right. Without the edge config, now it is booting for me.