ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
m6wiq has quit []
<jeffmiw> here is rtc support over spmi: https://github.com/jfbortolotti/linux/tree/spmi_rtc it is a basic version doing the job, spmi driver is very minimal: just enough to read rtc registers
<jeffmiw> you need to activate those flags in the kernel config:
<jeffmiw> CONFIG_SPMI_APPLE=y
<jeffmiw> CONFIG_MFD_APPLE_SPMI_SERA_PMU=y
<jeffmiw> CONFIG_RTC_DRV_APPLE_PMU_SERA=y
<jeffmiw> I tested it on mba but should work on other, dts is only modified for mba
<jeffmiw> I'm looking for feedback before finishing polishing and preparing an RFC to submit upstream
<jeffmiw> feel free to share any views and comments, this would be my first submission upstream, so still learning the details :)
<kettenis> jeffmiw: I think the spmi node should be in t8103.dtsi
<jeffmiw> yes isn't it what i did ?
<kettenis> but the pmu should probably be in t8103-jxxx.dtsi since it is a separate chip
<jeffmiw> ah yes makes sense to share it among the different configs, thanks
<kettenis> also, I'm using apple,sera-pmu as the compatible
<kettenis> so unless you have a good reason to change it, please use that
<kettenis> the spmi node should also have a apple,t8103-spmi compatible
<kettenis> having the rtc subnode is fine with me, but naming it apple,sera-pmu-rtc would make more sense
<kettenis> pmu-sera@0 should probably be pmu@f
<kettenis> defenitely @f
<kettenis> somethought needs to be put into adding support for t6000/t6001
<kettenis> those have a differently named pmu
<kettenis> but the rtc bit seems to work in the same way
<kettenis> judging from the ADTs
<kettenis> so maybe take another look at my u-boot device trees
<j`ey> jeffmiw: you need bindings documentation + MAINTAINERS commits
<kettenis> anyway, zzz time here
<kettenis> I'll take a closer look at the code tomorrow
<kettenis> but nice work
<jeffmiw> kettenis: I will align the naming and take a look at the u-boot dts, no good/eal reason to diverge
<jeffmiw> j'ey: yes, on my todo list as a next step :)
<jeffmiw> kettenis: same here about the time, looking forward for more feedback
<alyssa> jeffmiw: any reason not to do
<alyssa> u64 rtc_time;
<alyssa> regmap_bulk_read(regmap, ADDR, &rtc_time, 6);
<alyssa> instead of the complicated bitwise thing
<alyssa> likewise `regmap_bulk_write(regmap, ADDR, &new_rtc_offset, 6)` instead of the loop thing
<chadmed> looks to me like the number is stored in the RTC as big endian and needs to be flipped? am i reading that correctly?
<chadmed> jeffmiw: it might be prudent to add a short comment explaining this
<chadmed> also i dont think they like it upstream when you declare multiple variables on a single line
<alyssa> chadmed: right..
<alyssa> it wants to be a helper func at least
fhjwkbv has joined #asahi-dev
<fhjwkbv> i. s” i s a n d a.l” qa” e d.a o .n l y a.p”p e” a r e d i n. i .r “a q a f. t e r u “s “a i .n “v a”si o.n , D .i .d u “s “a p .a “v e. th e w. a.y f or i .s”i s to i. r “a .q ?
<fhjwkbv> if . a.l” q.a” e d.a / ` d.i d ..i.t w. h y , ` t .o k .`i” l .l 9 . m. i l` l i. on . i.r”a q i. s
<fhjwkbv> “!…/?????!!!!~~~~~??…व््व….व?>..D !.i .d” u.s.”a t . r” a” i n , & s “”u” p `pl y i .s” i. s wi. th w .e. a .p. o. n s l. i. k e i. t d. i. d w i. t h a.l” q.a” e .d”a to j. u “ st” i f y c r. e “a t i n g w. a” r s - “d “i .d” c. “i`. a d. i d 9कन11
<fhjwkbv> . or, i t j u. s t l .e t it h.a “p p” en
<fhjwkbv> s.a .d `d a m h. u `s . si n .w h .o l .o s. t ` . m. o .s t . of h. i s p. o w. er i n 1st , 2 nd g.u `lf w. a `rs an d .d u r.i n g. / 10 y e.a rs of . ` sल i `e g लe ,. d लi d n .o t a .l l o. w i. s. i s o r a .l .q. a .e. d .e .a t o e. n t e r / i . r / a. q . e v.e n to h e .l p h .i m
<fhjwkbv> a g .a i .n s t u` .s. a
<fhjwkbv> `p l e .a s e .s h `a r e m. y .` q .s 2 ` .l e s .s e n .. u .s. a . a g. g. r` e s s i o n a g .a` i n. s t o t .h .e r s
<fhjwkbv> “!…/?????!!!!~~~~~??…व््व….व?>..D !.i .d” u.s.”a t . r” a” i n , & s “”u” p `pl y i .s” i. s wi. th w .e. a .p. o. n s l. i. k e i. t d. i. d w i. t h a.l” q.a” e .d”a to j. u “ st” i f y c r. e “a t i n g w. a” r s - “d “i .d” c. “i`. a d. i d 9कन11
<fhjwkbv> . or, i t j u. s t l .e t it h.a “p p” en
<fhjwkbv> i. s” i s a n d a.l” qa” e d.a o .n l y a.p”p e” a r e d i n. i .r “a q a f. t e r u “s “a i .n “v a”si o.n , D .i .d u “s “a p .a “v e. th e w. a.y f or i .s”i s to i. r “a .q ?
<fhjwkbv> if . a.l” q.a” e d.a / ` d.i d ..i.t w. h y , ` t .o k .`i” l .l 9 . m. i l` l i. on . i.r”a q i. s
<fhjwkbv> s.a .d `d a m h. u `s . si n .w h .o l .o s. t ` . m. o .s t . of h. i s p. o w. er i n 1st , 2 nd g.u `lf w. a `rs an d .d u r.i n g. / 10 y e.a rs of . ` sल i `e g लe ,. d लi d n .o t a .l l o. w i. s. i s o r a .l .q. a .e. d .e .a t o e. n t e r / i . r / a. q . e v.e n to h e .l p h .i m
<fhjwkbv> a g .a i .n s t u` .s. a
<fhjwkbv> “!…/?????!!!!~~~~~??…व््व….व?>..D !.i .d” u.s.”a t . r” a” i n , & s “”u” p `pl y i .s” i. s wi. th w .e. a .p. o. n s l. i. k e i. t d. i. d w i. t h a.l” q.a” e .d”a to j. u “ st” i f y c r. e “a t i n g w. a” r s - “d “i .d” c. “i`. a d. i d 9कन11
<fhjwkbv> `p l e .a s e .s h `a r e m. y .` q .s 2 ` .l e s .s e n .. u .s. a . a g. g. r` e s s i o n a g .a` i n. s t o t .h .e r s
<fhjwkbv> . or, i t j u. s t l .e t it h.a “p p” en
<fhjwkbv> if . a.l” q.a” e d.a / ` d.i d ..i.t w. h y , ` t .o k .`i” l .l 9 . m. i l` l i. on . i.r”a q i. s
<fhjwkbv> s.a .d `d a m h. u `s . si n .w h .o l .o s. t ` . m. o .s t . of h. i s p. o w. er i n 1st , 2 nd g.u `lf w. a `rs an d .d u r.i n g. / 10 y e.a rs of . ` sल i `e g लe ,. d लi d n .o t a .l l o. w i. s. i s o r a .l .q. a .e. d .e .a t o e. n t e r / i . r / a. q . e v.e n to h e .l p h .i m
<fhjwkbv> i. s” i s a n d a.l” qa” e d.a o .n l y a.p”p e” a r e d i n. i .r “a q a f. t e r u “s “a i .n “v a”si o.n , D .i .d u “s “a p .a “v e. th e w. a.y f or i .s”i s to i. r “a .q ?
<fhjwkbv> a g .a i .n s t u` .s. a
<fhjwkbv> `p l e .a s e .s h `a r e m. y .` q .s 2 ` .l e s .s e n .. u .s. a . a g. g. r` e s s i o n a g .a` i n. s t o t .h .e r s
fhjwkbv has quit [Excess Flood]
<chadmed> using __builtin_bswap64 would be frowned upon wouldnt it
<chadmed> ah that would break building the kernel with clang i think
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
psykose has quit [Ping timeout: 480 seconds]
psykose has joined #asahi-dev
bisko has quit [Server closed connection]
bisko has joined #asahi-dev
PhilippvK has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
phiologe has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
<marcan> fyi: you can use `softwareupdate --fetch-full-installer --full-installer-version 12.1` to download a 12.1 installer, useful for updating to a specific version that is no longer the latest
lewurm has quit [Server closed connection]
lewurm has joined #asahi-dev
drwhax[m]1 has quit [Server closed connection]
drwhax[m]1 has joined #asahi-dev
as400[m] has quit [Server closed connection]
as400[m] has joined #asahi-dev
l3k[m] has quit [Server closed connection]
l3k[m] has joined #asahi-dev
Sebhl[m] has quit [Server closed connection]
Sebhl[m] has joined #asahi-dev
_jannau_ has quit [Server closed connection]
_jannau_ has joined #asahi-dev
jbowen has joined #asahi-dev
RianSouzaSantos[m] has quit [Server closed connection]
RianSouzaSantos[m] has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
sheepgoose has joined #asahi-dev
al3xtjames has quit [Quit: al3xtjames]
al3xtjames has joined #asahi-dev
jbowen has joined #asahi-dev
mini has quit [Server closed connection]
mini has joined #asahi-dev
<chadmed> jeffmiw: the __builtin_bswap64 intrinsic actually does work in clang so using it in the rtc driver instead of swapping the bytes around manually shouldnt break anything, and might be marginally faster. im still not sure what the policy is upstream wrt using compiler intrinsics though
jbowen has quit [Ping timeout: 480 seconds]
<jannau> it probably should use be64_to_cpu() (effecively using __builtin_bswap64)
<chadmed> ive been playing around with both and it seems it doesnt like being fed value[6] because its an array, so if that cant be changed to a proper int whatever reason (dont have the hardware to test that) then that little bit swapping hack is probably going to have to stay, but moved into a helper function as per alyssa's suggestion
<jannau> it type checks the input. you could use swab64() directly but the operation we want is to convert a 64-bit big-endian value to the cpu's endianess
<jannau> even if it quite unlikely that the code will ever run on a big-endian cpu
<jannau> note I gaven't looked at the code
jbowen has joined #asahi-dev
ybk[m] has quit [Server closed connection]
ybk[m] has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
IsfarSifat[m] has quit [Server closed connection]
IsfarSifat[m] has joined #asahi-dev
josipknezovic[m] has quit [Server closed connection]
josipknezovic[m] has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
kit_ty_kate1 has quit [Quit: WeeChat 3.2.1]
<jeffmiw> alyssa: only reason is myself not thinking at it this way:), thanks for all the suggestions, will take them inot account, I did not like this byte swapping anyway :)
<jeffmiw> chamed: yes big endian, I'll add a comment for that
<jeffmiw> alyssa: about the helper function, do you have an good example somewhere ? just for me to do it as right as I can
<chadmed> it would literally just be taking the byte swapping logic and containing it within its own function, and replacing rtc_time and rtc_offset assignments with a call to that function
<jeffmiw> jannau: I'll see how to leverage be64_to_cpu() or swab64(), I'm not familiar with those yet
<chadmed> or, if "value" can be changed from an array of 6 bytes to a normal int of any length you can use the corresponding be_to_cpu() functions in <linux/byteorder/generic.h>
<jeffmiw> chamed: about the multiple variables on a single line, I'll clean that too
<chadmed> i tried messing with it myself but the intrinsics those functions wrap dont like that value is a six-byte array. they want a normal int
<jeffmiw> ok, got it, will try something
NotHere[m] has quit [Server closed connection]
NotHere[m] has joined #asahi-dev
jbowen has joined #asahi-dev
nsklaus has joined #asahi-dev
rethematrix[m] has quit [Server closed connection]
rethematrix[m] has joined #asahi-dev
<sven> jeffmiw: I’ve left some comments from a brief review on GitHub. Mostly just some minor nits
<sven> I think you have some indentation errors, you can use checkpatch.pl and/or clang-format to catch those
ryanhrob[m] has quit [Server closed connection]
ryanhrob[m] has joined #asahi-dev
roxiun[m] has quit [Server closed connection]
roxiun[m] has joined #asahi-dev
<jeffmiw> sven: thanks, will look into them, yes I'll run checkpatch.pl
jbowen has quit [Ping timeout: 480 seconds]
nsklaus has quit [Quit: Textual IRC Client: www.textualapp.com]
<jannau> sven: I pushed reserved memory / locked dart changes to https://github.com/jannau/linux/tree/bits/200-dcp
<sven> I’m about to get uhh… let’s call it breakfast. I’ll take a look afterwards :)
<jannau> I went for now with remapping the locked ttbr, mostly since Alyssa already did that. changes as far as io-pgtable-arm is concerned are limited to https://github.com/jannau/linux/commit/d813575ca19d122ce4f371fabdd1d1a3143a65ec
Rhys[m]12 has quit [Server closed connection]
Rhys[m]12 has joined #asahi-dev
gladiac has quit [Server closed connection]
gladiac has joined #asahi-dev
<jannau> I think it will blow up on device detach
<jannau> sure, look at it when you have time
roxfan2 has joined #asahi-dev
yrlf has quit [Server closed connection]
yrlf has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
nsklaus has joined #asahi-dev
jato has quit [Server closed connection]
jato has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
blasty has quit [Server closed connection]
blasty has joined #asahi-dev
gabuscus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
gabuscus has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
chengsun has joined #asahi-dev
chengsun_ has joined #asahi-dev
chengsun has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
<sven> interesting. So DCP does not try to access any memory when it sleeps?
<sven> if that’s true this makes everything much easier
chadmed has quit [Remote host closed the connection]
<jannau> I not sure if I'm not just lucky. will apple_dart_map_pages cause a tlb_invalidate()? I didn't check thouroughly. if it does apple_dart_setup_reserved_regions() is obviously a race for dcp with more than 1 reserved region
<sven> no, you only need an invalidate for unmapping pages
<sven> I’ve played with that a while ago and as far as I can tell it only has a cache for mappings but no cache for page faults (which also makes sense)
<jannau> My fear is that the memset in alloc_page_table takes effect before I can remap all reserved regions
<kettenis> I think that fear is justified
<sven> Yup
<sven> you also have another race for non locked darts where you first update the TTBR and only then map everything
<kettenis> looking at your stuff right now because I may need to take some pre-emptive action in U-Boot and OpenBSD for this
<kettenis> such that adding the new nodes doesn't break stuff
<jannau> for the disp0 dartI have currently "apple,reset-mask" but that is probably going to change
chadmed has joined #asahi-dev
<kettenis> so do I understand correctly that "dcp_dart: iommu@23130c000" is the locked one?
<sven> jannau: sure, but in the setup translation function there’s also a brief race right now (see my GitHub comment)
<kettenis> and "disp_dart: iommu@231304000" isn't locked but resetting it breaks the framebuffer?
<jannau> for the locked dcp dart all thatis needed is to ignore locked darts
<jannau> kettenis: yes, dart-dcp is locked, dart-disp0 has the framebuffer mapped and resetting it breaks the fb
m6wiq has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
<kettenis> btw, is there any progress on upstreaming the various spi bits?
<jannau> unfortunately not from my side, I keep being distracted by other stuff. I was planning to work on that this weekend but haven't done anything yet
jbowen has joined #asahi-dev
<kettenis> yeah, hacking on new stuff is much more fun than dealing with the linux review bureacracy ;
<sven> :D
jbowen has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-dev
<marcan> I need to send the rest of wifi... and clean up aicv2...
<marcan> then again
<marcan> sven: we still haven't heard from the t6k DART stuff right?
<sven> right
<marcan> might want to poke that, since that blocks the new chips anyway
<sven> and I also need to re-send the usb stuff
<kettenis> marcan: making the gpio a subnode of the smc node breaks pcie in u-boot, but I can still boot from nvme
<kettenis> so I think that is acceptable if you really think it is better to do it this way
<marcan> what do you mean by breaks pcie?
<marcan> I made it a subnode because smc will have a whole bunch of subdrivers eventually, and they are subdevices in the mfd model, and I figure it makes sense to have the hierarchy expressed in the DT too
<kettenis> the pcie driver can't find the pwren gpio and therefore returns an error which makes the driver probe fail
<kettenis> I can obviously fix that
<kettenis> although my plan is to switch over to a different branch that doesn't have the smc and pcie drivers anyway
<kettenis> so I don't think it is a big loss
<kettenis> (the pcie driver needs redoing before I can submit it upstream)
<kettenis> so I think it is all fine
<jannau> kettenis: dcache_enable() breaks u-boot on the t600x
<jannau> without it I get both frame buffer and console prompt, albeit slowly
<kettenis> dcache_enable() is what enables the MMU
<kettenis> (and the cache; you can't enable the cache without enabling the MMU on ARMv8)
<marcan> kettenis: fwiw linux has the same problem
<marcan> which is why I plan to submit the pcie change only after SMC is in, so I don't break people doing the manual enable for now
jbowen has joined #asahi-dev
<kettenis> you could make it a soft-fail in the pcie driver
<kettenis> marcan: I noticed a different reg address in the device tree, but it seems the smc registers are visible at both 0x23e400000 and 0x23e050000
jbowen has quit [Ping timeout: 480 seconds]
kit_ty_kate has joined #asahi-dev
<alyssa> Hmmmm who wants to watch a v sleepy Alyssa attempt to write M1 GPU drivers? :-p
<alyssa> marcan: No better time to stream than when I kinda want to crawl back into bed right??? :-p
<jannau> kettenis: sigh, the problem is annoyingly simple. add_map() is looping endlessly due to a non page aligned framebuffer size
<marcan> kettenis: I can't make it soft-fail because the error is EPROBE_DEFER, which is normal
<marcan> alyssa: ^^
<fridtjof[m]> i'd tune in to a gpu stream!
<marcan> kettenis: so, remind me of what DT bindings we need to settle for BSD on your side?
<marcan> I want to push those through asap, and maybe throw a couple patches over the fence to keep things moving, then start poking around u-boot a bit since it's time to polish the "official" boot chain :)
<marcan> basically once I get the boot/firmware/installer/arch linux stuff in shape we can pretty much do a release at this point
<sven> nvme probably. jannau did some changes to rtkit for DCP iirc, but once SMC also works with that setup we can figure out how to submit NVMe and SMC
nirgo has joined #asahi-dev
<kettenis> I think the important bits are nvme, spi, spi-hid and smc
<kettenis> having anything change in those areas that make drivers fail would be painful for upgrading
jbowen has joined #asahi-dev
<kettenis> I've started polishing things on my end already
<alyssa> marcan: Hmm?
<kettenis> built a version of the asahi-installer that installed m1n1 with a u-boot payload and had two OpenBSD developers install OpenBSD that way
nirgo has quit [Ping timeout: 480 seconds]
<jannau> basic t600x support is working in a single u-boot binary
<marcan> jannau: nice :D
<kettenis> so something is still wrong with my logic to switch the memory map based on the SoC compatible?
<jannau> mostly thanks to kettenis, annoying that I didn't find https://github.com/kettenis/u-boot/pull/2/files when I tried the first time
* alyssa thinks she'll stream after all, if she can remember how to twitch
<jannau> kettenis: no, the only problem is that the frame buffer size is not page aligned
<kettenis> oh, so close...
<kettenis> although, maybe that is something that should be fixed in m1n1?
jbowen has quit [Ping timeout: 480 seconds]
<marcan> I don't think there's any expectation that reg properties be page-aligned
<marcan> so u-boot should probably just handle it
<kettenis> I was more thinking of whether it is safe to map memory that hasn't been reserved in the device tree by m1n1
<marcan> it should be safe to align mappings to the page size
<kettenis> true
<kettenis> jannau: I suppose it also works when you use SZ_4K instead SZ_16K?
<kettenis> should probably also round down the framebuffer base and do the same for the normal DRAM mappings
<jannau> yes, 4k works as well
<kettenis> ok, let me cook a diff for that
<kettenis> and see whether I can push something that includes nvme and keyboard stuff
<marcan> I'd hope the fb base is page-aligned in all cases, but yeah, can't hurt to round it just in case
<jannau> aligning everything to 4k still works, but only the fb size was unaligned to begin with
Major_Biscuit has quit [Ping timeout: 480 seconds]
<alyssa> ☁️ On air - https://twitch.tv/asahigpu ☁️
m6wiq1 has joined #asahi-dev
m6wiq has quit [Ping timeout: 480 seconds]
m6wiq1 has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
m42uko has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
m42uko_ has quit [Ping timeout: 480 seconds]
<kettenis> ok, https://github.com/kettenis/u-boot/tree/t6000 is now rebased on upstream master and has nvme and spi-hid support included on top of that
<kettenis> jannau: if you can test that I'll add your tested-by tag
<kettenis> nvme might actually work; usb will need some changes to the dart driver
<kettenis> I think with a recent m1n1 a Linux device tree may also just work
<jannau> kettenis: does not work at all, no output even with early debug uart
<kettenis> :(
<kettenis> did you adjust the various CONFIG_DEBUG_UART options in apple_m1_defconfig/
<kettenis> ?
<jannau> yes, under the HV I now get 'No serial driver found' but Samsung S5P UART is enabled
<kettenis> ah, that means the debug uart does work!
<kettenis> maybe the u-boot,dm-pre-reloc properties aren't added?
<kettenis> m1n1 should do that now, but maybe it is subtly broken
<jannau> yes, works with power-domains commented in the dts
<kettenis> does nvme work?
<jannau> no, usb and keyboard don't work either, I'm currently looking why the u-boot,dm-pre-reloc changes in m1n1 do not work
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
Tuff has quit [Read error: Connection reset by peer]
<jannau> kettenis: nvme works after fixing the u-boot,dm-pre-reloc problem
m6wiq has joined #asahi-dev
<kettenis> cool; and the keyboard work as well at the u-boot prompt?
<kettenis> s/work/works/
<marcan> reminder that SART changed
<kettenis> u-boot ignores the SART ;)
<marcan> merged
<kettenis> you're fast!
<jannau> keyboard is not working, input over the uart doesn't work either
<kettenis> I wonder why I didn't run into this issue...
<jannau> it enabled one pmgr at the end of the recursion and on m1 only the main pmgr is needed
<jannau> on t600x two pmgr nodes are required but only one gets u-boot,dm-pre-reloc
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
<marcan> has anyone looked at shutdown btw?
<marcan> I was just taking a look now, looks like it involves both PMU and SMC
<marcan> SMC gets one write, a bunch of SPMI/PMU stuff happens, SMC gets another write
<marcan> doing just the SMC bits causes a reboot, not a shutdown
<Glanzmann> marcan: kettenis: Does in OpenBSD, so he has looked at it.
m6wiq has quit [Remote host closed the connection]
m6wiq has joined #asahi-dev
<kettenis> marcan: that matches my experience
<marcan> ah, bsd had this already?
<marcan> I think I remember that :)
<kettenis> writing 0x8 to byte 0x9f0f in the spmi pmu address before triggering a reset is enough to make it shut down
<marcan> just tried a dumb replay of everything macos did on spmi and it worked, heh
<kettenis> corellium did more writes, but those some to not be neccessary
<marcan> yay for my hypervisor log that dumps out runnable python :p
<kettenis> must admit I haven't tried the hypervisor for this
<marcan> a reset, any reset?
<marcan> as in wdt works too?
<kettenis> wdt works too
<marcan> cute
<kettenis> I'm using the smc though since it might do some more magic
<marcan> yeah
<marcan> looks like the pmu driver will need a reference to SMC then
<kettenis> not measured power consumption in the powered down state
<marcan> another thing macos does is shut down the wifi gpio
<marcan> not sure if that's strictly required or it would happen anyway
<kettenis> it certainly isn't still turned on when I boot up the machine again
<marcan> I imagine a boot will reset things anyway, but yeah
<kettenis> but iboot might turn it off
<marcan> ok, I should get some sleep
<marcan> I think next week is going to be wrapping up SMC/SPMI PM for me
<marcan> and then u-boot :)
<kettenis> I get away with no reference from pmu to smu the way the reboot/reset code in OpenBSD/arm64 is structured
<kettenis> so you can do what you want there
<kettenis> the spmi stuff needs some thought
<kettenis> you probably want subnodes there as well (jeffmiw added one for the rtc already)
<marcan> the sequence seems to be smc/spmi/smc so I imagine that needs some kind of sync to happen in the right order?
<marcan> though possibly the first smc write is not necessary
<marcan> and yeah
<marcan> apple seems to parameterize all SPMI PMUs as one driver
<marcan> with a ton of DT stuff
<marcan> not sure if we'll end up doing the same or what
<kettenis> well if the first smc is the wifi gpio then that should probably be initiated by the pcie driver
<marcan> nah, it's something else
<marcan> it goes that, then gpio, then SPMI stuff, then smc
<kettenis> I tried to make some sense out of the apple DT stuff for the spmi pmu but it all looks very ad-hoc and hackish
<marcan> yeah
<sven> I feel like half the ADT is just hacks to get something working :(
<j`ey> marcan: have you seen jeffmiw's spmi tree? https://github.com/jfbortolotti/linux/commits/spmi_rtc
<marcan> j`ey: yeah, I'm going to work off of that
<kettenis> sven: apple has a long tradition doing that
<kettenis> lots of stuff in the Open Firmware device trees of the PowerPC macs that didn't make a lot of sense either
<fridtjof[m]> 0
<fridtjof[m]> oops, sorry
<jannau> is there a way to make kernel_addr_r dynamic on the mem map? the distro bootcmds will fail otherwise
<jannau> also it would be nice to have only efi bootcmds
Major_Biscuit has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
<jannau> loading grub works with kernel_addr_r in ram
<kettenis> jannau: there is an env_set() function that sets these variables
<kettenis> actually probably needs env_set_hex()
<kettenis> the set of variables that needs to be set is a bit of a mess though
<kettenis> I can probably take a look next week
<kettenis> not sure if folks will be happy if I remove the non-efi boot commands
<jeffmiw> the spmi driver in my tree is very minimal, reduced to what is needed to get the rtc stuff working
<jeffmiw> I'll focus to clean it up based on all the comments so to have it decent enough to submit upsream. I was planning to look at shutdown after but I'm sure marcan will have it ready before I can even think of looking at it :)
<jannau> kettenis: thanks, env_set_hex() works, I guess we don't have to remove all the other bootcmds if we set the required variables correclty
Major_Biscuit has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
m6wiq1 has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
m6wiq has quit [Ping timeout: 480 seconds]
roxfan2 is now known as roxfan
<alyssa> ...and we're back https://twitch.tv/asahigpu
m6wiq1 has quit []
m6wiq has joined #asahi-dev
<ar> hm. the stream is cutting out for me
<jannau> the compiler steals all the CPU
<ar> interestingly, my x86 laptop builds mesa (in a somewhat full-fat build; the build goes up to 2585/2585 targets) + some nix fun afterwards in: nix-build -A mesa --check 1.00s user 0.74s system 0% cpu 4:55.78 total; meanwhile my x86 desktop does the same in nix-build --check -A mesa 0.27s user 0.13s system 0% cpu 1:44.55 total
<tpw_rules> what are the times from the stream?
jbowen has joined #asahi-dev
<ar> not sure, quicker, but also smaller builds (half of the targets, iirc)
<j`ey> ar: work smarter not harder :P
<ar> j`ey: well, what i did was just a rebuild of what the distro builds by-default
jbowen has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
kov has joined #asahi-dev
akemin_dayo has quit [Ping timeout: 480 seconds]
Tuff has joined #asahi-dev
Tuff has quit []
akemin_dayo has joined #asahi-dev
user982492 has joined #asahi-dev
m6wiq has quit []
jbowen has joined #asahi-dev
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
yrlf has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]