On Mon, Jun 8, 2020 at 8:35 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On my MacchitoBin the GPU card was not usable because the memory window was too small to create the required BARs. Changing the window size and location solved the problem, commit d3446b266a8c ("arm64: dts: marvell: mcbin: enlarge PCI memory window").
The problem with the current way in qhich PCI devices are declared is that they do not indicate requirements and capabilities and let the software figure out a good mapping. But instead fixed mappings are hard-coded into the device-tree.
There are historically two different approaches for dealing with the translation windows: On machines that run a proper firmware, you would typically have the firmware set up the mappings to whatever makes sense, and the ranges communicate what they are to the kernel.
On 32-bit ARM machines, we often could not rely on the mappings set up by the boot loader when they were either not fit for the workload whatever the kernel needed, or just left at whatever the hardware init values were and not set up at all. As a workaround, some of the ARM32 specific PCI host drivers just read the mappings from the DT and then program the registers with that. This is definitely what we do on the Marvell EBU series (kirkwood, orion, ...) that are very flexible with the PCI mappings but don't have any good mapping that works for all users equally (e.g. you might have to pick three out of config-space, io-space, prefetchable-mem and nonprefetchable-mem, but can't have all four).
It's possible that the mcbin just ended up doing the same thing because they were used to that from the 32-bit chips, when this really should have been something that gets set up by the boot loader and put into the DT.
Arnd