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 > > <nsaenzjulie...@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
signature.asc
Description: This is a digitally signed message part
