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

本文探讨了WLAN驱动在Offload(OL)和Direct-Attach(DA)两种模式下的模块化设计,介绍了QCA芯片组如何通过通用kernel模块、DA模块与OL模块分离的方法,实现了灵活适配不同硬件的需求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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的模式中去。

驱动 - 框图
Driver - Block Diagram until QCA_Networking_2016.SPF.3.0 release
图 1-7 驱动 - 框图(截止QCA_Networking_2016.SPF.3.0发布时)

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

Block Diagram in QCA_Networking_2016.SPF.4.0 release and later
图 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 新框图
框图比较
图 1-9 框图比较

WLAN驱动框图
Driver - Block Diagram in QCA_Networking_2016.SPF.3.0
图 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层。

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

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

阶段1的修改
图 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的。

<think>好的,我现在要回答用户关于高通平台使用的编码方式,特别是涉及offloadno-offload模式的问题。首先,我需要确认用户的问题背景。用户可能是在进行音频开发,特别是Android系统上的音频处理,遇到了性能或延迟问题,想了解高通平台如何处理音频编码,以及两种模式的区别应用场景。 接下来,我需要回忆高通平台(Qualcomm)在音频处理方面的常见做法。通常,移动平台的音频处理有两种方式:一种是使用主CPU进行编码(no-offload),另一种是利用专用的DSP或硬件加速模块进行编码(offload)。用户提到的offloadno-offload应该是指这两种模式。 首先,我应该解释这两个术语的基本概念。Offload模式指的是将音频编码任务从应用处理器(AP)卸载到专用的数字信号处理器(DSP),这样可以降低CPU负载,节省功耗,适合长时间运行的音频任务,比如音乐播放。而no-offload模式则是在应用处理器上使用软件编码,可能更灵活,但消耗更多CPU资源,适合需要低延迟的场景,比如通话或游戏音频。 然后需要具体说明高通平台上的实现。高通通常在其芯片组中集成Hexagon DSP,用于处理音频、传感器等任务。在音频编码方面,例如AAC、aptX等编码格式,高通可能支持通过DSP进行硬件加速。Android系统从某个版本开始支持音频offload,通过AudioTrack等API进行配置。 用户可能还想知道如何选择这两种模式,以及实际开发中需要注意的问题。比如,使用offload需要检查设备是否支持,编码格式是否被DSP兼容,以及可能存在的延迟问题。而no-offload虽然更耗电,但兼容性更好,适合实时性要求高的场景。 还要注意权限API的使用,比如在Android中设置FLAG_HW_AV_SYNC等标志来启用offload模式。此外,不同高通芯片组(如骁龙系列)支持的编码格式可能不同,需要查阅具体文档。 最后,要确保回答结构清晰,分点解释,并提供示例或典型应用场景,帮助用户理解。同时,提醒用户在实际开发中进行测试,验证设备的支持情况,以及两种模式对性能功耗的影响。</think>在高通(Qualcomm)平台中,**offload****no-offload**是两种不同的音频编码处理方式,主要涉及音频编解码任务的硬件/软件分工。以下是关键差异典型应用场景: --- ### **1. Offload(硬件卸载编码)** **编码方式**: - 将音频编码任务**完全交给专用硬件**(如Hexagon DSP)处理 - 主CPU(应用处理器)不参与编码计算 **技术特点**: - ✅ **低功耗**:DSP功耗远低于CPU - ✅ **高效率**:硬件加速支持AAC/aptX/FLAC等编码格式 - ⏳ **高延迟**:数据需传输到DSP处理,适合非实时场景 - 🔒 **格式限制**:仅支持芯片预设的硬件编码格式 **典型场景**: - 音乐播放(如Spotify、本地音乐播放器) - 长时间录音(会议记录等) - 需要省电的后台音频处理 **Android API示例**: ```java AudioTrack.Builder() .setOffloadedPlayback(true) // 启用offload .setBufferSizeInBytes(1024*1024) .build(); ``` --- ### **2. No-Offload(软件编码)** **编码方式**: - 通过**CPU运行软件算法**完成编码(如Android MediaCodec) - 完全依赖应用处理器性能 **技术特点**: - ⚡ **低延迟**:数据直接在内存中处理,适合实时场景 - 🔄 **高灵活性**:支持任意编码格式(只要软件实现) - ⚠️ **高功耗**:CPU持续运行导致发热耗电 - 📉 **性能依赖**:编码速度受CPU负载影响 **典型场景**: - 实时语音通话(微信语音、Zoom会议) - 游戏音频采集 - 需要动态调整编码参数的场景 **代码实现路径**: ``` 应用层 → Android MediaCodec → CPU软编码 ``` --- ### **3. 高通平台实现细节** | 特性 | Offload (Hexagon DSP) | No-Offload (CPU) | |---------------------|--------------------------------|-------------------------------| | **编码格式支持** | AAC/aptX/FLAC/SBC等预设格式 | 任意格式(如OPUS、AMR-WB) | | **功耗对比** | 约降低50%-70% | 100%基准功耗 | | **典型延迟** | 100-200ms | <50ms | | **骁龙芯片支持** | 从骁龙820开始普遍支持 | 全系支持 | --- ### **4. 开发注意事项** 1. **格式检查**: 使用`AudioManager.isOffloadedPlaybackSupported()`检测设备是否支持目标格式的offload ```java AudioFormat format = new AudioFormat.Builder() .setEncoding(AudioFormat.ENCODING_AAC_LC) .build(); boolean isSupported = audioManager.isOffloadedPlaybackSupported(format); ``` 2. **混合模式**: 高通支持动态切换(如初始用offload播放音乐,当接到来电时切到no-offload处理实时语音) 3. **功耗优化**: Offload模式下建议设置`AUDIO_SESSION_ID_GENERATE`以启用硬件音频流水线 4. **调试工具**: 使用`dumpsys media.audio_flinger`可查看当前音频流是否处于offload状态 --- ### **5. 典型问题解决方案** **场景**:播放音乐时出现卡顿 - **Offload优化**:增大`AudioTrack`缓冲区(避免DSP饥饿) - **回退机制**:检测到连续underflow时自动切换到no-offload模式 **代码片段**: ```java if (offloadSupported) { try { offloadTrack.play(); // 优先尝试offload } catch (IOException e) { fallbackToSoftwareCodec(); // 异常时回退到软件编码 } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值