Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
gabuscus has joined #asahi-dev
Dcow has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
mini has quit [Quit: ZNC closing...]
mini has joined #asahi-dev
<marcan>
povik: not exactly how I'd do it, but I like the concept. I'll probably do something like that on top of the verbose flag gate once we start shipping this with u-boot pre-bundled
nkaretnikov has quit [Read error: Connection reset by peer]
nkaretnikov has joined #asahi-dev
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
WhyNotHugo has quit [Read error: Connection reset by peer]
WhyNotHugo has joined #asahi-dev
aleasto has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit []
jbowen has joined #asahi-dev
<marcan>
jannau: pushed a change to disable the missing i2c devices (and it's generalized, so I use it for USB too and got rid of the old function for that)
<marcan>
... whoops, broke the build, but apparently not with my compiler. repushed.
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
<_jannau_>
I would have simply disabled the i2c busses by default until we have a target using bus. This would have postponed this problem until someone starts implementing lights out management for the 10ge mac mini
<maz>
"PowerON, PowerOFF, Reset". that's a pretty limited LOM, but hey, I'd take that.
<sven>
and that obviously requires a fancy protocol! "The Controller in turn sends the command to the Mac Pro or Mac mini using a secured and proprietary protocol."
<dottedmag>
"slapped a signature on it and didn't bother documenting"
<marcan>
I think there's AOP I2C to it, so in principle they could implement fancier stuff
<marcan>
_jannau_: hey, you know we shave all the yaks over here ;)
<maz>
sven: yeah, that. yet another thing to RE, and I'm not holding my breath. Nothing a controlled PDU can't work around.
<marcan>
have I ever shared that comment my old boss wrote on the whiteboard when I was at Google with this crowd?
<marcan>
speaking of yaks shaved, I think I'm done with almost the ones I wanted to shave before sending the PMGR series
<marcan>
there's one more potential one
<marcan>
sven: think it's worth throwing PMGR reset support into the rtkit/ans stuff, so we can recover from a wedged ANS and exercise that feature in the pmgr stuff?
<sven>
into ans, yes
<sven>
i'm working on a nvme driver that actually uses it
<marcan>
fwiw, I added shutdown support to the m1n1 client stuff; tested with SMC at least a few times until it crashes with an overflow (I think we aren't fully initializing/polling something)
<marcan>
sven: the reset stuff?
<sven>
yeah. and also doing some other stuff in a saner way and getting rid of all the PCI cruft
<marcan>
did you actually try using it yet? if so that's good enough for me
<marcan>
just want to know the code isn't made of fail :)
<sven>
uh, maybe. i can try later
<sven>
i have code in there, i just don't remember if I actually tries with a DT that uses it
<sven>
*tried
<marcan>
heh
<marcan>
got a branch>
<marcan>
?
<sven>
not really. right now it crashes just after initializing the admin queue
<sven>
i'll give it a try after $work
<marcan>
kk
<marcan>
I'll get the pmgr branch ready then, as soon as you give me the OK on that I'll fire it off
<marcan>
(probably when I wake up tomorrow)
<sven>
sounds good to me
<marcan>
oh also, the m1n1 rtkit stuff now parses crashlogs partially
<marcan>
at least the message and mailbox log and some misc stuff
<sven>
ah, nice
<sven>
i've just been reading them using xxd :D
<marcan>
yeah, same, but you know :p
<sven>
yeah, it's useful
<marcan>
I was hoping to be able to crash DCP early enough to get a nice log of everything iBoot does, but it doesn't quite fit in 128 entries :(
<marcan>
though I have mostly figured out that it initializes about 4 of the EPIC endpoints (the ones we haven't looked at yet beyond the ring buffer...), and one of them, DISP0 I believe, is actually the iBoot protocol
<marcan>
(yay confusing name)
<marcan>
so if it comes down to it, we can *probably* implement a client for that in m1n1 to kick the display on the Mac Mini
<marcan>
shouldn't be as insane as the DCPEP stuff, but we'd still need the RTKit parts...
<sven>
unrelated, but fwiw SMC actually isn't reset by iBoot but just put into some low power state
<marcan>
yes, that's what I do now in m1n1
<marcan>
the .stop() thing
<marcan>
same with DCP
<sven>
sounds good
<marcan>
it actually sends the start command with another arg, which I guess makes that command the "set power/mode" command
<sven>
yeah
<sven>
0x6 and 0xb
<sven>
or something like that
<marcan>
b is for syslog, yeah
<sven>
both of them are somehow power state related
<sven>
pretty sure 0x6 is for the co-processor
<sven>
i think 0xb is to report the AP power state
<marcan>
we have 6 as "start" and b as "start syslog" but that might be total BS
<sven>
yeah :D
<sven>
see -re
<sven>
so i think we should remove the "poke the CPU START" bit out of the rtkit library
<marcan>
or at least make it a separate function
<sven>
the thunderbolt processors don't even have it
<sven>
yeah
<marcan>
sure
<sven>
so maybe just have a function to poke that bit and another function to wake up SMC or something like that
<marcan>
I also do wonder if DCP can actually be reset properly
<sven>
oh, and ANS firmware text also seems to be inside the same region the DCP firmware also uses. it's just the data section that seems to be inside the region that SErrors if we try to read it
<marcan>
makes sense
<marcan>
and yeah, I thought so
<marcan>
which also means we can also *censored*... :p
<sven>
yup :D
<marcan>
(I still don't understand why they lock down DCP firmware and then put the entire data section in writable memory...)
<sven>
i guess i should push my current rtkit changes somewhere if you want to start with SMC
<marcan>
please do
<sven>
at least those work and don't crash anything :>
<sven>
i'll push them later as well then
<marcan>
also, I don't think SMC is even in a low power state?
<marcan>
it has to keep running even without the OS
<marcan>
in fact it dies a bad death on t6000 if I kill SPMI
<marcan>
though that might've been when I was initializing it...
<sven>
hrm, do you remember which command iBoot sends?
<sven>
maybe it just uses 0xb which may just be "notify co-processor that AP power state is 0x0 now" and maybe that disables all messages it tries to send?
<sven>
0x0 is completely shut down and requires a hard reset but 0x10 allows recovery by just sending that wake-up message
<marcan>
for DCP it does this (you have to imagine the directions)
<sven>
iirc for ANS it uses 0x6 but with power state = 0x0
<marcan>
SMC is the same as DCP
<marcan>
b/6
<marcan>
it doesn't even bother shutting down the EP
<kettenis>
sending ANS2 the 0x600...220 message doesn't seem to hurt
<sven>
the only thing you can't do is send the same power state twice
<sven>
it'll panic then
<marcan>
wait no I'm dumb
<marcan>
sec
<kettenis>
fun
<sven>
yeah, that's obviously a reasonable action to take when you get an invalid argument! *sigh*
<marcan>
ok yeah, it is b/6
<sven>
i'm pretty sure 6 is "set co-processor power state" then
<sven>
marcan: where's the latest code for the reset/pmgr stuff? inside the t6000 branch?
<marcan>
yeah
<marcan>
going to rebase it out now
<sven>
ok
<kettenis>
meanwhile pali noted that PERST really should be active low
<kettenis>
so that'll need to be sneaked into the DT
<maz>
I'll post patches for that tomorrow (can't really drop the branch merging nightmare I'm in the middle of...)
Ariadne has quit [Ping timeout: 480 seconds]
jkkm has quit [Ping timeout: 480 seconds]
austriancoder has quit [Ping timeout: 480 seconds]
arnd_ has quit [Read error: Connection reset by peer]
cptcobalt has quit [Ping timeout: 480 seconds]
jabashque has quit [Ping timeout: 480 seconds]
austriancoder has joined #asahi-dev
arnd_ has joined #asahi-dev
Chainsaw has quit [Ping timeout: 480 seconds]
Ariadne has joined #asahi-dev
jabashque has joined #asahi-dev
jkkm has joined #asahi-dev
cptcobalt has joined #asahi-dev
Chainsaw has joined #asahi-dev
<kettenis>
maz: I'll push the u-boot change to the branch once I've seen that hit the mailing list
<maz>
kettenis: cheers.
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<marcan>
sven: pushed as pmgr/dev
<sven>
k
<marcan>
kettenis: feel free to take a look before I fire it off :)
<j_ey>
marcan: first commit has conflict markers
<j_ey>
0c503762d5d353945c0e16bcf14dbd8ffdf9e1e4
Dcow has joined #asahi-dev
<kettenis>
marcan: still reads ok
<marcan>
j_ey: lol, of course I screwed up the one file that doesn't break the build :p
<marcan>
fixed
<_jannau_>
make dtbs_check will complain a lot since aic/pinctrtrl/dart bindings don't allow "power-domains" properties
<_jannau_>
it also complains about the length of some power-maanagement nodes
<_jannau_>
at least it did that in t6000/bringup-work
<marcan>
really? I thought power-domains was a global thing
* marcan
runs the checker...
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi-dev
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
X-Scale has joined #asahi-dev
<sven>
marcan: pushed my current WIP rtkit stuff to rtkit/dev
X-Scale` has quit [Ping timeout: 480 seconds]
<sven>
if you're also working on it i can stop rebasing/squashing and instead just adding commits on top of that
<sven>
*add
<maz>
kettenis: fired.
<j_ey>
sven: apple_rtkit_management_rx_epmap, why are bitmap and base inside that for loop?
<sven>
🤷♂️
fredix771 has joined #asahi-dev
fredix771 has quit [Ping timeout: 480 seconds]
jbowen has quit [Read error: Connection reset by peer]
Dcow has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
nafod has quit [Remote host closed the connection]
<marcan>
_jannau_: you're right, I'll take a look at the bindings tomorrow.
<marcan>
I don't know why power-domains needs to be explicitly specified; that really feels like it should've been globally available (robher_?) given that at least single-PD modes are automatically handled by the driver layer, and work even for drivers with no runtime-pm support (where it just keeps the domain on)
nafod has joined #asahi-dev
nafod has quit [Remote host closed the connection]
nafod has joined #asahi-dev
firefox317_ has joined #asahi-dev
<firefox317_>
sven: in the Kconfig file in the 'WIP: soc: apple: rtkit: Add RTKit library' commit, you misspelled protocol (protocl)
<firefox317_>
in case you will upstream this ;p
<sven>
see "WIP" at the start of the commit
<robher_>
marcan: That's all kernel implementation details and we want to define how many power domains a device has.
<sven>
this is not remotely ready for review yet
<marcan>
robher_: for >1 I agree, it just feels like one domain is quite a generic situation
<robher_>
marcan: also allowing in any and every node would not be well defined. We do have that for pinctrl, but it's weird.
<kettenis>
being explicit probably is a good thing though, since it allows automated checking of the actual device trees
<marcan>
fair
<marcan>
and yeah, I noticed the pinctrl thing which is weird
<marcan>
expect a few patches adding those to the bindings tacked on to the series tomorrow then :)
* marcan
off to sleep
aleasto has quit [Remote host closed the connection]