(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)

1.4 Offload和direct-attach两种模式下驱动的模块化

这一章节主要描述当前WLAN驱动,模块化的设计与实现。Offload后续缩写为OL,Direct-Attach缩写为DA。
WLAN驱动的不断发展,驱动的模块化逐步退出历史舞台,但是,OL需求,其本质是仅需要UMAC模块的一部分。如果实际应用场景中,同时需要OL和DA两种模式,那么模块化就没有什么意义,但是对于特定的驱动(OL和DA二选一),模块化的处理方法,就很有帮助,因为这样可以不必全部夹在WLAN的驱动,仅按需取用即可。
新的QCA芯片组没有基于DA模型来,而是使用了通用kernel模块、DA模块与OL模块分离的模式来实现。这样可以使一些通用的模块,能够根据QCA无线设备的平台,灵活的使用DA或者OL。
这个架构,同样能够满足未来QCA芯片组的需要,虽然其可能并不按照DA或者OL的思路来做。下面是就截止到QCA_Networking_2016.SPF.2.0版本发布时的一些设计概要:

  • OL的代码是UMAC的一部分,并依赖于DA模块(LMAC,HAL)。
  • UMAC模块包含的代码应该按照模块化思想划分到OL或DA的模式中去。

驱动 - 框图
(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)_第1张图片
图 1-7 驱动 - 框图(截止QCA_Networking_2016.SPF.3.0发布时)

如上图所示,所有的模块都应用于DA或OL硬件。如果所有平台都有DA和OL硬件,那么这样的设计是没问题的。但如果目标平台只使用其中一部分,那么包含所有这些模块的驱动体量,就不太合适。客户只想使用DA或者OL模式,就被迫使用上面列出的所有模块,这大概需要4M大小的固件。

(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)_第2张图片
图 1-8 驱动 - 框图(QCA_Networking_2016.SPF.4.0发布及以后版本)

上图主要表现的是,为适配不同的驱动模型,而进行的模块划分。
以下设计点需要考虑到:

  • asf和adf是核心框架的一部分,这两个模块必不可少。
  • ath_dfs和ath_spectral模块对OL和DA芯片组是通用的,如果不使用,可以在编译的时候禁用掉。
  • umac模块对OL和DA通用,它实现了协议的一部分和Host层的数据通路。
  • 一些可选的模块可以根据需求来选用。
  • 其他的模块需要根据HW的类型来使用。
    • DA类型的硬件使用到HAL,rate,LMAC(ath_dev) 和qca_da模块。
    • OL类型的硬件将使用qca_ol模块。
  • qca_da和qca_ol实现指定类型的硬件功能,独立于其他模块。

框图比较
旧框图 Vs 新框图
(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)_第3张图片
图 1-9 框图比较

WLAN驱动框图
(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)_第4张图片
图 1-10 驱动 - 框图(QCA_Networking_2016.SPF.3.0)

上面的框图说明了了QCA_Networking_2016.SPF.3.0版本的WLAN驱动,各个模块之间的关系。
下面这些点需要关注:

  • asf和adf是核心框架的一部分,这两个模块必不可少。
  • spectral和dfs的用途不变,OL和DA都需要。
  • OL模块是UMAC的一部分,跟当前一样。
  • 所有DA模块中依赖UMAC的部分将从UMAC中移除。
  • UMAC中所有DA相关的功能,将被移到qca_da模块中。
  • DA驱动依赖于OL驱动。

WLAN驱动的模块化
在第一阶段(QCA_Networking_2016.SPF.3.0版本), OL模块是独立于DA模块的。
下面是这一阶段主要的修改内容:

  • 通用的LMAC (ath_dev)功能 (非DA相关的)移到了UMAC.
  • LMAC中DA相关的功能。移到了qca_da模块中。
  • UMAC中DA相关的功能,做的更通用了,并移到了ieee80211层。

下面这个图描述了上述修改。

注意 这个图并没有表现出所有的模块,只是列出了涉及到修改的模块。

(4)高通AP10.4开发者指南——WLAN(1.4 Offload和direct-attach两种模式下驱动的模块化)_第5张图片
图 1-11 阶段1的修改

LMAC (ath_dev) 功能迁移到UMAC
既然UMAC独立于LMAC,那么一些功能就需要移到UMAC中。这些功能是不依赖DA相关的,所以可以安全的移到UMAC中。这样做也是为了保持OL驱动的独立性。

下面这些是移到UMAC的模块:

  • ath_timer
  • ath_green_ap
  • th_wbuf
  • if_bus
  • ath_pci
  • ath_ahb

下面这些功能,将做成通用层,并移到ieee80211层,这样他们就可以直接被OL层调用。

  • ath_new_opmode -> ieee80211_new_opmode
  • ath_vap_iter_new_opmode -> ieee80211_vap_iter_new_opmode

UMAC中的DA功能,移到qca_da
所有的DA相关的功能,将被整合到一个新的模块:qca_da。这个模块和ath_hal,ath_rate,ath_dev,tx99一样,都是面向DA的。

下面这些是移到qca_da模块的内容:

  • ath_linux
  • ieee80211_aponly
  • if_ath
  • if_ath_amsdu
  • ath_cwm
  • ath_cwm_project
  • if_ath_uapsd
  • if_ath_dfs
  • if_ath_aow
  • if_ath_quiet
  • if_ath_mat

UMAC中的DA功能,做成通用层,并移到ieee80211层
目前这些功能处在UMAC模块里,面向DA的层次中 (if_lmac layer),但是这些功能也同样被OL层使用。由于if_lmac移到了qca_da模块,这些功能将被做到ieee80211层。

下面这些功能将被移到ieee80211层:

  • find_alternate_mode_channel
  • ieee80211_random_channel
  • ieee80211_get_test_mute_chan
  • ieee80211_vap_iter_update_bss_chan
  • ieee80211_dfs_action
  • ieee80211_mark_dfs
  • ath_net80211_buffull_handler renamed to ieee80211_buffull_handler.
    ic_notify_buffull will be removed.
  • ath_net80211_get_ald_statistics renamed to ieee80211_get_ald_statistics.
    ic_get_ald_statistics will be removed.
  • ath_net80211_add_hmmc renamed to ieee80211_add_hmmc .
    ic_add_hmmc will be removed
  • ath_net80211_del_hmmc renamed to ieee80211_del_hmm
    ic_del_hmmc will be removed

内核PCI/AHB接口
PCI设备的注册将独立与OL和DA硬件完成。UMAC模块将之注册OL设备。qca_da模块将只注册DA设备。每个模块都有它自己的PCI probe函数,并且各自独立的完成对设备的初始化。
这一点也对给予OK和DA的AHB设备适用。例如,QCA9558是基于DA的,IPQ4018是基于OL的。

你可能感兴趣的:(wireless)