[PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Ben Greear]

On 07/19/2016 11:05 PM, Michal Kazior wrote:
> On 20 July 2016 at 07:44, Adrian Chadd <adrian at freebsd.org> 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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com