On 20 July 2016 at 08:11, Adrian Chadd <[email protected]> wrote:
> Hi,
>
> The ath10k on-chip DMA engine only knows how to address the low 32
> bits of physical address space. It can't do DMA elsewhere without a
> hardware IOMMU in the system. Even then, as far as the device is
> concerned, it's being given < 32 bit physical memory addresses to DMA
> around.
Sure. ath10k even makes sure to use 32bit mask for dma (which is
redundant because it's already the default in linux pci subsystem
anyway).
> The local/host memory designation is different; IIRC when the CE is
> doing transfers between local/host memory it's explicitly setup to do
> so when you setup the ring/transfer. But those are all 32 bit
> addresses anyway.
Is CE involved in direct DMA accesses as well? Anyway my current
suspicion stems from this code hunk in ath10k:
static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
{
u32 val = 0;
switch (ar->hw_rev) {
case ATH10K_HW_QCA988X:
case ATH10K_HW_QCA9887:
case ATH10K_HW_QCA6174:
case ATH10K_HW_QCA9377:
val = (ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
CORE_CTRL_ADDRESS) &
0x7ff) << 21;
break;
case ATH10K_HW_QCA9888:
case ATH10K_HW_QCA99X0:
case ATH10K_HW_QCA9984:
case ATH10K_HW_QCA4019:
val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS);
break;
}
val |= 0x100000 | (addr & 0xfffff);
return val;
}
This is used for CE diagnostic window in ath10k. However there seems
to be a counterpart (A_DMA_ADDR/A_CPU_ADDR) in firmware that does
something similar and dma_local_bits seem to be constructed in a
similar manner (at least on QCA9880), i.e. ((x >> 21) & 0x7ff) << 21.
The QCA99X0 seems to do it slightly differently (in firmware code as
well). Perhaps there's some kind of bug or an unexpected overlap that
cause addressing problems?
Michał
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
