On 07/19/2016 11:05 PM, Michal Kazior wrote:
On 20 July 2016 at 07:44, Adrian Chadd <[email protected]> wrote:
Hi,
dma coherent doesn't /have/ to mean "low 32 bits". It's just supposed
to mean "try really hard to use uncached memory on platforms that
support it."
Good point. Maybe it does on x86, or at least some machines.
@Ben: Can you verify if that's the case for you? Can you see what
address ranges hostmem chunks get with and without the GFP_DMA32 (and
maybe compare it against a revert to compare to dma-coherent as well)?
You just want a printk("%p", foo); for the chunks returned with and without
this flag?
The ath10k hardware (at least what I've played with thus far) is all
32 bit DMA hardware, not 64 bit, so it can't be handed 64 bit memory -
contiguous or otherwise.
So, if dma coherent on linux means 32 bit only physmem, great.
Now, it also turns out that various platforms that say they do
coherent memory these days do "mostly coherent", and you still need
some flush/sync ops..
Yeah, but since the device has it's own CPU and RAM it has to have a
way to distinguish local and host memory in some way using these 32
bits, no? (think about firmware generating local 802.11 frames vs
pushing frames coming from host driver)
Host memory cannot be accessed directly I think, at least not by normal
code. Firmware uses some low level 'ce' type logic to handle that I think?
In 10.4 firmware, check out the code-swap code, for instance, or the
rate-ctrl swap logic in 10.1 or higher?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
