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
Fanfwe has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Fanfwe has joined #asahi
PeterEaston has quit [Ping timeout: 240 seconds]
PeterEaston has joined #asahi
Guest89357 is now known as jordan_
tsujp has joined #asahi
<tsujp>
Is there word on how package management etc with Asahi is going to work?
<tsujp>
Custom distro or eventually "based" on something?
<maz>
marcan: for these two VHE-specific issues, let's keep the discussion separate for now. It is likely that they would directly go into the arm64 tree anyway.
<maz>
marcan: feel free to keep one of the early patches around for context.
<marcan>
maz: since I have a weirdo merge base branch to make this all work anyway, I'll keep them there and won't submit them
<marcan>
they are not a dependency for arnd's merge anyway
<marcan>
the only hard dependency is the FIQ series, and the samsung stuff only if people care about transiently non-validating devicetrees depending on merge order
<marcan>
tsujp: the "official" distro will be Arch linux ARM + add-on repo and installer
<marcan>
but the goal of the project is to have the installer set up a useful boot environment for any distro to work, and to upstream things so other distros will work too
<marcan>
we're just basing our "bleeding edge/early adopter" style distro on ALARM
<kettenis1>
we need to have (somewhat) stable devicetree bindings before I can upstream that though
<kettenis1>
what I'm currently using is mostly a straight copy from corellium
<kettenis1>
with some adjustments to follow the binding in marcan's linux upstream patch series
furkan has joined #asahi
krispy has joined #asahi
krispy has quit [Client Quit]
tsujp has quit [Read error: Connection reset by peer]
tsujp has joined #asahi
<arnd>
maz, kettenis1: based on my understanding of how MSI works on this chip, I think modeling the AIC as the MSI target is both the easiest and the closest to what the hardware actually does
choozy has joined #asahi
jeffmiw has joined #asahi
<maz>
arnd: if the MSI doorbell was translated, I'd agree with you. but that's not how the HW seems to behave.
<maz>
it really looks like the doorbell is upstream of the IOMMU.
bisko has joined #asahi
jeffmiw has quit [Ping timeout: 240 seconds]
<arnd>
maz: it would be really nice to just use the generic pci controller though. What code does the mapping of the msi doorbell? If that's in the msi-controller driver, it shouldn't really matter whether that goes through the iommu or is passed through
<arnd>
In ADT, the "msi-parent-controller" property does point at the AIC, but of course that doesn't have to mean anything ;-)
<arnd>
maz: the part I don't understand so far is whether the assignment of specific MSI ranges in ADT is enforced by the hardware, or if that's just done to split up the available numbers evenly
<arnd>
i.e. if every pci host bridge has the same 32 MSIs at doorbell address 0x00f0ffff00000000, but they are routed to different AIC interrupts, then modeling them as separate irqchips as you say is probably better
Necrosporus has joined #asahi
<arnd>
but if any device can trigger any of the available global MSIs, it makes sense to conceptually have them handled by the aic driver
_rjeffman has quit [Remote host closed the connection]
<maz>
arnd: it looks like the 32 MSIs are global.
<maz>
arnd: as for using the generic PCI MSI controller, that's almost what I have (just a shim to allocate the various IRQ bits).
<maz>
but the non-translated doorbell is what gives me a strong indication that this all lives in the RC, and not in the AIC.
rjeffman has joined #asahi
<arnd>
maz: are you sure it's non-translated rather than a hardwired passthrough in the dart?
<arnd>
it's always the upper page, after then end of the vm-base/vm-size window in the dart
<arnd>
hmm, the interrupt numbers disagree between corellium and adt
<arnd>
in corellium's dt, it's always 32 MSIs starting at AIC interrupt 704, while in ADT, they are at AIC interrupt 704-735, 738-769 and 818-849, respectively
<arnd>
nevermind, I misread the corellium patches, it's always three distinct ranges
<maz>
corellium splits the MSI space for each controller in 3, though I'm not sure that's actually enforced by the HW.
<arnd>
in ADT, this is only done for one of the PCI controllers (apice), where each bridge gets eight MSIs, while the other two have a single bridge with 32 MSIs
<arnd>
I would also guess this is not enforced by the hardware
<maz>
the first one is odd, because they leave 8 MSIs on the table...
<kettenis1>
there are 32 MSIs for each PCIe bridge
<kettenis1>
Each PCIe bridge has multiple (3?) ports
<kettenis1>
there are registers in the PCIe bridge block that can be used to distribute the MSIs over the ports
<kettenis1>
Apple (and Corellium) give each port 8 MSIs and leave 8 MSIs on the table
<kettenis1>
For OpenBSD my aplpcie(4) driver simply shares the 32 MSIs among all 3 ports
<kettenis1>
so yes, the splitting is enforced by the hardware, but the way the splitting is done is programmable
<maz>
that's what I do too. I don't see a need for extra slicing.
<arnd>
kettenis1: the first PCIe port is hardwired to three on-board devices, right? Can any of those actually use more than eight MSIs?
<kettenis1>
There are three PCIe bridges
<kettenis1>
One is used for the onboard stuff and two are used for Thunderbolt
<kettenis1>
The one that is used for onboard stuff has 3 ports
<arnd>
sorry, I meant the first host bridge has three ports that are each wired to one on-board device
<kettenis1>
WiFi+BT is on one of the ports, Ethernet is on its own port and XHCI is on itw own port as well
<kettenis1>
so yes ;)
<arnd>
but what is the maximum number of MSIs that any of these three would want to use?
<kettenis1>
I beleive all three devices support MSI-X
<kettenis1>
I don't know if Linux makes use of multiple vectors for these devices though
<arnd>
this is xhci: xhci->msix_count = min(num_online_cpus() + 1, HCS_MAX_INTRS(xhci->hcs_params1))
<arnd>
so we'd prefer to have nine MSIs if supported by that xhci implementation
<kettenis1>
oh, wifi doesn't support msi-x
<arnd>
what are the device/vendor IDs on the wifi and ethernet chips?
<kettenis1>
That is ethernet, which is Broadcom BCM57762
<kettenis1>
I thing the Linux name for the Ethernet driver is tigon3
<arnd>
thanks
<kettenis1>
think even
<kettenis1>
anyway, I think the OS needs to program the registers that control how you split up the MSIs
<kettenis1>
so I think the generic driver won't be sufficient
<maz>
kettenis1: how are things configured in u-boot at the moment?
<kettenis1>
U-Boot doesn't touch the MSI-related registers
<arnd>
tg3 apparently supports up to four queues and one management interrupt in MSI-X mode, so at most five interrupts according to the current driver source
<maz>
kettenis1: are these registerse "documented" anywhere?
<arnd>
on my x86 machine, I see that none of the XHCI actually enables MSI-X, it's just one interrupt per instance
<arnd>
but the driver can clearly do it
<maz>
arnd: I think XHCI prefers MSI over MSI-X, for bizare reasons. I remember hacking it to test things on Chello.
odmir has quit [Remote host closed the connection]
<marcan>
arnd: it can't be passed through, because they use the same address for all controllers, yet they allocate different MSI ranges
<marcan>
so the hardware is most likely an address compare in the PCIe root port that then sends discrete edge-triggered IRQ signals out to AIC
<sven>
[ 0.147318] tps6598x 0-0038: probe start
<sven>
[ 0.892476] tps6598x 0-0038: probe done
<sven>
that's... slow
<sven>
but at least it works, heh
<kettenis1>
marcan: the address can be configured on a per-port basis
<marcan>
kettenis1: but apple always sets them to the same address
<marcan>
and yet the MSIs do not overlap
<marcan>
which implies the decoding is done at the ports, not by AIC
<kettenis1>
but the register for that is in the per-port register block so the comparison logic almost certainly lives there too
<marcan>
yes
tsujp has joined #asahi
<marcan>
so clearly AIC isn't doing the MSI handling here, it just takes a pile of discrete IRQ lines (or some other out of band signaling mechanism) from the ports
<marcan>
IIRC from last time I had to model this kind of nonsense (MSIs on PS4...), the sane way to do this is with another irqchip driver
<marcan>
it would be something very simple that binds to the port registers too, and chains IRQs to AIC
winocm has quit [Ping timeout: 245 seconds]
winocm has joined #asahi
ephe_meral has quit [Ping timeout: 260 seconds]
ephe_meral has joined #asahi
odmir has joined #asahi
maor26 has joined #asahi
choozy has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
bdju has quit [Read error: Connection reset by peer]
bdju has joined #asahi
<sven>
ugh.. this usb yak is getting bigger and bigger. looks like the tps6598x gets its interrupt from some gpio block
bdju has quit [Read error: Connection reset by peer]
bdju has joined #asahi
PeterEaston is now known as TheJollyRoger
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
VinDuv has joined #asahi
ephe_meral has quit [Ping timeout: 268 seconds]
tsujp has quit [Quit: Iridium IRC Client]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 268 seconds]
milek7 has quit [Quit: No Ping reply in 180 seconds.]
milek7 has joined #asahi
odmir has joined #asahi
wicast has joined #asahi
wicast has quit [Read error: Connection reset by peer]
wicast has joined #asahi
wicast has quit [Client Quit]
odmir has quit [Ping timeout: 240 seconds]
milek7 has quit [Quit: No Ping reply in 180 seconds.]
milek7 has joined #asahi
milek7 has quit [Client Quit]
milek7 has joined #asahi
odmir has joined #asahi
_rjeffman has joined #asahi
rjeffman has quit [Remote host closed the connection]
odmir has quit [Ping timeout: 260 seconds]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
richbridger has joined #asahi
VinDuv has quit [Quit: Leaving.]
odmir has joined #asahi
DarkShadow44 has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]