ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
mischa85 has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
pb17 has joined #asahi-dev
mischa85 has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
mischa85 has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
mischa85 has joined #asahi-dev
mischa85 has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-dev
mischa85 has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
nafod has joined #asahi-dev
nafod has quit []
nafod has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-dev
glem810054888 has joined #asahi-dev
nesnas has joined #asahi-dev
mischa85 has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
glem81005488 has quit [Ping timeout: 480 seconds]
glem810054888 is now known as glem81005488
mischa85 has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
john-cabaj has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
nora has joined #asahi-dev
nora_ has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #asahi-dev
nesnas has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-dev
nesnas has joined #asahi-dev
mischa85 has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
nesnas has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
mischa85 has joined #asahi-dev
nesnas has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
mischa85 has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
chrisl has joined #asahi-dev
ipatch has quit [Remote host closed the connection]
ipatch has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
aditya has joined #asahi-dev
mischa85 has joined #asahi-dev
chrisl has joined #asahi-dev
Calandracas_ has joined #asahi-dev
Calandracas has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
nesnas has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
mischa85 has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-dev
chrisl has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
mischa85 has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
glem810054889 has joined #asahi-dev
glem81005488 has quit [Ping timeout: 480 seconds]
glem810054889 is now known as glem81005488
aditya has quit [Quit: Connection closed for inactivity]
dcavalca85697 has quit []
mischa85 has quit [Ping timeout: 480 seconds]
dcavalca85697 has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
aditya has joined #asahi-dev
mischa85 has joined #asahi-dev
mischa85_ has joined #asahi-dev
mischa85 has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
john-cabaj has joined #asahi-dev
roxfan has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
<chadmed>
robher: im working on that tdm idle slot mechanism we discussed on the ML, but given that tdm-slot.txt is not a standard YAML thing im not sure how/where to document the new DT properties. Plain English in that file with the other TDM slot properties?
<kettenis>
chadmed: I fear that means you need to convert that to YAML first
<chadmed>
figured that would be the answer. thats okay it's tiny
<kettenis>
jannau: thanks for doing that u-boot test
<kettenis>
is upstreaming the dockchannel DT bindings on someone's radar?
<chaos_princess>
u-boot or kernel?
<kettenis>
kernel
<kettenis>
best if that happens first before I try to upstream the u-boot bits
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
mischa85_ has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
aditya has quit [Quit: Connection closed for inactivity]
<fl0_id>
mmh, regarding the 24 Mhz / 1 Ghz switch on M3+ - it seems CNTFRQ_EL0 is accessed in hv.c, hv_wdt.c, and utils.c (and gpiola.py and some experiments) I assume code will have to check for which chip/frequency is used everywhere, or probably preferably, introduce a separate function that does that?
<fl0_id>
i.e if < m3 = 24 Mhz, else 1 Ghz (or sth like that)
<kettenis>
more like fixed at 24 MHz if < M3, configurable between 24 MHz and 1 GHz when >= M3
<fl0_id>
kettenis ok but is it configurable? The change log makes it sound like with 15.x firmware, it always returns 1 Ghz on M3 or newer
<j`ey>
fl0_id: it can return 24Mhz if an app was built against the older SDK
<j`ey>
(on macOS)
<fl0_id>
j`ey ok, good to know. I just understood it as "don't use this directly, but use our lib / api which abstracts this"
<chaos_princess>
i think we would always want to run with 1ghz
<kettenis>
I don't think it really matters as long as we configure things consistent across cores
<kettenis>
but might as well pick 1 GHz since ARM has declared that's the future
chrisl has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<fl0_id>
kettenis it prob matters if you want to offer both, as it adds complexity I would guess
<kettenis>
open source OSes (and applications) already have to deal with the frequency varying from machine to machine
<fl0_id>
well yes but I meant f.e. m1n1 in this case
<fl0_id>
(if it matters somewhere)
aditya has joined #asahi-dev
chrisl has joined #asahi-dev
nesnas has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
nesnas has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
mischa85 has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
bjoto has quit [Ping timeout: 480 seconds]
hamr has joined #asahi-dev
enick_92 has quit [Quit: Bridge terminating on SIGTERM]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
hightower2 has quit [Remote host closed the connection]
nela has joined #asahi-dev
mischa85 has quit [Ping timeout: 480 seconds]
TheLink has quit [Quit: Bye!]
TheLink has joined #asahi-dev
TheLink has quit [Quit: Bye!]
cyrinux9 has quit []
TheLink has joined #asahi-dev
cyrinux9 has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
TheLink has quit [Quit: Bye!]
TheLink has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
bjoto has joined #asahi-dev
john-cabaj has quit [Remote host closed the connection]
<jannau>
rrendec: hej
<jannau>
do you have specific knowledge or interests related to our changes? are you familia with the kernel process?
<rrendec>
I haven't looked very closely at your changes because 1200 commits is a lot :)
<rrendec>
I was hoping to be able to get a quick overview here
<rrendec>
I am familiar with the kernel process and I have contributed before but I'm not actively doing upstream development in any specific area
<chaos_princess>
wifi
* chaos_princess
hides
chrisl has joined #asahi-dev
<chaos_princess>
really: if you look at the repo, you will see multiple branches that are called bits/000-something, see if something appeals to you
<rrendec>
I noticed there are a lot of changes related to Rust and DRM, and those are two areas that I'm really not familiar with, so I would stay away from those
<rrendec>
chaos_princess: thanks, that's a really good tip! will look at those branches
john-cabaj has joined #asahi-dev
pb17 has joined #asahi-dev
TheLink has quit [Quit: Bye!]
TheLink has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<rrendec>
010-soc, 030-misc, 060-spi, 130-cpufreq look interesting, and some of those patches are in areas where I worked before
<jannau>
rrendec: best bet would be bits from bits/030-misc or bits/080-wifi, bits/090-spi-hid (needs work), bits/150-xhci-firmware
<jannau>
060-spi should be already upstream
<chaos_princess>
xhci-firmware has annoying hw requirements
<chaos_princess>
thats like what, 4 port imac, and non-ultra mac studio?
<rrendec>
then maybe I can start with 030-misc?
<jannau>
from 010-soc I think only the pmgr changes are upstreamable. the rtkit ones are mostly all queued for upstream
<rrendec>
yeah, that was the other question: how do I know what's already being worked on, so I can avoid effort duplication?
<rrendec>
jannau: I see only two pmgr changes in 010-soc (or 3 with the dt bindings), so that looks like a low hanging fruit
<jannau>
in 030-misc the kvm/perf changes are handled. pasemi i2c were sent recently, PM domains changes might require a prior discussion. UHS-2 changes need more debugging
<chaos_princess>
force-disable/force-reset from 010-soc will be sent with isp, which is now blocked on dart changes
<jannau>
do you think it's necessary/advisable to send with isp? could easily just point to v1 isp submission as justification
<chaos_princess>
idk, can be split out i guess
<jannau>
rrendec: I can only think of asking here or checking if someone send something in the last months
<rrendec>
nice! would it be safe to assume that any kernel submission related to the project would cc that list?
<chaos_princess>
it should
<jannau>
I'd say 90 to 95% are
billak has joined #asahi-dev
billak has quit [Quit: Konversation terminated!]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
<jannau>
chadmed: I'm looking at the kernel atm and there is another conflict with the toplevel Makefile
mischa85 has joined #asahi-dev
<chadmed>
jannau: should we just drop genpatches while we're churning upstream stuff then? they dont really give us any benefits tbh
chrisl has joined #asahi-dev
<jannau>
they bring us closer to gentoo-{kernel,sources}. resolving the issue is just a minor annoyance but I think we have to just do it once per kernel release
mischa85 has quit [Ping timeout: 480 seconds]
<jannau>
kernel builds now
<rrendec>
all right, it looks like there isn't much I can work on in those branches I mentioned, so maybe 080-wifi is a better choice after all
<rrendec>
it's also something I can at test at least partially on the hw I have, which is a Mini M2, assuming it uses the brcmfmac driver (I haven't checked)
<sven>
it does
<sven>
getting wifi upstream would also be very nice since that branch should also help some other modern Broadcom boards iirc
zeezie01 has joined #asahi-dev
yuyichao_ has joined #asahi-dev
<rrendec>
well, then wifi it is; any suggestions on how/where I should start?
<chaos_princess>
i guess you can start reading the bits branch in chronological order, package it into self contained features and start sending
<rrendec>
sounds good
<rrendec>
thanks
mischa85 has joined #asahi-dev
<jannau>
m2 mini is the ideal target for wifi. a large part of it is for supporting the 6ghz capable bcm4388 used in the m2 mini
zeezie01 has quit [Remote host closed the connection]
zeezie01 has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
john-cabaj has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
nesnas has quit [Ping timeout: 480 seconds]
<PaulFertser>
rrendec: hi. I provided some feedback on brcmfmac patches testing it on AzureWave AW-CM256SM SDIO module (brcmfmac43455-sdio.bin firmware) but dberlin didn't really follow up.
<PaulFertser>
rrendec: also, brcmfmac was essentially unmaintained and I guess it still is, so the experience upstreaming anything to it might be frustating.
<fl0_id>
PaulFertser won't the subsystem maintainer then deal with it, if the original maintainer is mia?
<fl0_id>
(just curious, tryng to learn)
nesnas has joined #asahi-dev
<PaulFertser>
fl0_id: well, it's supposed to happen that way but the whole subsystem thing changed lately too (Kalle Vallo quitting) and also imagine you're a maintainer of all the Linux wireless and you're offered a patch that potentially affects plenty of hardware without any proper documentation for the kernel <-> firmware API. And you know that the driver as it currently is works good enough on
<PaulFertser>
RaspberryPi. What would justify the risk of breaking it unless the patch author is really convincing and also has tested important things on at least the most popular older models?
<PaulFertser>
fl0_id: those dberlin patches actually did regress functionality of the SDIO module I tried them on.
<fl0_id>
yeah good point. guess a new driver would be easier almost
<PaulFertser>
Also imagine the maintainers getting paid by Intel or similar, and the company requires certain performance and deadlines and such.
<PaulFertser>
fl0_id: such a large scale code duplication wouldn't be accepted either.
<fl0_id>
PaulFertser yeah I know, and it shouldn't. just aa hypothetical
mischa85 has quit [Ping timeout: 480 seconds]
<PaulFertser>
A practical way would be for someone to actually obtain at least the most popular brcmfmac devices and to test all the changes on all of them properly, and to become a real brcmfmac maintainer.
nesnas has quit [Ping timeout: 480 seconds]
<fl0_id>
PaulFertser true, but that sounds like a fulltime job almost
<fl0_id>
but yeah ofc that would be good
<PaulFertser>
You say it as if Linux isn't meant to be the product of full time paid developers these days.
nesnas has joined #asahi-dev
<rrendec>
haha, it is but many of them are paid to do other things too (myself included) or mainly other things
<fl0_id>
PaulFertser I know that. But yeah not all and not everybody is paid to work on it full time like rrendec said
<PaulFertser>
fl0_id: it's kind of risky being passionate about something that can be ruined any moment by money-driven people who have the ultimate control after all.