marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
booffo[m] has joined #asahi
dgc[m] has joined #asahi
EdwardAnd[m] has joined #asahi
JuniorJPDJ has joined #asahi
yuyichao has joined #asahi
dpatterbee[m] has joined #asahi
jevinskie[m] has joined #asahi
alexanderwillner[m] has joined #asahi
Nspace has quit [Quit: Nspace]
M31j[m] has joined #asahi
cavoirom[m] has joined #asahi
tylo1 has quit [Remote host closed the connection]
tylo1 has joined #asahi
LeviLynch[m] has joined #asahi
angustrau[m] has joined #asahi
wollymilkcap[m] has joined #asahi
AnushervonTabarov[m] has joined #asahi
M32thSystem[m] has joined #asahi
ilovetrains[m] has joined #asahi
camr0[m] has joined #asahi
peerp[m] has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
Spectrejan[m] has joined #asahi
<alyssa>
maz: I'm still trying to understand how the kernel merge windows work ... when do we expect pci/apple to be merged into linux-next?
<alyssa>
I see linux-next is updated continuously outside the mainline merge window but I'm not sure if there's more to it
<alyssa>
(Is there another hop between "subsystem maintainer merges into a feature branch" and "subsystem maintainer sends it to linux-next"?)
<alyssa>
(At any rate, I rebased on top of pci/apple and everything still works, including the half-baked wifi)
Aaron[m]1 has joined #asahi
PedroArajo[m] has joined #asahi
AndrewLee[m] has joined #asahi
kdrag0n[m] has joined #asahi
thebrinkoftomorrow[m] has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
ghantaz[m] has joined #asahi
bastilian[m] has joined #asahi
cgv[m] has joined #asahi
sandornagy[m] has joined #asahi
<marcan>
alyssa: AIUI it's when the subsystem maintainer merges it into their next branch
YichaoYu[m] has joined #asahi
<marcan>
feature branches mean nothing
ll3macorn[m] has joined #asahi
Caedus[m] has joined #asahi
SocioProphet[m] has joined #asahi
darkapex has quit [Remote host closed the connection]
<sven>
yeah, i think it's just the maintainer's preference
<sven>
i've seen many of them have different feature branches and then they just merge them for their next branch
<sven>
i guess that also helps if any of those branches ever is split to a separate tree as well
<arnd>
I think most maintainers have a 'fixes' branch and a 'for-next' branch, whatever they are named
<arnd>
both are merged into linux-next, but the fixes is for the current release, and may occasionally get merged into the for-next branch, which is sent in the following merge window
<arnd>
for the soc tree, we have around five branches that are updated with individual pull requests and then merged into the for-next branch, but then the separate branches are what we send in the merge window
<arnd>
the 'tip' tree works in a similar way, but they have a lot more branches
tylo1 has quit [Ping timeout: 480 seconds]
<sven>
makes sense
<maz>
arnd: BTW, shall I send you a PR for the the M1 pcie DT updates?
Nspace has joined #asahi
<arnd>
maz: ideally that should go through marcan's tree, but if he has no other changes, I can take it from you with his ack
<marcan>
the tree I don't have? :D
<marcan>
arnd: who would I upstream that through? you?
<maz>
arnd: fine by me. I'll let marcan pick them up.
<marcan>
(never quite worked out the post-initial-merge flow)
<arnd>
marcan: the way this should normally work is that you have a tree to collect all M1 specific changes that don't go through a driver subsystem tree. This tree should be part of linux-next, and then you send a pull request to soc@kernel.org for me or ojn to pick it up into the soc tree
<marcan>
makes sense
<marcan>
that would also cover those maintainer changes we talked about
<arnd>
most of the changes in that tree would be for arch/arm64/boot/dts, but occasionally there could be something else, like Kconfig, defconfig, or MAINTAINERS updates
<marcan>
yeah
<marcan>
also, we don't exactly have a mailing list for reviews; how are changes by the tree maintainer themselves normally reviewed?
<marcan>
I'm fine with the github flow but I imagine that clashes with what other kernel maintainers expect
<arnd>
if you only have a couple of changes for a given merge window, you can also just send individual patches instead of pull requests, the main purpose of the PR is to have a nicer git history with a merge commit that gets your tag description with an overview of the contents
<arnd>
marcan: for dts changes, I expect the review to happen during the review for the corresponding subsystem driver, and/or on the devicetree mailing list, cc linux-arm-kernel and anyone you want to participate in the review
<marcan>
ah, so it's just about the flow upstream in that case, not the review per se
<marcan>
makes sense too, since my tree would mostly only handle changes that are associated with some driver
<marcan>
though we probably will have random dts changes not associated with any driver at various points
<marcan>
e.g. adding more hardware or fixing things
<j_ey>
those seem to happen on LAKML too
<marcan>
yeah
<arnd>
right, so if you add an apple-m2.dtsi file that is not just adding support for another driver, that would probably need separate review, and you should loop in reviewers for that directly.
<marcan>
right
<marcan>
I guess ultimately if I'm making the changes myself, the review would be push-only
<marcan>
send the patches out, make changes, then once it's all good just push directly to my tree
<marcan>
(as opposed to another maintainer grabbing patches from the ML and applying them to a different tree)
<arnd>
when I get a pull request at soc@kernel.org, I usually take a quick look at all the contents to make sure nobody screwed up, but I expect the contents to have been reviewed at that point
<marcan>
yeah, makes sense
<marcan>
though e.g. for a silly MAINTAINERS change the review would probably only involve the ML and whoever is in that entry
<marcan>
right?
<arnd>
yes
<marcan>
cool, makes sense
<marcan>
thanks for the handholding :)
<marcan>
maz: I'll pick your patches up as soon as I have the progress report out and the other things sent out for review
<arnd>
btw, if you update the email addresses in that file (new reviewer, change of employer etc), please send that directly as a bugfix for the current release so it has the correct information at the time of release, don't wait for the merge window with those
<marcan>
ah, makes sense, yeah
<marcan>
I think right now it was just alyssa adding herself as a reviewer
<maz>
marcan: there's no hurry. it's not like that's the only thing missing in the grand scheme of things!
<marcan>
and also I wanted to throw sven in as a maintainer for the overall platform
<marcan>
maz: fair, but I do need to get into the kernel review/maintainer flow so best not leave it for too late ;)
<marcan>
arnd: for such bugfixes, would I still send that to you?
<marcan>
(pull from a fixes branch instead of a next branch)
<arnd>
also, regarding the timing: try to get an initial pull request out to soc@kernel.org early (i.e. before rc4 or rc5) if you have a lot of contents, you can always follow up with fixes or later contents when you have more stuff to add, I just don't want to get a large pull request shortly before the merge window as I'm trying to wrap stuff up for the pull requests I send to torvalds
<marcan>
ah yeah, makes sense
<marcan>
there's also the whole stable@ thing, but I mostly already know the rules about that
<arnd>
marcan: yes, same thing there: send bug fixes as soon as you can, batching things up over one or two weeks at most
<marcan>
cool
<arnd>
I'm a bit behind this release but I plan to pull in all remaining fixes today
<marcan>
I think it's fine if the MAINTAINERS update ends up in the next merge window anyway
<marcan>
no point in CCing stable for DT updates, right? just for driver bugfixes and such
<Glanzmann>
marcan: 10:16 < arnd> btw, if you update the email addresses in that file (new reviewer, change of employer etc), please send that directly as a bugfix for the current release so it has the correct information at the time of release, don't wait for the merge window with those
<marcan>
Glanzmann: yeah but I mean if it's too late anyway
<Glanzmann>
marcan: You have all day. 10:21 < arnd> I'm a bit behind this release but I plan to pull in all remaining fixes today
<arnd>
most maintainers send pull requests even if it's just one or two bugfixes, but feel free to send the fixes as individual patches if there are only a couple and it's a hassle to set up a git tree for it
<marcan>
nah, I'll send you a pull. besides, I didn't get you to sign my GPG key for nothing!
<arnd>
marcan: dt patches can be important fixes, this is generally your call to make to weigh the importance of the fix against possible regression risks. Generally I would prefer platform maintainers to categorize more patches as fixes for the current release though
<marcan>
given how our installer will work, DTs in stable kernels are mostly ~irrelevant anyway
<marcan>
since we're just going to be using some recent release for the m1n1 install, which will be kernel-agnostic
<arnd>
Adding a "Cc: stable@vger.kernel.org" tag for stable backports usually makes sense if the current code is definitely wrong and the fix you do would also address the same problem on stable kernels.
<marcan>
yeah, exactly
<arnd>
I wouldn't make a distinction between dts files and code here
<marcan>
that's what I do for driver fixes (also USB quirks I've sent around)
<marcan>
just doesn't seem like it would actually do anything for dts files given our platform
<marcan>
but if you think it's a good idea anyway I can do that
<arnd>
and in general I would assume that anything you want fixed in the current release cycle should also be fixed in stable trees, and vice versa
<arnd>
gregkh often complains about patches marked as cc:stable but not sent as fixes for the current release, so he has to do a ton of backports to the just-released kernel after -rc1 comes out with all those fixes in it
<marcan>
ah...
<marcan>
that's up to the maintainers, right?
<arnd>
his process for stable kernels is otherwise very automated, so you don't need to worry about creating extra work due to the cc:stable tag
<marcan>
(I've sent a lot of random things marked cc:stable but where they send it is up to them, right?)
<arnd>
yes, the cc:stable tag is mostly there to inform gregkh and that the patches are known to apply to older kernels as well
<arnd>
Sasha also has a set of scripts and AI logic to find patches that have no cc:stable tag but look like they should be backported
<marcan>
heh
<marcan>
I do wonder if we should have a mailing list for asahi stuff
<marcan>
might be a convenient place to have people subscribe to
Nspace has quit [Quit: Nspace]
<marcan>
and also a place of record for more durable conversation
<arnd>
It's better to be explicit here. cc:stable is obvious, and you can add the minimum kernel version it applies to (sometimes backporting a fix to an older kernel causes the opposite regression), and if you think a patch looks like a fix but should not be backported, just add a sentence in the description to explain why not
<arnd>
yes, I think having a mailing list would be good
<arnd>
you can ask postmaster@vger.kernel.org to add a list if you want it hosted there
<marcan>
I can set up some infra for ourselves, but yeah, I might opt for that too
<marcan>
depends on how painful it looks to set up :)
Nspace has joined #asahi
<arnd>
regardless of where it goes, you should ask mricon to set up a lore.kernel.org mirror after that, it's super useful as a reference
<arnd>
and if you want to pick up patches from that list, you can use 'b4' to interact with it, and it will even add links to the archive in the commit message
<maz>
funny to read this while I have powered the G5 to check something else... the Mini is a lot quieter!
<kettenis>
heh
<maz>
(last powered on in 2012...)
<TheLink>
"This is effectively a requirement for most SoCs, because hardware tends to vary quite a bit from generation from generation ..."
<TheLink>
guess it should be "from generation to generation"
<kettenis>
I don't think the powerpc macs should hit that codepath as all the pcie devices are represented in the device tree on these machines (even cards plugged into the pci slots)
<kettenis>
but I'm also not sure the change makes sense as interrupt-map is only supposed to translate interrupts for child nodes
<kettenis>
that diff is needed to correctly map interrupts for the root ports isn't it?
<kettenis>
anyway, I don't want to derail the series
<maz>
yes. that's what they are needed for (RP own interrupts, INTx).
<maz>
I think this represents the HW pretty accurately though.
<kettenis>
have to head home (first day at the office for a very long time)
<maz>
the RP is both an interrupt controller and interrupt generator.
<maz>
ah... that's tomorrow's activity here!
<marcan>
maz: I was going to ask if I had to power on my G4 Mac Mini but you beat me to it :)
<maz>
marcan: I'm sure it is a lot quieter than the XServe! :D
<marcan>
:)
<maz>
(which runs kernel 3.6, and I need to update it to something sloghtly more modern...)
<marcan>
yeah...
<marcan>
I installed Debian on mine quite some time ago, not entirely sure what kernel it has...
<maz>
I though it'd be quicker to just reinstall Debian, but the install media is missing both ethernet and sata drivers...
<marcan>
oops
<maz>
amusingly, it was a tigon3 already...
<marcan>
ha :)
tylo1 has quit [Ping timeout: 480 seconds]
tylo1 has joined #asahi
tylo1 has quit [Ping timeout: 480 seconds]
tylo1 has joined #asahi
<alyssa>
marcan: too many exclamation points in the blog post
<alyssa>
most of them should be .'s
<marcan>
pfft, this is exciting stuff
<alyssa>
you still get a quota
<alyssa>
> Bet you hadn’t heard of that USB standard before!
<alyssa>
no USB standard, no matter how exotic, is exciting stuff ;-)
<marcan>
it's exciting in that it's a giant ball of pain :p
<marcan>
removed a *few* :p
<marcan>
(pushed, will take a while to deploy)
<alyssa>
28 exclamations in a 3k word blog is... excessive
<marcan>
it's 22 now!
<alyssa>
proselint:
<alyssa>
text:4:23: leonard.exclamation.30ppm More than 30 ppm of exclamations. Keep them under control.
<alyssa>
actually proselint turns up multiple related issues
<alyssa>
(Advice for anyone writing on Linux -- run your text through proselint. It is not nearly as good as Grammarly but it still catches issues.)
<alyssa>
signal:noise ratio can be a bit low, though
<marcan>
those things with line numbers that don't match my source aren't terribly useful
<alyssa>
marcan: source then? or run it yourself? :-p
<marcan>
it's on the git repo!
<alyssa>
...I knew that
<psykose>
a lot of these are really... not worth a lint at all? who minds a difference between ... and …
<marcan>
though that won't catch transforms that the markdown parser will do for you, like the ... thing
<j_ey>
marcan: you'll have to forgive alyssa, she's still at university :O
<j_ey>
*:P
<marcan>
that ... it's complaining about it from *alyssa's tweet*
<marcan>
(which is not in the source, it's an embed)
<alyssa>
I deserve that :_p
<marcan>
all the article ones get …'d
<alyssa>
good
<psykose>
even if it was in the source, it's so nitpicky
<alyssa>
psykose: when every mistake is seen by 50k people, it's worth nit picking
<marcan>
yeah, no offense but I disagree with most of those :p
<marcan>
the ones i have context for anyway
<j_ey>
lol eyes peeled is cliche
<marcan>
the preferred forms ones I have no idea what the context is
<psykose>
… to ... is not a mistake, neither is the ! ppm, or the dates back, or the 'very'
<psykose>
if anything i prefer the opposite style of all these suggestions, and not because i'm a weird contrarian
<alyssa>
the 'very' should be dropped in virtually every case in the article
<marcan>
I disagree...
<psykose>
i verily disagree
<psykose>
marcan: great article by the way, loved the read :)
<alyssa>
if the adjective/verb you chose is not emphatic enough without the "very", you need a stronger adjective/verb.
<marcan>
also, it's 2:40AM here and I'm getting solidly into "I couldn't care less, I'm gonna git send on all the announcements" territory :p
<marcan>
*hit send
<alyssa>
$ git send-email announcements.txt
<j_ey>
git send-email
<alyssa>
hard core ;-p
<alyssa>
"a very good idea" --> "a firm understanding"
<alyssa>
"very high level interface" --> "high level interface"
<psykose>
you would make a great middle manager :p
<marcan>
I'm going to give you the "firm understanding" concession, and I'm hitting send
<alyssa>
"a very exciting opportunity" --> "an exciting opportunity"
<psykose>
those verys were important
<psykose>
or at least they always read as two entirely different things in tone
<psykose>
(to me)
<marcan>
announcements sent :p
<alyssa>
💤
<frode_0xa>
hey all, just wanted to say that I'm really impressed with the progress you'll made already!
<frode_0xa>
It is now really close to being ready for daily driving for me
<frode_0xa>
I may need to buy an M1 soon :D
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
<marcan>
\o/
<nsklaus>
frode_0xa: indeed, i have same opinion too. very good team, good progress being made
<nsklaus>
can't wait for this project status to reach v1
<nsklaus>
i'll need audio and wifi to be able to jump in
MatrixTravelerbot[m] has joined #asahi
<j_ey>
nsklaus: audio works if you have a usb headset
<nsklaus>
macbookpro don't have ethernet, unless we use an usb dongle.. and no sound is a bit too sad
<marcan>
wifi works, it's just an ugly mess right now I don't want to ship
<nsklaus>
j_ey: i don't think i have one, all i have are bt headset, that may be plugged in usb-c but i think it's just for power delivery
<marcan>
just needs a big cleanup/rewrite round plus installer scaffolding to put the firmware somewhere useful, and userspace scaffolding to copy/link it to /lib/firmware
<j_ey>
nsklaus: sure, just saying that with buying a dongle or other headset, there's a workaround for now!
<nsklaus>
marcan: i'm patient, i can wait more for the dust to settle a bit, and since thing project is moving along quite fast, hopefully it won't be too long for these missing bits materialize in a first public beta
yuyichao_ has joined #asahi
<nsklaus>
i bet before the end of this year i'll be using asahi full time
<marcan>
nice :)
<marcan>
and yeah, the wifi thing is just on the list of things to clean up for the public release... the bigger question is should I jump into GPU first or do a bit of that :p
<marcan>
we'll see
<nsklaus>
networking should be first imho, we can survive by using a fast framebuffer, but not without network
<marcan>
I mean I wouldn't do the release without wifi
<marcan>
it's more like do I spend some time on GPU first or prioritize the "end user testable" thing
chile09[m] has joined #asahi
<marcan>
I guess I should send out cpufreq+mcc for review, work out my DT tree, then at least start poking at GPU while the other kernel drivers go through review
<marcan>
and once the kernel stuff is a bit more settled, put together the more-final installer
<marcan>
(+wifi or whatever)
<marcan>
(tbh wifi is a one day job)
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
anyway, I should sleep :)
<nsklaus>
that's not to say i'm not eager to see gpu being worked upon, it's of course a very important part and i'm following the progresses made on that front too, but networking ..without networking i cannot do anything
<Glanzmann>
marcan: GPU, or you use the m1 as your only machine and the rest will sort itself out. :-)
<nsklaus>
but well, whatever comes first, it's all good news :)
<Glanzmann>
Yes, but the wifi can do many people, its just cleanup work. The GPU not so much.
<nsklaus>
the situation on macos with moltenvk is realy suboptimal
<marcan>
Glanzmann: I need thunderbolt to make the M1 my main machine ;)
<nsklaus>
it's good such project exist to bring vulkan on macos despite apple refusing to make it happen and third party devs having to do it, but it has many limitations and not progressing that fast.. so opengl is outdated, vulkan support is sub-standard and the whole situation is a bit sad
<Glanzmann>
marcan: That what I mean, once you work with it the gpu will be done in one day.
<Glanzmann>
Because you get anoied by the tiering scrolling in the browser.
<nsklaus>
Glanzmann: that may be aa tad too much optimism :)
<Glanzmann>
nsklaus: marcan moves fast once he gets in the right state of mind we've all seen it.
<nsklaus>
sure.. but 'all in one day ..
<nsklaus>
there's only 24h in those ..
<Glanzmann>
than a week.
<nsklaus>
i'd be happy with 1 or 2 month
<Glanzmann>
Btw, has someone tried the current state of m1 linux on battery? How it is holding up, I really have to try.
<nsklaus>
but if it happen faster then all the better
<alyssa>
Glanzmann: I have to assume "bad" at this point but I wouldn't mind being surprised
<Glanzmann>
I have to try it and report back.
<nsklaus>
i'd be interested to hear the results too
<nsklaus>
you could test with powertop
<Glanzmann>
I think, I'll just work for an hour with it, boot macos and check the battery.
<nsklaus>
around 30mn with all tables tunned to good should give an estimation
<Glanzmann>
There is no driver for the battery state on linux for the m1, is there?
<nsklaus>
powertop will show you the overall power consumtion in watts
<alyssa>
no, but IIRC marcan has code in m1n1 to show it
<Glanzmann>
Wow, cool.
<alyssa>
IIRC. uh
<nsklaus>
*consumption
<alyssa>
no maybe not
<alyssa>
what was I looking at then? SMC maybe? 🤷
<nsklaus>
alyssa: powertop may not work fully in asahi current state you mean ?
<alyssa>
powertop is userspace, so no
<nsklaus>
on x86, running powertop as root, tunning all tables to 'good', unplugging the power cable, it shows the overall power consumption in watts and is accurate, at least on x86. on M1 and asahi current state, i can't say though.
<nsklaus>
i mean, i do that often on my macbookpro early 2015 model, running arch linux
<nsklaus>
on that model, i run between 6-10watts
<nsklaus>
depending the brightness of monitor and what tasks are actives
<nsklaus>
i can have it run around 6 watts, but that mean i disabled a much stuff as i could, like blutooth and all, and capping cpu frequency to lowest etc ..
<nsklaus>
*as much stuffs as i could
<sven>
alyssa: maybe PMP? i remember marcan played around with that during some stream
<alyssa>
sven: Ah, could be
<j_ey>
SMC has some battery "keys" too
<alyssa>
I can talk to my Mali board and reach the net at once. That's nice.
tylo1 has quit [Ping timeout: 480 seconds]
tylo1 has joined #asahi
tylo1 has quit [Ping timeout: 480 seconds]
tylo1 has joined #asahi
vulpun has joined #asahi
vulpun has quit []
Nspace has joined #asahi
Nspace has quit [Quit: Nspace]
aleasto has quit [Quit: Konversation terminated!]
doggkruse has joined #asahi
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yuyichao has joined #asahi
<chile09[m]>
are there a lot of binary blobs on this platform?
<alyssa>
far too many
<alyssa>
for my comfort, anyway
yuyichao_ has quit [Ping timeout: 480 seconds]
<chile09[m]>
what parts of the system use binary blobs