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
boardwalk has quit [Quit: The Lounge - https://thelounge.chat]
<alyssa> j`ey: on parle seulement l'anglais, merci beaucoup :-p
yuyichao_ has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-dev
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi-dev
yuyichao has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
axboe_ has quit [Quit: leaving]
<Glanzmann> povik: mini and air target are online.
sirn- has joined #asahi-dev
sirn has quit [Ping timeout: 480 seconds]
sirn has joined #asahi-dev
sirn- has quit [Ping timeout: 480 seconds]
<rkjnsn> marcan, yeah, 300-600 IOPS isn't great, but it's a lot better than 46 for cases where one wants to ensure internal consistency but doesn't care about losing a second or two of writes. It's almost certainly the mode I'll end up using for fsync if we provide it as an option.
willemml has joined #asahi-dev
<marcan> rkjnsn: that's partially a filesystem thing; according to axboe linux doesn't really do barriers these days
<rkjnsn> Right. I mean if there was an option to translate fsyncs into drive barriers instead of full flushes.
<marcan> I don't think drive barriers are a thing
<marcan> the barrier flush thing in macos is probably just something it constructs on top of the cow/journal of the filesystems
<marcan> and it's still slow because it still has to flush once in a while, but can probably enforce barrier semantics across multiple writes through the metadata without flushing every time
<Glanzmann> marcan: I don't know if that is relevant, but if you repeat the random test with the files in place I get 70k IOPS: https://pbot.rmdir.de/NAZqGckf6JqZoyrwOvlMnQ
<marcan> no --fsync?
<marcan> not sure what test sven was doing but I'm pretty sure you aren't flushing each write that way if you're getting that performance
<j`ey> alyssa: desole mais tu viens de parler en francais aussi!
<rkjnsn> Without some way to pass the barrier on to the ANS, how would it enforce ordering to persistent storage without requiring individual flushes?
<Glanzmann> marcan: This was with axboes patch, I just wanted to show the file system overhead.
<marcan> oh, well then yeah
<rkjnsn> Maybe it's worth seeing if there's a similar speedup for F_BARRIERFSYNC vs F_BARRIERFSYNC on an HFS+ partition, which presumably can't be doing any CoW shenanigans try to enforce ordering with fewer flushes.
<marcan> alright, so things for the next asahi
<marcan> am I forgetting anything other than what was already in spmi/work and jannau's spi fixes?
<marcan> sven: nvme stuff? I think RTKit is already in order in the spmi branch, right?
<Glanzmann> marcan: Two patches from axboe:
<marcan> povik: any new audio updates?
<marcan> ah right, that bug
<Glanzmann> Yep, without the first patch with cpufreq 'nvme' hangs. Second one for performance.
<jannau> rtkit should be covered by spmi/work and works for nvme, smc, and dcp
<povik> yes, some fixes at the very least
<povik> marcan: you doing this right now?
<povik> what's the base? latest next?
<j`ey> the 'defer nvme flush' commit has the interval defaulting to 1s, there was talk of that actually defaulting to 0s (aka always flush)
<jannau> not sure if you count the two top commints in https://github.com/jannau/linux/commits/bits/010-devicetree under the spi fixes
<j`ey> povik: next-20220217
willemml has quit [Quit: willemml]
<marcan> povik: I pushed asahi-soc/next, that
<marcan> (which is what j`ey said)
<marcan> jannau: ah, thanks, missed thsoe
<marcan> *those
<rkjnsn> As a random person on the internet, I would feel better defaulting to always flushing.
<mps> rkjnsn: +1
<povik> then one or two audio fixes will be there already :-)
<povik> let me prepare a 'for-marcan' then
<rkjnsn> (I also think abxoe mentioned that flushing by default would be needed for it to be accepted upstream.)
<Glanzmann> rkjnsn: Yes, he did.
<mps> (I prefer consistency and correctness over performance)
<marcan> I think I'm going to make the default deferring flushes *this time* just so people test that codepath
<marcan> if you're concerned about consistency/safety you probably shouldn't be running this kernel anyway for a myriad of other reasons :-)
<marcan> but it will not be the default down the road, at least not on desktops
<j`ey> that sounds reasonable
<Glanzmann> marcan: \o/
<mps> marcan: yes, for current status it is not important
<marcan> done with the merges so far, fixing build issues due to conflicts now
<marcan> I think that's just povik's changes left :)
<povik> it will take me half an hour let's say
<povik> there are changes that i want to keep out and i need to test the result
<marcan> np :)
<j`ey> marcan: theres also https://git.kernel.dk/cgit/linux-block/commit/?h=m1-test&id=6b70875739979358439ec81f8736cba9e24b0575 for nvme, I think sven has informally acked that
<marcan> ah, just a fixup, sure
<Glanzmann> Yes, he did. Small performance improvement.
<j`ey> marcan: btw are either of your m1 max/pro the lower core models?
<Glanzmann> j`ey: You should no him better than that.
<Glanzmann> know*
<marcan> j`ey: noipe
<marcan> and yeah, I need to fix m1n1 for that
<j`ey> Glanzmann: he was trying to cover a range of models :)
<marcan> I can simulate it with the HV though, easily
<marcan> just nuke nodes there
<marcan> we already do it for !SMP mode anyway
<marcan> for now I pushed updated bits/*, in case anyone wants to take a look
* j`ey looking
* Glanzmann too.
<mps> which branch? asahi-soc/next?
* mps goes to prepare tea and after that build and test
<jannau> mps: just the bits branches for now
<jannau> still waiting for audio fixes
<jannau> asahi-soc/next is just the base
<mps> jannau: aha, I see. thanks
<mps> sorry j`ey ^
<Glanzmann> jannau: Are your dtsi and spi patched for the device tree for u-boot in?
<j`ey> marcan: 13bff188e3817dbede4fbb458d3e48847058a42e is not needed anymore, fixed in next
<j`ey> marcan: see 147ab5376f18045da9f22a8262185707745bbf77
<marcan> ah, thought so but I didn't check :)
<marcan> dropped it
<marcan> they are already squashed if they're fixups
<jannau> Glanzmann: the changes are squashed in the main commits
<jannau> marcan: https://lore.kernel.org/all/e6b80669-20f3-06e7-9ed5-8951a9c6db6f@kernel.dk/ is not yet in next and prevents un-ackable irqs on macbook pro 14/16 where tps6598x fails to probe for all ports except magsafe
<jannau> looks good otherwise
<marcan> thanks, I'll throw it in misc
<j`ey> marcan: I think macsmc_rtc_get_time is leaking p_off
<j`ey> nvmem_cell_read() states buffer should be freed by the consumer with a kfree().
<Glanzmann> jannau: I see, thanks. I did not know.
<marcan> j`ey: indeed, good catch
* marcan is not a fan of APIs that return newly allocated buffers...
<j`ey> also theres a double newline before macsmc_rtc_probe if youre editing that file
<marcan> thanks :)
<marcan> fwiw, the asahi diffstat:
<marcan> 165 files changed, 18045 insertions(+), 559 deletions(-)
<j`ey> marcan: I suppose that means that nvmem_cell_get_u8 is leaking too, in macsmc-reboot
psykose has quit [Remote host closed the connection]
<j`ey> I mean, if youre about to reboot or powroff anyway...
psykose has joined #asahi-dev
<jannau> 18k insertions is less than I would have guessed
<marcan> well, it'll leak every time you read that sysfs file :)
<marcan> fixed
<j`ey> bad indentation
<j`ey> seems to be spaces, not tabs
<marcan> yeah, copypaste fail
<j`ey> marcan: not sure for the reason of having an 'enum pm_setting'
<j`ey> you just use them as ints in ac_power_mode_map[]
<marcan> no real reason, it could be #defines
<j`ey> #defines seems to be the usual way, but maybe this subsystem does it like that? *shrug*
<marcan> no idea tbh, I usually favor enums for this kind of thing but I haven't checked
<marcan> that supersedes bits/070-audio, right?
<marcan> except the dt bits
<povik> yes, also the dt bits
<marcan> sound/soc/apple/mca.c: In function ‘apple_mca_probe’:
<marcan> sound/soc/apple/mca.c:917:45: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long int’ [-Wformat=]
<marcan> sound/soc/apple/mca.c:951:47: warning: too many arguments for format [-Wformat-extra-args]
<marcan> sound/soc/apple/mca.c:951:47: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘struct device_node *’ [-Wformat=]
<marcan> that looks mildly broken :)
<marcan> also heh, panics early on t6000... I need to look at this
<marcan> (not the audio)
<j`ey> marcan: copy paste fail again in smc :P
<j`ey> kfree(buf); should be p_off
<marcan> already fixed :p
<j`ey> thanks to git push -f, it never happened!
<povik> uh
<povik> clang didn't seem to kick me for those
<marcan> uhhh
<marcan> edecc06b4d34e9
<marcan> rebuilding, but I'm pretty sure that's broken
<j`ey> you have CONFIG_SPARSEMEM_EXTREME?
<j`ey> oh, I do too lol
<j`ey> sounds too EXTREME for regular use
<marcan> sigh
<marcan> I love people fixing compiler warnings without reading the code
<marcan> yeah, reverting that (and the subsequent fixup) fixed it)
<j`ey> at least you found it quickly
<marcan> angry email sent :p
<j`ey> how can that not be breaking more things.
<marcan> j`ey: very few machines don't have memory at 0
<marcan> pushed asahi, barely smoke tested, have fun :-)
<j`ey> I thought a decent amount of arm machines didnt
<marcan> t8103 does boot and doesn't; I think it needs to be significantly above 0 :)
* marcan off to shower and, er, lunch?
<sven> marcan: yeah, rtkit in there + axboe's patches are all fine
<sven> the flush thing is a bigger hack than it needs to be but it's good enough for now
<sven> (and axboe wanted to clean that up anyway)
<mps> povik: I booted latest asahi, audio card is not detected on MBP
<mps> and I don't see any new option related to audio .config
<mps> maybe DTS is changed
<marcan> CONFIG_SND_SOC_APPLE_SILICON
<Glanzmann> Thanks.
<mps> marcan: already had it set
<Glanzmann> I also get this: https://pbot.rmdir.de/aKbAxtC0HVErbRD03D9-mw maybe it is helpful.
<mps> Glanzmann: I didn't noticed this when compiling
<marcan> are you missing ARCH_APPLE?
<mps> marcan: :-)
<Glanzmann> marcan: Yes, I did. Forgot that my build box is now an amd64 ...
<j`ey> >_<
<Glanzmann> You found it faster than I, because that was the last thing that I checked.
<mps> marcan: ah, you asked Glanzmann and not me, sorry
<marcan> the message literally told you...
<Glanzmann> marcan: Yes, it did, but I started testing kernel options from the bottom up, now top down.
<Glanzmann> not*
<marcan> but that sounds like SND_SOC_APPLE_MCA needs a dep on ARCH_APPLE too to prevent that broken dep chain
<marcan> Glanzmann: it's the only thing in the message that doesn't have a [y] next to it and isn't COMPILE_TEST
<marcan> it was the only option
<mps> I have few aarch64 machines (some are powerfull) and I always build on them everything for aarch64
<Glanzmann> We don't need that, do we? https://pbot.rmdir.de/u/V5wo5cz6XyHacO6BGpYEzQ
<Glanzmann> marcan: I see.
<marcan> no, didn't realize that patch fixed a broken build
<marcan> just turn off that driver
<Glanzmann> mps: Debian bootstrap.sh needs 8 minutes on the air, 4 on the ryzen ...
<povik> shouldn't have touched the kconfigs
<povik> let's see what i did there
<Glanzmann> povik: I think it is unrelaed, maybe I had it just on in my usually broken config without any reason whatsoever.
<kettenis> marcan: I just created an "asahi" u-boot branch with all the diffs that we still need on top of u-boot master
<kettenis> but maybe it makes sense to have that under github.com/AsahiLinux?
<j`ey> did poweroff also rely on 12.x firmware, or just rtc?
<kettenis> just rtc I think
<povik> since the asahi branch now has NCO patches verbatim as they are on the list
<povik> you can try playback with couple of different samplerates, then post a tested-by here: https://lore.kernel.org/linux-clk/20220208183411.61090-1-povik+lin@cutebit.org
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
joerg has joined #asahi-dev
joerg is now known as Guest293
<Guest293> exit
<Guest293> oh sorry
Guest293 has quit []
joerg1 has joined #asahi-dev
joerg1 has quit []
<ah-[m]> povik: oh does https://github.com/povik/linux/commit/babbcf6fe43a957fa373094241d764a9aeec41ad mean you got something working on t6000?
<povik> no, that's for the cs42l83 codec on t8103 macs
<ah-[m]> ah, t6000 is cs42l84
<povik> but the other day Dcow[m] suggested cs42l92 as possibly similar to cs42l83: https://statics.cirrus.com/pubs/proDatasheet/CS42L92_F2.pdf
<povik> and the l92 even has a linux driver!
<povik> er, similar to cs42l84, not cs42l83
<sven> looks like i just can't reproduce those missed nvme interrupts anymore (without the additional lock around command submission) no matter what i try :/
<jeffmiw> j`ey: I'm with an old macOS 11.5.2 and neither rtc nor shutdown work with latest asahi branch, currently updating my system to latest macOS 12 to re-test
<j`ey> jeffmiw: shutdown worked for me in the end, also 11.x. make sure you had all the SPMI/MFD/NVMEM options
<j`ey> jeffmiw: but upgrading is needed anyway soo
<j`ey> (for rtc I mean, and dcp)
axboe has joined #asahi-dev
<jeffmiw> I had all the SPMI/MFD/NVMEM options, I saw some errors on the spmi nodes in the dt, which model are you testing on ? I'm on mba
<j`ey> jeffmiw: "bad cell count" errors are currently expected. MBA here too
<jeffmiw> ok so probably something else wrong in my setup then. I dig into it if I still see the issue after updating. For testing power off I tried halt or shutdown, how do you so it ?
<j`ey> I did 'poweroff -f' but that was from an initramfs setup with busybox
<jeffmiw> ok, I'll check this. Thanks. I also have a minimal initramfs with busybox.
<mps> poweroff also works for me
axboe has quit [Quit: leaving]
axboe has joined #asahi-dev
grgy has quit [Quit: ZNC 1.8.2 - https://znc.in]
grgy has joined #asahi-dev
<kettenis> hmm, did I misunderstand that the CLUSTER_PSTATE register contains the actual power state of the cluster as well as the desired state?
willemml has joined #asahi-dev
willemml has quit [Quit: willemml]
bps has quit [Ping timeout: 480 seconds]
willemml has joined #asahi-dev
willemml has quit []
bps has joined #asahi-dev
boardwalk has joined #asahi-dev
Hiroshi has joined #asahi-dev
Hiroshi is now known as Guest306
axboe has quit [Quit: leaving]
Guest306 has quit []
axboe has joined #asahi-dev
axboe has quit [Quit: reboot]
axboe has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
<alyssa> j`ey: blasphemie
<j`ey> alyssa: excusez-moi pour chaque faux pas que j'ai faire
Gaspare has joined #asahi-dev
willemml has joined #asahi-dev
willemml has quit []