<povik>
i think it's almost ready for audio samples being shoveled in on the SIO side
<povik>
now to get the DCP side up :|
<j`ey>
what audio bits use it? oh audio over HDMI or something?
<povik>
y
<povik>
probably s/m1n1.hw.sio/m1n1.fw.sio/ :)
<nicolas17>
does audio over USBC-to-HDMI adapter need the same? :P
<povik>
would be surprised if not
<nicolas17>
I should buy one of those
<povik>
AIUI, DCP does the HDMI then it's routed through the usb-c ports
<povik>
it's magic to me
<tobhe>
Ё
<nicolas17>
povik: I read somewhere that USB-C Alternate Mode for HDMI is little supported in practice
<nicolas17>
no idea if Macs support it
<nicolas17>
instead they use displayport and the adapter converts it to HDMI
<povik>
then it's likely displayport that's routed to usb-c
* povik
should read up on the relation of hdmi, dp and usb-c
<povik>
downside is, then it won't be magic anymore :(
<povik>
do you know the joy of having no idea how something works?
<nicolas17>
sometimes, yes
<nicolas17>
other times it's more like "I MUST KNOW"
<nicolas17>
but yeah
<nicolas17>
I learned how the .zip format works and I want to unlearn it
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-dev
eiln has quit [Remote host closed the connection]
coailtb^ has joined #asahi-dev
Dementor has quit [Remote host closed the connection]
Dementor has joined #asahi-dev
Dementor has quit [Ping timeout: 480 seconds]
Dementor has joined #asahi-dev
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #asahi-dev
<chadmed>
marcan, povik: how do you feel about bumping the amp gains to the same as macos eventually? ive got a set of IRs for it and it helps with low end response at low-ish volumes enough that it wont really matter if we cant easily integrate the equal loudness plugin
<chadmed>
no clipping or melting or magic smoke has been observed as of yet
nicolas17 has quit [Quit: Konversation terminated!]
<marcan>
chadmed: once the safety stuff is in place my intention is to set the amp gains statically to what macOS uses (unless we find we really don't need extra headroom and can go lower), and give DVC control over to the safetyu stuff.
<chadmed>
excellent, where theyre set now really kills low volume performance. the way ive got it now with the gain set to 15 (18.5 dB) we dont even need the compressor in pipewire anymore top stop clipping which saves a boatload of cpu time and makes the equal loudness plugin slightly less necessary
<marcan>
I'm a bit confused though, how does lower gain kill *low* volume performance?
<marcan>
or do you mean low DVC volume? if so we should switch to software volume
<chadmed>
pipewires software volume control, the woofers just become far too quiet below ~45-50% at the current setting
<marcan>
but then can't you just add gain?
<chadmed>
not dynamically, which is why i was playing around with the equal loudness filter
<marcan>
I mean a static gain in software would be equivalent except at higher volumes where it clips?
<marcan>
unrelated: people are reporting spi-hid issues with suspend and also just in general, and I still haven't fixed the "trackpad randomly dies" problem. I think it's high time to give that spi-hid driver a serious debugging & overhaul session.
<chadmed>
yeah which is what i was doing in the IRs to make up the difference, but setting it in the kernel driver to the macos value and getting rid of the gain bump from the pipewire end fixes a lot of the problems ive been tearing my hair out trying to deal with
<chadmed>
idk if it was the software side being saturated after all the filters were applied or whatever but theres now no more clipping at max volume and the software volume control has way more useable range
<chadmed>
also re spi-hid the only showstopper ive noticed here is not being able to use the trackpad while pressing any non-modifier keys. that made playing xonotic last night quite difficult :P
<chadmed>
oh nvm thats a libinput setting...
SSJ_GZ has joined #asahi-dev
kettenis has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi-dev
<sven>
povik: almost nothing uses HDMI altmode. It’s always DP altmode plus some DP to hdmi converter
<sven>
even the internal MacBook screen is hooked up through a DP to hdmi converter even though it doesn’t even use type c
trsohmers has quit [Ping timeout: 480 seconds]
trsohmers has joined #asahi-dev
<sven>
uh. Never mind the last comment
<sven>
I meant the internal screen is hooked up via DP and the HDMI output on the mini goes through a converter
* sven
shouldn’t type before coffee
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
bgb has joined #asahi-dev
Dcow has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-dev
bisko has quit []
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
<povik>
got it
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-dev
<sven>
so chances are if audio output over the mac mini's hdmi works it might also just work over the type-c ports :)
<sven>
maybe just needs some additional EPIC calls but i'd be surprised if it's very different
capta1nt0ad has quit [Quit: Konversation terminated!]
StupidYui has joined #asahi-dev
mps_ is now known as mps
<povik>
jannau: you engaged in binding discussions on iommu mappings so you might know this off the top of head: how do i represent the SIO's required DATA section mappings?
<jannau>
povik: look what I do with dcp in m1n1, src/kboot.c:dt_carveout_reserved_regions()
<jannau>
create a memory region in /reserved-memory and link to that region via "memory-region" in the device
<povik>
ah, so the relation to a DART instance is through the device
<povik>
i was looking for iommu= property of sorts on the reserved memory node
<jannau>
looking at the output of `dtc -I fs -O dts -o - /proc/device-tree` might help
<povik>
yeah, i should do that. thanks!
<jannau>
yes, it's through the device. the "iommu-addresses" gets a device phandle too
<jannau>
see dt_device_set_reserved_mem()
<jannau>
parsing segment-ranges in kboot.c makes more sense than the /chosen/carveout-memory-map handling for dcp
<povik>
so what happens now is the carveout-memory-map is combined with DART contents to produce the FDT data?
<jannau>
feel free to use code or refactor reserved memory region writing of dt_carveout_reserved_regions() as you see fit
<jannau>
yes, the physical addresses from the carveout-memory-map are matched with the dart mappings to produce physical address, device address, size
<jannau>
there are two reasons for that with dcp. 1) dart-disp0 needs to be covered as well (no segment-ranges for that) 2) text not mapped via dart through of my first high level segment-ranges parsing attempt
<jannau>
dcpext can be switched to segment-ranges parsing as soon as the code exists
<povik>
ah. then we can't completely replace the carveout-memory-map logic even if we wanted
<povik>
we still don't know how to decide on the mapping of the TEXT section based on segment-ranges
<povik>
but maybe we can map it every time?
<povik>
or maybe it's an oversight that iboot makes the mapping on M2
gladiac has joined #asahi-dev
capta1nt0ad has joined #asahi-dev
<jannau>
phys and device address being equal could signal not to map text via dart
<povik>
aha!
<jannau>
no, that doesn't seem to apply for sio
chengsun_ has joined #asahi-dev
chengsun has quit [Ping timeout: 480 seconds]
bgb has quit [Ping timeout: 480 seconds]
<povik>
patch for parsed segment-ranges in adt dumps:
coailtb^ has quit [Remote host closed the connection]
pbsds0 has quit []
pbsds0 has joined #asahi-dev
onethirtyfive has joined #asahi-dev
onethirtyfive has quit [Quit: WeeChat 3.7.1]
onethirtyfive has joined #asahi-dev
onethirtyfive has quit [Quit: WeeChat 3.7.1]
onethirtyfive has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
<povik>
jannau: am i wrong in expecting general kernel code to set up the reserved-memory iommu mappings?
jluthra has joined #asahi-dev
<jannau>
povik: maybe, it could be that I did that only inside 'if (dart->locked)', let me check
<povik>
ah, so it's dart code?
<povik>
the dcp compatible and no-map property surprised me
<amarioguy>
-sep_panic_mbox_to
<jannau>
yes, see apple_dart_setup_resv_locked(). that is only called on locked dart
<amarioguy>
hmmmmmmmmmmmmmmmmmm
<povik>
jannau: got it
<jannau>
you can call that unconditionally
<povik>
TODO: error handling! :p
<povik>
but the io_pgtable_dart_setup_locked needs to remain conditioned, i suppose
<jannau>
the .compatible is so far not used, no-map is required to prevent u-boot from fsck-ing things up
<jannau>
yes, io_pgtable_dart_setup_locked should only be called on locked darts
<povik>
shouldn't it be something other than apple,dcp since that's exactly the dcp binding?
<povik>
or is that the custom?
___nick___ has quit [Ping timeout: 480 seconds]
<jannau>
this is going change soon but you don't need to care. make apple_dart_setup_resv_locked unconditional and I'll keep it working
<jannau>
it probably shouldn't be "apple,dcp"
<sven>
amarioguy: sep‘s panics are a bunch of numbers that look like they’re encrypted fwiw
<jannau>
povik: maybe "apple,ascwrap-text" and "apple,ascwrap-data"?
<ChaosPrincess>
for people who traced spi stuff before - does it send a 64-bit 0 as the first thing? the touchbar tx/rx dumps both begin with that, and idk what generates it.
<povik>
jannau: maybe even asc-specific compatibles in addition if we need special handling in future to fix something
<povik>
still no mapping after making that call unconditional, hm
<povik>
will try to debug a bit
hir0pro has quit [Quit: hir0pro]
<jannau>
do you already have a SIO device/driver stub?
<povik>
yes
<povik>
it gets to booting the SIO and a DART miss
<amarioguy>
sven: not unexpected given it's purpose tbh tho still probably good to know
<jannau>
ChaosPrincess: iirc the keyboard/trackpad starts sending data after power-on
<jannau>
does the devicetree node contains already a reference to the dart iommu?
<povik>
ah i am not adding the memory-region prop to sio node *facepalm*
<ChaosPrincess>
jannau: for touchbar its tx/rx a 64-bit zero, then send the firmware in yet-another-apple-encoding, then it sends hid events using 'z2' protocol. i figured out how the firmware upload works, but not sure where the 64bit zero comes from
<povik>
[ 0.500180] apple-sio 236400000.sio: RTKit: Initializing (protocol version 11)
<povik>
:)
bluetail has quit [Ping timeout: 480 seconds]
<jannau>
ChaosPrincess: looking at old keyboard traces macos seems to do that there as well. I don't think we do that spi_hid