ARM: bcm2835: dt: Use 0x4 prefix for DMA bus addresses to SDRAM.
There exists a tiny MMU, configurable only by the VC (running the closed firmware), which maps from the ARM's physical addresses to bus addresses. These bus addresses determine the caching behavior in the VC's L1/L2 (note: separate from the ARM's L1/L2) according to the top 2 bits. The bits in the bus address mean: From the VideoCore processor: 0x0... L1 and L2 cache allocating and coherent 0x4... L1 non-allocating, but coherent. L2 allocating and coherent 0x8... L1 non-allocating, but coherent. L2 non-allocating, but coherent 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent From the GPU peripherals (note: all peripherals bypass the L1 cache. The ARM will see this view once through the VC MMU): 0x0... Do not use 0x4... L1 non-allocating, and incoherent. L2 allocating and coherent. 0x8... L1 non-allocating, and incoherent. L2 non-allocating, but coherent 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent The 2835 firmware always configures the MMU to turn ARM physical addresses with 0x0 top bits to 0x4, meaning present in L2 but incoherent with L1. However, any bus addresses we were generating in the kernel to be passed to a device had 0x0 bits. That would be a reserved (possibly totally incoherent) value if sent to a GPU peripheral like USB, or L1 allocating if sent to the VC (like a firmware property request). By setting dma-ranges, all of the devices below it get a dev->dma_pfn_offset, so that dma_alloc_coherent() and friends return addresses with 0x4 bits and avoid cache incoherency. This matches the behavior in the downstream 2708 kernel (see BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h). Signed-off-by: NEric Anholt <eric@anholt.net> Tested-by: NNoralf Trønnes <noralf@tronnes.org> Acked-by: NStephen Warren <swarren@wwwdotorg.org> Signed-off-by: NLee Jones <lee.jones@linaro.org>
Showing
想要评论请 注册 或 登录