[PATCH v1 09/10] pci: Add driver for Broadcom STB PCIe controller
Nicolas Saenz Julienne
nsaenzjulienne at suse.de
Tue Apr 28 13:30:40 CEST 2020
Hi Maerk,
On Tue, 2020-04-28 at 11:49 +0200, Marek Szyprowski wrote:
> Hi All,
>
> On 27.04.2020 15:54, Marek Szyprowski wrote:
> > On 27.04.2020 12:15, Nicolas Saenz Julienne wrote:
> > > On Fri, 2020-04-24 at 18:50 +0200, Sylwester Nawrocki wrote:
> > > > This patch adds basic driver for the Broadcom STB PCIe host controller.
> > > > The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
> > > > handling removed. The inbound access memory region is not currently
> > > > parsed from dma-ranges DT property and a fixed 4GB region is used.
> > > >
> > > > The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
> > > > USB Host Controller.
> > > >
> > > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne at suse.de>
> > > > Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > > > ---
> > > > Changes since RFC:
> > > > - reworked to align with current Linux mainline version and u-boot
> > > > driver
> > > > by Nicolas Saenz Julienne
> > > [...]
> > >
> > > > +
> > > > + /*
> > > > + * TODO: Use the base address and size(s) provided in the
> > > > dma-ranges
> > > > + * property.
> > > > + */
> > > > + rc_bar2_offset = 0;
> > > > + rc_bar2_size = 1ULL << 32;
> > > From experience this works fine, although it highly depends on how
> > > DMA memory is
> > > handled in u-boot.
> > >
> > > For example, in arm64 Linux, DMA memory was allocated from
> > > ZONE_DMA32, which
> > > would return memory smaller than 4GB. This was not good enough for
> > > bcm2711b0 --
> > > revision b0 of rpi4's SoC, so far the most common out there -- which
> > > has an
> > > internal wiring bug that prevents PCIe from accessing memory higher
> > > than 3GB
> > > (RPi4 might have up to 4GB). So we had to introduce a ZONE_DMA,
> > > which covers
> > > the lower GB of memory, in order to allocate suitable DMA memory for
> > > PCI and
> > > other DMA limited devices.
> > >
> > > While playing around with u-boot's xHCI I saw that all memory is
> > > allocated is
> > > located in the lower 1GB. But never got to look into why. I'm curious
> > > to know
> > > if someone knows how's that handled in u-boot. Ultimately, depending
> > > on how it
> > > works, we might be able to just disregard dma-ranges altogether.
> > >
> > > For some extra context xhci_malloc() gets its memory from memalign().
> > > And it's
> > > not clear to me how that function decides which memory to use.
> >
> > I think that memalign() allocates memory from the uboot's defined
> > SDRAM (from its end). Assuming that CONFIG_SYS_SDRAM_SIZE is set to
> > 128M in include/configs/rpi.h it should be always safe, but I will
> > check that tomorrow to be 100% sure.
Thanks for having a look at this!
> Okay, I've checked and memalign always get memory from the malloc pool,
> which is set almost at the end of the first memory bank (in runtime), so
> it is always below the first 1GiB. So this should be safe.
I see.
> It is however not safe for explicit reads (and possible other
> transactions) above 3rd GiB, see the log below:
[...]
> I think that there cannot be done much about it. u-boot doesn't have any
> true DMA-mapping layer or a way to express the current limitations. IMHO
> it is enough that it works for malloc'ed memory and everything else
> should be considered as not really supported.
I agree. And on the good side, it's very unlikeyly we'll ever have to parse
the dma-rages.
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/20200428/36ef2d8d/attachment.sig>
More information about the U-Boot
mailing list