00:03Mis012[m]: doesn't Linux still use a special pcie driver on x86 instead of the generic one... though I supposed that's Linux's fault
00:03Mis012[m]: *suppose
00:06Mis012[m]: Ampere could probably make their CPU cores support nGnRnE non-device memory if they thought that was a good idea
00:14Mis012[m]: this is not necessarily even pcie specific, unless you suggest they make pcie accesses to VRAM cache coherent? :P
00:22HdkR: Mis012[m]: AmpereOne fixed the issue as far as I'm aware. It's just Altra that has the issue
00:23Mis012[m]: well, the "fix" would probably be to allow specifying nGnRnR on normal memory, which is not a thing in arm's spec
00:24Mis012[m]: I suppose allowing unaligned access tp device memory is not the worst option though
00:25Mis012[m]: iirc that is allowed by the spec, just that we will never get everyone to do it
00:25HdkR: Which is what Tegra supports as far as I can tell
00:31Mis012[m]: doesn't Tegra also use pci glue for the iGPU for some unclear to me reason? could be related to that more than expecting anyone to use an external one
00:31HdkR: iGPU up until Orin is at least connected to something called Host1x
00:32HdkR: Grace and GB10 use NVLink instead
00:32HdkR: I wouldn't be surprised if Thor this summer uses NVLink as well
00:33HdkR: NVIDIA sort of expects people to connect GPUs to the bus of these things, so it makes sense to support all the features :D
00:35Mis012[m]: the sad part about the new things is that they seem to use ACPI, but I guess it makes sense since they love out-of-tree drivers too
00:36Mis012[m]: and it's probably just sane enough that nobody will feel the need to make it work with dt
00:37HdkR: Thank goodness, I hate fussing with DT files
00:38HdkR: Going to need to mess with the DT of this Orin board to see if I can get 16GB+ of BAR2 space
00:40Mis012[m]: dtbs are supposed to be shipped with the system, it's just that hw that has dt support usually doesn't care about running mainline Linux
00:42Mis012[m]: if this was x86, Linux would bend over backwards to support whatever the board ships, on arm if the stock fw is unusable the user is expected to use the dtb built alongside Linux
00:43Mis012[m]: HdkR: I assume messing with ACPI to change BAR size would be much more painful...?
00:45HdkR: Well Orin doesn't use ACPI and I don't have Grace (yet), and GB10/Thor isn't available yet :D
00:46Mis012[m]: from my experience messing with ACPI is a lot more pain than messing with dt
00:47Mis012[m]: but I guess the typical way to do it is to just add hacks in the kernel because we need to keep the facade of "just works"
00:47HdkR: Doesn't help that Snapdragon ACPI is effectively Windows only. So those implementations should be ignored anyway
00:48Mis012[m]: well, it does help, otherwise they might seriously consider actually supporting it :P
00:49Mis012[m]: again, if that was x86 I bet they would try
00:49HdkR: Not wrong there
00:50Mis012[m]: ACPI doesn't offer anything to Linux, it's Windows that can't do it's own power management and doesn't know what a clock is
00:54Mis012[m]: the ACPI alternative to fixed-clock is literally "hardcode it in the driver"
00:58HdkR: Sounds like the qcom approach to acpi as well
01:07Mis012[m]: well yes, if there is no ""standard"" way to do it (or I guess if they don't feel like using that), it's either hardcode in driver or dump a raw struct in the ACPI as hex or something like that
01:09Mis012[m]: I think on arm companies are more open to using devicetree-like properties which make ACPI quite a bit less insane, but might as well go to the logical conclusion and use dt :P
08:37glehmann: benjaminl: the real question is why do you care about the type?