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

From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>,
	Adrian Chadd <adrian@freebsd.org>
Cc: Rajkumar Manoharan <rmanohar@codeaurora.org>,
	"Manoharan, Rajkumar" <rmanohar@qti.qualcomm.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
	"Valo, Kalle" <kvalo@qca.qualcomm.com>,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	"nbd@nbd.name" <nbd@nbd.name>
Subject: Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform
Date: Wed, 20 Jul 2016 09:48:22 -0700	[thread overview]
Message-ID: <578FAB56.1030606@candelatech.com> (raw)
In-Reply-To: <CA+BoTQ=ehuXpcJUOeSscLKzX9T=hZyp5i2G9GoxTVX=LAg_4hA@mail.gmail.com>

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k