go back to using dma_alloc_coherent() for firmware scratch memory.

Kalle Valo kvalo at qca.qualcomm.com
Wed May 31 04:15:00 PDT 2017

Adrian Chadd <adrian at freebsd.org> wrote:

> This reverts commit b057886524be ("ath10k: do not use coherent memory for
> allocated device memory chunks") in 2015 which converted this allocation from
> dma_map_coherent() to kzalloc() / dma_map_single().
> The current problem manifests when using later model NICs with larger
> (>700KiB) scratch spaces in memory.  Although the kzalloc call
> succeeds, the software IOMMU TLB code (via dma_map_single()) panics
> because it can't find 700KiB of linear physmem bounce buffers for DMA.
> Now, this is a bit of a silly failure mode for the dma map API,
> but it's what we currently have to play with.
> In these cases, doing kzalloc() works fine, but the dma_map_single()
> call fails.
> After chatting with Linus briefly about this, it indeed should be
> using dma_alloc_coherent() for doing larger device memory allocation
> that requires some kind of physical address mapping.
> You're not supposed to be using kzalloc and dma_map_* calls for
> large memory regions, and I'm guessing not for long-held mappings
> either.  Typically dma mappings should be temporary for DMA,
> not long held like these.
> Now, since hopefully the major annoying underlying problem has also been
> addressed (ie, ath10k is no longer tears down all of these allocations
> and reallocates them every time the vdevs are brought down) fragmentation
> should stop being such a touchy issue.  If it is though, using
> dma_alloc_coherent() use gets us access to the CMB APIs too relatively
> easily and ideally we would be allocating memory early in boot for
> exactly these reasons.
> Signed-off-by: Adrian Chadd <adrian at FreeBSD.org>
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

Patch applied to ath-next branch of ath.git, thanks.

79e68821582d ath10k: go back to using dma_alloc_coherent() for firmware scratch memory



More information about the ath10k mailing list