[PATCH 7/8] xhci: translate virtual addresses into the bus's address space

[Nicolas Saenz Julienne]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201120/b8f371f3/attachment.sig>