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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
vlixa has quit [Remote host closed the connection]
<brentr123[m]>
did i seriously get kicked from #freenode_#asahi-gpu:matrix.org for being idle for 30 days? i dont really talk in there, im just a observer
<Graypup_>
brentr123[m], that's matrix
<brentr123[m]>
anyway to fix that?
<Graypup_>
talking once every 30d, using a normal irc client :/
<Graypup_>
(or)
<Graypup_>
i was reminded by your message to look at matrix to not get kicked from a project channel i care about greatly on matrix ;-;
Calchan has joined #asahi
phiologe has quit [Ping timeout: 258 seconds]
phiologe has joined #asahi
<marcan>
kettenis_: one thing I do want is for Linux not to depend on u-boot initialization, unless there are very good practical reasons for that
<marcan>
beacuse the ability to boot linux directly from m1n1 (during testing) is quite handy
marvin24 has quit [Ping timeout: 252 seconds]
marvin24 has joined #asahi
<amw>
If I'm understanding the end plan is signed (minimal) m1n1 -> u-boot (complex boot loader support) -> Linux
<amw>
So m1n1 is very rarely upgraded but u-boot occasionally bugfixed/extra features, Linux regularly upgraded
jeffmiw_ has joined #asahi
taziden has quit [Ping timeout: 258 seconds]
jeffmiw_ has quit [Ping timeout: 240 seconds]
<marcan>
correct
<marcan>
actually, m1n1 and u-boot will be upgraded together, as they are combined into one file
<marcan>
and you need to go into 1TR to upgrade them (it cannot be done from linux or any normal OS)
<marcan>
many users will probably do m1n1 -> u-boot -> grub -> Linux
<marcan>
grub is the first piece that will be easily upgradable
taziden has joined #asahi
zkrx has quit [Ping timeout: 240 seconds]
zkrx has joined #asahi
wicast has quit [Ping timeout: 260 seconds]
wicast has joined #asahi
klaus has joined #asahi
<arnd>
shenki: it looks like that tg3 firmware is always flashed into the chip though, so no need to load any blob (open source or not) into the device for network booting
raster has joined #asahi
<sven>
didn't someone have a simple python apple device tree parser? I can't seem to find that one anymore
<sven>
maz: I think that was the one I had in mind, thanks
<arnd>
marcan: regarding the v4 submission, it seems that there were only very minor comments that you can just fix up and send a v5 pull request with any additional changes as fixups on top.
<marcan>
arnd: I think so, yeah
<arnd>
maz: I see you gave a Reviewed-by for the irqchip driver. Do you think we should also get an Acked-by from tglx for merging it through the soc tree in addition?
<maz>
arnd: tglx usually isn't that interested in the non-x86 irqchip stuff, which is why I'm dealing with it.
<arnd>
marcan: can you send that pull request in the next two days then? I don't want to merge it too late, and it seems there won't be an -rc8 this time after all
<arnd>
maz: ok, fair enough
<marcan>
if we're good on everything else I can send it today, but we still have the hard dep on the FIQ series
<marcan>
maz: has that gone through yet?
<maz>
arnd: I'll just mention the driver in my PR to tglx.
<maz>
marcan: nah, I'm preparing the branch at the moment.
<marcan>
cool
<maz>
marcan: actually, the FIQ stuff is in the arm64 tree.
<marcan>
everything else is soft, so I think I don't need it as a merge base for my PR, right arnd? the worst that will happen is that if the merge order is "wrong", intermediate states will fail the dtb linter (due to missing bindings), but no build failures or anything like that
<maz>
marcan: I expect arnd to drag it.
<marcan>
ah, in that case I will use that as a base
kharit[m] has quit [Ping timeout: 248 seconds]
ponikrf[m] has quit [Ping timeout: 248 seconds]
wagood[m] has quit [Ping timeout: 248 seconds]
hothotleg[m] has quit [Ping timeout: 248 seconds]
ryanhrob[m] has quit [Ping timeout: 248 seconds]
r1fl has quit [Ping timeout: 248 seconds]
tardyp has quit [Ping timeout: 248 seconds]
<marcan>
just need a final commit to make sure I don't pull in an incomplete series
<arnd>
right, I thought that's what you had already done last week
rcombs has quit [Ping timeout: 248 seconds]
<marcan>
not quite, didn't know it was in amd64 already
<marcan>
(but almost)
<maz>
I'm trying to get Will to get the VHE crap a once over.
<marcan>
that one is completely orthogonal, so we don't have a merge dep on it
<marcan>
arnd: if you think the potential dtb check noise risk from merge order is OK, then I suggest I just base my series on the FIQ commit in the amd64 tree (or some later commit); that avoids having to do any actual merges at all
r1fl has joined #asahi
tardyp has joined #asahi
<marcan>
otherwise I can merge in gregkh's tty thing like I did for the v4 tree
<arnd>
marcan: isn't the tty series also needed in order to boot with a serial console?
<marcan>
it is, but not to build
<arnd>
I would much prefer to have a branch that actually works standalone
<marcan>
in that case I'll have to do it like v4, that's FIQ + VHE + tty
<marcan>
do you need me to sign the PR?
<arnd>
Remind me what the VHE series is for, is that also required for booting?
<marcan>
yes
<marcan>
it wouldn't be a kernel version ago :-)
<maz>
the CPUs can't do non-VHE, which is the way Linux boots now.
<marcan>
but recent changes broke booting on noncompliant VHE-only systems (M1)
<arnd>
ok
rcombs has joined #asahi
<marcan>
maz is just trying to make this merge as fun as possible for everyone :-)
<arnd>
marcan: please sign the PR with the key that you plan to use in the future, even if that doesn't have any signatures from other developers yet
<marcan>
let me cook something up then. debating whether to use my "usual" yubikey (if I can associate it sanely to a PGP identity, nominally I've only used it for SSH purposes so far, note: ed25519 keys) or throw an RSA 2k key into a spare I have lying around
<maz>
marcan: always happy to help.
<marcan>
(jokes aside, going from random drive-patches to ALSA every odd year to upstreaming *this* SoC of all things at *this* time has been quite the crash course in kernel procedures)
tburgin[m] has quit [Quit: Idle for 30+ days]
<sven>
you should be able to just create a signature-only (S) subkey on that yubikey and sign that with your C pgp parent key. I'd strongly recommend to try that on a separate yubikey before though since I managed to delete a key like that before :D
<marcan>
if I'm going to have a long-term identity for this I probably want a hard offsite backup of that parent key (encrypted etc); I care less about that for SSH keys since I have redundant ones and can always just use one to update the others
<marcan>
but in principle that should work with the parent key done on-CPU (in an offline computer at least) and then signing the signature-only subkeys I already have, maybe
<marcan>
will have to test :p
<sven>
that's what I did a while ago :)
<sven>
but I didn't read any warnings etc. and overwrote one of my ssh keys on my yubikey
<sven>
worked fine for the second one though
<marcan>
heh
<marcan>
bbiab, need to run to the pharmacy before it closes
<marcan>
I'll wrap this up today after I'm back :)
furkan has joined #asahi
<sven>
marcan: ah, btw., can I just put the clock gate + i2c stuff under you in the MAINTAINERS file?
furkan has quit [Ping timeout: 240 seconds]
furkan has joined #asahi
ponikrf[m] has joined #asahi
ryanhrob[m] has joined #asahi
wagood[m] has joined #asahi
kharit[m] has joined #asahi
brandas has quit [Remote host closed the connection]
<kettenis_>
marcan: based on the discussion from yesterday I think my immediate goal would be to let m1n1 do some minimal RC port initialization and let u-boot take it from there
<kettenis_>
that means the device tree would contain enough information for linux to bring up pcie if booted directly from m1n1
hothotleg[m] has joined #asahi
<kettenis_>
that doesn't mean m1n1 can't be extended later to fully bring up pcie
<arnd>
kettenis_: I suppose this means we don't put a /chosen/linux,pci-probe-only property in the DT, but u-boot may add this to speed up the boot
<arnd>
it's slightly annoying to have linux do a complete PCI bus/resource assignment even when the firmware has done it correctly already, but somehow we ended up doing that on most machines
<marcan>
arnd: I can set up a non-github server too if you prefer
<marcan>
please check that the key is kosher and such; if it looks good I'll sign it with my old less-securely-managed key (for continuity) and if you want we can do a verification over video or something like that
<delroth>
just post it on twitter /s
<marcan>
I added it to github for starters, so it shows the verified badge :p
<arnd>
marcan: github is fine, but the tag description should be more than one line. You can probably just copy most of the v4 cover-letter text into that
<marcan>
I was going to ask about that
<arnd>
I usually also add a Signed-off-by line to a tag, though some others don't
<marcan>
I'll use the cover letter then, add add the minor v5 change notes
<arnd>
the tag description should not contain the '[PATCH v4]' prefix on the subject line
<marcan>
leave vN to the tag name, right?
<arnd>
I don't know what the latest is on keeping the change nodes in the tag description. I usually don't do it myself, but I've seen others do it
<marcan>
can also just go in the PR email
<arnd>
I don't care about the tag name for the purpose of the pull request, I'd say including v5 in the name makes sense unless it's unchanged from v4
<arnd>
git request-pull just pastes the tag description, so that makes it in there automatically
<marcan>
cool
<marcan>
do people prefer https:// or git://?
<arnd>
I think there is a slight preference for https://
<arnd>
I'm still confused about the nVHE patches, the tag you sent now has these at the bottom after the other two merges. Shouldn't this be a merge commit to get the same commits that make it into the arm64 tree?
<arnd>
or do these just go through the soc tree without showing up in the arm64 tree as well?
<maz>
no, they must go via the arm64 tree.
<maz>
neither Will nor Catalin have even Acked the second patch, which is the critical one.
<arnd>
ok
<marcan>
arnd: those were in there for testing purposes, because they weren't in arm64 yet
<arnd>
marcan: ok, got it
<marcan>
so we're blocked on that, but I can get everything else in order
<maz>
marcan: as you pointed out, that's not really a blocker. these patches can land independently, and nothing breaks compilation wise.
<arnd>
marcan: in this case, it makes sense to start the tag description with '[DONT PULL]' and an explanation
<arnd>
maz: I said earlier that I'd prefer the branch to have all the patches to make it work (not just build) in one piece
<arnd>
obviously if we expect that to take longer, that is something we can reconsider
choozy has joined #asahi
<arnd>
Or I could merge the rest into a standalone branch, and then merge the VHE patches on top after they make it into the arm64 tree
<maz>
arnd: I don't really see what that buys us. it's not like we're merging a fully working system. At the current state of things, it only gives you a serial console...
<arnd>
true
<arnd>
the worst case would be someone needing to bisect an m1 specific (boot time, I guess) regression that is caused by something else merged into v5.13. In this case, "someone" most likely ends up being marcan, and he can figure it out regardless ;-)
<arnd>
maz: if we merge the m1 support without the VHE patches, do we still need the FIQ patches to cleanly build, or should marcan drop those as well then?
<arnd>
nevermind, I see it's needed to build the aic driver
<maz>
arnd: yup, that's the ugly link in the chain.
<arnd>
marcan: ok, please just drop the VHE patches from the branch, and send that pull to soc@kernel.org with cc to everyone that commented in the past, and explain the situation with all the dependencies in the tag.
<arnd>
I'll be busy with the backlog of other pull requests for the rest of my day here, so no need for you to loose sleep over doing it today. If you send it by tomorrow, I'll pull it in right away
<arnd>
we can still debate over whether I should merge in the VHE branch into the soc tree after that makes it into the arm64 tree
brinly has quit [Ping timeout: 260 seconds]
brinly has joined #asahi
Hetflik[m] has quit [Quit: Idle for 30+ days]
mofux[m] has quit [Quit: Idle for 30+ days]
mofux[m] has joined #asahi
modwizcode has joined #asahi
<marcan>
arnd: cool, got it
<marcan>
thanks! :)
<marcan>
maz: does the #define thing I proposed make sense to change? at least it'll make the real meaning of those hwirqs more evident
VinDuv has joined #asahi
zopieux has quit [Ping timeout: 246 seconds]
zopieux has joined #asahi
omoiti has joined #asahi
vimal has quit [Remote host closed the connection]
<sven>
let's see if it's maybe just a bit somewhere that selects it
<kettenis_>
it means that you're exposing more memory to the device than desirable
<kettenis_>
and may end up having to expose the same set of 4k pages multiple times
<kettenis_>
not sure how linux handles DMA of network packets, but the problem probably already exists in that area when two packets are stored in a single page
<kettenis_>
in other news, there is more evidence that the pcie root ports are based on synopsys designware crap
<kettenis_>
version 5.30a-ea15 to be specific
<marcan>
no big surprise there, considering USB is also designware
<marcan>
I'm really curious about thunderbolt though
<marcan>
how that ties in
<sven>
i also couldn't really add a mapping from an iova/to a paddr that's not aligned to 16k easily
<sven>
there's also at least a BUG_ON((granule > PAGE_SIZE) in the linux iommu code which i should hit with 4k cpu pages
<sven>
good news on the pcie root port though :)
<sven>
let's hope there's even more hw that's a variant of something known
omoiti has joined #asahi
<kettenis_>
sven: I'll probably need a tunables_apply_local() variant that takes an explicit base address
<sven>
ah, yeah. i've been meaning to get back to that
<sven>
do you also need one that walks up the ADT or takes a parent node for the "regs" property?
<kettenis_>
if I have one that takes a base address, I can use that
ephe_meral1 has quit [Ping timeout: 240 seconds]
<kettenis_>
I need that base address later on anyway
<kettenis_>
so I'd just call adt_get_reg() on the parent node myself
<sven>
true. is that base address not based on a reg property at all?
<sven>
(i.e. it's nothing like regs[25] + some_offset?)
<kettenis_>
it is based on a reg property
<kettenis_>
but the reg property is in the parent node
<sven>
ah, okay. so it'll be somewhat ugly anyway.
<sven>
might be more flexible to just have the base address as an argument then
<kettenis_>
not sure what marcan wants to do
<kettenis_>
could just pull what you have now and I add the function I need as part of the pcie setup code
<sven>
sounds like we'll either need tunables_apply_local(.., base_addr) or tunables_apply_local(.., "parent-node", parent_reg_idx, addr_offset)
<sven>
or just do that for now :)
<kettenis_>
the first approach would make most sense in my context
<arnd>
sven: the dma-mapping API does not guarantee dma_map_sg() to produce a consecutive bus address range even with an IOMMU, so for normal drivers it should be fine even when the iotlb page size is larger than the CPU page size. You still get the isolation and address-expanding properties
<sven>
kettenis_: it also sounds like it's the most flexible to me. the current function could just use that one as well internally so that we don't have to duplicate any code
<arnd>
however, anything that relies on controlling the iommu from the driver directly will have a problem
<arnd>
so no SVA, no vfio, and no probably no GPU with with per-task contexts
<sven>
okay, so at least some thing will work with 4k pages then even if i don't find a way to switch the iommu to 4k pages as well
<sven>
*things
<sven>
still not great though
luca020400 has quit [Ping timeout: 248 seconds]
<arnd>
sven: it also appears that you will hit that BUG_ON() in init_iova_domain() when setting up the domain for the dma-mapping API. I'm fairly sure that it is possible to lift that restriction, but I don't know how invasive the changes will be for that.
odmir has joined #asahi
luca020400 has joined #asahi
luca020400 has quit [Remote host closed the connection]
luca020400 has joined #asahi
luca020400 has quit [Remote host closed the connection]
luca020400 has joined #asahi
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
<sven>
yeah, i'll just remove that BUG_ON tomorrow and see what happens with 4k pages.
jeffmiw_ has joined #asahi
<sven>
but after that i think i should include at least will in this discussion since he'll likely have a strong opinion how to deal with this situation as well
luca020400 has quit [Read error: Connection reset by peer]
luca020400 has joined #asahi
<kettenis_>
sven: thanks, I'll give it a go
<arnd>
sven: maybe also loop in Jean-Philippe Brucker <jean-philippe@linaro.org>, he's jbru on #armlinux. Will is wildea01 there, fwiw. I don't know if Robin Murphy is on IRC, but he's the one that added the BUG_ON() when implementing support for multiple i/o page sizes
luca020400 has quit [Quit: WeeChat 3.1]
luca020400 has joined #asahi
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
<sven>
will do, thanks!
luca020400 has quit [Read error: Connection reset by peer]
luca020400 has joined #asahi
omoiti has quit [Ping timeout: 240 seconds]
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
VinDuv has quit [Quit: Leaving.]
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
luca020400 has quit [Read error: Connection reset by peer]
luca020400 has joined #asahi
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
luca020400 has quit [Client Quit]
luca020400 has joined #asahi
omoiti has joined #asahi
PendulumSwinger7 has joined #asahi
PendulumSwinger has quit [Ping timeout: 268 seconds]