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@suse.de Signed-off-by: Sylwester Nawrocki s.nawrocki@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 thedma-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