user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<maz>
j`ey: there is something in the spec for link-up, but this is not necessarily the right value for the HW at hand. once we have the SMC driver up and running independently of the rest of the stack, I'll have a look at just handling hotplug events without ever waiting for anything.
<povik>
aaand with that, speakers are up on t6000 with no outside help
<povik>
(well, almost)
<povik>
in the baseline variant of left/right only, needs to be said
<marcan>
nice!!
<marcan>
povik: m1n1 should probably do that if it's a one-time thing
<marcan>
are the required settings represented somewhere in the ADT, or is it hardcoded?
<sven>
povik: awsome! :)
Shiz has quit [Ping timeout: 480 seconds]
<sven>
also lol, i just realized why apple split their tunables into so many properties: they are all based on a different entry in the regs array
<sven>
that probably explains why nothing was working :D
<j`ey>
so you were applyin the tunables to the wrong addresses?
<sven>
yeah... i was kinda applying them all to the usb2 phy
<sven>
which uh... probably did nothing
povik has quit [Remote host closed the connection]
<j`ey>
sven:good luck then!
<sven>
i'll only get to try again this evening. that idea just came to my mind and i quickly confirmed it by looking at a stored XNU log I had around :D
povik has joined #asahi-dev
<povik>
marcan: it's hardcoded
<povik>
it is that narrow reg range in mca-switch node, if you remember
<povik>
that tells you the addresses, the values cannot be derived from ADT as far as i can tell
<povik>
also, it's a one-time thing
<marcan>
fair enough
the_lanetly_052__ has joined #asahi-dev
Shiz has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<Dcow[m]1>
povik: great news! what do you mean by "baseline variant of left/right only" ? only two speakers of array are working or what?
<Dcow[m]1>
also, just curious, what about capture?
<povik>
Dcow[m]1: as you said, only two speakers alive
<povik>
no capture on t600x
akemin_dayo has joined #asahi-dev
<marcan>
povik: if you think it's good enough I could sneak it into the first release, plus the m1n1 change
<marcan>
would be really cool to have the speakers working to some extent on all models
<povik>
when do you plan that release?
<povik>
depends on that
<marcan>
this week :)
<marcan>
also, even if the kernel part isn't ready, if the DT bits are and I add the m1n1 thing we can ship that and then people just have to upgrade their kernel package to get it later
<povik>
let's start with that
<povik>
let me send you a python script with what i think we should do in m1n1
<povik>
on t8103 it should be a no-op and on t600x it should do the right thing
<povik>
will test it in a minute on both
<marcan>
cool, is it always reg[2]?
<povik>
yes, with N=2
<povik>
weird thing is on t6000 the reg[2] has 6 clusters worth of clocks, but it only has 4 clusters
<marcan>
heh
<povik>
maybe we should remove that last 0x09
<marcan>
there is also AOP_MCA0/1, is it possible it's those?
<povik>
don't think so
<povik>
it's possible but would be very surprising
<marcan>
maybe it's just a leftover then
<marcan>
they have some of those
<marcan>
(e.g. the two die thing is in m1pro AIC even though obviously it can't use it)
<povik>
AOP_MCA is on t8103 also, and there the 5th and 6th clock is for vanilla MCA
<marcan>
right
<marcan>
alright, let me implement that
<marcan>
does it make sense to have all the settings for t8103 too? and I guess the 6th doesn't make sense since we don't have a dedicated NCO for it?
<povik>
i would clip the presets at the fourth or fifth (as i posted it)
<povik>
shouldn't matter in the end
<povik>
hmm, don't we have 6th NCO channel? what i did in the DT for t8103, then? :)
<povik>
ah, i shared the 5th channel between mca4 and mca5
<povik>
which is how it indeed is
<povik>
(with iboot values in muxes on t8103)
<marcan>
ah, I'll do the same then I guess
<povik>
script appears to be okay
<marcan>
povik: pushed
<marcan>
I initialize all muxes, but clamp the mux values to 5..9
<marcan>
so anything beyond 5 will repeat 9
<povik>
good
<kettenis>
note that adding clocks further up the hierarchy is hard/impossible to do without breaking backward compatibility in the DT
<marcan>
the problem is we don't really know anything about the clock tree until apple uses it anyway
<marcan>
but I'd say if we end up needing to do this "properly", it'll be in a new machine anyway, at which point we just need a minimum kernel for that one to get audio (which, shrug)
<marcan>
hard to imagine a reason why we'd need to make these dynamic though...
<kettenis>
we may need to restore these when resuming, but I guess we already anticipate m1n1 being in the loop there
<marcan>
yeah
<marcan>
actually I'd be surprised
<marcan>
doubt that will be necessary
<marcan>
clock muxes are part of PMGR and that definitely stays alive during sleep
<kettenis>
even better
<povik>
marcan: i had to set the NCO's input clock (in DT) to be half of what's in clock_frequencies in ADT
<povik>
on t8103 it's the clock_frequencies value exactly
<povik>
i worry that there is a divider-by-half in the way
<marcan>
the mux regs have a divider setting
<marcan>
have you tried clearing the lower bits?
<marcan>
I think some are hardcoded to
<marcan>
*too
<povik>
not exntesively
<povik>
maybe we should settle that too before we start caring about backwards compatibility
<marcan>
does macOS do the same thing?
<povik>
i don't know
<marcan>
the NCOs have 4 input clocks but we only use the first one, right?
<marcan>
also looks like on t6k only the first one is set weird (and not divided)
<marcan>
maybe we should just also set the dividers to 2 everywhere?
<povik>
okay, i take that back, on t6000 the div-by-2 on MCA input is not set
<povik>
ah, i was looking at the first one :)
<marcan>
on mca0 only!
<povik>
yeah
<povik>
let me see if that div is even implemented
<marcan>
yeah
<povik>
doesn't seem to be
<povik>
writing 0x05000100 doesn't do anything, in place of 0x05000000
<povik>
watching the data rates
<marcan>
is it implemented for the NCO inputs?
<povik>
handy you posted the dumps
<povik>
also not
<povik>
is it a sure thing that 0x100 is div-by-2?
<marcan>
I'm not even sure if that bit is the divider any more, tbh
<povik>
ah
<marcan>
ah, could be bits 7:0
<povik>
tried setting 1,2,4,8 there on NCO and MCA0
<povik>
nothing
<marcan>
I have no idea then :)
<marcan>
or maybe it needs bit 8 set and also one of the others?
<marcan>
like div enable
<povik>
still nothing, tried a bunch of things
amw has quit [Ping timeout: 480 seconds]
<marcan>
there's one way of figuring out if the divider is before or after the NCO; deliberately making the fractional counter take a while to converge and measuring how long it takes
<povik>
can't say i want to go into that... :)
<povik>
although it sure is a way
<povik>
btw remember how the NCO output frequencies were inexplicably measured a bit off?
<povik>
on t600x it doesn't happen anymore
<povik>
(estimated rate: 24000.01 dwords/s)
<marcan>
hm, I thought it was accurate in the end?
<marcan>
after we worked out the NCO formula
<povik>
no, there was still a bit of error
<marcan>
oh, huh
<povik>
and it is there up to this day
<marcan>
how much?
<povik>
it was there for macos values too
<povik>
something like 47997 vs 48000
<marcan>
ah
<povik>
that's what our measurement gave us for iboot/macos values as well
<povik>
now it measures exactly
<povik>
seems like something that was fixed in the chip
<marcan>
47997 vs 48000 is 60ppm, which is not unheard of for xtal tolerance
<marcan>
if it's a different reference clock, that would be down to individual variance
<marcan>
if it's the same clock then it's possible somewhere higher up in the clock tree there's just an inaccurately specified clock
<povik>
makes sense, both explanations
<marcan>
24000.01 certainly sounds like the same reference, it's too good for two xtals :)
dlssscr^ has quit [Remote host closed the connection]
<povik>
i would bet my money on inaccurately specified clock then, as the error was similar for both of us
<povik>
anyway...
MajorBiscuit has joined #asahi-dev
eragon has quit [Quit: WeeChat 3.4]
eragon has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
joske has joined #asahi-dev
<joske>
povik: I just built your branch and with the DT and m1n1 changes, I now have working speakers on MBA!!
<joske>
thx!!
<Glanzmann>
joske: Wow, nice.
Glanzmann has quit [Quit: leaving]
yuyichao has quit [Ping timeout: 480 seconds]
<povik>
uh oh
<povik>
i though i told you you are not supposed to do that :-p
<povik>
anyway i am happy it works for you
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<joske>
povik: what will happen? will it explode? ;-)
<kettenis>
povik: no clarity yet on how to handle multiple speakers per channel?
<kettenis>
(in the DT I mean)
yuyichao has joined #asahi-dev
<povik>
joske: no, but it is best to make sure first that the code is even worth letting people test
<joske>
don't worry, I won't complain if it doesn't work/breaks/whatever, but I will cheer if it does :-)
<povik>
okay, then you are certified free to test anything you want :)
<povik>
kettenis: not yet
<joske>
it sounded like you weren't sure if it works on t8103, so I tested myself ;-)
<povik>
kettenis: maybe we should have a textual descriptions for speaker position, and let sound-name-prefix fallback to that?
joske has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
joske has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
Glanzmann has joined #asahi-dev
user982492 has joined #asahi-dev
<kettenis>
it seems that sound-name-prefix is only used to provide names for userland, but doesn't actually encode the topology
<kettenis>
what I would like to do in OpenBSD is have a single stereo sample stream and be able for the amplifier codecs to pick the right channel out of that stream
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
<povik>
i am proposing e.g. sound-speaker-position="Left Rear"
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
<kettenis>
yes, something like that
<kettenis>
should be a closed vocabulary
<kettenis>
so a choice from a number of strings in the binding
<kettenis>
and maybe lower-case
<kettenis>
maybe it makes sense to use the "label" property for this
<povik>
label being the name-prefix, or something else?
<povik>
'label' verbatim?
<kettenis>
"label" is a generic device tree property to label a device and is often used to express the function of that device
<kettenis>
but I guess this all highly depends on the views/preferences of the linux sound system maintainers
<povik>
hmm
<kettenis>
and it isn't cear to me where such conversations happen
joske has quit [Read error: Connection reset by peer]
<jannau>
sigh, I should not use the virtual uart to upload retina display framebuffers
<jannau>
that said experiments/dcp.py works on t6001
<jannau>
without HV dcp crashes with "Message 1: MMU out of tables: 200,200,0"
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
pFalken has quit [Quit: WeeChat 3.0]
yuyichao has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
King_InuYasha has quit [Read error: Connection reset by peer]