<povik>
should be sending out NCO today, anyone wants to be CCed on that? (marcan has a default opt-in)
slicey has quit [Quit: cya]
<sven>
yes. please also include kettenis for at least the device tree bindings
<marcan>
povik: awesome! remind me again, what's the state of the audio stuff? works on the mini, have we tested the headphones jack or speakers on anything else?
<marcan>
I'm writing the progress report, so if you think the jack should trivially work everywhere I might as well test it and color that entire row green (yes I'm doing a table thing this time)
<marcan>
(well, not green, green is for upstreamed drivers, but you get the idea)
<marcan>
jannau: if it works well enough to use I might just merge it into asahi in its current state, might as well :)
<marcan>
povik: also happy to merge in the audio work if you think that's okay
<marcan>
I basically want linux-asahi to be a testing ground for drivers headed in the right direction, even if they're rough, at least at this point in the game
<j`ey>
jannau: so hid-mouse works with multitouch?
<j`ey>
hid-generic I mean
<marcan>
I think he means hid-generic works in multitouch *mode* because it still picks up the first few bytes of the reports?
<_jannau_>
yes, I suspect that is the case without looking into it. multi touch does not work
<marcan>
_jannau_: btw, I do have access to an older Intel MacBook with SPI touchpad, so I can test that when we get there
<marcan>
I also noticed the Touch Bar multitouch is also ostensibly HID over SPI, but possibly a different protocol? unclear
<povik>
marcan: playback through speakers and jack works on the mini. haven't been tested elsewhere
<povik>
jack should work everywhere (if the codec on t6000 macs isn't too different from the one on t8103 macs)
<povik>
^ in principle
<marcan>
awesome, I'll give it a shot after dinner :)
<marcan>
since it has the fancy table you'll probably want to run it locally; just install hugo and `hugo serve` at the repo root
<marcan>
(table will change based on what I do with the hid and audio stuff today :))
<povik>
there's some rough edges with how the jack is presented to userspace (pulseaudio isn't happy with it, and you need to set a knob in alsamixer for jack not to be muted)
<povik>
but this seem as minor issues to me, obviously we know how to drive the hardware
<povik>
(plug event is detected in kernel btw, just doesn't make it userspace probably)
<kettenis>
marcan: maybe mention that basic M1 support (USB type-C only) has been upstreamed in U-Boot now as well and will be part of U-Boot 2022.01?
<marcan>
kettenis: ah yes, totally forgot about that, will do!
<marcan>
povik: the userspace stuff is a whole different story anyway (there's profiles and stuff, we'll probably have to create some on top of figuring out what to do for the speaker crossovers)
<j`ey>
marcan: good report
<j`ey>
marcan: dunno if povik or jannau want their names as links..
<marcan>
I think Jannau can point to twitter, can't remember if povik has one too?
<marcan>
let me know :)
<kettenis>
I did a bit more exploring of the battery-related SMC keys yesterday and added stuff to the wiki page
<kettenis>
funny thing is that most values are native-endian, but the remaining capacity seems to be reverse endian
<kettenis>
some values are available both as an integer and as a float
<kettenis>
but the float values don't seem to provide more resolution
<povik>
oh hey i do have twitter
<povik>
with one old tweet in Czech
<povik>
marcan: link to my github, better than nothing i guess
<sven>
marcan: the usb quirk stuff is still pending fwiw (and i need to submit a follow up for the binding), not sure it'll make it to 5.17
<povik>
will put up a "for hire" note there, see if anything happens :-p
<sven>
and regarding nvme... there's still at least one annoying problem. for some reason anything that uses random writes with sync (fsync, sync, etc.) is incredibly slow (<1MB/s). not sure that counts as "works well"
<povik>
marcan: re: the report. s/supporting the various codec chips/supporting the various codec configurations/
<povik>
the speaker amps are mostly the same, just need TDM set up to share one I2S bus
<povik>
(for speaker support elsewhere than mini)
<kettenis>
sven: do those sync commands result in an NVMe flush command being issued?
<sven>
yes
<sven>
i think that's also what slows it down
<kettenis>
flushing the cache is defenitely expected to be "slower"
<sven>
it goes from 300 MB/s down to like 1MB/s. and testing the same setup with e.g. fio on macos doesn't do that
<kettenis>
OpenBSD only flushes the disk cache before shutdown/powerdown basically
<sven>
hm, i guess macos does the same. still need to verify that though
<_jannau_>
as far as I'm aware my name is globally unique so it does not need links ;)
<povik>
i need a link to not be confused with my grand grand grand father of the same name
<kettenis>
_jannau_: same here ;)
<_jannau_>
marcan: I think there are only two drivers for for the touchpad report format, hid-magicmouse will not work out of the box. but I really need to start looking at the reports in detail
<kettenis>
btw, you're right, the "mouse" HID report is at the start of the packet
<kettenis>
and it continues to be sent, even in "raw" mode
<kettenis>
"raw" mode just extends the packet with touch information (which isn't really HID-compliant)
KDDLB has quit [Quit: Ping timeout (120 seconds)]
KDDLB has joined #asahi-dev
<marcan>
sven: maybe send a revision to that soonish to poke things?
<sven>
yeah
<sven>
nvme has just been more fun ;)
<marcan>
:D
timokrgr has quit [Quit: User left the chat]
<kettenis>
sven: don't let perfect be the enemy of good enough
<sven>
well, the previous nvme driver would kernel panic if you just poked it enough. that's probably not good enough ;)
<kettenis>
heh
<kettenis>
I'd say the write cache buffer flushing slowness is something folks could live with for a while
<sven>
sure
<kettenis>
and getting usable nvme out there will actually allow other people to look into it
<sven>
right. i just happen to have a day job and it's not this.
<marcan>
I guess that will make mca the first driver to actually do that with pmgr
<marcan>
but you don't have to worry about that for now
<kettenis>
sven: ah yes, $DAYJOB
* kettenis
goes back to answering e-mails about VLBI
<sven>
:-)
timokrgr has joined #asahi-dev
<povik>
marcan: yeah, reckoned that the way out is teaching the MCA driver some PD support
<marcan>
yeah
<marcan>
also, is nco_inp just a guess on the clocktree based on the frequency?
<povik>
yup
<povik>
it expresses two things: the frequency, being tied to clkref probably
<marcan>
I think we're better off with fixed frequency clocks since we don't know; that way, if something ends up being dynamic or changing, we can teach m1n1 to propagate frequencies from the ADT
<marcan>
kinda harder to do that with ratios :)
<povik>
sure
<povik>
will change that when i visit the DT again
<marcan>
np
<marcan>
if we knew the full clocktree I would absolutely do it that way... but we don't :(
<marcan>
I imagine if refclk changes (though I get the feeling it never will) they'd change all the multipliers anyway
<povik>
so, did anyone got the NCO patches? i don't see it on the lists yet
<marcan>
povik: MCA should probably pull in ADMAC in the kconfig, otherwise it's pretty pointless
<j`ey>
(MAINTAINERS should be in a commit of its own for v2)
<marcan>
re MAINTAINERS, you can add a new entry and volunteer yourself, or you can shove it under the apple SoC stuff; depends on how much you want to commit ;)
<marcan>
(if it's a new entry it doesn't need to be a separate commit)
<jn>
hmmm, a bit more theory-of-operation would (IMO) be nice to have in the driver, specifically an explanation of the role that the LFSR stuff plays
<povik>
ah, kind of hoped MAINTAINERS would sort itself out later
<sven>
marcan: speaking of which, we never merged the dart entry to the general apple soc one, did we?
<marcan>
ah, the MAINTAINERS thing? don't think so
<marcan>
we can do that if you want
<sven>
sure. it's almost all the same people anyway
<povik>
meaning you two? :D
<sven>
+ alyssa i think
<sven>
marcan: also, reminder about that mailing list :D
<marcan>
ah yes :)
<marcan>
I'm trying to get the audio jack to work on t6000... and getting an unhandled IRQ... on the DART fault handler IRQ?!
<marcan>
I expected breakage but not *this*
<povik>
uh
<sven>
huh
<sven>
i thought only the USB DARTs shared an interrupt
<sven>
there's also this thing apple calls SMMU (not the ARM one) but that's only for the disp dart and i don't even know if it can create interrupts
<marcan>
only this DART is listed under this IRQ in the ADT
<marcan>
:D
<sven>
weird
<sven>
the SIO DART also has a DAPF but i think its errors also go the normal DART error status :/
<povik>
the MCA has an interrupt although i don't do anything to unmask it on the MCA side
<marcan>
[ 542.714722] cs42l42 1-004b: PLL failed to lock: -110
<marcan>
I'm pretty sure the codec is broken too
<povik>
no that's okay
<marcan>
alsamixer reverts any changes I make though
<povik>
it sets the PLL even if getting master clock from the SoC
<povik>
i think i see the same in my dmesg
<povik>
that should probably be fixed in the cs42l42 driver
<povik>
anyway i forgot about one thing. i don't know what the MCA and ADMAC drivers will do on t6000
<povik>
that's completely untested
<povik>
restricted my attention to the codec when i said the jack has a chance of working there
<povik>
:-p
<marcan>
this is indeed forever reading the DART error registers which show no error
<marcan>
hmpf
<povik>
is it at least the SIO DART?
<sven>
hrm, the spurious irq detection should kill it eventually. not that that's much better
<marcan>
this looks like the device ID, but it's in the wrong place
<marcan>
something is really messed up with the i2c interface
<marcan>
maybe it's time for gpiola...
<marcan>
this almost looks like the i2c addressing mechanism is different from what I expect
<marcan>
yeah, like 16-bit addresses, not the banking thing...
<kettenis>
you mean register addresses?
<marcan>
yes
<marcan>
cs42l42 (aka cs42l83, apparently) uses a weird banking thing with 8 bits of page address and 8 bits of register address
<kettenis>
there are many chips that do it like that
<marcan>
cs42l83 instead seems to use 16-bits of address outright
<marcan>
yeah, I know
<marcan>
cs42l92 uses *32-bit* addresses so that is precedent for cirrus doing this
<marcan>
let me see if I can find a codec they do with 16-bit addrs...
<marcan>
yeah I get the feeling this is one of those "apple got first dibs on a new chip or got them to make something custom" things
<marcan>
povik: yeah, this doesn't look like anything I can find, and stringsing the macos driver points in that direction too
<marcan>
84 is very different from 83
<povik>
:(
<povik>
well that is a tricky plus-by-one
<marcan>
some register field names do match 42l42, so it's not like a total from-scratch chip, but if nothing else the addressing is different for one
<kettenis>
so it's not just a simple quirk where they basically undone the banking?
<marcan>
and there's stuff I can't find a match for in '42, though it does seem apple may be making up register names
<povik>
the upside is the SoC side doesn't break on t6000
<marcan>
yeah
<marcan>
the ID register properly says CS42L84 for this one, for one
yuyichao has quit [Ping timeout: 480 seconds]
<povik>
the 83 also says 83 in ID register
<marcan>
some of the plug detect stuff is the same as '42; but there are new concepts: "hi cap" mode, "MSM", some sample rate thing, something called "ccm"
<marcan>
apparently this one can measure headphone impedance
<marcan>
dcid seems to be related to that
<marcan>
"DC impedance detect" perhaps?
<marcan>
there's a thing about boosting the output voltage
<marcan>
it sounds like this thing got quite a bit smarter about adapting to different headphone types
<marcan>
povik: so yeah, sounds like there's quite a bit of reversing work here to get this to work properly :/
<marcan>
will leave it aside for now, let me test the headphone jack on the iMac or something
<marcan>
ah, but I don't have a rootfs :-)
<marcan>
I should put something on a USB drive...
<marcan>
povik: the funny thing is the macOS driver has basically verbosely documented all the register reads/writes... it's like they have a macro that stringifies the arguments to write32 mask32 etc and them passes those strings too
<marcan>
soo at least there's that for understanding this mystery chip
<marcan>
OTOH; I can confirm the register addresses are different
yuyichao has joined #asahi-dev
<marcan>
might be worth extracting just the reg info from the driver (under the premise that register names aren't really copyrightable) and working off of that + HV logs
<marcan>
that should be automatable
<kettenis>
makes sense; apple boasted about supporting high-impedance headphones on the m1 max/pro laptops in their marketing
<marcan>
hah
<kettenis>
and given how they operate, that also explains why the chip isn't publically available
<marcan>
yeah...
aleasto has joined #asahi-dev
<maz>
marcan: AICv2: is there really no way to control the affinity at all?
<maz>
marcan: this is going to hurt with devices with multiple queues where the driver really expects a given queue to be associated with a given CPU and doesn't expect the interrupt anywhere else.
ChaosPrincess has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
Dcow_ has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
drwhax[m]1 has joined #asahi-dev
alyssa has joined #asahi-dev
<alyssa>
marcan: bluetooth I think should be nul, not ehh
<alyssa>
the corellium patches are AFAIK wifi only and I don't think anyone has looked at bluetooth?
<alyssa>
IIRC it's the same chip but the corellium patch is incomplete or something
<alyssa>
RTC should be ehh, the corellium patch works fine
<alyssa>
(and doesn't have crazy dependencies)
<kettenis>
alyssa: yes, I have seen no code for the bluetooth part of the wifi device
<alyssa>
kettenis: no bluetooth support is a security feature ;-)
<kettenis>
I don't disagree ;) (we ripped out bluetooth support in OpenBSD years ago since the implementation wasn't up to our standards)
<alyssa>
Heh
<alyssa>
The last time I used bluetooth was in Sep 2020