millenialhacker has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
bisko has quit [Ping timeout: 480 seconds]
pseigo_ has quit [Ping timeout: 480 seconds]
<marcan>
robher: btw, the aic2 binding applies unmodified to M2 ;)
<marcan>
(and the aic1 binding apparently goes back quite a few Axx generations, folks backported Linux to some much older chips and the driver only needed trivial changes that can be autodetected)
<marcan>
so I think I made the right call with the generic compatibles :)
<marcan>
almost everything in M2 is directly compatible, or wildly new drivers in a few cases. the one annoying case I found so far is cpufreq (not upstream yet), which had to add a bit to the pstate counts, which was fine for the main switching register but shifted a field in the feedback register I'd discovered and started using.
<marcan>
that one is nice to have so cpufreq can report the accurate *current* frequency, capped by hardware limits, not just what the kernel asked for.
<marcan>
my current idea for that one is have a generic compatible that doesn't use that register (which is still very much a usable result), and then use the per-SoC compatibles to enable it knowing the bit count.
<marcan>
for future SoCs that remain compatible (as far as we can tell) then we'd end up with something like "apple,tFOO-soc-cpufreq", "apple,t8112-soc-cpufreq", "apple,soc-cpufreq", if that works for you?
millenialhacker has joined #asahi-dev
<marcan>
(with the driver only binding to apple,t8112-soc-cpufreq and apple,soc-cpufreq unless in the future we find something special to do for tFOO)
<marcan>
I might cap the "generic" compatible mode to 16 pstates or so, just to be safe, so in that case older kernels wouldn't reach the highest CPU p-states (which is still a usable state, we do expect people to upgrade kernels to seriously use new machines, I just want the things to be able to boot if at all possible)
<marcan>
current M2/t8112 status is that, if PCIe doesn't have any surprises (it's missing bootloader enablement still, haven't tested it), and if we'd done t8110-DART ahead of time (which we didn't, but was needed for M1 Pro/Max too, we just didn't get to it in time), M2 would've booted unmodified kernels with missing keyboard/mouse, RTC, and poweroff support (new hardware for those)
<j`ey>
RTC changed?
<marcan>
SPMI did
<marcan>
and the RTC offset is there
<j`ey>
ah
<marcan>
this is very much a usable state of affairs for a distro installer if you can plug in an external keyboard, so I consider that a success story for my theory that we can support upcoming SoCs in old kernels with just bootloader/DT changes "enough to install a distro and upgrade to a hardware enablement kernel"
<marcan>
(at least some of the time)
<_jannau_>
did you test the watchdog? reset in u-boot did not work for me (once) on M2. I have not looked at it at all
<marcan>
I remember something being broken there, yeah. reset did not work for me initially but did later, in the hypervisor?
<marcan>
I'm not sure what's up
<marcan>
need to check again
<marcan>
maybe something linux does makes it work?
<marcan>
also, another funny thing I noticed: sleep in macOS does *not* kill the hypervisor now (not: the HV has always hijacked the CPU sleep mode stuff to stop them from disabling IRQs/etc)
<marcan>
so that's good for figuring out sleep mode stuff
<marcan>
I had macOS go to sleep and woke up to a live hypervisor
c10l49 has quit []
<marcan>
not sure if that means it's s2idle type stuff, or if the final sleep trigger would be the boot CPU going into low power mode and we just aren't doing that
millenialhacker has quit [Ping timeout: 480 seconds]
c10l49 has joined #asahi-dev
<marcan>
but this is good for working out how sleep/wake works, especially if I can figure out how to trigger a wake signal in a way that macOS likes, without breaking the HV
<kettenis>
"The watchdog driver might has an issue."
<kettenis>
s/has/have/ there, but maybe you want to rewrite that message anyway when we sigure that one out
<kettenis>
added some style comments in github
millenialhacker has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
kettenis has quit [Read error: Connection reset by peer]
kettenis has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-dev
deh^ has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
deh^ has quit [Ping timeout: 480 seconds]
deh^ has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
deh^ has quit [Ping timeout: 480 seconds]
deh^ has joined #asahi-dev
<robher>
marcan: nice! That all sounds fine to me.
<marcan>
robher: great! :)
<marcan>
did you see my earlier comments on the new keyboard/touchpad story? TL;DR there is now a coprocessor involved, with the usual interface, but that interface isn't used for the actual data - there is another interface for that, which is logically independent. So far we've treated the coprocessors as an integral part of the device they manage, but in this case it really behaves more like a "helper".
<marcan>
so we have the coprocessor (which just needs to come up), the interface (which is a dumb byte FIFO - is there any subsystem binding / consumer type stuff that would fit here?), and then some kind of HID device binding on top. but that same FIFO hardware type is used as a special debug UART too (we just haven't implemented it yet), so it should also have a tty consumer driver. and in that case ...
<marcan>
... there is no coprocessor involved.
<marcan>
logically, I would say the coprocessor is one device, the FIFO is another device, and the HID mapping is a direct consumer (child node?) of the FIFO and a device link to the coprocessor so it can depend on it being up
<marcan>
but I'd like to know your opinion on what this binding should look like
<marcan>
so far we've only had one other device where the copro was *mostly* logically detached from the real device node, NVMe - in that case we ended up with a single device node for both, while that could've been modeled as separate devices. but that separate device abstraction is slightly leaky in the case of some debug commands at least, so there is some argument that a combined device is a good idea ...
<marcan>
... there anyway.
<marcan>
I'm not so sure that's the case here, it really does sound like we should use separate devices to model this new keyboard/trackpad coprocessor and the associated FIFO interface / HID protocol.
<marcan>
one thing I thought of is having the coprocessor driver as a genpd, which feels a bit weird to say, but does provide the semantics we'd want ("this needs to be on before the consumer device") - I'll have to look at how it handles power management (can the copro turn off while the user isn't touching anything to save power and still get an IRQ? how would that work?) to see whether this actually ...
<marcan>
... makes sense.
<marcan>
in every other case of coprocessors so far (display controller, GPU, power metrics controller, SMC, camera though that one's even more special, and I think the neural engine too) the main coprocessor interface/mailbox and protocol stack is the main communication mechanism, so I think what we're doing with the single node is correct and we should keep doing it.
deh^ has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
kov has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
deh^ has joined #asahi-dev
<marcan>
jannau: ERROR: modpost: missing MODULE_LICENSE() in drivers/iommu/io-pgtable-dart.o :)
amarioguy has joined #asahi-dev
<marcan>
for modules you need to define the other deps separately in the Makefile, otherwise they become separate modules
psykose has quit [Remote host closed the connection]
ptrc has joined #asahi-dev
psykose has joined #asahi-dev
<marcan>
fixup pushed to bits/020-t6000-dart
deh^ has quit [Remote host closed the connection]
nsklaus_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
balrog_ has quit []
balrog has joined #asahi-dev
Catyre_ has joined #asahi-dev
Catyre has quit [Ping timeout: 480 seconds]
Catyre_ has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi-dev
pseigo_ has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
<marcan>
... okay that fixup wasn't enough
<marcan>
io-pgtable stuff needs to be built in
yamii has quit [Quit: WeeChat 3.5]
Catyre has quit [Remote host closed the connection]
Catyre has joined #asahi-dev
amarioguy has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.5]
Catyre has quit [Remote host closed the connection]
pseigo_ has quit [Read error: No route to host]
pseigo_ has joined #asahi-dev
pythonen[m] has joined #asahi-dev
nsklaus has joined #asahi-dev
<marcan>
hm, still doesn't work with apple-dart as a module, it claims to initialize fine but nothing can use the iommu properly
<marcan>
was hoping to test some images but I'm punting until tomorrow, need to figure out what's going on here
<j`ey>
seems only you and jannau with m2 so far anyway
millenialhacker has joined #asahi-dev
<marcan>
this is on t6k
<marcan>
it's a regression
<marcan>
(from the io-pgtable move presumably)
Catyre has joined #asahi-dev
<marcan>
one of those lovely failure cases where no actual message is printed for the failure
millenialhacker has quit [Ping timeout: 480 seconds]
Catyre has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
Catyre has quit [Ping timeout: 480 seconds]
<marcan>
okay, I think I figured it out
<sven>
bah... how did i break this bluetooth driver while trying to clean it up now :<
<marcan>
mood
<sven>
yeah :/
<sven>
and ofc this one time I decided I don't need atomic commits so I can't even bisect *sigh
millenialhacker has joined #asahi-dev
<sven>
[ 2.272353] nvme-apple 27bcc0000.nvme: ANS did not boot <-- okay, how did that break now :<
millenialhacker has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi-dev
<marcan>
okay, dart thing is fixed, linux-asahi package pushed. that has jannau's DART series plus fixes, lid switch regression fix, t8112 cpufreq support & related t600x DT change (mostly to make sure I didn't break it)
<marcan>
please give it a smoke test, if it's not broken I want to make test installer images tomorrow
<marcan>
off to sleep :)
Catyre has quit [Ping timeout: 480 seconds]
<kloenk>
Which branch should I look at, so see how the RTKit adapter works? Just want to look at it, and see how hard it would be to write in rust
<j`ey>
kloenk: asahi branch drivers/soc/apple/*
millenialhacker has joined #asahi-dev
<sven>
probably not too hard since it’s pretty isolated and doesn’t use many kernel APIs
millenialhacker has quit [Ping timeout: 480 seconds]
<kloenk>
Saw some bitmaps. They will be a bit to implement IIRC. And exporting it to C is not really possible yet. But should be manageable, maybe even quite automatic and I just have to write the header for now
<sven>
bitmaps? do you mean the GENMASK/BIT stuff?
<kloenk>
AFK right now. Will look again when back. Could be that I remember wrong and that was a different file
<kloenk>
This one is the line I'm not sure how complicated it will be: "DECLARE_BITMAP(endpoints, APPLE_RTKIT_MAX_ENDPOINTS);"
<kloenk>
It's in the rtkit internal header
<j`ey>
probably not very, it's just an array
<kloenk>
For what does EP stand? Doing the enums right now, and then to bed, Uni tomorrow
<kloenk>
EP in "APPLE_RTKIT_EP_MGMT"
<j`ey>
endpoint
<sven>
yeah, it's essentially just an array of bools
<sven>
also, looks like i broke the driver during this cleanup in more than one way. now it can scan again but refuses to pair new devices :(
<j`ey>
:S
<kloenk>
"APPLE_RTKIT_MGMT_EPMAP"and "APPLE_RTKIT_MGMT_EPMAP_REPLY" have the same value, is that intentional?
<kloenk>
same with "APPLE_RTKIT_MGMT_SET_AP_PWR_STATE" (rust can't have that in enums, so can only define it once)
<sven>
yes
<sven>
it's the same value but a different thing semantically
<sven>
first thing is a message from rtkit, second thing is a message to rtkit
<kloenk>
Okay, will have to see how to do it best. Could do const, but enum has a bit nicer syntax IMHO
<sven>
j`ey: it doesn't help that half the time I just don't know if it's the usual bluetooth flakiness or an actual bug in the driver :D
<j`ey>
;_;
<kloenk>
I could do a enum with an anonymous struct. one u8 for the value of it, and one bool if its's reply or not
<kloenk>
Either way, good night :)
Catyre has joined #asahi-dev
Catyre has quit [Remote host closed the connection]
Catyre has joined #asahi-dev
<sven>
alright, it's pairing again. but ofc audio is broken again :<
Catyre has quit [Remote host closed the connection]
Catyre has joined #asahi-dev
millenialhacker has joined #asahi-dev
Catyre has quit [Ping timeout: 480 seconds]
Catyre has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
<sven>
lol, i was wondering why the music was pretty glitch-y and only then realized that I had all my debug spam and the tracer on :D
joske has joined #asahi-dev
<joske>
I built the new asahi branch (and u-boot and m1n1), and all seems fine, although I'm not sure the build was correct, uname says 5.18.0-asahi-dirty, shouldn't this say 5.18.7?
<joske>
from the tag, but the Makefile says 5.18.0
<j`ey>
it's not based on stable 5.18.7
<j`ey>
it's just a local extra version that markan adds
<j`ey>
sven: hehe nice, like when you discover sleep(n) calls in your code ;)
<sven>
yup :D
<sven>
seens to be working again now though
<sven>
still need to clean up some minor crap but the core part is reasonable now
<j`ey>
sven: commit it, make a new branch 'audio-working' :P
<sven>
lol
<joske>
j`ey: oh ok, indeed, seems based on Linus' v5.18
<sven>
I’ll try to push it this weekend
<joske>
well then I confirm it's working on MBA (with 4k pages iommu patch)
<j`ey>
(it was more to stop you from breaking it again, than wanting you to push it!)
<sven>
is there anything except for audio that people use Bluetooth for? :D
<sven>
oh, it’s already committed now :)
<Bastian[m]>
bluetooth mouse/keyboard?
<j`ey>
joske: nice that youre keeping that patch alive :P
<sven>
ah, true. Let’s see if I have something like that lying around
<sven>
j`ey: fwiw, I’m waiting for robin to finish his iommu_set_bus cleanup and then I’ll get back to it
<sven>
(that’s at least my current excuse!)
<j`ey>
sven: :-)
<joske>
j`ey: I need vscode to work, so have no choice ;-)
<dottedmag>
sven: also serial port (e.g. Lego EV3 brick has it)
<j`ey>
joske: VScode will work with 16K pages At Some Point
<j`ey>
once it uses a new enough electron
<joske>
yes, right now still using chromium 98
<joske>
so no 16k pages for me
joske has quit [Read error: Connection reset by peer]
millenialhacker has joined #asahi-dev
<sven>
btw. anyone with a t2 Mac that the bcm4377 chip here?
<sven>
*that has the
<j`ey>
Redecorating[m]: ^
<j`ey>
emergenz[m]: ^
<sven>
can anyone of you run acpidump and upload that somewhere?
<j`ey>
not exactly sure if they have that one, just ppl that talked about t2 in the past
millenialhacker has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
<rkjnsn>
“<sven> is there anything except for audio that people use Bluetooth for”
<rkjnsn>
I use it to send files to/from my Android phone.
pseigo_ has quit [Ping timeout: 480 seconds]
Catyre_ has joined #asahi-dev
Catyre has quit [Ping timeout: 480 seconds]
pseigo_ has joined #asahi-dev
<jannau>
I don't think there's a problem with watchdog. reset through the watchdog seems to disable the HW uart routing