diff options
author | Raja Mani <rmani@qti.qualcomm.com> | 2016-01-27 09:54:25 (GMT) |
---|---|---|
committer | Kalle Valo <kvalo@qca.qualcomm.com> | 2016-01-28 08:47:19 (GMT) |
commit | 0b523ced9a3cd05abf240e913b2d80e7d0fa3478 (patch) | |
tree | 8605074ae40e7b1e60de09f3fb234a107f2e8c1f /drivers/eisa | |
parent | 90188f807f2a8bada8e165b932b56f7e03b0a9b9 (diff) | |
download | linux-0b523ced9a3cd05abf240e913b2d80e7d0fa3478.tar.xz |
ath10k: add basic skeleton to support ahb
qca4019 uses ahb instead of pci where it slightly differs in device
enumeration, clock control, reset control, etc. Good thing is that
ahb also uses copy engine for the data transaction. So, the most of
the stuff implemented in pci.c/ce.c are reusable in ahb case too.
Device enumeration in ahb case comes through platform driver/device
model. All resource details like irq, memory map, clocks, etc for
qca4019 can be fetched from of_node of platform device.
Simply flow would look like,
device tree => platform device (kernel) => platform driver (ath10k)
Device tree entry will have all qca4019 resource details and the same
info will be passed to kernel. Kernel will prepare new platform device
for that entry and expose DT info to of_node in platform device.
Later, ath10k would register platform driver with unique compatible name
and then kernels binds to corresponding compatible entry & calls ath10k
ahb probe functions. From there onwards, ath10k will take control of it
and move forward.
New bool flag CONFIG_ATH10K_AHB is added in Kconfig to conditionally
enable ahb support in ath10k. On enabling this flag, ath10k_pci.ko
will have ahb support. This patch adds only basic skeleton and few
macros to support ahb in the context of qca4019.
Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Diffstat (limited to 'drivers/eisa')
0 files changed, 0 insertions, 0 deletions