On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
With the introduction of the Raspberry Pi 4 we've found a new contender
for the use of bus DMA limits, as its PCIe bus can only address the
lower 3GB of memory (of a total of 4GB). This is impossible to represent
with a mask. To make things worse the device-tree code rounds non power
of two bus DMA limits to the next power of two, which is unacceptable in
this case.
In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
over the tree and treat it as such. Note that dev->bus_dma_limit should
contain the higher accesible DMA address.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx>
I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version. That way tomorrows
linux-next run should still pick it up.
Actually. This doesn't apply because the dma-mapping tree doesn't
have you zone_dma_bits change. I guess we'll need to wait for the
next merge window, or maybe post rc1 if this happens to fix the
powerpc problem that Christian reported.
Hmm, there's no functional dependency though, is there? AFAICS it's
essentially just a context conflict. Is it worth simply dropping (or
postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
perhaps even cross-merging arm64/for-next/zone-dma into dma/for-next?
Robin.
