millenialhacker has quit [Ping timeout: 480 seconds]
zshrc has joined #asahi-dev
zshrc has quit []
jmalexan has joined #asahi-dev
jmalexan is now known as NotDisliked
weitcis_ has quit [Ping timeout: 480 seconds]
weitcis_ has joined #asahi-dev
user982492 has joined #asahi-dev
amarioguy2 has quit [Ping timeout: 480 seconds]
amarioguy2 has joined #asahi-dev
<amarioguy2>
re: the "go into OS selector every time" question there's probably some hacky workaround but officially sanctioned i don't think so
<cyrozap>
povik: Thanks again for your help--I've managed to successfully download and extract the ASMedia firmware. Interestingly, the firmware version ("191118_70_11_11") is newer than any other I've seen in the wild so far. I wonder if they fixed the bug where trying to read from two devices simultaneously can sometimes cause a bad DMA write...
amarioguy2 has quit [Ping timeout: 480 seconds]
weitcis_ has quit [Quit: Konversation terminated!]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
stsmwg has joined #asahi-dev
stsmwg has quit []
stsmwg has joined #asahi-dev
NotDisliked has quit [Quit: Konversation terminated!]
<cyrozap>
I have some questions regarding the DART IOMMU. If my understanding is correct, some Apple SoCs only have a 36-bit address space, while others have a 42-bit address space. Is this just the physical limit, and the I/O virtual address can be larger (e.g., greater than 48 bits)? Or does this limit apply to the virtual addresses as well? Like, would Linux running on an Apple SoC ever tell a PCIe device to
<cyrozap>
write to an address larger than 48 bits?
stsmwg has quit [Quit: Lost terminal]
<chadmed>
marcan: i think 7cf5c453e960 on asahi-installer collides with the latest asahi-scripts
<chadmed>
python tries to install /usr/bin/asahi-fwextract now which makes no sense if we have it in asahi-scripts
<marcan>
ah, yeah
<marcan>
cyrozap: we're still having trouble with the "reset to ROM code for firmware upload" step sometimes, so if you find anything wrong in the code please do tell...
<marcan>
I just reverse engineered that by copying what macOS does, I don't know what the indirect write regs do
<marcan>
also now I wonder where the hell I got ASM2214 from, that has to be a typo...
millenialhacker has joined #asahi-dev
<marcan>
probably meant to write 2142
<marcan>
lovely that I typoed the firmware filename... good thing we have fwextract to fix that...
<marcan>
still should probably use the public part number for the firmware name
<marcan>
cyrozap: re the instability, maybe we need the confirmed mmio write thing?
<marcan>
or just the sleeps
<cyrozap>
If you do use the public part number, I'd use 2142 instead of 3142, since as far as I can tell the 3142 is just a newer die revision of the 2142. No idea what the _actual_ differences are, but they both use the same firmware images and have identical mask ROMs.
<cyrozap>
And yes, you might need to confirm the writes.
<marcan>
I think some people said they are the same chip, and the firmware is the only difference
<marcan>
as in you can turn a 2142 into a 3142
<marcan>
(IIRC 3142 has higher speed USB support?)
<marcan>
could be a product differentiation thing
mac456 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cyrozap>
they support the same speeds on both USB and PCIe. Since ASMedia no longer lists the 2142 on their website, and the 2142 and 3142 have different chip version numbers (which you can access by doing an indirect read to byte 0x150B2), I'm pretty sure they just fixed something in the silicon and called it a new chip to avoid having to explain multiple 2142 revisions to their customers. I hope to eventually
<cyrozap>
have someone decap and image both the 2142 and the 3142 so we can confirm if they really are the same die, and check the mask revision numbers to confirm what changed.
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
beeblebrox has quit [Quit: Konversation terminated!]
nicolas17 has quit [Quit: sleep]
<cyrozap>
marcan: Regarding instability, thinking again about what I needed to do to get direct firmware loading working on the older chips, I think you might need to confirm the writes to the address registers for both the indirect code RAM writes and the indirect MMIO writes. And yes, you might also need the sleeps, too. My Python code using PCI config space accesses is slow enough that I didn't experience
<cyrozap>
much issues (though I do remember adding the sleeps for the indirect MMIO writes), but C kernel code writing to PCI MMIO may simply be writing all the registers too fast for the chips internal busses to keep up.
<cyrozap>
And to be clear, those sleep values were obtained by experimentation and I just set them to "good enough to work reliably but not too slow", so you might want to experiment to see if you can get away with smaller delays.
<cyrozap>
Oh, and one more thing:
<cyrozap>
Actually, never mind.
<cyrozap>
I wrote a bunch of stuff, but then realized it didn't apply :P
<cyrozap>
I think I'm going to try some stuff myself on an ASM3142 I have here, and report back with my findings.
millenialhacker has quit [Ping timeout: 480 seconds]
tmlind has quit [Quit: leaving]
tmlind has joined #asahi-dev
nickchan has joined #asahi-dev
nickchan has left #asahi-dev [#asahi-dev]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
lethalnyan has quit [Quit: kill -9 -1]
lethalbit has joined #asahi-dev
nickchan has joined #asahi-dev
nickchan has left #asahi-dev [#asahi-dev]
fossdd has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
dsharshakov has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
<dsharshakov>
chadmed: could you please discuss new audio requirements in PipeWire IRC room? Not urgent
millenialhacker has joined #asahi-dev
<chadmed>
there are none at the moment actually, i figured out how to integrate the compressor in a sane way
dsharshakov has quit [Remote host closed the connection]
<chadmed>
actually we might want the equal loudness plugin to work properly at some point
dsharshakov has joined #asahi-dev
<dsharshakov>
So you managed to make woofers not touch the lower case?
<chadmed>
yeah that problem is all fixed, the final frontier now is just tying the volume control to a port on a plugin in the chain
<chadmed>
i.e. linking the volume control to the volume knob on the equal loudness plugin
<dsharshakov>
Okay, so my task is limited to loading filter chain for now?
<chadmed>
yep, safety et al will be handled elsewhere either in the DSP chain or as an external thing that talks directly to alsa
millenialhacker has quit [Ping timeout: 480 seconds]
<chadmed>
so all we need out of wireplumber is hiding the "real" device and loading the filter chain automatically a la UCM
<dsharshakov>
Sure, disclaimer WP isn't a safety software!!!
<dsharshakov>
Whats up on safety research btw? Will it live in kernel or a daemon monitored by it?
<chadmed>
supposedly a userspace daemon monitoring the V/ISENSEs of the speaker amps that will talk directly to alsa and cut the volumes in alsamixer dynamically to prevent meltdown
<chadmed>
so we dont need to worry about it from a DSP perspective, the compressor is there because the cones flapping against the chassis is not a meltdown problem, its a physical constraint problem
<chadmed>
and simply lowering the max volume to fix it is stupid because you lose a boatload of headroom and make the whole thing quieter when really you just want certain frequencies quieter for tiny fractions of a second at a time
<dsharshakov>
That simple? No need to handle VI sense in PW to avoid approaching limits using DSP?
<chadmed>
nope, which im ambivalent about
<chadmed>
on one hand implementing that in pipewire is probably going to be nightmarish since it has to keep track of _all_ the mixer controls and stuff and then that would need to be generalised for all similar devices with some new system/format for safety rules
<chadmed>
but at the same time that really does sound like good long term goal...
<dsharshakov>
Yup. And why not a kernel based alarm system for emergency shutdown?
<chadmed>
we already have that, the amps cut out on certain failure conditions and theyve been programmed to bring themselves back up after doing so
<dsharshakov>
Oh btw wanted to ask povik to add a panic handler turning safety mute on just in case. At least on PC systems hang can keep the audio playing
<chadmed>
the other thing is having safety stuff outside of any particular audio server means itll work for everyone using bare alsa, pulse, etc
<dsharshakov>
Yes, but why not a simple averaging thing for vi in kernel?
<chadmed>
something something floating point i think idk
dsharshakov has quit [Remote host closed the connection]
<chadmed>
also why bother with a semi-hacky kernel gaffer tape solution when we _know_ what we need to do to implement it properly and can do so with much more freedom in userspace?
dsharshakov has joined #asahi-dev
<dsharshakov>
Well, simpler and feels safer than a daemon monitored by a watchdog
<chadmed>
yeah but simpler is not better in this case
eiln has joined #asahi-dev
<chadmed>
whats important to prevent meltdown is the temperature of the coils and magnets, and to derive that from V/I we need a bunch of floating point maths
<chadmed>
the actual V/I by themselves arent useful
<dsharshakov>
Well, less things that could break, bug out or be mishandled by users
<dsharshakov>
Well, fpu stuff is hard for kernel, yea
<chadmed>
sure and thats why the kernel driver already handles _obviously_ wrong stuff, like clamping down the amp gains so that you cant drive enough current through them to _instantly_ pwn them
<dsharshakov>
How is watchdogging planned to be done?
<chadmed>
wdym
<chadmed>
with the derived coil temperature we can just determine when theyre getting too hot and taper down the mixer controls until they cool down again
<dsharshakov>
I cannot imagine a proper solution to monitor the speakersafety daemon to be sure it's doing well and we're safe to use the amps
<chadmed>
it only needs to be tested once, all the values for the temperature model come from apple so its not like we're flying blind
<dsharshakov>
Math principles of the thing are pretty clear to me
<chadmed>
we know the formula, we know the coefficients we need to plug into it, we know it works in macos
<chadmed>
we just need to implement it, verify once that it actually does turn the mixer controls down when its meant to, then we can just leave it alone
<dsharshakov>
But what if it hangs or get killed by megabrain users?
<dsharshakov>
Kernel driver is less prone to that
<chadmed>
yeah, it would be nice to just emergency kill output if the daemon is not running
Graypup_ has quit [Quit: meow]
turo has quit [Remote host closed the connection]
<sven>
because you generally want to avoid floating point in the kernel. you can also just make the watchdog ping it and if it hasn’t seen any feedback in aome time just kill the output
Graypup_ has joined #asahi-dev
<sven>
*some
millenialhacker has joined #asahi-dev
turo has joined #asahi-dev
<dsharshakov>
What would be the api for watchdog? Where would watchdog be?
<chadmed>
but ^, we just cannot implement this modelling in the kernel and you cannot rely on V/I alone even as an estimation because impedance/resistance change with temperature which is what we are trying to measure
<dsharshakov>
I understand it's not to be in kernel. But userspace monitoring should be very robust and resilient against failures
<chadmed>
i think at some point we just need to say "look, we have taken every reasonable precaution but if you run 'killall do-not-kill-this' then youre beyond saving sorry"
<dsharshakov>
* or users messing with it as well
<dsharshakov>
What if it get OOM killed?
<dsharshakov>
No way
<sven>
I don’t think anyone proposed an api yet and it doesn’t make much sense to discuss it before that
<chadmed>
yeah but we cant help users messing with it, to paraphrase qui gon jinn, theres always a stupider user
<dsharshakov>
Need better protection against fails
<sven>
and again, just make it ping the kernel and the kernel shutdown on timeout
<dsharshakov>
Got it
<chadmed>
lets get the stuff we're actively working on ready to ship before we start worrying about this in too much detail anyway
<dsharshakov>
povik: my idea for enhanced speaker safety is to also have a panic handler disabling TAS2764 in case of kernel panic. I think admac will keep sending a stuck audio fragment in case cpu hangs
<chadmed>
as far as a standard asahi install goes now that we have pipewire we can make things "safe enough" OOB for brave users to try out
<dsharshakov>
Yep, will work on that! Need to port things to new wp 0.5 and fix validity issues
<chadmed>
with the DSP chain in place and the latest kernel driver im confident enough to say its impossible to break the speaker array. what we need extra stuff for is to _guarantee_ that safety to _everyone_
<dottedmag>
This is not what is in the latest blog update, isn't it? «Of course, you could limit the volume to a known-safe level, but this would result in significantly reducing the overall volume and leave a lot of unused headroom for most normal music and audio signals!»
millenialhacker has quit [Ping timeout: 480 seconds]
dsharshakov has quit [Remote host closed the connection]
<chadmed>
thats exactly what im saying though
<chadmed>
we cant just brute force a lower volume in the kernel because then you lose headroom and things sound bad at low volume etc
<chadmed>
so we need to do two things
<chadmed>
a) be able to dynamically control the volume based on how hot the driver is
<chadmed>
b) dynamically control the volume based on the strength of the input to stop the cones "bottoming out" on the chassis
<chadmed>
b) is easy and we do this in DSP already, a) is harder and is what we're talking about
<chadmed>
being able to do that dynamically means that we get to keep all the headroom available when its safe to do so and only start capping stuff when we need to
Graypup_ has quit [Ping timeout: 480 seconds]
<dottedmag>
I still don't get it. Is it something like "unless we have a heartbeat, volume is capped to overall-safe level, but as long as the monitoring daemon is live, the volume can go beyond the statically-safe limit, based on output from that daemon"?
dsharshakov has joined #asahi-dev
turo has quit [Ping timeout: 480 seconds]
tpw_rules has quit [Ping timeout: 480 seconds]
<chadmed>
well again we havent gotten that far but thats one way to do it
<chadmed>
the point dsharshakov is making is that the kernel driver should do something _like_ that if the daemon isnt running to stop the speakers from melting if the daemon crashes or is killed
<dottedmag>
yeah, the driver should fail-safe, obviously.
<dsharshakov>
Yes, that is the proper approach when all the safety mechanisms are in place to make sure every single moment amps work there's strict observation to keep things safe. When no daemon is present, set low hardware volume caps unless it appears and starts monitoring.
<dsharshakov>
Also ensure robust panic and hang handling
Graypup_ has joined #asahi-dev
<dsharshakov>
And after daemon shakes hands no one can take over hw gain control while it's running. Even root
turo has joined #asahi-dev
<chadmed>
can you make alsa lock how kcontrols from userspace?
<chadmed>
s/how/out
<dsharshakov>
Ofc not a protection from malware running as root, but a measure against messing with sudo alsactl
millenialhacker has joined #asahi-dev
tpw_rules has joined #asahi-dev
tobhe has joined #asahi-dev
dsharshakov has quit [Remote host closed the connection]
tobhe_ has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Ping timeout: 480 seconds]
<eiln>
github is still giving me hell
<eiln>
oh sorry -- forgot to re-introduce myself. my nickname before was "lamlam", i.e. ane guy. my real name is eileen (handles use eiln).
<eiln>
in the mean time ive enabled 1D element-wise mode! add/mult/min/max working good
<eiln>
still fighting some float packing and tiling for multi-dim...
SSJ_GZ has quit [Remote host closed the connection]
SSJ_GZ has joined #asahi-dev
millenialhacker has joined #asahi-dev
tobhe_ has joined #asahi-dev
Graypup_ has quit [Ping timeout: 480 seconds]
turo has quit [Ping timeout: 480 seconds]
tpw_rules has quit [Ping timeout: 480 seconds]
turo has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Ping timeout: 480 seconds]
Graypup_ has joined #asahi-dev
tpw_rules has joined #asahi-dev
<ChaosPrincess>
eiln: are you using a weird email address on ghithub
<ChaosPrincess>
as in - a weird domain
<eiln>
no i have gmail and proton
<eiln>
argh the support page updated with " Due to high support volume.." and are asking "up to seven business days" ..
<eiln>
API is slowly breaking too.. can't search code, etc.
<TellowKrinkle>
I've been randomly getting 100-200kbps clones recently
<TellowKrinkle>
I thought it was just my internet being funny but maybe not
capta1nt0ad has quit [Read error: Connection reset by peer]
dsharshakov has joined #asahi-dev
<dsharshakov>
It might be right time to have redundant mirrors of essential repository on g.fd.o
<dsharshakov>
But that won't help organizing tons of bits branches however
<dsharshakov>
eiln: what're your plans on UAPI to expose ANE to apps? How suitable does accel from 6.2 feel?
dsharshakov has quit [Remote host closed the connection]
<eiln>
dsharshakov: great question, no idea. im not even sure where it would even fit under drivers/, if i get to that point
dsharshakov has joined #asahi-dev
<eiln>
i dont know apple terminology too well but im pretty sure accel is their cpu framework.
<dsharshakov>
That would depend on memory model
<dsharshakov>
Accel subsystem of Linux kernel I mean, read news about 6.2
<chadmed>
accel seems like a good fit from preliminary reading
<chadmed>
i guess itll take a little while for userspace applications to start making use of it though
<sven>
please stop skipping to step 100 when step 1 isn't even done :D
dsharshakov has quit [Remote host closed the connection]
<eiln>
agree, exciting stuff but i still havent figured out dma interleave when size >= 32
<sven>
lina's gpu UAPI also started with essentially a hack and now she's only slowly converging towards something upstreamable
dsharshakov has joined #asahi-dev
<dsharshakov>
chadmed: if it could be wired up to TensorFlow PluggableDevice API, then tf apps will be able to make use of ANE even in case supported op count is low. Unified memory gives us possibilities to not care about moving data between ANE and CPU being slower than benefits from initial ops implementation
dsharshakov has quit [Remote host closed the connection]
<sven>
<sven> please stop skipping to step 100 when step 1 isn't even done :D
zimsneexh has joined #asahi-dev
millenialhacker has joined #asahi-dev
dsharshakov has joined #asahi-dev
<maz>
marcan: solved my X issue with 6.1 on m2: the FB_EFI was getting in the way. with 6.0, simpledrm is able to take over from EFI, but not with 6.1, apparently. just disabled the option, and all is good.
<dsharshakov>
Alright, sorry for that. Sometimes having an outline of end product can help developing core as well, so I added those ideas to keep them around
dsharshakov has quit [Remote host closed the connection]
millenialhacker has quit [Ping timeout: 480 seconds]
<eiln>
considered doing literally 1+2 a feat yesterday, longg way to go
eiln has quit [Quit: Page closed]
<sven>
yeah, these things go a bit different when reverse engineering hardware. it makes sense to start these discussion once it comes to implementing a linux driver but before that it's just guesswork because it's unclear what the hardware can even do
<sven>
and running something equivalent to "1+2" is already a big step when reverse engineering :)
bluetail9 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
a_plastic_bag has joined #asahi-dev
leitao has joined #asahi-dev
bluetail has quit [Ping timeout: 480 seconds]
bluetail9 is now known as bluetail
a_plastic_bag has quit [Quit: WeeChat 3.7.1]
leitao has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
zimsneexh has quit [Quit: zimsneexh]
millenialhacker has quit [Ping timeout: 480 seconds]
Kasper has joined #asahi-dev
Kasper has quit [Remote host closed the connection]
CatDentures has joined #asahi-dev
jvzr has joined #asahi-dev
jvzr has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
cylm has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
weitcis has joined #asahi-dev
pjakobsson has joined #asahi-dev
weitcis has quit [Remote host closed the connection]
jvzr has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
Heyb4r has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
Heyb4r has quit [Remote host closed the connection]
Heyb4r has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
Heyb4r has quit [Ping timeout: 482 seconds]
Heyb4r has joined #asahi-dev
Heyb4r_ has joined #asahi-dev
Heyb4r has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #asahi-dev
Heyb4r_ has quit [Ping timeout: 480 seconds]
Heyb4r has joined #asahi-dev
Heyb4r has quit [Remote host closed the connection]
Heyb4r has joined #asahi-dev
Heyb4r has quit [Ping timeout: 480 seconds]
Heyb4r has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
Heyb4r_ has joined #asahi-dev
Heyb4r_ has quit [Read error: Connection reset by peer]
<sven>
it also contains the "proper" code to recognize and switch to dp-altmode
<sven>
won't work with dcpext yet though because the HPD OOB notification won't work yet
<sven>
(note that the role switch quirk changed a bit again, the tipd typec_set_mode path changed and the DTs have svid = <0xff01>; for now because that's what the mux code expects)
<amarioguy>
maz: speedy vgic time :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
zimsneexh_ has joined #asahi-dev
zimsneexh has quit [Ping timeout: 480 seconds]
zimsneexh_ is now known as zimsneexh
<maz>
amarioguy: bah, there wasn't much overhead from the traps the first place (interrupts are a pretty rare event anyway)
<ChaosPrincess>
i am trying to trace spi with mini and getting an error "Event checksum error: Expected 0x00000002, got 0xd0decade", after which the mac reboots. Anyone seen something like that?
<sven>
reboots usually happen when you do something either the soc itself or xnu really doesn’t like
<sven>
can you paste the tracer you use somewhere?
millenialhacker has joined #asahi-dev
<sven>
and iirc most of spi goes through this weird SmartIO coprocessor
<ChaosPrincess>
if i comment out the exception code in m1n1, only m1n1 client crashes, while the mac proceeds to boot
<jannau>
ChaosPrincess: I don't think I saw that while tracing the keyboard/mouse. the sio tracer in hv/trace_keyboard.py had sharp edges but I can't remember any SPI only issues
<ChaosPrincess>
the touchpad does not seem to use sio
<jannau>
SPI only is for the keyboard unfortunately not interesting