On Fri, 2020-11-20 at 07:15 +0100, Stefan Roese wrote:
Hi Bin, Hi Nicolas,
On 20.11.20 01:31, Bin Meng wrote:
+Stefan
On Fri, Nov 20, 2020 at 1:49 AM Nicolas Saenz Julienne nsaenzjulienne@suse.de wrote:
So far we've been content with passing physical addresses when configuring memory addresses into XHCI controllers, but not all platforms have buses with transparent mappings. Specifically the Raspberry Pi 4 might introduce an offset to memory accesses incoming from its PCIe port.
Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these limitations and make sure we don't break non DM users.
I believe this was already addressed by Stefan before, to support xHCI in MIPS.
I believe from taking a quick look at the code, that Nicolas not only needs to transfer between phys and virt addresses, but also needs to support different "offsets" on multiple devices. IIUTC, it's an extension to the already available support for mapped addresses (virtual != physical).
Yes, in Stefan's case virt != phys, in Raspberry Pi's 4 phys != bus. On top of that the phys<->bus translation is device specific, hence the need to introduce a dev_phys_to_bus() family of functions. Some examples of below, note that in RPi4 XHCI is provided by a VIA805 PCIe chip:
On a RPi4b, SoC version BCM2711C0 with 8GB of memory:
[0x0 0x200000000] [0x0 0x200000000] [0x200000000 0x400000000] virt address phys/cpu address PCIe bus address space space space
On a RPi4b, SoC version BCM2711C0 with 4GB of memory:
[0x0 0x100000000] [0x0 0x100000000] [0x100000000 0x200000000] virt address phys/cpu address PCIe bus address space space space
On a RPi4b, SoC version BCM2711B0 with 8GB of memory (bus can only access the lower 3GB of memory because of a SoC routing bug):
[0x0 0x200000000] [0x0 0x200000000] [0x00000000 0xC0000000] virt address phys/cpu address PCIe bus address space space space
BTW: Do we really need to support non-DM code with this new approach in this late phase of DM conversion?
Well I tried to introduce the dev parameter into the regular phys_to_bus() call, but the result was pretty ugly. More than half the callers don't have a udevice to pass. And frankly, IMO, passing NULL isn't that much better than having two distinct functions.
That said, I'm pretty new to u-boot internals, so feel free to propose a better solution. :)
Regards, Nicolas