<marcan>
I'm going to go ahead and say I want to release on the 17th :-)
<marcan>
let's see if I can make it
<marcan>
... first I need to do my taxes today though
<tpw_rules>
marcan: has the ESP property made it into a released version of m1n1 yet? i don't see it on my system
<tpw_rules>
(also it would be cool if it were lower case)
<marcan>
I just merged that
<marcan>
it's not released though[
<tpw_rules>
okay, cool
gladiac has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<marcan>
... server is overloaded and I can't file by e-tax. never change, japan...
<marcan>
at least I got my accounting in order though
<psykose>
one pentium box per city
<marcan>
today is the deadline, but it looks like they'll extend it due to the overload... which has apparently been going on since yesterday
<marcan>
back to asahi then I guess
MajorBiscuit has joined #asahi-dev
ChaosPrincess has joined #asahi-dev
<firefox317>
marcan: I found some issues with the current hosted installer installing the asahi base image on a j313. It seems like the 5G partition is not auto-sized after first boot (is this intentional?), and the wifi doesnt come up (seems like some pcie issue)
<povik>
whoa it's march already
* povik
should think about his taxes too
<chadmed>
firefox317: yes and yes, it is a pcie problem
<chadmed>
seems like my issues with wireplumber arent related to it, but something else. i duplicated my j314s config on another of my machines with an almost identical userspace setup and it works fine - wireplumber connects the output of the filter chain to the hardware device as expected and plasma lets me route all audio via the filter
<chadmed>
so im thinking its something to do with these machines in particular somehow
<chadmed>
which if thats the case, means the only feature wireplumber/pipewire needs to have for what im envisioning is the ability to "hide" sinks but still have them be accessible on the back end
<chadmed>
since pipewire already implements the infrastructure required to do these transforms internally, all youd really need to implement to solve DSP in for all of linux is a utility to automate the setting up of pipewire (like what ive already done but more generalised) and a database to store IRs and configurations for retrieval by the utility
<povik>
i feel like we should crash #pipewire
<firefox317>
marcan, the pcie issue is different than the one mentioned in the GH issue. Im getting a pcie-apple 690000000.pcie: /soc/pcie@690000000/pci@0,0 link didn't come up
<chadmed>
povik: i asked about it a couple of days ago and the response was just "pipewire doesnt do that"
<chadmed>
i would 100% try implementing such functionality myself but i do not know enough about pipewires internals and am not that good with C, and right now i simply do not have the time to learn either to a level where i could do something like that at all, let alone well enough to get it upstreamed
<j`ey>
firefox317: also known
<firefox317>
j`ey, is it? its not in marcan s blockers list :)
<j`ey>
firefox317: yeah its one of the 2 ways wifi fails
<firefox317>
okay, well as long as it is known its good.
* marcan
forks xkeyboard-config
<sven>
lol, i hate atcphy. right now either usb3 hotplug *OR* usb2 hotplug works
<marcan>
sven: lol
<sven>
and ofc usb3 -> usb2 -> usb3 hotplug also doesn't work
<sven>
because that makes sense!
<bluetail[m]>
USB is significantly cheaper than thunderbolt right? A DAS with TB costs easily 4 times as much in my case…
<bluetail[m]>
TB is PCIe backed though. Higher bandwidth
<firefox317>
marcan, just for reference, but there is the journalctl of the first boot: https://pastebin.com/Xv4k5AqA It looks like there are some more minor issues, like the EFI firmware being unaligned and a unknown kernel command line argument BOOT_IMAGE
<chadmed>
"unknown" only means unknown to the kernel
<marcan>
the unaligned firmware is a u-boot thing and should already be fixed I think
<marcan>
(right kettenis?)
<chadmed>
grub appends BOOT_IMAGE to the kernel command line, and other userspace stuff sometimes make use of the kernel command line too
<marcan>
either way it can be ignored even if not
<j`ey>
no the u-boot issue requires more fixes
<chadmed>
good example is plymouth, which will only start if you have "splash" in the kernel command line (the kernel does nothing with that flag)
<firefox317>
chadmed, ah grub puts it there, okay wasnt aware of that. thanks :)
<firefox317>
I was just mentioning these, because people will also report these issues probably when we release a first version
<povik>
chadmed: re: pipewire, i won't shy away from writing something if we can get an agreement as to what it's supposed to be -- both here and with pipewire people
<povik>
as to the universal solution, instead of configuration utility i would expect all projects to directly read from the database, something like how pulseaudio reads UCM files AIUI
<chadmed>
the problem with that is convincing distros to package and ship potentially thousands of IR samples and configuration files
<povik>
yeah, that
<chadmed>
depending on the sample rate and bit depth, they can be upwards of a megabyte each
<povik>
they already package UCM files for every supported card though
<chadmed>
even more if youre packing them with 0s to add delay/reverb
<povik>
hmm? a megabyte each? i would doubt that
Major_Biscuit has joined #asahi-dev
<chadmed>
well the ones i ship just for the j314s are 512KiB each
<chadmed>
and theyre extremely basic EQ filters
<chadmed>
with a time-domain window applied to shrink them
<chadmed>
theyd be even larger if i left them unconstrained or if the card supported a higher native sample rate
<povik>
(the card should support 96 or maybe even 192 btw)
<povik>
(depends on the codec)
<chadmed>
yeah im working off the assumption of 96kHz, thats what the IRs are
<povik>
ok, good
<chadmed>
i think i tried 192 and it all came crashing down
<povik>
ah, not so good
<chadmed>
macos only supports 24/96 on this machine too
<povik>
should either politely refuse the high sample rate or work :-p
<chadmed>
but yeah my thinking was something like a small graphical utility and a JSON data format. the utility reads a json file provided to it from a remote database with a list of speakers/machines the database has IRs for
<povik>
anyway it goes against my intuition that the IRs are that large, maybe i will take a look whether something can be done
<chadmed>
kind of like the printer driver list the plasma system settings module shows you
<povik>
uh, don't like how complicated that is
<povik>
well in the short term, can pipewire be configured so that we ship IRs for couple of macbooks, and it picks up the right ones?
<chadmed>
the short answer is no it cant, you need to specifically tell it which ones to use via config
MajorBiscuit has quit [Ping timeout: 480 seconds]
<chadmed>
which is why i built that quick and nasty "installer" today
<povik>
and the config can't be conditioned on card name?
<chadmed>
no thats a session manager scripting thing, which means pipewire would have to spawn filter chains for all cards at all times and then have the session manager pick which one to actually route
<chadmed>
but again the problem with that is pipewire cant hide devices, so youd end up with a list of x virtual sinks, x being however many machines are supported
<chadmed>
and even still, the user has to select it themselves via their DE. wireplumber is only responsible for sending the virtual sink's output to the hardware device. it wont transparently select that virtual sink as the user's default
<povik>
so the two issues are we can't spawn filter chain specific to a card, and another to make that the default sink
<povik>
i don't know if we need to hide the physical sink as long as it's not the default
<chadmed>
well three issues, we cant hide the "real" sink from the user
<chadmed>
its not necessary sure, but i think it would be pretty essential to a seamless desktop experience
<chadmed>
depending on how a user has {mis}configured their DE, you can make it swap to the hardware device by default, which signals the pipewire session manager to tear down the filter chain's link to the hardware
<chadmed>
and the only way to get it back is reloading the pipewire config by killing pipewire
<povik>
uh
<povik>
well i meant there could be some use to the real sink for the user
<povik>
but i suppose not really when it's not any standardised channel set
<chadmed>
yeah i struggle to see who would want to listen to the real sink when the quality is roughly adjacent to Alexander Graham Bell's first telephone conversation
<povik>
point made :-p
<chadmed>
but yeah i think just with the way pw/wp have been designed, it would be pretty infeasible to ship IRs for every single machine with them and implement some sort of matching logic in either
<chadmed>
i kind of like the printer driver model just because it doesnt burden pipewire with the maintenance of a huge database of IRs and configurations for random niche sound devices, distros can package these databases up just like they do with PPDs
<povik>
sure, that gets the IRs to your disk, but how does pipewire load the ones?
<povik>
*right ones
<chadmed>
well youd ship precomposed pipewire config fragments in the database corresponding with those IRs, similar to how ive done it in my github repo
<chadmed>
when you select your device in the utility it would shift the related config fragment over to /etc/pipewire/pipewire.conf.d/ or even the user's local one (could be a toggle) and then restart pipewire
<chadmed>
that part all happens seamlessly for the user
<chadmed>
and at that point your only issue would be hiding access to the "real" sink for cases where it's warranted, like ours
<povik>
that's not the printer model though. the user has to pick the right ones and only those
<povik>
while in the printer model people can download as many drivers as they want, the system picks the right one if it's available
<povik>
we should have that too i think to solve it properly
<chadmed>
yeah thats true, but cups has the logic to do that
<chadmed>
i guess we could put together a feature request and see what happens?
<mps>
^ personal config tweaked with jannaus for Arch
<mps>
oh, and added my personal terminus fonts patch
<povik>
chadmed: looks good! only put there more realistic card name like "Macbook Pro J314/6 Audio" in place of "j314s-macaudio"
<mps>
but this is irrelevant for anything working or not in kernel
<povik>
also just realized there will be jack and microphone on that ALSA device in future, which need to be exposed even if speakers are hidden
<povik>
don't know if alsa's hw:0,0 and hw:0,1 are different sinks in pipewire's model
<marcan>
j`ey: 4K or 16K?
<mps>
marcan: I mostly use 4K
<mps>
sometimes also test with 16K
<jannau>
vert.active -= 74;
<j`ey>
marcan: 16K
<mps>
actually thinking to convert all my disks from f2fs to ext4 and use only 16K
<j`ey>
jannau: is ff broken for you too?
<jannau>
I think the arch firefox-98.0-1 update broke for me, without kernel changes
<jannau>
I noticed it was not restored after login after the update but didn't investigate
<jannau>
confirming right now
<mps>
oh, I didn't upgraded FF from 98.0 to 98.0.1 on m1, did on another machine
<chadmed>
povik: pipewire treats them as independent nodes. what we'd be "hiding" is a pipewire node, not the entire hardware device
<marcan>
yeah, 97.0.1-1 works
<povik>
ok
<marcan>
yay for not cleaning up my pkg cache
<marcan>
98.0 is broken too
<mps>
just upgraded 98.0.1, works
<psykose>
.1 only changed some default search providers
<mps>
psykose: yes
<mps>
but wanted to test upgrade anyway
<jannau>
it's half broken for me, when starting from a terminal line I get ALSA errors and a black window with a "close Firefox" title after quite a while
<jannau>
firefox (97.0.1-1 -> 98.0-1) broke it for me
<marcan>
yup
<psykose>
guess they did some funny stuff in 98
<psykose>
on alpine smoosh didn't even build anymore, so i assume they broke a bunch of things randomly
<jannau>
recompiling firefox on arch will be annoying since you have to rebuild rust first without jemalloc
<povik>
marcan: what safety limits would you see implemented at pipewire level?
<marcan>
ahaha, amazing
<marcan>
0:03.90 checking for cargo... /usr/bin/cargo
<marcan>
0:04.07 DEBUG: Executing: `rustup which rustc`
<marcan>
0:04.07 DEBUG: The command returned non-zero exit status -6.
<marcan>
0:04.07 DEBUG: Its error output was:
<marcan>
0:04.07 DEBUG: | <jemalloc>: Unsupported system page size
<marcan>
0:04.07 DEBUG: | <jemalloc>: Unsupported system page size
<marcan>
so I can't *build* firefox because rust is busted on 16K
<povik>
i expect to find a maximal amp gain setting from macos and that's that
<Jamie[m]1>
would mozregression (bisecting on nightly build artifacts) be useful here?
<marcan>
only if those official nightly builds actually crash
<chadmed>
povik: that doesnt solve the problem for other machines. like marcan said, this is a problem that goes beyond just macs and its really about time someone got the ball rolling on standardising this stuff. and all it took was a trillion dollar company's attempt at a paradigm shift in desktop computing
<marcan>
I don't see ARM64 official betas
<sven>
lol
<jannau>
huh, rust from rustup was working for me, the arch rust package one not
<marcan>
exactly
<marcan>
and the arch one is the one the PKGBUILD wants to use
<marcan>
ugh, jemalloc is compiled into rustc?
<mps>
earlier I would advice everyone to use alpine but nowadays I'm not sure
<psykose>
if you can run the pkgbuild yourself and it just uses your existing root you can delete the rust part from the pkgbuild and that should be fine
<psykose>
should just use the PATH rustup rust then
<psykose>
but i forget if pkgbuilds build in chroots or something
<kettenis>
in OpenBSD we call these private malloc implementations "vulneravility mitigation countermeasures" ;)
<sven>
aaand with some more horribly hacks now both usb2 and usb3 hotplug works :>
<sven>
tl;dr: using the PORT_RESET workaround completely breaks the usb3 phy no matter what so we're back to "tear dwc3 down completely and reinit it"
<marcan>
nice!
<Jamie[m]1>
lmao kettenis
<Jamie[m]1>
(fwiw it apparently provides an 8-10% perf improvement for rustc, at least on x86-64)
<kettenis>
yes, by throwing security features out of the window
<chadmed>
yeah malloc is quite slow apparently, its why games almost invariably ship with tcalloc
<Jamie[m]1>
rustc also throws out other security features that are enabled by default in normal rust programs, in exchange for big perf gains (e.g. DoS-resistant hash tables)
<Jamie[m]1>
which makes sense in a compiler context but not many other places :)
<marcan>
looks like JEMALLOC_SYS_WITH_LG_PAGE=16 might work
<kettenis>
to be honest, we disable PIE for llvm on OpenBSD as well to make things run a bit faster
jn has quit [Read error: Connection reset by peer]
<marcan>
and see if it still runs on 16K (or just send me the package)?
<sven>
Timing O_DIRECT cached reads: 148 MB in 2.02 seconds = 73.15 MB/sec <-- hrm... i wonder if this usb stick just sucks immensely or if I'm still missing some magic pokes
<kettenis>
well that is more than usb 2.0 could give you
<mps>
marcan: you need this with glibc, not musl I guess?
<sven>
looks like it's just that stick, same model (from the same order even...): 402 MB in 2.01 seconds = 200.11 MB/sec
<_jannau_>
sven: sandisk extreme USB 3.0 stick on my intel laptop: "Timing O_DIRECT cached reads: 402 MB in 2.00 seconds = 200.66 MB/sec"
<sven>
:>
<sven>
i still only do half of what macos does but i guess that's enough for usb 3 gen 1 at least
<sven>
have you macos under the m1n1 hypervisor before?
<bluetail[m]>
No. I got the question as whether usb 3.2 gen 2 works under 3.1 which it does
<bluetail[m]>
cause its still usb 3.1
<sven>
i guess? the 3.1 is probably just a hardcoded name somewhere
<sven>
the bus certainly supports up to gen 2x2
<bluetail[m]>
I havent seen a single gen 2x2 device though except for pcie cards
<tpw_rules>
i might have one, how can i double check under linux?
<Jamie[m]1>
apparently there's an orico nvme adapter which uses 2x2, seems useful to have so I might buy one lol
<bluetail[m]>
yea, those are all nvme if anything
<sven>
tpw_rules: i think dmesg will show something like "new device SuperSpeed Gen 2x2"
<sven>
Jamie[m]1: huh, and that thing is just 20 eur. i would've expected these things to be more expensive
<sven>
ah, the 20 gbit which is 2x2 is actually 60 eur
<bluetail[m]>
sven: How hot does it get? I read somewhere those nvme enclosures run hot
<Jamie[m]1>
orico cranks out an absurdly large number of quite cheap variations on the "external drive enclosure" concept
<Jamie[m]1>
my local computer store has like 2 shelves dedicated to redundant-purpose orico products lol
<milek7>
does m1 actually have 2x2? apple specs say "USB 4 (up to 40Gb/s); USB 3.1 Gen 2 (up to 10Gb/s)"
<Jamie[m]1>
bluetail: well apparently it has a fan...
<Jamie[m]1>
ah, that would be a no then milek7
<Jamie[m]1>
did it change in pro/max?
<sven>
milek7: hrm, interesting. i assumed it was up to 2x2 because there seems to be a code path in the typec phy that configures both lanes to be USB
<sven>
and a separate path for usb4
<bluetail[m]>
<Jamie[m]1> "bluetail: well apparently it has..." <- which specific model? Having a spare SanDisk Extreme Pro here. And it gets warmer than I'd like it to
<Jamie[m]1>
sven: apparently there's also something called usb 3.2 gen 1x2, which is dual 5gbps
<sven>
ah, ofc there is.
<Jamie[m]1>
not to be confused with 3.2 gen 2x1 (aka 3.1 gen 2)
<sven>
<3 usb
<Jamie[m]1>
:3
<sven>
so far i've only seen macos configure the lanes to be USB/DP though but i assumed that was because I don't have any device that uses two lanes
<sven>
but maybe that just doesn't work?
<bluetail[m]>
Do you want me to check speeds with my usb 3.2 gen2x2 device?
<bluetail[m]>
I mean, I wouldnt have to, there are benchmarks done on macOS too and its as good
<marcan>
going to give up on s2idle because pci, not sure if I can sanely make the pci cores not sleep and either way brcmfmac seems like it might need actual dev work to make sleep work, since I think macOS uses an entirely different mechanism and that other android driver hints at another mechanism even
<marcan>
so no s2idle for the alpha release, we'll look at that later
<marcan>
I did merge the nvme/usb support stuff though, so that will work in the asahi branch once I push it if you disable PCI
<j`ey>
marcan: and serial?
<marcan>
yes
<marcan>
eh, I'll just push it now
<marcan>
pushed :)
<marcan>
this also has the new audio stuff from povik, plus a few fixes I made on top to the speaker amp (still disabled by default though)
<mps>
marcan: nice
<LuigyLeon[m]>
nice :)
<marcan>
(no asahi package yet, I'll figure that out tomorrow)
<mps>
do we need upgraded u-boot for this to test
<marcan>
you need the aic2 devicetrees, that should've already been in the previous push
<marcan>
nothing changed since then IIRC
<mps>
ok, lets build it and test
<marcan>
however the chainloading (top-level m1n1) did get a few changes to how it handles the GPT UUID which will be used in u-boot in the future
<marcan>
so now is probably a good time to upgrade that anyway, let me at least rebuild the installer
<marcan>
ah sorry, not m1n1 per se, just the installer
<mps>
good, thanks
<tpw_rules>
marcan: i ran into an issue yesterday where an m1n1 chainloaded from disk could not access the ADT from the hypervisor run_guest script; the size was reported as 0. can you test that? it would be good to have fixed before lots of people stick an m1n1 in with kmutil that's broken
<mps>
povik: marcan: `/work/asahi-linux/src/linux/sound/soc/apple/macaudio.c:59: undefined reference to `asoc_simple_parse_routing'` this is not yet fixed
<mps>
snd-simple must be in-kernel, not module for now
<marcan>
tpw_rules: you mean kmutil m1n1 -> gpt m1n1 -> hv?
<tpw_rules>
yes. the m1n1 on gpt did not have any payloads
<marcan>
mps: ah yeah, need to fix that
<marcan>
tm
<marcan>
*hm
<tpw_rules>
(and the kmutil m1n1 was installed with the installer's UEFI environment option)
<marcan>
that's very weird though because obviously the ADT gets passed through or everything would explode
<kettenis>
I did push a new u-boot to the asahi branch earlier today
<kettenis>
basically a rebase because jannau's logo color fix made it upstream
<marcan>
tpw_rules: do you have logs?
<tpw_rules>
yes. i also noticed that the on-disk m1n1 printed the correct size on screen
<tpw_rules>
https://pastebin.com/MFatUiiz that's all i saved, just that the run_guest script read a size of 0. not sure if the bootargs struct is being read from the wrong place or what
<marcan>
that looks like bootargs isn't properly passed through
<marcan>
which is weird
<marcan>
ohhh wait
<marcan>
no
<marcan>
not that
<marcan>
hmm
<tpw_rules>
also the same m1n1 binary that was on disk worked fine when installed via kmutil
<marcan>
I think I have an idea of what it must be
<marcan>
likely something clobbers the bootargs between when m1n1 loads and the python stuff loads
<tpw_rules>
i mean it should be straightforward to reproduce?
<marcan>
yeah found it
<marcan>
I wasn't reserving memory for bootargs/etc
<marcan>
that's actually kinda bad so yeah
<marcan>
workaroundable downstream though
<marcan>
thanks for catching this :)
<mps>
hmm, got blank screen on mbp with latest merges to asahi kernel, probably have to upgrade u-boot also
<marcan>
if you are on t6000 and you did not upgrade back when the AIC2 binding changed then yes
<marcan>
tpw_rules: pushed new installer & m1n1
<mps>
no, I'm on t8103
<sven>
hmmm…. DisplayPort or thunderbolt now? :>
<Dcow[m]1>
display over thunderbolt?
<Dcow[m]1>
pretty please xD
<sven>
that’s the final stage I guess :D
<maz>
sven: TB. you know you want it.
<marcan>
sven: displayport first
<Dcow[m]1>
is it TB or USB4 btw?
<marcan>
(being nice here)
<maz>
(nobody needs a display, everyone needs a bunch of PCIe cards).
<marcan>
maz: TB *includes* display!
<sven>
not sure tbh, there’s lots of references to a dpphy in the kexts that scare me
<marcan>
and you think atcphy will be easier? :p
<maz>
marcan: let be rephrase that: PCIe over a long, thin wire.
<maz>
me*
<sven>
I mean… I can already switch the lanes to thunderbolt mode at this point
<sven>
it’s “just” that their cio coprocessor and the pcie parts aren’t up
<sven>
I guess I’ll trace everything and connect a display and then some thunderbolt thing to see what requires more magic pokes
<marcan>
sven: all the actual DP PHY stuff should be done by DCP
the_lanetly_052 has joined #asahi-dev
<marcan>
like the training etc
<marcan>
keep in mind there are kexts that are dupes of DCP functionality
<marcan>
since for some reason all the code to do it without DCP is also there
<sven>
good point
<sven>
let’s what macOS does, maybe it’s really just setting up this DisplayPort crossbar thing
<sven>
atcphy itself is also fairly high level fwiw, most of what I needed to do was essentially enables some clocks, configure the lane modes, apply those tunables and switch what they call “PIPE handler” to the correct mode
<sven>
and sync that all to the correct place inside dwc3 ofc
<marcan>
dwc3?
<marcan>
you mean for usb4 comms?
<marcan>
oh you mean 3
<sven>
even for usb3, dwc3 and atcphy are interconnected
<marcan>
yeah
<sven>
part of the atcphy regs are inside the dwc3 node e.g.
Major_Biscuit has quit []
<sven>
(In the adt)
<marcan>
PIPE is the term for the back end of the USB3 PHY IIRC
<marcan>
it's like that ULPI thing for USB2
<marcan>
heh, right
<sven>
PIPE also contains the dwc3 reset bits and that final mux thing that decides usb2/3/4
<marcan>
wait usb*2* is muxed?
<sven>
apparently…
<marcan>
how does that work?
<marcan>
it's a dedicated lane...
<sven>
I need to switch a register xnu calls something like “pipe handler mux mode” from what works for usb2 to what works for usb3 :/
<marcan>
but both need to work at the same time...
<sven>
and I think usb4 is another setting there
<marcan>
otherwise hubs wouldn't work
<sven>
I know
<sven>
It’s probably just mislabeled
<marcan>
maybe usb2 is just 2-only, usb3 is both, and usb4 is 2+4-over-thunderbolt?
<marcan>
which basically means, as far as PIPE is concerned, usb2 means "null", usb3 means "usb3 PHY", and usb4 means "tunnel through TB"
<sven>
could be, there are strings about "cioTunnelMode" nearby
<marcan>
that would make sense for a "pipe mux"
<sven>
yeah, that makes sense then
<sven>
there's also a string about a "dummy PHY" related to usb2, so that would also fit
<marcan>
yup
<sven>
one less "// TODO: WTF does this do" comment :D
<marcan>
so that's the digital mux in front of the USB3 host/device core
<marcan>
Dcow[m]1: this answers your question, it's USB4, because that setting in that mux is precisely what USB4 is (that TB isn't)
<marcan>
(we knew it was USB4 already but this is the specifics)
<sven>
also makes sense that it's tightly coupled to dwc3 then
<marcan>
yup
<sven>
you can't e.g. switch that mux when dwc3 is in softreset
<marcan>
it's literally in front of it so yeah
<marcan>
I do wonder if atcphy is a pure apple design, sounds like it might be
<marcan>
which is pretty cool if so (their PCIe stuff isn't)
<marcan>
but I don't think anyone else other than intel has done a TB PHY so...
<sven>
the exact sequence you have to do is "bring up usb2 phy (because dwc3 will never clear the softreset otherwise", "bring up dwc3", "bring up atcphy", "switch mux to usb3"
<marcan>
of all the phy-ish crap, I'm guessing Apple would have the most interest in NIHing this one
<marcan>
and yeah, the USB2 PHY is definitely something they licensed
<marcan>
it's the same silicon block copied and pasted in front of everything and it probably hasn't changed since like the iphone, modulo process changes
<marcan>
same thing's in front of the debug-usb too
<sven>
it's certainly all very interconnected. i can e.g. break the atcphy/pipehandler paer by issuing a port reset for the usb2 phy only
<sven>
-paer
<sven>
(break as in requires a PMGR reset of atcphy and dwc3 to work again)
<marcan>
heh
<sven>
i guess that reset messes up something inside dwc3 which then messes up the pipe part or something
<sven>
the low 2 is some clock enable, the high 2 selects the mode (or the other way around)
<marcan>
ah, fair
<sven>
and it really hates you if you do both at the same time :D
<marcan>
wonder if the lanes are done at a lower layer then or what. I guess it depends on how that 2x2 bonding thing works
<marcan>
also shouldn't there be delays in there if timing really matters? or maybe it just has to have a trivial delay?
<sven>
two strs just after another work fwiw
<marcan>
heh, fair
<sven>
xnu also doesn’t have an additional delay in between
<sven>
the lanes are configured inside atcphy
<sven>
part of that is tunables, and then there are two or three registers
<marcan>
I guess aggregation happens inside the PHY then
<marcan>
anyway, I should sleep
<sven>
yeah
<marcan>
let's see if I can tick off a bunch of things off that TODO list tomorrow
<sven>
:)
<marcan>
I want to release on the 17th :p
<sven>
Goodnight!
<sven>
That’s still plenty of time :P
<marcan>
about 45h if I want to make it in time for JST :p
<sven>
you’ll probably also need a blog post or something to go along with it!
___nick___ has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
<sven>
alright, the atcphy stuff still needs some more cleanup but i'll push it tomorrow. if someone is bored and wants to help until then: I still need to track down the fuse locations for the other t8103 and the nodes+fuses for all t6000 phys.