On Mon, Jun 8, 2020 at 8:35 PM Heinrich Schuchardt <[email protected]> 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
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
