DMA mapping error after switching to 64 bit on t1042

[jaredbents]

Hi,

I am running fsl-v2.0-1703 on a t1042.  Everything was brought up and working in a 32 bit version of the build (fsl-v2.0 and fsl-v2.0-1703 worked) but after switching to 64 bit, I am experiencing problems with just one part, the ath10k wifi modules I have on the board.  Most of the time when it is performing it's first dma_map_single for the ath10k, it will end up giving me an address of fbff7000 and then dma_mapping_error will return with an error.  Other times, it will work for some of the dma maps but then eventually fail on one with the same address of fbff7000 (Note, every time it fails, it is this address).  I have attempted to solve this issue by enabling CMA and reserving a dma-pool/cma-pool in the device tree.  Note, many other things are doing dma maps and working just fine.  The only things I have on PCI are the two ath10k modules and an SSD which is working.  Are there device tree settings that need to change because of the 64 bit kernel?  Does anyone know why dma_map_single (dma_map_single_attrs in include/asm-generic/dma-mapping-common.h) is giving me a bad address according to dma_mapping_error (Note as seen in /proc/iomem, this address should be ok 00000000-1ffffffff : System RAM)?

Below are a couple of dmesg printouts with two added printk messages in ath10k_pci_hif_exchange_bmi_msg from drivers/net/wireless/ath/ath10k/pci.c

ath10k_pci 0001:01:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
pci_bus 0002:01: busn_res: [bus 01] end is updated to 01

req_paddr = 7cd54180 dma_mapping_error = 0
resp_paddr = fbff7000 dma_mapping_error = 1
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)

ath10k_pci 0001:01:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
pci_bus 0002:01: busn_res: [bus 01] end is updated to 01
req_paddr = 7ce4a1c8 dma_mapping_error = 0
resp_paddr = 7cd2d5a0 dma_mapping_error = 0
ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/cal-pci-0001:01:00.0.bin failed with error -2
req_paddr = 7cd2d5a0 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
resp_paddr = 7ce4a240 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
resp_paddr = 7ce4a240 dma_mapping_error = 0
req_paddr = 7cd2d5a0 dma_mapping_error = 0
resp_paddr = 7ce4a240 dma_mapping_error = 0
req_paddr = fbff7000 dma_mapping_error = 1
ath10k_pci 0001:01:00.0: unable to write to the device (-5)
ath10k_pci 0001:01:00.0: could not write board data (-5)
ath10k_pci 0001:01:00.0: failed to download board data: -5
ath10k_pci 0001:01:00.0: failed to run otp: -5
ath10k_pci 0001:01:00.0: could not init core (-5)
ath10k_pci 0001:01:00.0: could not probe fw (-5)

[jaredbents]

For reference, I also have some ath9k modules that I have tested with this new 64 bit build (they work in the 32 bit build) and they also suffer from the exact same dma mapping error.  I added a printk to print the address it tried and it is the same address that causes the ath10k to fail.

ath9k 0000:01:00.0: enabling device (0000 -> 0002)
ath: EEPROM regdomain: 0x6a
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x6a
dma_map_single_attrs addr = fbff7000
ath: phy0: dma_mapping_error() on RX init
ath9k 0000:01:00.0: Failed to initialize device