thelounge7571340 has quit [Remote host closed the connection]
whistlingoat has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
whistlingoat has joined #asahi-dev
whistlingoat has quit [Ping timeout: 480 seconds]
Etrien__ has joined #asahi-dev
Etrien_ has quit [Ping timeout: 480 seconds]
Etrien__ has quit [Read error: Connection reset by peer]
Etrien_ has joined #asahi-dev
chadmed has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
Etrien has joined #asahi-dev
Etrien_ has quit [Read error: Connection reset by peer]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
argonaut has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
<chadmed>
povik, marcan: thoughts on deactivating the * Mux kctls on the laptops? i dont see any need for a user to change them, and having them statically set in the driver eliminates one more avenue for misconfiguration
<chadmed>
also fwiw the amp gain kctls dont have Volume in their name, so those gain caps in the fixup methods werent applying
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chadmed has quit []
chip_x has joined #asahi-dev
chadmed has joined #asahi-dev
<chadmed>
ignore that last message
chipxxx has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
gaudem has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien_ has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
Etrien has joined #asahi-dev
Etrien_ has quit [Ping timeout: 480 seconds]
duban6 has quit []
duban6 has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
gaudem has quit [Quit: Connection closed for inactivity]
Etrien_ has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
Etrien_ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
jeffmiw has joined #asahi-dev
<povik>
chadmed: well, there's one weak case for when they could be useful: user not employing speaker EQ, feeding speakers directly, having both speakers and headphones on primary, switching between one and the other using 'pin' controls (which enable the endpoints) instead of restarting playback on different device
<povik>
that's the geneeral case for it
<povik>
arguably it's more useful on mac mini/studio than on the laptops, but i would rather not introduce additional differences into macaudio across models
<povik>
06:10 < chadmed> also fwiw the amp gain kctls dont have Volume in their name, so those gain caps in the fixup methods werent applying
<chadmed>
^ yeah that was the message to ignore, i realised what it was doing immediately after i sent that
<povik>
i guess you figured out some tools don't show the control name in full. if the caps weren't being applied, the driver would refuse probe. really, you should be giving more credit to the driver ;)
<chadmed>
heh yeah, i think i have a better idea of whats going on now that ive spent all day staring at macaudio.c
<povik>
haha, hope it wasn't too bad an experience :p
<chadmed>
once i got my head around the OF parsing functions it was fine :)
<povik>
those are beefy. patches to ease reading of them welcome
<chadmed>
looking at other drivers though, it seems like everyone else hard codes TDM slots based on the hardware. obviously we cant do that since we have lots of different devices to support, but theres also the dai-tdm-slot-num DT property that we may be able to take advantage of
<chadmed>
but since the problem is on the frontends and not the backend DAIs, i cant really see how we would enforce the number of TDM slots unless we could make the safe assumption that the secondary frontend is always the internal speakers, which is why i asked about it
jeffmiw has quit [Remote host closed the connection]
<povik>
re dai-tdm-slot-num. i know it's there. i moved away from the approach of describing the DAI links in full in the DT since there's just too many details and they are tied to internal ASoC representation instead of being inherent to the hardware, so compatible="apple,j313-macaudio" must be where all those details are hidden in
<povik>
including, as you point out, not having a DT representation for the frontend links, since those are an ASoC vehicle
<povik>
11:13 < chadmed> but since the problem is on the frontends and not the backend DAIs, i cant really see how we would enforce the number of TDM slots unless we could make the safe assumption that the secondary frontend is always the internal speakers, which is why i asked about it
<povik>
we shouldn't enforce the slots (which would constrain the number of channels in mca.c), we should constrain the number of channels from macaudio.c directly
<povik>
and that we can do to the maximum number of channels on a backend link, so to the number of speaker channels
<povik>
so there's not much we need to assume
<chadmed>
so basically look at the backends, get the max number of channels on any one backend, then set a constraint to that number on secondary?
<povik>
exactly. you can set the constrain on all frontends
<povik>
on the primary, it will be a no-op, since it's already constrained by slots
<povik>
but it's better than to special-case
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<povik>
chadmed: if you want to give implementing it a go, i think you should apply the constrain in .startup of macaudio_fe_ops
<povik>
then call the alsa constraint function like in the recent channels-according-to-slots MCA patch
<chadmed>
ack, ill have a go of it on tuesday
<jannau>
sven: does apple-dart miss a check to prevent .domain_alloc or at least .attach_dev if there's already a device attached to a specific dart sid?
<sven>
uhh… maybe. Not sure if that’s indirectly enforced by the iommu groups
<jannau>
I started looking into switching piodma to an unmanaged domain. I've currently just create the domain and attach piodma to it. everything still works since the dart is locked but if it wasn't it would be completely broken
<sven>
Doesnt the iommu api look up the piodma group and then just switches the domain on attack for that group?
<sven>
*attach
<jannau>
the group in sysfs still says DMA as type but I end up apple_dart_attach_dev() with domain->type IOMMU_DOMAIN_UNMANAGED
<jannau>
so I think the default domain is still there and keeps working
<sven>
And I assume dart_attach_dev succeeded?
<jannau>
it doesn't prevent iommu_attach_device() from succeeding
<sven>
hm, weird
<sven>
this sounds like something the iommu api should enforce tbh
<sven>
it knows which device belongs to which group and shouldn’t allow a group to be attached to two domains
<jannau>
I think I spotted in the path in iommu.c just a check if there's just a single device in the group
<sven>
it just sounds like an issue every driver would have
<sven>
and something that can be easily caught in the iommu core
<sven>
and also something that should already work tbh
<sven>
vfio more or less does the same thing: create a domain and then attach a device to it that probably still had the default dma domain
<jannau>
I guess it works as long as just the last domain which has device attached is used
<sven>
yeah, but that's by design
<sven>
i'm more concerned that sysfs still shows DMA after attaching the unmanaged domain
<sven>
domain really just means "pagetables with some mappings"
<sven>
technically a domain doesn't need to know about which devices it will be attached to
<sven>
and it's perfectly fine to have two domains with valid mappings to you keep switching
<sven>
+which
<sven>
(the iommu api is a bit confusing because dart has to hack around it quite a bit. this will all get better once robin's cleanup series is done)
<jannau>
there is a check in iommu.c __iommu_attach_group(), the default and blocking domains can be replaced this way
<jannau>
except there is nothing in in apple-dart which can switch between two pagetables
<jannau>
apple_dart_hw_set_ttbr() is only called from attach_dev path
<sven>
isn't attach_dev called from attach group eventually?
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
<jannau>
sysfs shows the type of the default domain
<jannau>
I think everything is working more or less as expected, the default_domain handling is a little surprising and that dma_map_sgtable() still works with the unmanaged domain
<sven>
huh, dma_map_sgtable should go through the dma-api code and create the mapping there
<sven>
so they shouldn’t appear in the unmanaged domain
r0ni has joined #asahi-dev
<jannau>
it ends up in the dart pagetable, not sure how it gets there but the default domain and the unmanaged can write both there
<sven>
now that sounds broken
<sven>
only the currently attached domain should be able to write there
<sven>
but that’s also related to the part where the dart driver has to hack around the iommu so it’s quite possible I messed that up
<jannau>
I don't see how we can enforce that if we map the L1 table for locked darts and the devices is not detached from the default domain
<jannau>
it's only a problem for locked darts and how they are handled right now
<sven>
ah
<jannau>
still a strange that dma_map_sgtable continues to work. I would have expected errors
<sven>
dma_map_sgtable will just create a mapping in the default domain that's not attached anymore
<sven>
and creating mappings in unattached domains is totally fine
<sven>
one way around this for locked darts is to have a shadow copy of the L0 pagetable that's used by iopgtbl the entire time and not memmap anything. then whenever there's a map/unmap you just memcpy(locked-l0, shadow-l0)
<sven>
you can even optimize that with the flush/invalidate callbacks to only memcpy the required entries
<sven>
then device attach is just "memcpy(locked-l0, domain-l0)" and each domain has its own domain-l0
<sven>
(maybe s/L0/L1/, i don't remember the terminology. in the above line L0 = "first level pagetable that sits in memory and is configured in the locked TTBR register")
<jannau>
yes, we still need a way to figure out which is the active
<sven>
why?
<sven>
for each domain you always have a valid allocated shadow-l0
<sven>
and iopgtbl only writes to that
<jannau>
only the active domain can sync to the real L0 table
<sven>
and then only the flush/invalidate callback moves the required pointers to the real l0
<sven>
oh.. true
<sven>
so for the default domain detach is never called?
<sven>
you could probably stash the currently active domain into the group data and only do the l0 sync in flush/invalidate if domain == get_group(dev)->domain
<jannau>
detach_dev doesn't seem to be called at all, even for an explicit iommu_detach_device()
<sven>
huh, I wonder if that's intentional or a bug inside the iommu core
<jannau>
on the other hand there seems to be an attach_dev for the default domain after detach
<sven>
that makes sense
<jannau>
"New drivers should support default domains and so the detach_dev() op will never be called"
<sven>
ah
<sven>
ok
<sven>
so essentially stuffing the currently active domain into the group data on attach and then only syncing to the locked table in attach/flush/inval should work for locked darts
<sven>
not great.. but oh well
<sven>
or maybe even stuff it into something in struct apple_dart. dart->fake_ttbr = domain; :-P
<sven>
marcan: ^-- so I can reliably overflow the mailbox queue with just lots of dcp debug spam. kinda surprised lina hasn't run into this with the gpu yet
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Adelphos has joined #asahi-dev
Adelphos was kicked from #asahi-dev by ChanServ [You are not permitted on this channel]
Adelphos was banned on #asahi-dev by ChanServ [*!*@169.150.196.*]
<sven>
hrm, when tracing I can see the dcp->ap call that sets all modes but for some reason they aren't propagated to drm correctly I think
<sven>
huh, looks like parse_mode fails for all of them
pg12 has quit [Quit: pg12]
<marcan>
sven: lina's GPU stuff is synchronous right now, so you can't run into it unless you have MBOX_TX_QUEUE_LEN/2 apps actively rendering simultaneously I guess
<marcan>
so... that's a global define?
<marcan>
can we just yeet this thing already?
<marcan>
this is a giant mess
<sven>
yup, global define
<sven>
and apparently the three(?) context switches in the tx path are enough to overflow that queue
<marcan>
lovely.
<marcan>
kill it with fire please.
<marcan>
if you come up with something to migrate RTKit to an internal implementation in soc/apple I will merge it and push for it upstream
<sven>
yeah, it should be simple enough
<sven>
ive hacked the define to 200 for now to debug DCP
<marcan>
yeah
<marcan>
also for lina, I think she can make the hardware tx queue unable to ever block, since she has 12 pipes I think? and 12 < 16
<marcan>
the shared mailbox code can keep a ring log of the last 16 submissions, and then a special TX function could poll the pending ones (reading the rptr from the hardware) and elide the send if there is already an identical message queued
<marcan>
(since mbox messages for AGX are just doorbells)
<sven>
for DCP syslog the rx path seems to be much faster than the tx one which results in that overflow
<sven>
probably because the rx one doesn’t have those additional context switches in there
<marcan>
yeah lol
pg12 has joined #asahi-dev
<jannau>
how does the parsing fails? I hope it's not the color mode check I added for lina's capture card / glmark2-drm
thelounge7571340 has joined #asahi-dev
<sven>
not sure yet, went for lunch and now i'm gonna add more tracepoints to see what's going on
thelounge7571340 has quit [Remote host closed the connection]
<sven>
looks like it gets color modes though. guess something on the dptx side is broken then
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
<jannau>
if you uncomment "#pprint.pprint(self.dcpav_prop[key])" dcpext.py will print the parsed Color/Timing Elements
<sven>
dcpext.py is kinda broken now :D
<sven>
but i already don’t see all the dptx calls that I expect in Linux
<mps>
kettenis: any hint or doc how would multiple esp work? create two or or more esp on same disk?
<kettenis>
two proper installs using the Asahi installer
<mps>
aha, thanks
<kettenis>
I don't want to be rude, but this probably should be tested by somebody who understands how multiple ESPs work
<mps>
np, I just wanted to get idea how it would work, not to test it now
henry has joined #asahi-dev
<jannau>
kettenis: booting works. any idea how to handle "/chosen/asahi,efi-system-partition"?
<jannau>
what would be required to have labels for the boot entries
<kettenis>
jannau: see the "HACK: Use designated ESP" commit on that branch
<kettenis>
regarding labels, that can be done through UEFI variables
<kettenis>
I think
<kettenis>
those can be created from u-boot and will land on a file on the designated ESP
<jannau>
that didn't work for me, it was still the m1n1 set one although I booted a different partition
<kettenis>
ubootefi.var is the name of the file
<kettenis>
jannau: oh you mean if you deliberately boot from a different disk, u-boot should change "/chosen/asahi,efi-system-partition"?
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
yes, asahi-scripts uses that variable
<jannau>
the better option would be to prevent booting from other ESPs
<kettenis>
How would you boot an installer on a USB stick?
<jannau>
prevent booting from other nvme ESPs
<kettenis>
well, I think having a single ESP and use that to boot multiple OSes should be allowed
amarioguy has joined #asahi-dev
<jannau>
I have no problem with the allowed but I don't think it will be an supported config and the boot menu makes it far to easy
<kettenis>
anyway, I'll look at what needs to be done to update the value
kettenis_ has joined #asahi-dev
kettenis_ has quit [Remote host closed the connection]
kettenis has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
single ESP with multiple OSes installed is "supported" in the "you get to keep the pieces when it breaks" sense
<marcan>
there's a single set of DTs, a single firmware bundle, and I bet a world of pain once SEP support is in
<marcan>
booting via USB is a special case where the USB OS should not be mucking around with the system ESP in principle
<marcan>
having several co-habitating OSes with a single ESP probably won't be a supported config ever if you want to have everything work as expected with automation
<marcan>
if you're hacking around manually, sure
<marcan>
but I don't think it's something we ever want to offer to end users by default
<marcan>
and given the DT mismatch, I don't think we should allow booting from other nvme ESPs, yeah
<marcan>
that means the user did something wrong
henry has quit [Read error: No route to host]
jakebot6022 has quit [Ping timeout: 480 seconds]
<tobhe>
kettenis: bootmenu works here too. labels would be nice
<tobhe>
and it looks like aplaudio doesn't like my 6.0 DT
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<kettenis>
tobhe: yes that's a know issue (it doesn't crash does it?)
<kettenis>
but aplaudio(4) doesn't work yet on the M2 anyway ;)
<tobhe>
it does on my m2
<tobhe>
well ;)
pthariensflame has joined #asahi-dev
pthariensflame has quit []
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
amarioguy has quit [Remote host closed the connection]
<ChaosPrincess>
what does the aop do that would be useful in linux? Do you have to enable to enable it to even get the built-in mic signals?
<jannau>
<jannau>
povik: any idea what could cause "apple-admac 238200000.dma-controller: missing or invalid apple,internal-irq-destination property" on j457
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<povik>
jannau: yes. old driver seeing recent devicetree
<povik>
there's been a breaking change in the binding some time ago, dropping that irq-destination property
<povik>
ChaosPrincess: yes. at least that's how macos does it
<povik>
i would love to skip it and "access" the mics directly
<povik>
it's easy to do other than we should write our own LEAP firmware in that case, instead of needing the one that's embedded in AOP firmware
<povik>
what's LEAP you ask? it's another processor i discovered is on the SoCs!
<jannau>
povik: yes, neverming. I had EFI_ZBOOT enabled causing me using an Image.gz
<jannau>
sorry
<povik>
LEAP does signal processing we probably don't want to skip over, and apple's firmware for it clocks at ~500 instructions
<j`ey>
jannau: whats the usae case for zboot for you?
<povik>
and it's mostly repetitive
<jannau>
j`ey: compressed kernels with systemd-boot
<povik>
(i have been thinking the past few days about how we could crowdsource the description of the custom ISA it seems to have. we can single-step on the processor)
amarioguy has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
ljs has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]