DMA issues on PowerPC64

[Kalle Valo]

Jared Bents <jared.bents at rockwellcollins.com> writes:

> Some background information first.  I transitioned a build from 32 bit
> to 64 bit and discovered my wifi modules no longer work.  I am using
> fsl-v2.0-1703 on a qoriq t1042.  I sourced the problem to DMA mapping
> errors and found that it was trying to map addresses in regions not
> allowed by the kernel.
>
> ath10k_pci 0001:01:00.0: unable to get target info from device
> ath10k_pci 0001:01:00.0: could not get target info (5)
> ath10k_pci 0001:01:00.0: could not probe fw (5)
>
>
> I discovered that if I limited my memory from the actual 8GB present
> down to just 2GB with the bootarg mem=2048M, the ath10k modules
> worked.
>
> So I started poking around in ath10k/pci.c and noticed that if I ORed
> the regions specified in the memory allocations with GFP_DMA, I could
> get rid of the initial dma mapping errors.  A couple of examples are
> below.
>
> skb = __dev_alloc_skb(pipe->buf_sz, GFP_DMA | GFP_ATOMIC);
> treq = kmemdup(req, req_len, GFP_DMA | GFP_KERNEL);
>
>
> But then came across these failures which I have yet to sort out.
>
> ath10k_pci 0001:01:00.0: failed to connect htt (-5)
> ath10k_pci 0001:01:00.0: could not init core (-5)
> ath10k_pci 0001:01:00.0: could not probe fw (-5)

Do note that GFP_DMA is not supposed to be used anymore:

 * GFP_DMA exists for historical reasons and should be avoided where possible.
 *   The flags indicates that the caller requires that the lowest zone be
 *   used (ZONE_DMA or 16M on x86-64). Ideally, this would be removed but
 *   it would require careful auditing as some users really require it and
 *   others use the flag to avoid lowmem reserves in ZONE_DMA and treat the
 *   lowest zone as a type of emergency reserve.

> I am wondering if anyone else has come across this issue and solved it
> or if somehow this is just an issue on ppc64 and I am somehow the only
> one in that use case.  Unfortunately because of the qoriq t1042, I am
> on the latest kernel I can use via the latest available sdk for my
> processor which is linux kernel version 4.1.35-rt41

I don't know if this is a problem with ath10k or your arch, but I think
you should ask help from wider audience, like linux-kernel, pci or ppc
lists. Though I don't know how they will react as you are using an
out-of-tree kernel.

-- 
Kalle Valo