Alsa-Audio 二

本文介绍了ASOC (ALSAsystemonchip) 架构中的关键组件,包括snd_soc_machine和snd_soc_dai_link结构体,解释了它们如何在SoC芯片内部音频控制器与外部解码芯片之间建立连接。
 

ASOC (ALSA system on chip)              // 主要为嵌入式系统专门开发的sound管理体系结构[luther.gliethttp].
Digital Audio Interface (DAI) types
/* SoC machine */
struct snd_soc_machine {                // snd_soc_machine集cpu内部音频控制逻辑和cpu外部音频解码芯片通信逻辑于一体[luther.gliethttp].
    ......                              // audio machine driver表示音频设备结构体,我的ep9312作为一个arm-SoC芯片,
                                        // 就是这里的machine,一个machine当然要包含自己内部的音频控制接口单元--cpu_dai和
                                        // 外部音频设备通信协议转换接口单元--codec_dai这两部分,这样ep9312才能使用自己
                                        // 内部的一个音频控制通道,通过数据交互总线协议(如:PCM,IIS或AC97)
                                        // 控制接口单元--codec_dai,向外部的具体芯片发送或接收音频数据[luther.gliethttp].
    /* CPU <--> Codec DAI links  */
    struct snd_soc_dai_link *dai_link;  // 核心单元,一个黏结器,黏结了cpu内部音频控制器接口和arm开发板中cpu外置音频解码芯片通信接口
    int num_links;
};
/* SoC machine DAI configuration, glues a codec and cpu DAI together */
struct snd_soc_dai_link  {              // 当然就是指该SoC芯片的DAI接口链接了,它主要包含下面2个内容.cpu_dai和.codec_dai
    ......
    /* DAI */
    struct snd_soc_codec_dai *codec_dai;// cpu外置的解码芯片的DAI数字音频控制接口[luther.gliethttp]
    struct snd_soc_cpu_dai *cpu_dai;    // cpu内部支持的DAI数字音频控制接口,比如ssp,IIS等
    ......                              // cpu_dai和codec_dai将被强制绑定在一起,实现一对一,点对点数据和控制信息彼此交互.
};

 

转载: http://zougaoming.blog.163.com/blog/static/238089512011912101433347/

在内核模块构建过程中,如果遇到 `modpost` 报错提示类似 **"GPL-incompatible module xxx.ko uses GPL-only symbol 'mutex_destroy'"** 或 **'mutex_lock_nested'** 的错误信息,通常是因为模块尝试使用仅限于 GPL 许可证模块访问的内核符号。这类问题的核心在于模块许可证声明与所调用符号的许可限制之间存在冲突。 --- ### 内核符号导出机制简介 Linux 内核中通过 `EXPORT_SYMBOL` 和 `EXPORT_SYMBOL_GPL` 宏来控制符号对模块的可见性: - `EXPORT_SYMBOL`:导出的符号可供所有模块使用,无论其许可证。 - `EXPORT_SYMBOL_GPL`:仅允许使用 GPL 兼容许可证(如 GPLv2)的模块访问该符号 [^1]。 当一个非 GPL 模块试图调用由 `EXPORT_SYMBOL_GPL` 导出的函数(如 `mutex_destroy`、`mutex_lock_nested` 等),构建工具 `modpost` 会检测到此不兼容并报错。 --- ### 解决方法 #### 方法一:修改模块许可证为 GPL 若模块源码允许更改许可证,则可在模块源文件中添加如下宏定义: ```c MODULE_LICENSE("GPL"); ``` 这将使模块声明自身为 GPL 兼容模块,从而可以合法调用 `EXPORT_SYMBOL_GPL` 导出的函数 [^1]。 #### 方法:避免使用 GPL-only 符号 如果无法更改模块许可证,应尽量避免调用 `EXPORT_SYMBOL_GPL` 导出的函数。例如: - 使用替代的同步机制而非 `mutex_lock_nested`。 - 不显式调用 `mutex_destroy`,而是在模块卸载时确保互斥锁已处于未初始化状态。 ##### 示例替换逻辑: ```c struct mutex my_mutex; // 初始化互斥锁 mutex_init(&my_mutex); // 加锁操作 mutex_lock(&my_mutex); // 执行临界区代码... // 解锁操作 mutex_unlock(&my_mutex); // 在模块退出前不主动销毁互斥锁 // mutex_destroy(&my_mutex); // 避免调用 GPL-only 函数 ``` #### 方法三:修改内核配置以放宽限制(不推荐) 可以通过修改内核配置项 `CONFIG_MODULES_TREE_ALL` 或调整 `modpost` 工具的行为来绕过此类检查。然而,这种做法会削弱内核模块的许可合规性,可能带来法律或维护风险,因此不建议用于生产环境 [^3]。 --- ### 构建日志分析建议 根据以往经验,构建失败时查看 `/var/lib/dkms/xxx/build/make.log` 是定位问题的关键步骤 [^2]。确认是否还有其他类似的 GPL-only 符号被非法引用,并据此逐一修复。 --- ### 开发实践建议 - **明确模块用途与许可要求**:决定是否需要遵守 GPL 协议。 - **依赖分析自动化**:使用 `modinfo` 或 `depmod` 分析模块所依赖的符号及其来源。 - **构建环境隔离**:使用 DKMS(Dynamic Kernel Module Support)进行模块构建,便于调试和版本管理。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值