thelounge7571340 has quit [Remote host closed the connection]
<povik>
just to make sure: this ^ has DT patches that should go in for 6.1 for us not to have issues with a shared audio reset
<povik>
since the binding change has an ack already (it got one within 3m of posting!) patches #1 and #2 should be good to pick up
thelounge7571340 has joined #asahi-dev
chip_x has joined #asahi-dev
chipxxx has quit [Read error: Connection reset by peer]
<sven>
marcan: fwiw, that command that breaks bluetooth on 6.0-rc6 is somehow related to coex afaict
<marcan>
oh huh
<sven>
it does some "Mobile Wireless Standard" frame configuration. it's unclear if this also includes wifi though
<_jannau_>
I think it's just mobile phone networks
<sven>
could be, it's a bit unclear
<sven>
it also fails with "command disallowed" and not with "unknown command"
<sven>
" The Bluetooth Core Specification does not specify signalling between the Bluetooth Controller and a Wireless LAN device." so jannau is right, this MWS seems to be about coex with other 2.4 GHz radios
<_jannau_>
so there is need to support it for ipads with cellular network support (and iphones) but using it doesn't make sense on macbooks
<sven>
it's still weird the firmware on 4378/87 claims to support it but then disallows that command though
<marcan>
still wondering if there's an actual wlan coex enable though, or I'm missing something on the wlan side. changing coex profiles on the wlan side didn't seem to do anything
<sven>
4377 claims support and _does_ support that command
<marcan>
there is some readback support for the coex stuff, I should try it and see if it's *doing* anything on the wlan side
<sven>
have you pushed the wifi tracer? i can adapt the bt tracer and make it spit out btmon traces we can stare at then
<sven>
on macos it does lots of vendor specific commands but I can't easily trace the setup there
<sven>
there's a cute "PacketLogger" thing you can get with xcode. older versions seem to even include names for most vendor commands :D
<sven>
they dumped pretty much all broadcom vendor commands into PacketSniffer afaict
<sven>
(well, all vendor commands that existed a few years ago before they noticed)
<marcan>
ReadSupportedVSCs sounds useful
<marcan>
VSC_ForceWLANChannel also
<sven>
I think I tried ReadSupportedVSCs and just got "command denied" or something
<sven>
but maybe it needs parameters
<marcan>
and VSC_ChangeConnectionPriority could be related to coex prio
<marcan>
VSC_CoExDebugCounters
<marcan>
VSC_ChangeLNAGainCoexECI hmm
<marcan>
anyway, yeah, trace macos and see what it does?
<sven>
yup, pretty much
<sven>
just need to take r's tracer and move it over to the new pcie framework and then make it spit out the commands in a way humans can read them
<marcan>
and make sure to test a coex scenario (A2DP with wifi on 2.4) to see if anything changes
<marcan>
macos changes the wlan coex profile on 2.4 but not 5, when A2DP starts sending data (when audio plays)
<sven>
oh, interesting
<sven>
i think i can already do that just from macos without the hv.
<marcan>
I think what that does is prioritize l2cap, but I don't know for sure
<sven>
well, if i can force it to 2.4 GHz without changing my wlan ap config :/
<marcan>
this is why I have 2.4-only and 5-only SSIDs...
<chadmed[m]>
+1 i have a particularly noisy microwave and band steering only guarantees that my entire network goes down when anyones trying to cook rice
<sven>
it's spamming lots of vendor specific commands
<sven>
VSC_HandleLeMetaVsc1 so someting something LE advertisments
<sven>
and VSC_WriteHighPriorityConnection (sounds supicious), VSC_Olympic (???) and VSC_EnhancedLinkQuelityStats
<sven>
yup, just before it starts sending audio frames it seems to send VSC_WriteHighPriorityConnection
<marcan>
maybe that's all we need then?
<marcan>
it's possible the wlan side coex profile only prioritizes connections marked as that
<marcan>
sven: can we figure this out at the hci layer? might need sniffing packets, something something look for an l2cap PSM 0x19 (I think that's the one)?
<marcan>
of course the real way to do this is with a new API but that would end up needing support all the way to userspace..
<sven>
maybe, let me first try to actually make btcoex fail because uh.. it seems to work here?
<marcan>
yeah that's the thing
<marcan>
it sort of works
<marcan>
just not... great
<marcan>
it completely falls over with LDAC devices apparently
<marcan>
but I still get more glitches and hiccups than expected with SBC
<marcan>
try higher bitrates for more effect
<marcan>
(pavucontrol has profiles)
thelounge7571340 has quit [Remote host closed the connection]
kov has joined #asahi-dev
<rmk>
yay, brcm4378 patches merged :)
<chadmed[m]>
queued for 6.1?
<rmk>
yep
<sven>
huh?
<sven>
ohh… WiFi
<sven>
confusingly the Bluetooth chip is also called 4378 ;)
<chadmed[m]>
Certified Broadcom Moment(tm)
<rmk>
and is probably the same device
<sven>
yeah
<sven>
it’s the same device, just a different pcie function
thelounge7571340 has joined #asahi-dev
<rmk>
the 4329 and 4330 that SolidRun used on their platforms is the same (except it's SDIO for WiFi and serial for BT)
<sven>
chadmed[m]: don’t get me started…
<j`ey>
rmk: yay! 12 down..
<rmk>
24 to go? :/
<j`ey>
*100+ to go :p
<rmk>
I was meaning for brcmfmac
<sven>
for these macs Broadcom (or apple) decided to invented a new weird IPC over PCIe protocol for sone reason
<sven>
*some
<chadmed[m]>
hopefully t6k dart goes in for 6.1 too so we can actually have wifi across the board
<jannau>
I think we have more 200 patches on top of v6.0-rc5
<sven>
:(
<chadmed[m]>
jannau: im pulling down the whole tree now to recalc this while i have Feature Support open
<rmk>
it would've been nice to get macsmc gpio and pcie sorted so we could have the wifi functional for 6.1
<jannau>
still no email/commit from Joerg since sunday morning a week ago
<rmk>
but at least we have some progress towards macsmc gpio
<sven>
yeah, I just copied the old cover letter completely
<povik>
\o/ v3 out
<sven>
I wonder if I actually get comments on the actual driver this time :D
<marcan>
rmk: pcie gpio probably won't go into 6.1 because that binding has to change radically, and I can't know I did that right until sleep works
<marcan>
would've loved to get to this earlier but alas... my schedule has been kind of swamped lately (see Akademy talk tweet, and others) :(
<marcan>
upstreaming is good, but best not rush things that aren't ready, and that one isn't :) (in a way that has compat implications)
<marcan>
re new patches, we'll see, there's the whole sleep thing, but that's a big yak to shave anyway...
<marcan>
I should submit dockchannel, since it looks like that works and it's worth getting in, but it has some deps on the spi-hid series... that whole input stuff needs cleanup and debugging still
<rmk>
marcan: you mean gpio-macsmc ?
<marcan>
no, I mean the PCIe power GPIO binding/support
<jannau>
I started working on spihid but there is quite a bit of cleanup to do
<jannau>
on input side the keyboard is mostly good to go but we need to decide on dt binding for the keyboard layout
<jannau>
we need it for hid-apple since we need to set iso_layout dependent on the actual layout and not just the us/iso/jis type
<jannau>
for hid-magicmouse it would make sense to check if it can't be refactored to share more code between the trackpad and the usb devices
<jannau>
it currently feels a little like two drivers in one file
<jannau>
not sure where the bad crc packets are coming from but apparently those are not garbled keyboard packets
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
nicolas17 has joined #asahi-dev
<marcan>
the keyboard layout is going to be a big yak to shave if we intend to specify all the details
<marcan>
do we really need that? afaik Apple's USB stuff does not report anything other than us/iso/jis either
<marcan>
that's what I did for dockchannel too
<marcan>
I do want us to specify the keyboard layout a different way, but that's a much bigger conversation to be had regarding what the list of valid keyboard types should be
<Tramtrist>
I was able to configure my Japanese keyboard very easily.. Thank you all again for your good work
<marcan>
:)
<ChaosPrincess>
not exactly asahi related, but how did y'all started upstreaming patches to kernel. i ported some drivers for an unrelated board from vendors random fork to upstream kernels, and want to upstream it, but want to hear about how people did it
<jannau>
I think it's also a problem for the usb keyboards hence the module option. probably nothing to be done for USB keyboards but we have the information to handle this correctly
<jannau>
we do not need the full layout in the dt for this. a flag to tell the two iso variants apart would be enough
<j`ey>
ChaosPrincess: you just send them out!
<jannau>
maybe it's just enough to set apple_find_translation
<jannau>
err, APPLE_ISO_TILDE_QUIRK
thelounge7571340 has quit [Remote host closed the connection]
<sven>
(and then changed email providers because email sucks *sigh*)
<ChaosPrincess>
i also read all of that, but sending patches that way feels way more intimidating than sending a PR for some reason :P
<sven>
sending a PR via email was even more intimidating. I think I sent that nvme PR ti myself like five times before I was convinced everything was good ;)
<sven>
seriously though, just try send-email and see what happens. There’s a very high chance you find some typo or similar mistake 5 seconds later anyway
<sven>
(see my Bluetooth series from a few hours ago…)
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
compassion has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
SSJ_GZ has quit [Ping timeout: 480 seconds]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
jole has quit [Ping timeout: 480 seconds]
roxfan has quit [Remote host closed the connection]