当前位置: 代码迷 >> 驱动开发 >> UDA1341音频驱动有关问题
  详细解决方案

UDA1341音频驱动有关问题

热度:14   发布时间:2016-04-28 10:41:01.0
UDA1341音频驱动问题
本帖最后由 iamrhq 于 2012-11-07 08:59:50 编辑     

最近在学UDA1341音频驱动,可是遇到一些问题,一直搞不清。UDA1341和S3C2440之间的通信到底是怎样,在这里向大家请教。

UDA1341和S3C2440一般是采用DMA传输音频数据的,就如上图那样:也就是上图的内存缓冲区是不是就是为DMA向内核申请到的DMA内存,IIS总线设置为DMA模式代替FIFO(选择成了DMA模式后是不是原来大小为64K的FIFO就被申请的DMA内存代替了,FIFO的就由DMA控制了,直到DMA传输完成之后就执行DMA中断),哎,我觉得思路真的好乱,

我现在觉得有好多问题不懂:
1.向内核申请的DMA内存是给音频文件用的还是给IIS的FIFO用的,音频文件是不是存在那个内存缓冲区里边的。(那块内存缓冲区是不是申请的DMA内存来的)
2.IIS总线的FIFO只有64K所以要选择DMA模式,可是选了DMA模式后,是不是FIFO就验DMA代替了,控制权交给了DMA,只有DMA传输完成时才会执行一次DMA中断。
3.当发起一次DMA传输时,它的从那里发到那里的(也就目的地方和源地址分别是那个)我现在理解为:内存缓冲区发到IIS总线的FIFO地址那里,可是问题又来了,不是只有一块DMA内存吗,申请的那块DMA内存验文件那里用了,那IIS的DMA模式内存又在那里呢?
4.那要是数据通过DMA获取到总线的使用权后,自动把数据传到IIS的DMA中,那IIS中的音频数据又是怎样通IIS总线发到UDA1341上边去发出声音来呢?是不是通过DMA中断启动IIS发送出去的。

真心的发觉自己太笨了。请大家向小弟指点指点。
------最佳解决方案--------------------
你的描述还真有点乱

使用DMA模式,需要设置DMA源地址和目的地址,比如源地址设为buffer(就是图中的内存缓冲区),目的地址设为IIS的数据接收寄存器,这个时候不需要使用fifo,buffer就具有fifo的功能,音频数据不经过fifo

IIS总线和UDA1341的通信是通过IIS协议的,是另外一回事了

简单点说,DMA控制IIS controler到memory之间的大量的数据搬运,很大解放了cpu;IIS controler通过IIS协议和UDA1341通信,获取和发送音频数据
------其他解决方案--------------------
发送:音频数据->IIS控制器TX_FIFO->通过DMA方式搬到内存某处->DMA搬运完成后告知CPU->IIS控制器把内存某处的数据用IIS协议发给UDA1341
------其他解决方案--------------------
希望大家能指点一下
------其他解决方案--------------------
谢谢你的解答,这样一来我的思路清晰多了。
昨天我看了一下源码,以播放为例:其DMA源地址设置为申请到的DMA内存基地址,目的地址设置为S3C2440的0x55000010(IIS FIFO REGISTER),然后IIS controler的发送选择为DMA模式并且使能IIS接口。
文档中IIS DMA模式是这样子写的:

DMA 传输
   该接口对FIFO的访问采用了DMA模式取代了中断
   在此模式下,发送或接收FIFO 对DMA 控制器是可访问的。在发送或接收模式下的DMA服务请求是由FIFO 准备标志自动执行。

所以我现在的理解为:
   当应用程序要播放一段音频数据时,驱动程序做一系列的初始化后最终会发起一次DMA的传输,在DMA控制器的控制下,音频数据会往目的地址(也就是IIS FIFO)中传输,因为之前在初始中IIS接口是使能的了,所以在FIFO中音频数据通过IIS协议会自动的往UDA1341传输,从而实现声音的播放。

现在还有几个问题不清楚:
1.楼上的说音频数据不经过fifo,可是DMA传输目的地址就是IIS FIFO地址,是不是我那里理解错了。
2.IIS DMA模式描述,FIFO的访问采用了DMA模式取代了中断,那是不是当FIFO中有一旦数据时,就直接通过IIS协议往UDA1341里边传了,(还是要等到FIFO中数据满64K时才会往UDA1341时传输)
3.DMA往FIFO里传输数据与FIFO往UDA1341传输数据是不是同时进行的,都使用独立的时钟。

4.就是驱动发起一次DMA传输时,会不会阻塞当前驱动程序,调度别的驱动程序运行,等到DMA传输完毕时,才唤醒阻塞的驱动程序。


学驱动没多久,好多地方不懂,希望大家能够指点一下
------其他解决方案--------------------
到现在为止总算清晰了挺多的了
我的理解为这样:(不知道是否正确,有错误希望大家能指出来)
    以播放为例,当应用程序要播放一段音频数据时,驱动程序做完一系列的初始化后最终会发起一次DMA的传输,之后DMA会占用系统总线,在DMA控制器的控制下,音频数据会往目的地址(也就是IIS FIFO)中传输,当DMA一块数据传送完毕之后就会去执行相应的DMA中断例程去处理DMA的一些计数等,要是还有音频数据的话,将再次发起一次DMA传输,如此的循环,直到所在数据发送完毕。
    还有的就是IIS FIFO了,当数据通过DMA往IIS FIFO时,FIFO中就会存有数据,因为在之前的驱动初始化中使能了IIS 接口,所以一旦FIFO中有数据存在就会自动通过IIS控制器根据IIS协议往UDA1341中传输数据了,当数据到达UDA1341时,经过其ADC就会发出相应的声音来了。

所以根据我的理解:
1.数据还是要经过FIFO的。
2.只要FIFO里边有数据IIS就会启动传输。
3.DMA和IIS的时钟应该是独立的(这个不太清楚,暂时这样理解)。
4.还没找到答案,我想应该不会阻塞,DMA本来就是不占用CPU的,只是占用系统总线而已。
    录音就是返过来流程了。

    论坛里的人不太给力呀,只有一个人回复,基本上还给靠自己去找原因,衷心希望大家能够共享经验,多多指点咱们这种菜鸟,让美帝国主义反过来山寨咱们的技术和产品。以后山寨就不叫Made in China 而是 Made in USA
------其他解决方案--------------------
回4楼:通过DMA方式搬到内存某处->DMA搬运完成后告知CPU->IIS控制器把内存某处的数据用IIS协议发给UDA1341 
可是一般分配的DMA内存要比TX FIFO大好多的。在DMA搬运完成再用IIS控制器把内存某处的数据用IIS协议发给UDA1341 不会造成FIFO溢出吗