On Wed, Oct 02, 2019 at 05:49:46PM +0200, Thierry Reding wrote: > On Wed, Oct 02, 2019 at 05:46:54PM +0200, Thierry Reding wrote: > > From: Thierry Reding <treding@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > --- > > Arnd, Rob, Robin, > > > > This is what I came up with after our discussion on this thread: > > > > [PATCH 00/11] of: dma-ranges fixes and improvements > > > > Please take a look and see if that sounds reasonable. I'm slightly > > unsure about the interconnects bindings as I used them here. According > > to the bindings there's always supposed to be a pair of interconnect > > paths, so this patch is not exactly compliant. It does work fine with > > the __of_get_dma_parent() code that Maxime introduced a couple of months > > ago and really very neatly describes the hardware. Interestingly this > > will come in handy very soon now since we're starting work on a proper > > interconnect provider (the memory controller driver is the natural fit > > for this because it has additional knobs to configure latency and > > priorities, etc.) to implement external memory frequency scaling based > > on bandwidth requests from memory clients. So this all fits together > > very nicely. But as I said, I'm not exactly sure what to add as a second > > entry in "interconnects" to make this compliant with the bindings. It definitely sounds reasonable to me :) Maxime
Attachment:
signature.asc
Description: PGP signature
