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
<marcan>
I want to avoid most of it by initializing in m1n1, but I think some of it will have to happen in the kernel
<marcan>
it might be possible to just hardcode this stuff in the kernel like AMD for some cases, but that loses generality (and means upstreaming, to some extent, blobs; copyright-wise I don't think register lists have an issue, but it seems a waste not to use the ones in the Apple device tree, which would be more general and avoid the distribution question entirely)
<arnd>
marcan: what do those registers do? Is this for suspend-to-ram or something else?
<marcan>
it's init stuff; right now one fairly short set is the PCIe root port configs that need to be set after a PCIe reset, and I think for *that* one we can turn it into higher-level driver logic
<marcan>
but, I want to know how to approach this if it comes up again
<kettenis_>
marcan: I don't think we can
<arnd>
I fear we have to look at each one individually.
<marcan>
suspend-to-ram will be a whole separate can of worms, but I don't want to think about that until we have most drivers working to begin with and I can start testing real power consumption
<arnd>
For PCIe init, I would hope that can be done in m1n1 before loading the OS
<kettenis_>
these are pci config space tweaks that are (presumably) model-dependent
<marcan>
it depends on what they do
<marcan>
I need to check all 3 models and compare
<marcan>
but if we need model-specifity there is probably some saner way of describing that than a blob of pokes
<marcan>
arnd: apparently these need to be applied after PCIe reset, so doing it in m1n1 means the kernel isn't allowed to do a reset
<marcan>
kettenis_: right?
<kettenis_>
right
<arnd>
marcan: can you read back the registers from config space during boot and remember the current values?
<marcan>
that might work
<kettenis_>
sure, but how do you tell which registers are affected?
<marcan>
if it's always the same stuff...
<marcan>
I mean e.g. it was mostly turning some features off and the link speed stuff, right?
<marcan>
that all didn't seem terribly hard to understand
<kettenis_>
yes, but in my opinion building logic in the OS driver (and duplicating it in various OSes and U-Boot) isn't sane
<arnd>
marcan: have you checked if the registers match up with one of the common PCIe implementations (dwc, cadence, mobiveil, ...)?
<arnd>
maybe we already have code that understands them
<marcan>
bbiab, got a pizza waiting :)
<marcan>
but yeah, I'm not trying to come up with the answer to this case so much as get an idea for what the right direction for the DT is if we wind up having to pass this kind of stuff after all
<sven>
fwiw, i suspect that usb will also need quite a few tunables to get usb3 working. some of them for the PHY but i believe there are also quite some in the drd node
<kettenis_>
it doesn't match up with anything I'm familliar with
<sven>
but i'll have to take a closer look at those and see if they are known registers
<marcan>
yeah, if stuff is applied during mode switching there's no way around that one
<marcan>
also, I expect dragons in the TB stuff
<marcan>
there's no way TB can't have dragons
<marcan>
and that's all hotplug so it complicates things
<Necrosporus>
dragons?
<marcan>
as in here be dragons
<arnd>
marcan: I looked at the known PCIe controllers but see no particular resemblance. Even if it's one of the ones we already support, it's likely that the tuning registers are Apple's add-on
<arnd>
most of the registers looks like they could be abstracted into a phy driver to keep them out of the base PCIe code, but that doesn't really help the question of how that driver knows the correct values
marvin24 has quit [Ping timeout: 276 seconds]
<kettenis_>
arndb: so most of the various pcie-related tunables can be applied by m1n1 and "stick" even if you then disable/enable clock gating or reset the PHY
<kettenis_>
those can be applied in m1n1
<kettenis_>
but the config space ones I listed on the wiki page that marcan quoted require significant more bringup of the PCIe controller and don't survive a PERST
<kettenis_>
not sure if Linux ever wants to do a PERST
<kettenis_>
but if m1n1 takes stuff out of PERST, U-boot and/or the OS need to be careful about doing it again
marvin24 has joined #asahi
<arnd>
kettenis_: looking through a few Linux drivers that trigger a PERST, I see that most of them do it only during the initial probe, though the Mediatek driver also does it when resuming from suspend
<arnd>
I don't think there is any generic way to trigger a PERST from outside the host controller driver
<kettenis_>
ok, so maybe we don't need to pass this information through to Linux
<kettenis_>
as long as m1n1 or u-boot applies these fixups that is
<kettenis_>
for u-boot we'd still need to pass the information in the device tree
<arnd>
kettenis_: what is the tradeoff for having the PCIe init code in m1n1 vs u-boot?
<arnd>
If it's in m1n1, u-boot wouldn't care about the registers either, right?
<kettenis_>
right
<kettenis_>
there is quite a bit complexity, and I've already implemented that for u-boot
<kettenis_>
needs some gpio, pinctrl and mailbox stuff
<kettenis_>
maybe it is possible to bring the RC ports out of reset and let u-boot take care of the more complicated stuff
<kettenis_>
out of reset in m1n1 I mean
<arnd>
bus scanning and resource assignment probably makes sense to keep in u-boot, since that is complicated and u-boot has platform independent code for it
<kettenis_>
right
<arnd>
unless m1n1 wants to support booting from a PCIe attached device (network, usb storage, ...) itself
<arnd>
not sure what marcan's long-term plan is for the scope of what to support in m1n1
<kettenis_>
sven already wrote the code for dwc3 usb support for m1n1
<kettenis_>
that is for the type-C ports
<kettenis_>
full pcie support would bring support for the type-A ports and Ethernet
<kettenis_>
but that is only present on the mini, not on the laptops
<sven>
my code is only device-mode fwiw. it emulates a cdc acm serial device
<sven>
but usb host mode is just xhci
<sven>
(and a slightly different magic phy init sequence)
odmir has joined #asahi
<sven>
not sure what marcan's plans are but bringing in a full pcie + usb ethernet to m1n1 feels just a little bit overkill to me ;)
<sven>
u-boot already supports those with your patches, doesn't it?
<kettenis_>
haven't tested usb ethernet myself, but that must be what maz is using to netboot ;)
<sven>
nice :)
HannaM has joined #asahi
<kettenis_>
I think marcan's plans include nvme support to access some of the firmware blobs
<maz>
kettenis_: yeah, some bog-standard ASIX adapter.
frode_0xa has quit [Quit: leaving]
<sven>
that makes sense
frode_0xa has joined #asahi
<kettenis_>
but that doesn't need pcie
<arnd>
I think u-boot has a port of the Linux USB network drivers, so it can support a lot of hardware
<kettenis_>
so I think pcie support in m1n1 would be fairly low priority
frode_0xa has quit [Client Quit]
odmir has quit [Ping timeout: 260 seconds]
<arnd>
The main use that I could see would be USB keyboard and mass storage support on the Type A ports
frode_0xa has joined #asahi
jeffmiw_ has joined #asahi
<sven>
true. and if we wanted those we could first add support for those on the type c ports which doesn't require pcie bringup and then later just re-use that code.
jeffmiw_ has quit [Ping timeout: 260 seconds]
frode_0xa has quit [Quit: leaving]
frode_0xa has joined #asahi
Stary has joined #asahi
Stary has quit [Changing host]
<robher>
arnd, marcan: Looks like designware controller to me.
<robher>
Those are only Tegra194 specific registers because we don't have a second user, but 0x8xx registers are DWC port logic registers. One of the extended cap registers lines up with what we used to hard code (I got rid of all the hardcoded offsets recently).
<arnd>
robher: ah, nice. I had not looked in the soc specific dwc files, so I missed that
<kettenis_>
well spotted
<kettenis_>
GEN3_RELATED_OFF_RATE_SHADOW_SEL_MASK
<kettenis_>
the tunables that mess around with that have "shadow" in their name
<robher>
If there's enough memory space for ECAM, then put all the PCIe setup in bootloader. Unless you want power management...
<kettenis_>
robher: looks like there is enough ECAM space
<robher>
'shadow' may refer to the port logic registers having writable versions of PCI config registers.
<robher>
...of read-only PCI config registers, that is.
<kettenis_>
robher: what is the policy for documenting devicetree that the Linux kernel wouldn't care about but that we need to pass information from m1n1 to u-boot?
odmir has joined #asahi
<robher>
kettenis_: bindings should be documented. Who is the consumer should be mostly irrelevant.
<robher>
kettenis_: To look at it another way, for every node in a dts there should be a schema covering it and all the properties. At least that's the goal of where we want to get to with schemas.
<marcan>
arnd, sven, kettenis_: with u-boot I see no reason to put pcie init in m1n1, at least not in the core or in normal builds. having proxyclient scripts to do it anyway may make sense for experiments.
<marcan>
we don't need to pull any blobs from m1n1
<marcan>
I expect us to either do that directly in linux (with APFS support) at runtime, or copy them at install time from 1TR
<marcan>
so far only wifi needs that treatment
<maz>
I'd be surprised if tg3 didn't need some firmware too.
<marcan>
isn't that standard though?
<marcan>
the problem with wifi is only apple uses these chips
<maz>
no idea.
<marcan>
tg3 would probably run with linux-firmware stuff, I'm guessing
<kettenis_>
tg3 runs fine without firmware
<maz>
I guess something gets fed to it early on.
<maz>
or it has a ROM of some sort.
<marcan>
I should diff the wlan firmware against other broadcom stuff. wouldn't be surprised at all if it's the same silicon, just rebranded for apple, as some common part
<marcan>
and the common firmware would work sans apple features (AirDrop)
<marcan>
good find on the designware tidbit
<kettenis_>
the broadcom wifi needs a "nvram.txt" file with settings that are specefic to how the chip is integrated
<marcan>
yeah, but that one is probably not copyrightable
<marcan>
also, I can tell you from experience that using a generic one on a new device works pretty often :)
<kettenis_>
yeah, it might not fully meet the regulation for RFI, but as long as you stay away from our radio telescopes I ewon't complain
<sven>
:-)
<marcan>
radio telescopes run on ISM bands? that must *suck+
<kettenis_>
difficult to build a broadband receiver without running into the ISM bands
<marcan>
right...
<kettenis_>
and difficult to build a transmatter for those bands that doesn't spill over into the neighbouring spectrum
<marcan>
yeah, I was going to ask if it was mostly a harmonics thing
<kettenis_>
anyway, back on topic, I'm going to play a bit more with having m1n1 doing some of the RC port initialization and having u-boot do the remainder
<arnd>
The tg3 driver has code to load firmware from user space, but it's only 3 to 7 KB, and apparently many variants have that in the builtin eeprom
<arnd>
This is old hardware, the driver has (c) 2001
<sven>
looks like the ADT even tells us the topology for the gated clocks :) UART1 --> UART_P --> SIO --> SIO_BUSIF; I2C0 --> SIO --> SIO_BUSIF; etc.
<arnd>
the last time new tg3 PCI IDs were added was in 2013
PedroArajo[m] has quit [Quit: Idle for 30+ days]
HannaM has quit [Read error: Connection reset by peer]
vimal has quit [Remote host closed the connection]
vimal has joined #asahi
odmir has quit [Remote host closed the connection]
VinDuv has joined #asahi
amonakov has left #asahi [#asahi]
marvin24 has quit [Ping timeout: 245 seconds]
marvin24 has joined #asahi
wicast has quit [Ping timeout: 260 seconds]
wicast has joined #asahi
ephe_meral1 has quit [Ping timeout: 260 seconds]
choozy has joined #asahi
Bublik_ has joined #asahi
Bublik has quit [Ping timeout: 240 seconds]
VinDuv has quit [Quit: Leaving.]
raster has quit [Quit: Gettin' stinky!]
rjeffman has quit [Ping timeout: 260 seconds]
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Ping timeout: 246 seconds]
raster has joined #asahi
raster has quit [Quit: Gettin' stinky!]
riker77 has quit [Quit: Quitting IRC - gone for good...]