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
brandas has joined #asahi
troseman has joined #asahi
Bublik_ has joined #asahi
crabbedhaloablut has quit [Ping timeout: 245 seconds]
crabbedhaloablut has joined #asahi
Bublik has quit [Ping timeout: 250 seconds]
<marcan>
kettenis: cute, so either it's latched by AIC itself, or by the PCIe core with some kind of feedback of when it is acknowledged
<marcan>
either way, for all intents and purposes that makes it edge triggered to us, implicitly
<marcan>
I guess the AIC driver needs to just accept both types then
JusticeEX has quit [Ping timeout: 260 seconds]
raster has quit [Quit: Gettin' stinky!]
choozy has quit [Remote host closed the connection]
roxfan2 has joined #asahi
<amw>
marcan: Is there any plans to update the asahi github "stable" branches?
<amw>
I've just looked at linux and m1n1 and they are pretty old e.g. Feb and March 15th.
bdju has quit [Quit: Reconnecting]
bdju has joined #asahi
roxfan has quit [Ping timeout: 240 seconds]
<amw>
I'm thinking it would be nice to consolidate Sven's normal USB serial code support on m1n1 as it worked
<amw>
for me - at least linux kernel booting.
Eighth_Doctor is now known as Conan_Kudo
Conan_Kudo is now known as Eighth_Doctor
ifthenelse6 has joined #asahi
stemnic1 has joined #asahi
ifthenelse has quit [Quit: Ping timeout (120 seconds)]
stemnic has quit [Quit: Ping timeout (120 seconds)]
stemnic1 is now known as stemnic
ifthenelse6 is now known as ifthenelse
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arcsor5 has joined #asahi
ifthenelse has quit [Quit: Ping timeout (120 seconds)]
ifthenelse has joined #asahi
riker77_ has joined #asahi
riker77 has quit [Ping timeout: 248 seconds]
riker77_ is now known as riker77
<amw>
~.
<marcan>
amw: you are confusing commit date with branch age
<marcan>
m1n1 is going to get the more recent changes merged in, don't worry
<marcan>
but the linux branch is much newer than february
<marcan>
commit date reflects the date that commit was *created*, not *revised*
<marcan>
so all the rebasing and squashing I've been doing does not get reflected in those dates
<marcan>
that's because most of the past month on the Linux branch has been review feedback, not new code :)
<amw>
marcan: Ok - used git for many years didn't know about commitdate vs authordate
<amw>
git log --format=fuller marcan/upstream-bringup-v4 : shows commitdate Mar 6th vs Feb 4th for authordate
Necrosporus has quit [Ping timeout: 252 seconds]
<amw>
I'm just thinking this week end might be nice to have official branch that you can boot with a normal USB cable serial as per Sven's usb-uartproxy-console-wip for m1n1
<amw>
But I that the m1n1 main is a fairly similar date - but not sure if it has usb serial support yet?
phiologe has quit [Ping timeout: 252 seconds]
phiologe has joined #asahi
JusticeEX has joined #asahi
<amw>
But I that the m1n1 main is a fairly similar date - but not sure if it has usb serial support yet?~.
troseman has quit [Ping timeout: 240 seconds]
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arcsor5 has joined #asahi
marvin24 has quit [Ping timeout: 252 seconds]
marvin24 has joined #asahi
<marcan>
yeah, m1n1 hasn't been updated
<marcan>
don't worry, that's coming soon
<marcan>
my priorities right now are v4 first, then that
<marcan>
the kernel release schedule has hard deadlines and missing them means months of wait until the next version, so I really want to make sure we make 5.13
<bkero>
Sounds like your priorities are right :)
prabinspkt has joined #asahi
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
bbolli has quit [Ping timeout: 265 seconds]
Necrosporus has joined #asahi
mxw39 has quit [Read error: Connection reset by peer]
mxw39 has joined #asahi
mxw39 has quit [Client Quit]
mxw39 has joined #asahi
<amw>
marcan: Ok - great. Happy to wait, good to get a status update, I can work from Sven's branch
prabinspkt has quit [Quit: Connection closed for inactivity]
marcan has quit [Quit: Now where's my screwdriver...]
marcan has joined #asahi
eichin has quit [Read error: Connection reset by peer]
eric_engestrom has quit [Ping timeout: 240 seconds]
HeN has quit [Ping timeout: 248 seconds]
jkkm has quit [Read error: Connection reset by peer]
eric_engestrom has joined #asahi
eichin has joined #asahi
jkkm has joined #asahi
HeN has joined #asahi
VinDuv has quit [Quit: Leaving.]
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 252 seconds]
<sven>
yeah, there's no rush. people who can make good use of the usb serial code right now can just use my wip branches
<sven>
i'd rather have the code i wrote properly reviewed and tested than quickly merged
JusticeEX has quit [Ping timeout: 252 seconds]
alvaro_fe has quit [Ping timeout: 245 seconds]
goldenkrew3000 has joined #asahi
Namidairo_ has quit [Read error: Connection reset by peer]
Namidairo has joined #asahi
shenki has quit [Ping timeout: 258 seconds]
shenki has joined #asahi
vimal has quit [Ping timeout: 276 seconds]
furkan has quit [Ping timeout: 260 seconds]
raster has joined #asahi
klaus has joined #asahi
vimal has joined #asahi
ephe_meral2 has joined #asahi
jaXvi has joined #asahi
goldenkrew3000 has quit [Ping timeout: 252 seconds]
<arnd>
marcan: do you think there are any show-stoppers left? Final consensus on the "non-posted" property is the only thing I still see as necessary, not sure where we actually are on that, or if there are any other issues. Once there are only minor style issues left, I would like to just merge a branch in to my for-next tree and let you follow up with patches on top of that
<marcan>
arnd: I think we're pretty much there, I just sent the last feedback email on v4
<marcan>
er, on v3 (for v4)
<arnd>
ok, good
roxfan2 is now known as roxfan
<arnd>
I think gregkh already merged the serial driver patches into his tree, not sure if that is a problem for having everything in one branch
<marcan>
I think the nonposted stuff is also pretty much OK, robher just needs to review my final, simpler version
<marcan>
but I think we agree on the approach
<marcan>
yeah, I noticed that... before they were finally reviewed too, not sure if that will be a problem now since those changed
<marcan>
I was hoping he would just review them, not merge them
<arnd>
note that gregkh doesn't remove stuff from his branch, so it's now part of the git history, though he could revert the patches if necessary
<marcan>
in that case the changes I have queued for v4 should go in fixup patches I guess
<marcan>
I'm honestly a bit confused as to how the pipeline with gregkh and krzysztof works here :)
<arnd>
what we could do in theory is to have your branch based on the serial git, or a merge of that into another branch. I'd probably reserve a top-level branch in the soc tree for m1, so that this time we have "arm/dt", "arm/defconfig", "arm/drivers", "arm/soc" and "arm/m1" branches, and after 5.13 you split the patches into dt, defconfig, drivers, etc as everyone else
<marcan>
yeah, that was my thinking, I can rebase on top of a common point like that
<arnd>
the usual procedure for the serial drivers is that gregkh would wait for an Acked-by or Reviewed-by tag from krzk and then apply the patches directly. There is rarely the need for gregkh to require a pull request from a driver maintainer
<arnd>
marcan: cmarinas mentioned that he also has picked up maz' patches for GENERIC_IRQ_MULTI_HANDLER into the arm64 tree (I don't know what patches those are, but I assume you do), so you'll want to merge that branch and the serial driver on top of -rc3, and then rebased the rest on top of that
<marcan>
yeah
<marcan>
let me see what gregkh actually merged
<arnd>
I hope there are not too many additional branches you depend on
<marcan>
krzysztof reviewed everything but had a couple caveats, but I think they only related to a spurious whitespace change and commit messages; nothing is actionable there any more if they already got merged
<marcan>
in which case what's left is andy's feedback being too late
<marcan>
only annoying thing now is I already squashed all of that in :-)
<marcan>
but I can re-diff and split
<marcan>
yeah, they got merged verbatim, just with Krzysztof's tags
<marcan>
I'm guessing this was largely automated then, after he sent those tags even though there were a couple nits left
<arnd>
marcan: if nothing of the additional feedback is required for correct operation of the driver, I'd suggest you keep those fixups separate from the rest of the series and just send them to gregkh as cleanups
<marcan>
yeah, let me double check but I think they are NFC
<marcan>
should I just drop them from the series then, as they already got independently merged?
<marcan>
(I mean the originals)
<marcan>
so the base should just be arm64-fiq-20210315 (which is based off of v5.12-rc3), with tty-next merged on top
<marcan>
the GENERIC_IRQ_MULTI_HANDLER is in -rc3, that tag contains the rest of the fiq support series, tty-next pulls in the samsung changes that gregkh already merged, and then everything else goes on top
vijfhoek has quit [Quit: Quit Message]
furkan has joined #asahi
<arnd>
marcan: I would start out with -rc3, and then "git pull --no-ff" the other branches into that one at a time, with a merge changeset describing why you need then.
<arnd>
Let me check out tty-next to see if there is a sensible way of having a subset of that
<marcan>
arm64-fiq-20210315 is already that, so I can start with it
<marcan>
oh, --no-ff, sure
vijfhoek has joined #asahi
vijfhoek has quit [Client Quit]
<arnd>
marcan: tty-next seems to have a backmerge of -rc3 into that, with the previous patches based on -rc2
<arnd>
I'd prefer not to have the same backmerge of in my tree (it messes up the history), so maybe either merge in 71b25f4df984 (the last commit for the samsung serial driver) or 3d82be8be6fd (the last commit before the backmerge) instead of the entire tty-next
<marcan>
works for me
<marcan>
I just broke out the v4 changes into a separate branch, so that can go in later, nothing critical there
<marcan>
the serial ones I mean
<marcan>
bleh, 71b25f4df984 does not merge cleanly into -rc3
<marcan>
arnd: maybe I should just cherry-pick the relevant patches?
<arnd>
no, cherry-picking makes it worse because then torvalds has to resolve that merge again
<marcan>
I thought git would just skip identical patches like that
<arnd>
it doesn't consider them identical if they have different commit IDs and there was a merge conflict in the old version
<arnd>
it might still work
<marcan>
the conflict is in an unrelated driver
<arnd>
what I'd suggest is to merge 71b25f4df984 into your branch and resolve the conflict the same way that gregkh did in his tree. Then try to merge tty-next on top of that. If that is a clean merge, it should be fine, otherwise I can see if I have a better idea
ephe_meral2 has quit [Ping timeout: 240 seconds]
<marcan>
sounds reasonable
vijfhoek has joined #asahi
goldenkrew3000 has joined #asahi
ephe_meral2 has joined #asahi
<marcan>
yeah, that worked
goldenkrew3000 has quit [Remote host closed the connection]
chatcat has joined #asahi
furkan has quit [Ping timeout: 246 seconds]
<marcan>
maz: wait, how did the guest masking ever work? AFAICT the aic FIQ mask code in v3 is completely broken :D
<marcan>
I forgot to subtract out the AIC IRQ offset from the hwirq number, so nothing ever gets masked/unmasked
ephe_meral2 has quit [Remote host closed the connection]
<arnd>
eta: rerere only remembers the changes you did yourself, it doesn't get put in the history
awordnot has quit [Ping timeout: 248 seconds]
manawyrm has joined #asahi
hir0 has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
VinDuv has joined #asahi
arcsor5 has joined #asahi
ephe_meral1 has quit [Ping timeout: 252 seconds]
<maz>
marcan: interesting. it just means that the timers are always disabled, and that we are just opportunistically injecting virtual interrupts into the guest as a best effort measure. given what little guest code gets run at the moment, it isn't surprising we didn't notice that.
<maz>
I can rebase my stuff on top and give it a go.
<marcan>
arnd: feel free to take a look too, maybe this is the good one :)
<marcan>
AIC ended up getting another pile of cleanup, mostly unifying irq_data accesses
<marcan>
I also threw in allowing edge-triggering for IRQs, since it seems MSIs work like that after all
<marcan>
though it's all automagic, so it just allows either mode
<maz>
they have probably baked the trigger mode at synth time.
<maz>
saves gates.
<marcan>
likely
<marcan>
basically they behave as level IRQs that go high on the event, and low after the AIC event register is read
<maz>
marcan: that's consistent with the edge being consumed by Ack, which is what I'd expect.
<marcan>
yeah
<marcan>
so basically they have some flops to latch the edge that get cleared on ack, and its output is presented as the level state
<marcan>
this is useful because it means we can still do software IRQ priorities on edge-triggered IRQs (e.g. poll all or a subset of IRQ states in a different order, bypassing the internal logic; this might make sense if we want to desperately prioritize, say, a couple IRQs for some reason)
<marcan>
could also be done by playing with masks I guess
<marcan>
nothing beautiful but possible on paper if needed
<maz>
indeed. or allocate the interrupts in the order that satisfies the required priority.
<marcan>
well, we don't get to allocate
<marcan>
I mean for non-MSI stuff
<maz>
for MSIs, you do.
<maz>
for non-MSI, I'm not sure they have the flop.
<maz>
they shouldn't need it.
<marcan>
they don't, but if they're level-triggered the logic still works
<chatcat>
is there some way to dump the EEPROM(s) on the board with software only?
<marcan>
maz: does the kernel run at EL1 in CONFIG_VHE=n mode? if so, it won't work with the current AIC anyway
<marcan>
I need to fix that for EL1 mode (I will a bit later, don't want that to block this series)
<marcan>
chatcat: which ones?
<marcan>
there's a spinor but I don't want to go near that unless we have to, because it's a brick risk. there's also the PD controller flash which is similarly fairly critical
<chatcat>
marcan: there is usually some 64 MB winbond and apparently another macronix (not sure about this) on the macbook air m1 and the mini
<marcan>
yeah there would be the two I mentioned at least
<chatcat>
which one is the pd controller?
<chatcat>
flash
<marcan>
it should be the smaller one, that's not 64MB
<chatcat>
how do you know it used for that?
<marcan>
there is definitely *some* flash used for that
<chatcat>
how do you know?
<chatcat>
is the firmware for those eeproms actually part of upgrades, i.e. can you get it from somewhere else?
<chatcat>
and will it be erased/resored during a dfu upgrade?
<marcan>
it is, but the firmware is just patches for the internal ROM; I don't know what happens if you wipe it, I don't know if DFU itself can work off of the internal ROM only
<marcan>
it's entirely possible it can't
<chatcat>
so the dfu does not run from the m1 itself?
<marcan>
it does
<marcan>
but it's USB, it has to go through the PD/mux chips
<marcan>
so if those are too broken to make DFU work, then it won't
<marcan>
I don't think DFU would erase that firmware, I would expect it to upgrade it to the latest version though
<chatcat>
i did not yet take a close look at all other similar devices like ipad, iphone which are kinda similar to the ARM Macs but iirc there were not eeproms
<marcan>
they definitely have eeproms
<marcan>
the ipads in particular use similar PD chips I believe
<chatcat>
thx what board is this? some way to physically dump the chips would also be nice (though not related to asahi directly) , you could restore it and take a closer look what is in there, there are some testpoints on the board but the air m1 is a bit ... crowded, not sure about some useful testpoints for the mini
<marcan>
you used to be able to read/write the flash directly from the host, but I got the impression that now they're doing some unlock/signing stuff
<marcan>
not sure though, there may be a working read command
<marcan>
either way we pretty much know what's there, for the PD controller it's tricky to make sense of since it's just function hooks, not the entire firmware
<marcan>
the big 64M flash should be easily dumpable once we have spi working, but I'm not going to be instantiating that driver in default device trees for safety
<svenpeter>
At least the “normal” Read flash commands form the TI data sheet don’t work fwiw
<arnd>
marcan: a few formal details:
<arnd>
- for the merge commits, please add a little more detail on why it gets merged in the changelog. I would also add a Signed-off-by for the merge, though that is not strictly required
<arnd>
- When you add Reviewed-by or similar tags, please keep your own Signed-off-by as the last tag in the list
<arnd>
- finally, I see the irqchip driver is still missing an Ack from the irqchip maintainers. I don't know if you already point this out in the cover letter, otherwise please add it
<arnd>
I'd hope to get a Reviewed-by from maz, plus an Acked-by from tglx for merging it through the soc tree instead of the tip/irqchip tree
<arnd>
Once you have those, I can pull it into the soc tree for linux-next, and whatever comes up later can be add-on patches
<marcan>
arnd: yeah, I'm hoping for a quick v4 on the mailing list to get the remaining acks
<marcan>
thanks for the notes, I'll update it tomorrow and probably send v4 :)
<arnd>
I can also give some Reviewed-by replies for the patches I have looked at in detail, though they are not that meaningful if I'm also the one to merge the patches
<marcan>
oh yeah, I guess I can drop gregkh from v4 cc, right?
awordnot has joined #asahi
choozy has joined #asahi
odmir has quit []
<arnd>
right
Izumoo has joined #asahi
Izumoo_ has quit [Ping timeout: 258 seconds]
odmir has joined #asahi
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
raster has quit [Quit: Gettin' stinky!]
odmir has quit [Ping timeout: 240 seconds]
devinvs[m] has joined #asahi
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raster has joined #asahi
odmir has joined #asahi
arcsor5 has joined #asahi
JusticeEX has joined #asahi
Izumoo has quit [Quit: Konversation terminated!]
odmir has quit [Ping timeout: 260 seconds]
VinDuv has quit [Quit: Leaving.]
zkrx has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
macc24 has quit [Ping timeout: 252 seconds]
raster has quit [Quit: Gettin' stinky!]
macc24 has joined #asahi
zkrx has joined #asahi
chatcat has quit [Ping timeout: 240 seconds]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]