关于codec driver的调试一般我们说的是按照linux设备树管理和alsa标准框架下的驱动调试。
也有些嵌入式设备厂商因为要频繁更换codec,为了方面不想每次更换codec都需要修改dts和导入新driver,所以并不依照linux标准的形式来实现设备驱动,而只是简单的通过gpio设置和i2c接口实现设备的初始化工作,在此不再讨论了。
使用标准驱动好处有:
1.方便调整soc的 clk和功放的上电时序。
2.可以使用alsa的kcontol接口封装对codec的操作接口,方便手动使用tinymix调整和上层调用。
3.codec driver可以知道strem和系统的状态,比如系统待机和启动suspend和resume,和alsa的underrun等等。
缺点是如果产品硬件迭代更新频繁,codec经常更换没加一个驱动和dts就意味着又要单独编译一个版本了。当然这种设备树框架也可以通过软件做到uboot里加载不同的dts文件实现。
1 .准备前提
第一部先确认硬件上的相关信息如audio pinmux 的配置,codec需要哪些gpio引脚,对应的i2c总线,i2c地址,这些可以从硬件原理图上确认。
可以使用i2cdetect工具来确认i2c通讯是否正常和设备i2c地址等信息,很多codec的i2c地址是可以根据硬件板子上的地址pin连接的电阻阻值来片选的。
上图所示,i2c总线上0 显示了一个0x60设备,表示这个地址上有一个实际的外设,地址为0x60
i2c总线1上0x2e的位置显示为UU,表示有驱动占用了这个地址,这并不代表实际上有这个外设,可能根本就没有这个设备,如果去掉驱动之后,这里显示为0x2e就说明确实有是实际的外设。
linux 标准的codec driver都是一样的模板,无论是什么codec都比较容易能参考着实现一份,
不同地方在于初始化时必要的init寄存器,这些可以阅读spec,也可以向原厂所要。
按照linux设备树的规则,将codec设备配置到对应i2c节点上,同时挂在声卡对应的sound dai节点的cocec list上
codec和dts配置完成后,编译软件烧录到平台
可以cat /proc/asound/pcm看codec是否挂载成功到声卡:
上面显示tas5805 挂在了tdmb设备上,这样通过tinyplay验证时可以使用命令:
tinyplay test.wav -d 1
碰到无声时先检查步骤:
1.codec是否成功init, cat /proc/asound/pcm是一种方式,tinymix也可以看到codec driver中添加的kcontrol接口是否存在,如果这一步都正确,说明codec driver已经probe成功了。
2.示波器量i2s的mclk,bclk,data是否正常,codec driver的reset pin、pd pin是否正确拉高。
3.使用i2cdump codec 寄存器确认有无异常。