<j`ey>
marcan: disabling pcie and nvme, I get a resume from s2idle.. but then it appears unresponsive
<j`ey>
this is using the vuart with hv, so maybe there's an issue there, can try with the keyboard/fb in a bit
<marcan>
j`ey: vuart definitely shouldn't break... unresponsive as in no console?
<marcan>
breakpoint it in the HV and see what it's doing? you might have to go through all CPUs
<marcan>
(there's no nice way to automate that right now due to the cpu switch command being a console exit behind the scenes... I just paste a pile of cpu(0)\nbt\ncpu(1)\n... )
<marcan>
s/breakpoint/break/
<j`ey>
unresponsive in that when Im trying to type into picocom, no characters get written, which I think means the other end isnt accepting any?
<j`ey>
sven: you will cut your compile times down a lot, worth it!
<sven>
j`ey: yeah, it's just going to be annoying because i develop on macOs running on my macbook air and my target machine is the mini. so i'd have to reboot to the mini, sync files, compile there, sync files back, reboot again
<j`ey>
I was thinking a linux vm on the mba
<sven>
hrm, yeah, that would work actually
<sven>
i guess it's time to yak shave instead of hacking on the kernel for now then :D
<marcan>
I looked at what resume was doing and noticed it was first restoring the IRQ flags in resume_noirq, then calling reset in resume which masked with ucon_mask
<marcan>
and was obviously undoing that
<marcan>
those flags are apple-specific so it doesn't apply to other chips (though one other variant uses ucon_mask for something else)
<marcan>
(I actually introduced ucon_mask myself in the S5L patchset...)
<j`ey>
ah nice, cool
<j`ey>
so just pcie left?
<marcan>
yup
<marcan>
which might be more painful, but maybe not *that* bad since all the scaffolding for suspend/resume should already be there?
<marcan>
probably apple-pcie just needs a huge pile of re-init ports en masse on resume?
<marcan>
and also figure out why brcmfmac outright blocks it
<sven>
hrm, i hope the pcie thing doesn't need the PHY init from m1n1 again
<j`ey>
marcan: pull & rebuilt & works, nice
<marcan>
sven: if it does we can just stop powergating it for now, which we probably want to anyway for "normal" s2idle since people probably want wake-on-wlan?
<marcan>
and then punt it to full system sleep which will happen via m1n1 anyway
<sven>
yeah, that sounds reasonable
<marcan>
honestly I'm surprised s2idle even tries to full sleep all devices like this
<marcan>
but I guess it makes sense
<marcan>
but there's probably some way to just mark pcie as "don't do that"
<sven>
though I think the main reason we wanted to avoid pulling all that crap into linux where tunables and fuses and well... we'll likely need those two for atcphy anyway
<marcan>
yeah :/
<marcan>
so maybe it's time to bite that bullet
<sven>
I could *probably* get away without the fuses and some tunables but I feel like there's a reason why macOS also tears down the entire atcphy when a cable is unplugged just like usb
<sven>
but we'll always need those mode-specific tunables anyway
<marcan>
well... remember the usb2 nonsense...
<marcan>
so yeah
<sven>
yeah... exactly
<marcan>
the SS lanes do have redrivers
<marcan>
though I want to say *that* doesn't have magic protocols
<marcan>
and is just straight through redriving
<marcan>
but who knows...
<sven>
yeah, I'm mostly concerned about usb3 <-> thunderbolt transitions and stuff like that
<marcan>
maybe there's some idle state signaling that confuses things
<marcan>
yeah
<sven>
that might just break horribly if you don't do a full reset anyway
<sven>
btw. regarding those tunables, I could either pass them through as apple,tunable-<apple-names> or merge some of those together. e.g. apple,tunable-ln1-usb which would contain USB_LN1_AUSPMA_TX_TOP, USB_LN1_AUSPMA_RX_TOP, USB_LN1_AUSPMA_RX_SHM and USB_LN1_AUSPMA_RX_EQ which are always applied in that order
<sven>
any opinion?
<marcan>
also we have that power domain flag that says "never go below clkgate"
<marcan>
we could use *that* for pcie and I'd hope that doesn't lose PHY state
<marcan>
though that would introduce a DT compat break if we ever remove it, for older kernels
<marcan>
but we might just never want to do that, and leave full PCIe powergate for deep sleep
<marcan>
sven: I would merge
<marcan>
if there's nothing special to it other than them being applied in order
<sven>
at least for the lane ones there isn't afaict. still need to check if the "always apply these after a reset" ones are applied in a different order for thunderbolt
kaprests has quit [Server closed connection]
kaprests has joined #asahi-dev
<marcan>
so I'm getting about 5W power draw in suspend, which is not great. I wonder how much of that is the CPUs...
<marcan>
let's see
<marcan>
so smp_start_secondaries makes *no* difference to power usage, which is using deep sleep, so at least now we know that's pretty good
<marcan>
now let me switch to light sleep
lewurm has quit [Server closed connection]
lewurm has joined #asahi-dev
<marcan>
ok, that's about 100mA = 2W gone there
<marcan>
that might make the case for doing an ugly hack in linux to support deep sleep for the time being, that's a significant win and should be trivial to just do as a throwaway patch
_jannau_ has quit [Server closed connection]
_jannau_ has joined #asahi-dev
<marcan>
letting the e-cluster go to sleep too saves us a bit more too
<marcan>
and then of course there's the screen, can't do much about that until the DCP driver is in place, but I bet that'll save a bunch of power too
<marcan>
since putting 3K onto the screen all the time can't be cheap, and in FB mode it has to keep refreshing from RAM, it can't know you didn't touch it
<j`ey>
even with s2idle?
<marcan>
DCP doesn't know about s2idle
<marcan>
it's purely an OS-level thing
<marcan>
anyway, with the deep sleep hack I would expect at least 24h of sleep battery life, which is enough to get you through randomly putting the laptop away for a day
<marcan>
maybe more since these are USB-C level measurements, there's going to be some loss and some power spent on trickle charging the battery
<j`ey>
in this sentence, 'it' refers to DCP? "and in FB mode it has to keep refreshing from RAM"
<sven>
the actual display-controller doing the scan out, not necessarily the DCP co-processor
<Glanzmann>
marcan: kettenis meassured the screen power to be aroung ~ 1 Watts. (that is by toggling the backlight gpio).
<marcan>
>screen
<marcan>
>backlight
<marcan>
these are two different things
<Glanzmann>
I see.
<alyssa>
sven: misread those registers as USB_L1NA_USPMA_TX_TOP and got very confused
<marcan>
I can tell you right now how much power the screen draws, actually
<sven>
alyssa: uh.. and now i'm confused :D
<j`ey>
sven: right, makes sense
jato has quit [Server closed connection]
jato has joined #asahi-dev
arctan95 has quit [Quit: Connection closed for inactivity]
<alyssa>
marcan: re backlight, it's my understanding brightness is controlled by the DCP?
vitorbarth has joined #asahi-dev
<j`ey>
sven: you might need something like 4ae85b2ba1debea2ce828ca24de73ce49e41e516 in the efuses driver
<j`ey>
sven: "Say y here to enabled suppor", enable not enabled
<sven>
thanks, fixed!
Shiz has quit [Server closed connection]
Shiz has joined #asahi-dev
vitorbarth has quit [Read error: Connection reset by peer]
<marcan>
ok, so the lowest I can get things is 3.3W, but there's like a whole 1W unaccounted for in the SPMU for some reason, so I don't know what that's about (assuming I guessed the SMC keys right, of course)
<marcan>
that's 22h runtime
<marcan>
then again, the way I brute force powered things down via PMGR and the PMU GPIOs may not be correct :p
<jannau>
this sounds like I should make sure that the current dcp driver and m1n1 dcp changes are always on github
<marcan>
there's about 1W going to the SoC CLVRs, which also doesn't sound right for mostly being idle
<marcan>
well, could be pcie? let me nuke that
<marcan>
nope
<marcan>
anyway, dunno, will have to cross check this with osx and see if there's some magic that makes it use less power
<marcan>
maybe PMP manages some of that, who knows
<marcan>
or maybe the RAM isn't configured to go into lower power states right now
the_lanetly_052___ has joined #asahi-dev
<alyssa>
jannau: yass
<alyssa>
feed me, DCP, feed me! :-p
<sven>
:>
jix has quit [Server closed connection]
jix has joined #asahi-dev
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
akemin_dayo has quit [Remote host closed the connection]
<jannau>
not much changed besides replacing the locked dart hacks with "/reserved-memory"
<jannau>
I squashed the macos 12 dcp ABI changes so you need to update
maz has quit [Server closed connection]
maz has joined #asahi-dev
bisko has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
<jannau>
HV dcp tracing doesn't blow up on t600x. anyone willing to bet if the linux dcp driver will just work after adding the missing nodes to the device
<alyssa>
that seems like it would be too easy
bisko has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
j`ey has quit [Server closed connection]
j`ey has joined #asahi-dev
<marcan>
jannau: at the very least the DVA offset is different, if that isn't a DT prop yet
vup has quit [Server closed connection]
<jannau>
marcan: not sure what you mean
<marcan>
the offset that is added/ORed to DART IOVAs to yield RTKit DVAs
<marcan>
which is configured in the DAPF, but we don't inspect that
<jannau>
it's currently hard-coded in the driver but it fails already to power on dcp/rtkit
<jannau>
also disp0 has only 5 instead of 7 registers
bisko has joined #asahi-dev
<jannau>
at least the dart preserved memory setup works
VinDuv has quit [Server closed connection]
VinDuv has joined #asahi-dev
<marcan>
do we even need to touch disp0?
<jannau>
dcpep_cb_rt_bandwidth asks for the two missing registers and we map the disp0 mmio regs for dcp
<marcan>
the map is by index though, isn't it? IIRC
<marcan>
anyway, I need to get some sleep, and I think I'll disconnect for tomorrow... it's apartment cleanup day ;)
<jannau>
good night
vup has joined #asahi-dev
Nspace has quit [Server closed connection]
Nspace has joined #asahi-dev
tanty has quit [Server closed connection]
tanty has joined #asahi-dev
os has quit [Server closed connection]
os has joined #asahi-dev
sandyriver[m] has joined #asahi-dev
agraf has quit [Server closed connection]
agraf has joined #asahi-dev
_andy_t_ has quit [Server closed connection]
_andy_t_ has joined #asahi-dev
ar has quit [Server closed connection]
ar has joined #asahi-dev
user982492 has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
chengsun has quit [Quit: Quit]
chengsun has joined #asahi-dev
jvsg[m] has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sandyriver[m] is now known as peer[m]
<alyssa>
jannau: disp0 changing is an easy enough DT change, no?
xerpi[m] has quit [Server closed connection]
xerpi[m] has joined #asahi-dev
bisko has quit [Remote host closed the connection]
M1bn3mar[m] has quit [Server closed connection]
M1bn3mar[m] has joined #asahi-dev
bisko has joined #asahi-dev
ella-0[m] has quit [Server closed connection]
ella-0[m] has joined #asahi-dev
<jannau>
alyssa: still struggling with waking dcp up. even gone back to walking tables for dcp-dart
<alyssa>
good luck.
bisko has quit [Ping timeout: 480 seconds]
emilazy has quit [Server closed connection]
emilazy has joined #asahi-dev
HayashiEsme[m] has quit [Server closed connection]
HayashiEsme[m] has joined #asahi-dev
jevinskie[m] has quit [Server closed connection]
jevinskie[m] has joined #asahi-dev
<kov>
marcan, looks like defconfig is missing CONFIG_BACKLIGHT_GPIO and that breaks DRM now
<j`ey>
breaks it how?
<j`ey>
from the commit it looks like it should gracefully handle not having a driver for it
<Glanzmann>
j`ey: Maybe the same error CONFIG_BACKLIGHT_CLASS_DEVICE=y (fails if it is =m)
<Glanzmann>
I had*
<kov>
j`ey, no DRM node in /dev, no messages in dmesg
<j`ey>
hm odd
<kov>
X failed to come up, tried weston, then I noticed the device nodes were missing, after a bit of banging my head against menuconfig I realized the new dt had the backlight stuff and could it be gpio_backlight missing? that made it work
<j`ey>
looking at 46ff9b5bb0a48baba8bd69db3b53a6604fcae160 makes it looks like that case should be handled
user982492 has joined #asahi-dev
dhewg has quit [Server closed connection]
dhewg has joined #asahi-dev
bisko has joined #asahi-dev
fridtjof[m] has quit [Server closed connection]
fridtjof[m] has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
<jannau>
sigh, it was the "apple,min-state = <4>;"
<alyssa>
?
<jannau>
some power management magic, it was missing from the t6001 ps_disp0_cpu0 power state
gladiac has quit [Quit: k thx bye]
<alyssa>
womp
cde[m] has quit [Server closed connection]
cde[m] has joined #asahi-dev
<sven>
ouch. that essentially means “don’t powergate DCP” which is probably require because DCP isn’t completely shut down
<sven>
+d
psykose has quit [Remote host closed the connection]