psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sheepgoose has joined #asahi-dev
user982492 has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
petermlyon[m] has joined #asahi-dev
ar88kk[m] has quit [Server closed connection]
ar88kk[m] has joined #asahi-dev
davay[m] has joined #asahi-dev
DanielHuisman[m] has joined #asahi-dev
Emantor[m] has joined #asahi-dev
Liam[m] has joined #asahi-dev
Ferluci[m] has joined #asahi-dev
fried_dede[m] has joined #asahi-dev
javier_varez[m] has quit [Server closed connection]
javier_varez[m] has joined #asahi-dev
lovesegfault has quit [Server closed connection]
lovesegfault has joined #asahi-dev
HaoYanQi[m] has quit [Server closed connection]
HaoYanQi[m] has joined #asahi-dev
DanStrong[m] has quit [Server closed connection]
DanStrong[m] has joined #asahi-dev
peerp[m] has quit [Server closed connection]
peerp[m] has joined #asahi-dev
RasmusEneman[m] has quit [Server closed connection]
RasmusEneman[m] has joined #asahi-dev
pulpy_orange2[m] has quit [Server closed connection]
pulpy_orange2[m] has joined #asahi-dev
retonlage[m] has quit [Server closed connection]
retonlage[m] has joined #asahi-dev
sikkileo[m] has quit [Server closed connection]
sikkileo[m] has joined #asahi-dev
spot[m] has quit [Server closed connection]
spot[m] has joined #asahi-dev
Synth[m] has quit [Server closed connection]
Synth[m] has joined #asahi-dev
uur[m] has quit [Server closed connection]
uur[m] has joined #asahi-dev
GregoryRWarnes[m] has quit [Server closed connection]
GregoryRWarnes[m] has joined #asahi-dev
xiaomingcc[m] has quit [Server closed connection]
xiaomingcc[m] has joined #asahi-dev
Xichao[m] has quit [Server closed connection]
Xichao[m] has joined #asahi-dev
YichaoYu[m] has quit [Server closed connection]
YichaoYu[m] has joined #asahi-dev
jeffmiw has joined #asahi-dev
msmith12[m] has quit [Server closed connection]
msmith12[m] has joined #asahi-dev
zbotpath[m] has quit [Server closed connection]
zbotpath[m]1 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arekm has quit [Quit: leaving]
arekm has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
CDFH has joined #asahi-dev
<marcan>
jeffmiw: I want to get it wrapped up this week, but I think at this point it's going to be a bit of a rewrite given what we found out about how the different PMUs should be unified
<marcan>
for the SPMI MFD driver I'm outright making a generic one a la simple-mfd-i2c, because it's silly having what is basically an empty driver for just apple
<marcan>
the RTC and power control stuff will have to change to use reg properties to know where things are, since it changes from PMU to PMU
<marcan>
as for the SPMI driver, it's kind of barebones at the moment and I want to whether it makes sense to make it interrupt-driven or not; it could use a bit of reverse engineering to narrow things down
<kettenis>
my OpenBSD is based on what I learned from the corellium code, but for the functionality I implemented it made enough sense for me to not explore things much further
<marcan>
looks like rtc, alarm being consecutive at least is consistent
<marcan>
hope we can rely on that one
<marcan>
howeverm, the other regs differ
<marcan>
control etc
<kettenis>
yup
<marcan>
robher: another one where you might have some input. looks like Apple generalized their PMU/RTC driver by outright having the register offsets in the ADT
<marcan>
we could do the same with custom properties, or with a bunch of reg ranges, one per register (named in reg-names)
<marcan>
or we could just use the compatible, but it's a bit sad if we can't support even basic RTC functionality in future hardware
<marcan>
or we could split the difference and only explicitly specify the time and time offset reg addresses somehow, and say that future chips only get that and not alarm/etc functionality
<marcan>
that suggests the pattern that the irq pair is adjacent and RTC/ALARM are adjacent holds
<marcan>
but that's about it
<marcan>
they sure do like moving registers around
<kettenis>
wonder if these registers are real hardware registers or just SRAM that's updated by the firmware
<kettenis>
if it is the latter, the firmware team didn't get the memo ;)
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
int16h has quit [Remote host closed the connection]
<marcan>
I think they're real registers
<marcan>
the offset is just scratch RAM though, which is why it was separate from the RTC on older chips
<marcan>
seems that was introduced recently
<marcan>
maverick I guess made it into part of the RTC component
<kettenis>
I agree that having the basic RTC and shutdown support generic would be nice to have
<kettenis>
almost asks for implementing the RTC alarm stuff as a separate subnode
<marcan>
shutdown would be generic, since that seems to be a scratch area and always the same offset/bit
<marcan>
I don't know about splitting off alarm though, that's logically part of RTC
<marcan>
it would make more sense to have the RTC node do that via the compatible, and then have the RTC time and offset regs explicitly specified via props
<marcan>
and that would be used as a fallback
gladiac is now known as Guest80
gladiac has joined #asahi-dev
Guest80 has quit [Ping timeout: 480 seconds]
<robher>
marcan: EFI provides a RTC protocol, right?
<marcan>
that it does
<marcan>
are you suggesting we do all the RTC stuff in EFI?
<marcan>
that would imply EFI owning that SPMI host and everything under it, which might be a problem in the future... unless we do a sharing thing...
<marcan>
it also means now EFI need to take care of shutdown to make that work, and since that involves both SMC and PMU, EFI needs to talk to SMC, which means we need to figure out how to share that sanely
<robher>
that would solve the future h/w support issue, but sharing generally doesn't work with EFI...
<marcan>
yeah... I think it could work for current machines, but if Apple decides to use the SPMI controller for something else or the PMU needs to do more interesting stuff in the future, then we have a sharing issue
<marcan>
and the SMC sharing thing would be a bit of a hack at the very least
<robher>
Are all the masks consistent or you need properties for those too?
<marcan>
you mean bits for alarm and stuff? I think they're consistent at this point, but I'm okay with using compatibles for features like that
<marcan>
we could do the middle ground thing and just have props for RTC time and RTC offset, to at least make the RTC work
<marcan>
and say alarm support needs an up to date driver
<marcan>
those two are consistent AFAICT
<marcan>
just the offset changes
<robher>
I'm okay with the offsets in 'reg' if you want to go that route.
<marcan>
so something like reg-names = "rtc", "time", "offset"; where rtc covers everything and the other two are just those two registers?
<marcan>
and then the generic driver would only use those
<marcan>
and we'd have compatibles like "apple,maverick-pmu-rtc", "apple,spmi-pmu-rtc"
<robher>
humm, it would be a bit odd if the reg entries overlap themselves.
<marcan>
they kind of have to in this kind of case, unfortunately
<robher>
are the rtc regs interleaved with other things?
<marcan>
there's some irq/pm setting stuff that I'm not sure about yet
<marcan>
they do not overlap the LEG_SCRPAD which is the other area which will have a driver at this point (to make shutdown work)
<marcan>
and I *might* guess that some implementation *could* put the RTC offset in a random scratchpad that's not part of the RTC block
<marcan>
in which case the offset reg would just not overlap rtc for those chips
<marcan>
if we need to split things up in the future we could add more reg names, like an associated scratchpad
<marcan>
ahh, looks like "pm setting" might be the "restart on power loss" flag
<robher>
You might want to have a mfd type node with rtc being a child node. I don't think having something like 'reg = <4 4>, <20 4>, <0 0x1000>;' would be a good idea. If you have that, I'd just have a custom offsets property with the offsets you need.
<marcan>
that's what we're doing now
<marcan>
the idea so far is rtc and a shutdown handler node (not sure what node type that one should be, maybe it could be a kitchen sink "power manager" thing that also covers the power loss mode?)
<marcan>
and sure, I could just do two custom properties for the two fallback offsets
<robher>
With an MFD node, it would define the full range of the block and then the child nodes define reg within the MFD range, but not overlapping with child node 'reg'.
<marcan>
hm, but then RTC would end up chopped into bits
<marcan>
0x0000D000 ALARM_CTRL
<marcan>
0x0000D001 PM_SETTING
<marcan>
0x0000D002 RTC
<marcan>
if PM_SETTING is handled by another node, then it either needs to overlap RTC or RTC needs to have a hole in it
<marcan>
just for reference, this is an SPMI device and I'm actually just making a generic SPMI regmap MFD driver because there's already two that are almost like that and it's silly to keep reinventing that stub driver wheel for every manufacturer
<marcan>
then under that MFD we'd have nodes for chip features
<arnd>
Making it an MFD is probably the most flexible, but if this is still conceptually just an RTC with some extra bits, I would make it a single node and a single driver that registers to the RTC subsystem and that also provides some other in-kernel interfaces.
<arnd>
the question is whether this device is conceptually one main function with a few extra bits, or you would think of it as a collection of individual interfaces that are all equally important
<marcan>
it's a PMU, it does lots of things, but *most* of those are managed by SMC
<marcan>
but not all, thanks apple
<marcan>
hence why we need to talk to some little bits directly
<marcan>
it has regulators, analog inputs, temperature inputs, GPIO, RTC, and even runs firmware (cortex-m0 or something)
<marcan>
but all the inputs/sensors/GPIO are abstracted out via SMC, and even RTC is readable it seems... but I haven't figured out a way to write it
<arnd>
ok
<marcan>
nor do I know if the pm setting stuff is tweakable via SMC
<arnd>
Does a regmap based interface fit, where you only provide a set of registers to each child node, or does the main driver also need to talk to it directly?
<robher>
I have to wonder if Apple wasn't disciplined enough for consistent register offsets, is the rest of the h/w functionality consistent? The answer for most vendors is very much a NO.
<marcan>
well, they do have one driver themselves with all the offsets in the ADT
<marcan>
and I haven't seen the driver inspect the PMU model or compatible to make decisions yet
<marcan>
there is also, uh, something related to bluetooth somehow that interacts with this
<marcan>
patent search says LPEM is "Low Power Express Mode" and has to do with near field comms, so I guess this is possibly some lower power mode where some radio stays active
<marcan>
ah, but that might be for iphones only
<marcan>
so we don't care
<marcan>
there is some bluetooth subsystem interaction though, somehow
<alyssa>
marcan: You don't want Exposure Notifications on your MacBooks???
<marcan>
lol
<robher>
marcan: BTW, are you aware of power/reset/syscon-poweroff.yaml? Might be useful for shutdown here.
<alyssa>
What if you're exposed to COVID at a coffee shop with your Asahi Linux Mac and aren't vaccinated because it's still 2020 but there's definitely Asahi Linux already
<marcan>
robher: it's not *quite* that because it's not actually a poweroff trigger, it's a pre-poweroff trigger
<marcan>
there's a dance that needs to happen between SMC and PMU, and it fits in nicely with that callback chain stuff
<marcan>
first SMC does a pre-poweroff signal (may not be required?), then PMU writes the value to set the system to poweroff, then SMC does a call that actually powers down the system
<marcan>
without the PMU poke it ends up rebooting instead
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
kettenis has quit [Server closed connection]
kettenis has joined #asahi-dev
Andre[m]1 has quit [Server closed connection]
Andre[m]1 has joined #asahi-dev
Jamie[m]1 has quit [Server closed connection]
Jamie[m]1 has joined #asahi-dev
Hinata[m] has quit [Server closed connection]
Hinata[m] has joined #asahi-dev
ey3ball[m] has quit [Server closed connection]
ey3ball[m] has joined #asahi-dev
spokv[m] has joined #asahi-dev
<kettenis>
marcan: looks like the "CLKM" SMC key was introduced by Apple with some 12.x firmware
Redecorating[m] has quit [Server closed connection]
Redecorating[m] has joined #asahi-dev
blassphemy[m] has quit [Server closed connection]
blassphemy[m] has joined #asahi-dev
rusty-nail[m] has quit [Server closed connection]
rusty-nail[m] has joined #asahi-dev
thasti has quit [Server closed connection]
thasti has joined #asahi-dev
BastienSaidi[m] has quit [Server closed connection]
BastienSaidi[m] has joined #asahi-dev
<kov>
marcan, could that LPEM thing be for bluetooth wake up? mac os has a setting for that
<marcan>
nah, I think it's an iphone thing
<DmitrySboychakov[m]>
it's might be a helper for airpods. they connect it to iphones/macbooks really fast. might be UWB or that
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
jbowen_ has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
Nspace has quit [Server closed connection]
Nspace has joined #asahi-dev
jbowen_ has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
marcan has quit [Server closed connection]
marcan has joined #asahi-dev
vafanlig1arde has quit [Server closed connection]
vafanlignarde has joined #asahi-dev
lonjil has quit [Server closed connection]
lonjil has joined #asahi-dev
zelig_[m] has quit [Server closed connection]
zelig_[m] has joined #asahi-dev
gladiac is now known as Guest111
gladiac has joined #asahi-dev
user982492 has joined #asahi-dev
Guest111 has quit [Ping timeout: 480 seconds]
<maz>
marcan: I'm starting queuing stuff for 5.18, so if you wanted to repost the fast-IPI stuff to reduce the queue, now would be the time! ;-)
___nick___ has joined #asahi-dev
<thermoblue[m]>
I genuinely hope I can get to the point where I can not only comprehend but contribute to this sort of development
<thermoblue[m]>
I really do enjoy scripting but I can't even begin to understand reverse engineering a system to work for an operating system. I'd imagine you guys do a whole lot of work in C?
<thermoblue[m]>
Any information is appreciated
<thermoblue[m]>
* enjoy scripting, but
<thermoblue[m]>
* enjoy scripting, but, * engineering a closed system to, * for an open operating system.
<thermoblue[m]>
* is appreciated - resources in order to learn how to start, etc. etc.
jbowen has quit [Quit: leaving]
feeleep[m] has quit [Server closed connection]
feeleep[m] has joined #asahi-dev
minecrell has quit [Server closed connection]
minecrell has joined #asahi-dev
DmitrySboychakov[m] has quit [Server closed connection]
DmitrySboychakov[m] has joined #asahi-dev
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-dev
jbowen has joined #asahi-dev
<jeffmiw>
marcan: ok. does that help if I try to do a bit re on te SPMI ? or do you see something else I can do to help ?
LilleCarl[m] has quit [Server closed connection]
LilleCarl[m] has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
grange_c has joined #asahi-dev
pg12 has quit [Server closed connection]
pg12 has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
TheLink has quit [Server closed connection]
TheLink has joined #asahi-dev
aleasto has quit [Server closed connection]
aleasto has joined #asahi-dev
BenPetterborg[m] has quit [Server closed connection]
BenPetterborg[m] has joined #asahi-dev
vimsos[m] has quit [Server closed connection]
vimsos[m] has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
FireFox317 has quit [Server closed connection]
FireFox317 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]