ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
Fanfwe42 has joined #asahi-dev
Fanfwe has quit [Remote host closed the connection]
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
Fanfwe has joined #asahi-dev
Fanfwe42 has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
zef has joined #asahi-dev
kettenis has quit [Ping timeout: 480 seconds]
zef_ has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi-dev
<kevans91>
this may be a stupid question, but is there some hardwar prereq for enabling the FPU (M1) that I might be missing? We take our very first floating point exception from el0, setup cpacr_el1, instruction barrier; the subsequent ldp to q0/q1 causes an apparent hang (no exception AFAICT)
<kevans91>
hardware, even
<kevans91>
I don't really see anything we do differently than, say, OpenBSD, in response to EXCP_FP_SIMD
Fanfwe42 has joined #asahi-dev
Fanfwe has quit [Read error: Connection reset by peer]
supay has joined #asahi-dev
<marcan>
povik: FWIW the safe cap is -14dB lower than the current one (at that volume level no speaker can overheat with worst-case input)
<marcan>
so that has to be the DVC level cap when no safety daemon is running
<marcan>
the thing is though, especially for the tweeters, the headroom helps a *lot*
<marcan>
you can hear it in the IWTLW demo: the snares during the dubstep part of the song sound nice and crisp, but when the insane clipped pads come in, they overload and throttle
<marcan>
then they gradually come back after that part
<marcan>
for less ridiculous inputs, that means you can have some pretty loud everything and still sound crisp even if the tweeters are running at like 4x max steady-state power during HF transients or even more (that's 6dB free headroom)
<marcan>
max steady-state for woofers is 1.3W, about 1.0W for tweeters
<marcan>
but the peak power the amps can put out is like 22W
<marcan>
(well, 11W peak for a sine, 22W is peak for a square/IWTLW)
<marcan>
so we basically have ~8x power headroom give or take, which is not ridiculous when ~4x is clearly actually useful
<marcan>
so I don't think we want to cap lower
<marcan>
this is all for j314
WindowPa- has joined #asahi-dev
WindowPain has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Ping timeout: 480 seconds]
akemin_dayo has quit [Ping timeout: 480 seconds]
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
akemin_dayo has joined #asahi-dev
nyilas has joined #asahi-dev
hir0pro has joined #asahi-dev
hir0pro has quit [Ping timeout: 480 seconds]
eiln has quit [Remote host closed the connection]
hir0pro has joined #asahi-dev
eiln has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ChaosPrincess>
sven: additional thing w.r.t firmware names - we already use that same firmware-name in dt scheme for dockchannel firmware
<sven>
which also isn't upstream and I'd probably have the same comment there
<ChaosPrincess>
ok
<ChaosPrincess>
i guess you convinced me to go grab the compatible from the root node
<sven>
maybe wait for the dt maintainer's opinion ;)
<kettenis>
I'm not necessarily against having the firmware name in the binding (and there is plenty of prior art)
<kettenis>
but having a directory name in there is a mistake if you ask me
chadmed has quit [Remote host closed the connection]
nyilas has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
<chadmed>
marcan: speakersafetyd still only works with 48 kHz. silver lining is that it seems pretty infallible for 48 kHz sources with the DSP graph on top of it!
<chadmed>
easy workaround for now if you want to ship something Soon(tm) is just lock to 48 kHz in the pipewire config file, but that will still break alsa and pulse users
<chadmed>
i still think long term if we _really_ dont want to worry about excursion we're going to need virt bass. if that can be implemented easily with biquads it would probably end up being easier on the CPU than the ridiculous multiband compressor we have now
<chadmed>
which only really exists to maintain a constant-ish sound profile as we clamp down the woofers
<chadmed>
all that overexcursion happens below 200-ish hz so cutting that out and replacing it with the psychoacousic effect would mean we should be able to get rid of the compressor and save a boatload of energy
<rowanG337>
I also have a M2 MBP Max if you want something from OSX
<rowanG337>
and I can see in LSPCI something with Goshen Ridge: `0000:01:00.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)`
hir0pro has joined #asahi-dev
<sven>
rowanG337: is that lspci output without the hub connected?
<rowanG337>
No with the hub connected. I can post the Full lspci output
<sven>
that would be helpful. essentially I'm looking for a machine with a usb4 host controller as well
<sven>
yup, look like that's a thunderbolt 4 host! :)
<sven>
can you run a kernel with thunderbolt debug out enabled?
<rowanG337>
Sure. If you tell me how I can do that.
<rowanG337>
Is that a kernel build option?
<sven>
the duct tape version is to replace dev_dbg, etc with dev_err drivers/thunderbolt/tb.h
<sven>
I think there's a way to use dyndbg to just enable it for thunderbolt as well as long as the kernel is compiled with CONFIG_DYNAMIC_DEBUG
<sven>
thunderbolt.dyndbg=+p in the boot args maybe
<rowanG337>
I will do the ducktape option. That should work for sure
<rowanG337>
does kernel version matter?
<sven>
not really
<sven>
what I'm curious about is the output when booting the machine without the hub connected, then connecting only the hub and then connecting another device after the hub
eiln has quit [Quit: Page closed]
<rowanG337>
Oke I will manage that. I probably do it tommorow since right now I use the laptop for work :).
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
sure :)
<sven>
I essentially want to compare the path and tunnel creation on a host that's known to work with what my m1 driver does
<sven>
rowanG337: oh, also lspci -xxxx would be useful but note that lspci claims that's "(dangerous; root only)"
<sven>
probably because it can trigger bugs in broken hardware and maybe require a reboot I guess
<chadmed>
you have to be _really_ hammering these sorts of speakers for a fair amount of time to cause permanent/audible damage
<chadmed>
and like i said if we "officially" support some sort of psychoacoustic bass thingy in pipewire we can just set the high pass on the woofer amps to 100hz and eliminate most if not all the overexcursion issues
<sven>
povik: nice!
<povik>
and the options actualy *do* work! :D
<sven>
:S
<sven>
*:D
<chadmed>
povik: making them work was the tricky part!
* sven
is looking forward to a picture of this old thunderbolt display I have connected to my mac mini :>
<sven>
just need to figure out why dcpext doesn't like dp-over-tbt tunnels
hir0pro has joined #asahi-dev
kesslerd has quit [Remote host closed the connection]
<jannau>
povik: \o/
<jannau>
how does that work from macaudio PoV. do we a single display audio output device or one for each dcp?
<jannau>
I guess we need to start thinking about how we model the output ports for the display subsystem in the device tree
<povik>
there's a separate sound card for each dcp. and it all is independent of macaudio.c
<povik>
the driver ended up not involving ASoC even
<povik>
i spawn a device here, and then the driver in gpu/drm/apple/audio.c binds on it
<povik>
that driver should move to sound/apple/dcp_audio.c or similar
<povik>
it just needs to be further decoupled from the rest of dcp
<povik>
(does #include "parser.h" at the moment)
arnd has quit []
arnd has joined #asahi-dev
<povik>
in the devicetree all that happens is that the dcp node gets an apple,audio-xmitter prop referencing a dpaudio node
<jannau>
maybe afk/epic/parser should be moved to drivers/soc/apple if the audio driver depends on parser
<povik>
but it's not the epic bits that the audio driver depends on, just general parsing of the apple structures
<povik>
though that might be moved there too, right
<jannau>
naming is a little weird since the mapping between dcp and output port will become deynamic
kesslerd has joined #asahi-dev
<povik>
i was thinking it makes sense keeping the parsing with dcp, just reworking the interface between dcp/dcp_audio so that the parsing is abstracted away from the audio driver
<povik>
actually it pretty much is already
<povik>
let's see why do i need parser.h
<jannau>
that sounds liek we should try to keep paerser with drm/apple
Fanfwe42 has quit [Ping timeout: 480 seconds]
<povik>
yeah, i just call the 'parse_*' functions directly from audio.c
<povik>
to be in line with other drm/audio drivers we should abstract this away to a set of callbacks in the platform data given to the audio device
<povik>
this is the decoupling i had in mind
Fanfwe has joined #asahi-dev
<povik>
jannau: re naming, there's getProductAttributes on the audio epic service
<povik>
we can patch that through to the audio device (it reads the data already, but merely exposes them in debugfs)
<povik>
and it can use the remote device name in naming of the sound card
<povik>
although i don't see a way to do dynamic audio device naming in ucm
<jannau>
that's the display's name
<jannau>
?
<povik>
it has bunch of info, including the display model
<povik>
i found out in what week my display was manufactured :D
kesslerd_ has joined #asahi-dev
<jannau>
so derived from EDID
<povik>
technically the ALSA sound card has to have a static name depending on the DCP instance only
<povik>
but we can offer further info for sound servers on read-only device controls
<jannau>
I think it would make more sense to have dynamic names based on which port dcp is muxed to
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jannau>
so probably only three distinct options: hdmi, usb-c, thunderbolt
<povik>
ah!
<povik>
there's one way to do it
<povik>
we can have individual jacks corresponding to hdmi, usb-c, thunderbolt on the sound card
<jannau>
not even sure if the distinction between usb-c and thunderbolt makes sense
<povik>
and their plug state will reflect to what port the dcp is routed to
<povik>
this can propagate into picking up the right 'SectionDevice' from ucm, which contains the name to be presented to users
<jannau>
ah, that makes sense. naming the cards after their dcp(ext) would work then
gladiac has joined #asahi-dev
<povik>
it would be hard to do otherwise, the alsa cards would need to be recreated dynamically probably
<povik>
but the alsa card name need not be the name presented to users, and there might even be some other way to influence the latter than by jack state
dsharshakov has joined #asahi-dev
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dsharshakov>
Maybe it's better to create it dynamically with the monitor name in place, since desktop HDMI audio does the same (IIRC being snd-hda-intel inside)
<povik>
really? are you sure?
<dsharshakov>
it's more expected to see display name from EDID there, not the port type
hir0pro has joined #asahi-dev
<dsharshakov>
AMDGPU shows monitor name
<dsharshakov>
And Radeon is being an HDA device. Unsure about the exact mechanisms
<dsharshakov>
so apparently it's reported in some non-ordinary way but uses that ELD
<povik>
which is something hdmi-codec.c has
<dsharshakov>
> The ELD format is specific to HDA Intel sound cards
<povik>
argh
<povik>
where is that from?
<dsharshakov>
first link
<dsharshakov>
but at least we (PW) shouldn't check for it being an HDA device. ALSA and PA might be different though
<dsharshakov>
And UCM is optional in that mix (maybe can be avoided), ACP can handle that just fine
<povik>
ACP is the pipewire alsa layer?
<dsharshakov>
ALSA Card Profile, yes, it's implemented by PW
<povik>
it's a profile for pipewire, it doesn't have meaning outside of pipewire, right?
<dsharshakov>
Yes, idk how PA handles devices without UCM and how does it treat HDMI
<povik>
ok, making sure i understand it right
<dsharshakov>
profile-wise, have you checked passthrough modes on HDMI (Dolby TrueHD, DTS, other codec bitstreamed directly to AV receiver)?
<dsharshakov>
might also be architecturally important
<povik>
i don't understand those words
<povik>
i get a blob from the dcp describing the available formats and channel layouts
<povik>
and i translate that into alsa talk
<dsharshakov>
SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE or something like this
<povik>
ah, i think we won't support that
<dsharshakov>
SPDIF-like data offloading. Apparently driver has something to do with that
<dsharshakov>
No RE sample like supporting TV to test?
<povik>
'RE sample like'?
<dsharshakov>
Something to attach and trace with to see how it's handled
<dsharshakov>
Many modern TVs should have that sort of thing, and macOS is likely to take advantage of that (since no immersive audio is possible with PCM only)
<povik>
why wouldn't immersive audio be possible otherwise? it's not possible to send a many-channel pcm stream over hdmi?
<dsharshakov>
I mean stuff like Atmos apparently only existing in compressed forms (pass bitstream to the AV receiver which decodes metadata to render sound objects)
<dsharshakov>
not just 7.1 which is handled by HDMI PCM
<ChaosPrincess>
povik: atmos and similar crap only exist as patent-encumbered undocumented format, and everyone just sends them to the AV receiver to decode, instead of decoding it on player cpu
<povik>
hmm
<povik>
yeah, sounds like crap :D
<povik>
(pun not intended)
<dsharshakov>
AFAIK also possible to offload just because of why not, even if it's just some spdif encoded format
<jannau>
bandwidth (you can have more than 7.1 channels) and you need missing knowledge of the speaker config (and room) to mix it correctly
<dsharshakov>
but maybe that can be left for later
<povik>
anyway indeed i don't have a TV with fancy sound regimes to test the driver against, but i implemented some features into the driver so people can post what DCP advertises about different displays
<povik>
so we will see about this
<kettenis>
jannau: isn't the bandwidth of some extra audio channels negligable compared to 4K video? ;)
<povik>
btw speaker layout is already parsed out from the DCP blob and pushed to userspace
<povik>
although there's one thing i don't understand about the channel layout negotiation
<povik>
but seeing the blob corresponding to different displays should help with that
hir0pro has joined #asahi-dev
dsharshakov has quit [Remote host closed the connection]
<jannau>
kettenis: it's transmitted during video blanking and max channels, samplerate and resolution is specified. I missed that it was increased to 32 channels in dp 1.4
rkjnsn_ has quit [Quit: Page closed]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0pro has joined #asahi-dev
<sven>
hrm, there’s a “CF VID” that seems to be somehow related to usb4 mode in the tipd chip
<sven>
any idea what that could be? can’t find anything related to USB PD called “CF”
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gladiac has quit [Quit: k thx bye]
eiln has joined #asahi-dev
hir0pro has joined #asahi-dev
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stickytoffee has quit [Quit: brb]
nyilas has joined #asahi-dev
hir0pro has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
stickytoffee has joined #asahi-dev
<povik>
jannau: upping LMB_MAX_REGIONS to 32 doesn't seem to help with the reservation errors
<kettenis>
the lmb ifdefs are a complicated maze that even confused the core u-boot developers recently
<sven>
cute, looks like xnu can freeze all drivers on a pci bus, reassign resources and then thaw everything again. looks it supports my usb4 hub to dock to another dock setup that way
<sven>
looks like that’s a special power state called kIOPCIDevicePausedState
<povik>
kettenis: will test
<sven>
still doesn’t explain why it gets hotplug interrupts and I don’t though :(
<povik>
:(
kesslerd__ has joined #asahi-dev
kesslerd has quit [Ping timeout: 480 seconds]
kesslerd_ has quit [Ping timeout: 480 seconds]
kesslerd has joined #asahi-dev
bluetail has joined #asahi-dev
<sven>
uhhh… why does it not access the config space of the bridge that gets the hotplug
<sven>
why does it instead access something in the config space if the root port
<sven>
im going to be very annoyed if it turns out that all hotplug interrupts are routed to some apple-specific thing in the root port
hightower2 has quit [Remote host closed the connection]