前两天在调试PHY的时候遇到了一堆问题，老刘都不耐其烦的搞定了，这次我们开始调试音频部分，音频部分很简单，无非就是录音，要是能把录音的音频拿到了，那就万事大吉了。老刘也是信心满满，老刘对我说，发哥，我对这个芯片特别熟悉，你要是搞不定的话，可以把驱动代码给我看看，我来帮你调试。
然后我们就开始调试了
也很快，我们就遇到了问题了，使用录音命令录音一会就崩了，是的，崩了。
我跟老刘说，我这边程序崩了，什么音频数据都录不到。
老刘跟我说，没事发哥，只要我们的波形正确了，我有办法帮你搞定录音的。
然后我和老刘就开始测量波形，我们遇到的第一个问题是，我们配置的Mclk是12.288M，但是呢，测量出来的波形是50M。
你看得没错，我也从来没有看到过50M的波形，这部分肯定是CPU的问题了，CPU当然是没有问题了，所以就是我的问题了。
我用命令查看了下时钟的配置，也确实不是12.288M
这个地方我就折腾了一段时间，刚开始是猜测我的ADC是不是没有配置正确，如果CPU配置成了master模式，ADC又配置成了master模式，那就有冲突了不是，所以这个部分我又检查了一会。
后面我看到这个时钟的配置是开始录音的时候去使能的，然后我每次测试的时候就会先去录音后，再测量波形。
然后还是没啥进展。
在这个没有进展的过程中，我们曾经有一次测量到了正确的波形，也就是16k的LRCLK和3.072M的BCLK，但是在软件没有修改的情况下，我们重新上电后，那些之前看到的美好景象都没有了。
然后，没有其他思路的情况下，我只好软件分析分析了。
使用下面的命令开始录音。
arecord -f S16_LE -c 4 -r 16000 -v -Vmono -D hw:2 /tmp/4ch.wav命令执行了一会就崩了。
然后我开始查声卡的信息
声卡的每个pcm都有两个核心的部分，一个是codec dai，一个是cpu dai，他们之间的配置要一致才可能让音频正确拾取。
我们codec 部分用的是dsp_a的IIS格式，但是我反复检查了CPU部分，cpu部分我们也已经配置成了dsp_a的格式。
dsp_a的LRCK波形如下：
老刘检查了两遍，硬件没有问题，时钟也都是正常的。
然后我使用下面的命令追踪了下arecord的调用流程
/ # strace arecord -f S16_LE -c 4 -r 16000 -v -Vmono -D hw:2 /tmp/4ch.wav
....
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_REFINE, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_PARAMS, 0x7fc8656820) = 0
ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0xf2167e0) = 0
ioctl(4, SNDRV_PCM_IOCTL_SW_PARAMS, 0x7fc86566d0) = 0
ioctl(4, SNDRV_PCM_IOCTL_PREPARE, 0x8) = 0
ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0xf2167e0) = 0
ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0xf2167e0) = 0
openat(AT_FDCWD, "/dev/snd/controlC2", O_RDWR|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, SNDRV_CTL_IOCTL_PVERSION, 0x7fc865653c) = 0
ioctl(3, SNDRV_CTL_IOCTL_CARD_INFO, 0x7fc86565b0) = 0
close(3) = 0
.....
newfstatat(AT_FDCWD, "/tmp/4ch.wav", {st_mode=S_IFREG|0644, st_size=44, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD, "/tmp/4ch.wav", 0) = 0
openat(AT_FDCWD, "/tmp/4ch.wav", O_WRONLY|O_CREAT, 0644) = 3
write(3, "RIFF$\0\0\200WAVE", 12) = 12
write(3, "fmt \20\0\0\0", 8) = 8
write(3, "\1\0\4\0\200>\0\0\0\364\1\0\10\0\20\0", 16) = 16
write(3, "data\0\0\0\200", 8) = 8
ioctl(4, SNDRV_PCM_IOCTL_READI_FRAMES, 0x7fc8656b40) = -1 EIO (Input/output error)
write(2, "arecord: pcm_read:2143: ", 24arecord: pcm_read:2143: ) = 24
write(2, "read error: Input/output error", 30read error: Input/output error) = 30
write(2, "\n", 1
) = 1
ioctl(4, SNDRV_PCM_IOCTL_DROP, 0x8) = 0
ioctl(4, SNDRV_PCM_IOCTL_HW_FREE, 0x8) = 0
close(4) = 0
exit_group(1) = ?
+++ exited with 1 +++
/ #看到调用里面有一个音频的读取相关的ioctl。
c文件里面的函数调用关系是这样的
snd_pcm_capture_ioctl1
->snd_pcm_lib_read
-->snd_pcm_lib_read1最后的函数会检查子流的状态。如果子流不处于可读取音频数据的状态（如准备、运行、暂停），则直接返回错误。
我这里不能读取到音频就是因为没有可读取的音频，所以就返回错误了，也就是说CPU看到的SDIO线上没有数据。
那问题就来了，示波器测量到的I2S数据线上已经看到数据了，但是为什么读取出来还是不行？
那不就是见了鬼了吗？
我跟老刘说，我这边已经没有办法了，已经把能检查的地方检查过了一遍，然后我让老刘给原理图，我想再检查一下。
我看了下原理图，其中有一个地方很奇怪，就是有一个GPIO口标注了两个名字，我就跟老刘说，这个GPIO口怎么又两个名字呢？
老刘跟我说，这个是一个比较牛逼的设计，因为我可以通过飞跳电阻的方式把这两个引脚飞到另外两个引脚，是硬件上面的预留设计。
我质疑了下老刘，我说这个地方会不会有问题呢？
老刘说，不会的，我已经检查了，波形也都出来了，说明这个地方是没有问题的。
老刘说，我想看看你的ADC程序，会不会程序上有什么可以配置的，我到你电脑上看看代码。
然后就是老刘看代码的时间，看了一会老刘给我指出一个宏，他说这个宏是不是可能配置成1，然后就是我给老刘解释代码的时间。
过了挺久时间。
大概是晚上10点40左右了，因为9点后这栋楼的空调会被物业统一关闭，实验室里面有点闷，老刘把我前面的窗户打开了，从外面吹进来一阵阵的热风把脑子吹得有些膨胀，这个时候我已经干掉了5瓶怡宝了。
我跟老刘说，你们有没有硬件配置跟这个差不多的，拿过来给我验证一把呢？
老刘说有的，然后就给我拿了一个硬件，我把我的固件烧录进去，神奇的事情是，录音程序没有崩。
我又跟老刘说，这个板子跑我的程序没有问题的。
老刘让我断电拿起板子去量了下，说了句，卧槽，这个地方短路了。
下面就是老刘的表演时间了，因为之前的GPIO反了的原因，这次的捣鼓也特别不容易。
这个时候是晚上11点20左右。
然后，就用刚才那个程序，录到声音了，我们用了一个linein给ADC输入了音频，也能从示波器上看到了音频波形。
真的是惊险万分，惊喜万分。
这个时候我跟老刘说，收工吧，明天再继续调试其他部分，老刘也是神情舒畅，心满意得，毕竟在硬件工程师这个职业中，老刘的技术威望那是不允许有过夜的问题存在的。
哦对了，今天有同学问，搞定寄存器计划的浮力还有吗？
我说，那必要还有，具体看下面这个链接
跟韦东山老师搞事
