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 <nsaenzjulie...@suse.de> > > > > Signed-off-by: Sylwester Nawrocki <s.nawro...@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
signature.asc
Description: This is a digitally signed message part