Etrien has quit [Read error: Connection reset by peer]
ricekot has joined #asahi-dev
ricekot has quit []
SSJ_GZ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-dev
chipxxx has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
espo has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
some thoughts about supporting both 4k and 16k pages in one kernel binary: arm64 needs to know page and virtual address size super early in the boot process, even before fdt is parsed and can be mapped. it looks like it would be needed to parse the fdt in efi-stub or u-boot, and modify the linux boot protocol to take the page+va size in a register.
<marcan>
for something so fundamental, it could just be a quirk based on CPU IDs (if apple -> 16K) I suspect
<j`ey>
the 4/16k thing is about having user space support 4k even with a 16k kernel, so I think in that case the kernel would always have a fixed size
<j`ey>
(unless youre talking about a different solution/approach)
<ChaosPrincess>
i was thinking of instead of having PAGE_SHIFT being a constant, it instead being a boot time variable
<ChaosPrincess>
so you can boot the same kernel on 16k arm macs and 4k raspis or whatever
<ChaosPrincess>
the 4k userspace with 16k kernel is way more difficult than boot-time page_shift, which is already hard
<j`ey>
ah right, yeah that is a bit simpler.. at least it would likely all be in arch/arm64 folder
MajorBiscuit has joined #asahi-dev
<ChaosPrincess>
hahahaha, no
<ChaosPrincess>
there are a lot of places that rely on it being a compile constant
<marcan>
that's the first thing macOS did, yeah, they turned that into an expression instead of a constant
<marcan>
but the split userspace support is quite another story
<j`ey>
anyone remember tccboot? we could just compile the kernel at boot time to set PAGE_SHIFT :P
<marcan>
:D
<ChaosPrincess>
marcan: if you have time, mind looking at pwm again? i did the whole sign off legalese thing.
<j`ey>
ChaosPrincess: actually what benefit of this runtime PAGE_SHIFT is there?
<j`ey>
distros only need to build 1 kernel, sure. but they still have to test both options?
<ChaosPrincess>
distro kernels being capable of shipping the same kernel to all arm machines
<ChaosPrincess>
well, thats implying distros test all their software :P
<ChaosPrincess>
and real answer - thats the workload on a probably-competent distro packager, not extra mental load on a user that when presented with two page size options will be confused.
<j`ey>
also the ???? perf regression
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<ChaosPrincess>
you can probably do a bunch of preprocessor abuse to not pay this cost on platforms where there is only page size, or if the user configures the kernel to only support 1
<j`ey>
which is what I would do :P
<j`ey>
I already have a bunch of hacks on top of the asahi kernel to disable things at compile time
MajorBiscuit has quit [Ping timeout: 480 seconds]
<_jannau_>
marcan: there are also the asahi-scripts PRs from fedora
<marcan>
yup, let me take care of that today
<ChaosPrincess>
also, if you have time, mind doing a `hexdump -C | grep nvram` on a nvram dump of a m1 pro machine? i want to check if some offsets are the same as on m1
ilya has quit [Remote host closed the connection]
cy8aer has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<kettenis>
ChaosPrincess: fixing the iommu stuff such that it works with 4K pages is probably easier that intoruding run-time page size configuration
<kettenis>
s/intoruding/introducing/
* sven
hides
kov has quit [Quit: Coyote finally caught me]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Major_Biscuit has joined #asahi-dev
espo has quit [Quit: espo]
espo has joined #asahi-dev
kov has joined #asahi-dev
gladiac has joined #asahi-dev
Major_Biscuit has quit []
Core5928 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Core9066 has quit [Ping timeout: 480 seconds]
Dementor has quit [Remote host closed the connection]
Core5928 has quit [Ping timeout: 480 seconds]
Dementor has joined #asahi-dev
naim has joined #asahi-dev
naim has quit []
<mps>
how suspend is activated? writing freeze or mem to /sys/power/state ?
<j`ey>
mem
<espo>
or hit F6 :D like i learned during a call today ...
<mps>
j`ey: I tested it by mem two previous night, after 7 hours battery goes from 100% to 57 for this time
<mps>
nights*
<j`ey>
that doesnt sound great(?)
<mps>
espo: heh, my F6 isn't set to do anything
<mps>
j`ey: yes, because this I thought to test freeze
<espo>
i thought the same :D and clicked bordly around and was a little suprised when my system went to sleep
<mps>
espo: I don't use ready made DEs
naim has joined #asahi-dev
<espo>
it was 2bwm :) so no "ready" made DE ;) i would say
<j`ey>
markan has talked in the past about closing his laptop and having it hardly drain battery, but maybe that was macOS?
<espo>
if i understood marcan right on his stream the s2idle doesn't save much power it only made it possible to get the system to a sleep state where running apps get suspended but the cpu and the screen still does it thing and "drain" the battery. So it will not save much power beside the additional power needed to drive "running" apps.
<mps>
j`ey: yes, my son uses macos and can confirm that drain is very low when closed
<mps>
espo: I use awesome wm, and openrc as pid 1
<_jannau_>
it seems to be variable, I've seen > 18h of no-dispaly battery run time with the m2 macbook pro (linux), but with sleep >90% bettery charge were lost in ~8h
<j`ey>
weird
<j`ey>
no-display = use the gpio to blank it?
<_jannau_>
yes
<mps>
xorg dpms does this automatically?
<kettenis>
sounds like there are bugs in the power management code
<mps>
on my acer elm arm64 chromebook drain is around 5% for 8-10 hours, mem mode
<kettenis>
which isn't surprising since this is something that hasn't received a lot of attention yet
<kettenis>
so unless you are a kernel hacker, I'd say you need to have a bit more patience
<mps>
kettenis: sure, I just asked if some have better results
<mps>
but thing is that I don't have to power down it at night and boot in morning, all state is preserved which is big bonus already
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
that sounds like some dumb bug, though we might need hwmon to debug it
<marcan>
unless it's an obvious "something eating cpu or poking MMIO" problem (easy to see from HV)
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi-dev
naim has quit [Quit: naim]
<marcan>
quick test on M1 Studio says all CPUs are idle and no weird MMIO traffic is happening
<marcan>
so either it's a hardware thing or hardware that only exists on the laptops
<mps>
only warning in dmesg on boot is this 'macsmc-hwmon macsmc-hwmon: JFB: in apple_soc_smc_hwmon_probe. Connected to smc_core(1852 keys)'
<marcan>
macsmc-hwmon is not a thing in official kernels yet
<j`ey>
marcan: so the times youve talked about closing the laptop overnight and stuff on twitter (maybe stream too), was when running asahi?
<marcan>
hm? overnight would've probably been macOS, but the jam session thing was asahi
<marcan>
_jannau_: wild guess: something with MTP? the rtkit helper stuff doesn't do suspend yet IIRC, but the dockchannel IRQs would be masked by default in s2idle. that would result in the FIFO filling up with HID events
<marcan>
which we already know
<marcan>
but I wonder if specifically touchpad events might quickly consume all FIFO space
<mps>
I have to say that I have pwm patch in this kernel
<marcan>
and then maybe MTP does something stupid like busyloop waiting for space
<marcan>
< j`ey> that doesnt sound great(?) <- half battery in 7 hours matches the ~14h idle runtime so it sounds completely expected (no major savings)
<marcan>
what _jannau_ reports is more worrying, and makes me more inclined to believe the MTP theory since that's M2-exclusive
<marcan>
anyway, adding suspend to MTP is trivial
espo has quit [Quit: espo]
<marcan>
(to rtkit-helper really)
espo has joined #asahi-dev
<j`ey>
marcan: fair enough, thanks for clarifying!
<marcan>
I think the big battery saving wins are going to be DCP and CPU deep idle
<marcan>
DCP because with a dumb framebuffer they *have* to poll memory so they can't do any PSR/power saving tricks (and it's also uncompressed, so memory bandwidth), so it *has* to be eating significant power relative to everything else idle, plus the panel itself being powered and refreshing
<marcan>
and CPU deep idle just because we're pretty sure that static power draw isn't negligible
<mps>
aha, this night I will test with gpio blanking screen
<mps>
display*
<marcan>
macos drain is very low when closed except when it isn't
<j`ey>
even so, it sounds like DCP ASC might still be polling? unless it knows not to when its blanked?
<marcan>
I've seen it last a week and die in a day
<j`ey>
heh
<marcan>
for random reasons
<marcan>
at least with linux s2idle you can know no random software is going to trigger wakeups (mostly because we don't support it :p)
<marcan>
macos... is too big and complex and has too much magic
<marcan>
and they've had a bunch of bugs around this
<marcan>
j`ey: DCP ASC polling what?
<marcan>
you mean the FB?
<j`ey>
marcan: isn't that what you meant with 'DCP because with a dumb framebuffer they *have* to poll memory'
<marcan>
not the ASC, the display scanout
<marcan>
I don't know if regular scanout with full DCP will do fun PSR type tricks, but it will definitely stop scanout and shut down the display when told to turn off the output
<j`ey>
Ok
<povik>
btw, talking about suspend
* povik
knows how to get lid angle measurements from AOP
* _jannau_
knows how to "open" the lid with an magnet
<rmk>
marcan: do you have any comments on Petr's review of the vsprintf patch, or shall I just make those changes?
gladiac has quit [Quit: k thx bye]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Gaspare has joined #asahi-dev
Gaspare has quit [Read error: Connection reset by peer]
<sven>
[ 6.531518] dcp_dptxport_call: 271c00000.dcp: AP call 21 (deviceNotResponding) <-- and now ofc atcphy hates whatever I do again
alyssa has joined #asahi-dev
<alyssa>
marcan: so, uh, when are you going to merge DCP exactly? o:)
<_jannau_>
we've started. the m1n1 part for iommu mapping is merged
<alyssa>
\ o /
<_jannau_>
I guess I should rebase it tonight onto asahi-wip
<alyssa>
marcan: I already wrote the DCP suspend/resume patches, it's in _jannau_'s tree, you just need to ship it! ✨
SSJ_GZ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<_jannau_>
DPMS in DCP turns the display (scanout) off as well and should reduce energy use as well
alyssa has quit [Quit: leaving]
SSJ_GZ has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
<marcan>
okay, okay :p
<marcan>
let's get DCP merged soon, though I won't turn it on in the release Asahi kernel for a while (more reason for that linux-asahi-dev thing)
<marcan>
need to make sure it's solid on all the machines first (at least t8103/t600x ones)
<_jannau_>
yes, I think it would be a good idea to have linux-asahi-dev, I would have proposed linux-asahi-dcp
<_jannau_>
I think most important missing piece is making the dart page table swap atomic. that one is annoying with the locked TTBR
<marcan>
Yeah...
<marcan>
how is that handled right now?
whistlingoat has joined #asahi-dev
<jannau>
in a completely unsafe way but in practice nothing happens due to caching of the mappings
<jannau>
io-pgtable-dart, memremaps the L1 table and clears the page. later apple-dart restores the mapping based on the DT provided mappings
<jannau>
as long as nothing invalidates the mapping nothing bad happens and scanout/simpledrm work
<marcan>
oof... okay, I can buy that interim solution but it really needs to be fixed at some point
<marcan>
it's *probably* safe given the TLBs but still...
MajorBiscuit has joined #asahi-dev
<jannau>
the main problem is that io-pgtable-dart currently has no knowledge for which device it initializes the page table. so installing the mappings from the DT there is weird
<jannau>
but we have to clear the L1 table in io-pgtble-dart since apple-dart can't replace an exisitng mapping
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
bisko has quit [Remote host closed the connection]
bisko has joined #asahi-dev
zzywysm has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]