arm64: tegra: Describe interconnect paths on Tegra194
On Tegra194, all clients of the memory subsystem can generally address 40 bits of system memory. However, bit 39 has special meaning and will cause the memory controller to reorder sectors for block-linear buffer formats. This is primarily useful for graphics-related devices. Use of bit 39 must be controlled on a case-by-case basis. Buffers that are used with bit 39 set by one device may be used with bit 39 cleared by other devices. Care must be taken to allocate buffers at addresses that do not require bit 39 to be set. This is normally not an issue for system memory since there are no Tegra-based systems with enough RAM to exhaust the 39-bit physical address space. However, when a device is behind an IOMMU, such as the ARM SMMU on Tegra194, the IOMMUs input address space can cause IOVA allocations to happen in this region. This is for example the case when an operating system implements a top-down allocation policy for IO virtual addresses. To account for this, describe the path that memory accesses take through the system. Memory clients will send requests to the memory controller, which forwards bits [38:0] of the address either to the external memory controller or the SMMU, depending on the stream ID of the access. A good way to describe this is using the interconnects bindings, see: Documentation/devicetree/bindings/interconnect/interconnect.txt The standard "dma-mem" path is used to describe the path towards system memory via the memory controller. A dma-ranges property in the memory controller's device tree node limits the range of DMA addresses that the memory clients can use to bits [38:0], ensuring that bit 39 is not used. Signed-off-by: Thierry Reding <treding@nvidia.com> --- Changes in v4: - add additional entries for interconnect-names to match interconnects - add EMC as destination for interconnect paths Changes in v3: - add missing interconnect properties for VIC Changes in v2: - use memory client IDs instead of stream IDs (Mikko Perttunen) Signed-off-by: Thierry Reding <treding@nvidia.com>
Showing
Please register or sign in to comment