用ARM 汇编指令完成对信号量减一计数后，调用了fail为标号的子程序，即传入的参数__down_trylock_failed 标号所在的子程序。
在/kernel/arch/arm/kernel/semaphore.c 文件中：
__down_trylock_failed: \n\
stmfd sp!, {r0 - r3,lr} \n\
mov r0,ip \n\
bl __down_trylock \n\
mov ip,r0 \n\
ldmfd sp!, {r0 - r3,pc}^ \n\
这里又调用了__down_trylock 函数。
int __down_trylock(struct semaphore * sem)
{
int sleepers;
unsigned long flags;
spin_lock_irqsave(&semaphore_lock,flags);
sleepers = sem->sleepers +1;
sem->sleepers = 0;
if (!atomic_add_negative(sleepers,&sem->count))
wake_up(&sem->wait);
spin_unlock_irqrestore(&semaphore_lock,flags);
return 1;
}
这里不再进一步深入说明。
若应用程序在调用write 函数时没有加入了O_NONBLOCK参数，即表示采用阻塞的文件IO方式，则会调用down_interruptible 函数来获得信号量sem。该函数将把sem的值减1，如果信号量sem的值非负，就直接返回，否则调用者将被挂起，直到别的任务释放该信号量才能继续运行。down_interruptible函数能被信号打断，因此该函数有返回值来区分是正常返回还是被信号中断，如果返回0，表示获得信号量正常返回，如果被信号打断，返回-EINTR。该函数与相关函数在一篇《Linux内核的同步机制》中有详细说明。
在/kernel/include/asm-arm/semaphore.h 文件中：
static inline int down_interruptible (struct semaphore *sem)
{
#if WAITQUEUE_DEBUG
CHECK_MAGIC(sem->__magic);
#endif
return__down_op_ret(sem, __down_interruptible_failed);
}
函数__down_op_ret 在上面已经有过说明。
在/kernel/arch/arm/kernel/semaphore.c 文件中：
__down_interruptible_failed: \n\
stmfd sp!, {r0 - r3,lr} \n\
mov r0,ip \n\
bl __down_interruptible \n\
mov ip,r0 \n\
ldmfd sp!, {r0 - r3,pc}^ \n\
这里又调用了__down_interruptible函数。
int __down_interruptible(structsemaphore * sem)
这里不再进一步深入说明。
if (audio_channels == 2){
chunksize =s->fragsize - b->size;
if (chunksize> count)
chunksize= count;
DPRINTK("write%d to %d\n", chunksize, s->buf_idx);
if(copy_from_user(b->start + b->size,buffer, chunksize)) {
up(&b->sem);
return-EFAULT;
}
b->size+= chunksize;
}
下面继续对音频通道数量进行判断，如果音频通道数为先前打开设备文件时设的2通道，则进入执行。
/
if (file->f_flags & O_NONBLOCK){
ret = -EAGAIN;
if (down_trylock(&b->sem))
break;
} else {
ret = -ERESTARTSYS;
if(down_interruptible(&b->sem))
break;
}
这里跟写设备函数中一样，根据file->f_flags 与上O_NONBLOCK值来进行判断，如果O_NONBLOCK 标记被设置，表示采用非阻塞的文件IO方法，则会调用down_trylock函数来试着获得信号量sem，如果能够立刻获得，它就获得该信号量并返回0，否则，表示不能获得信号量sem，返回值为非0值。该函数与相关函数在一篇《Linux内核的同步机制》中有详细说明。
若没有加入了O_NONBLOCK 参数，即表示采用阻塞的文件IO方式，则会调用down_interruptible函数来获得信号量sem。该函数将把sem 的值减1，如果信号量sem的值非负，就直接返回，否则调用者将被挂起，直到别的任务释放该信号量才能继续运行。该函数与相关函数在一篇《Linux内核的同步机制》中有详细说明。
chunksize = b->size;
if (chunksize >count)
chunksize = count;
将缓冲区地址的偏移量b->size赋值给chunksize，这里b->size 一开始应该为一个DMA缓冲区片大小，即一个s->fragsize 单位大小，若所要读取数据的长度count小于chunksize 值，那就以count 为准备读取数据的长度。在count 大于chunksize的情况下，读取的数据长度以一个s->fragsize 大小为单位。
if (copy_to_user(buffer, b->start +s->fragsize - b->size,
chunksize)) {
up(&b->sem);
return -EFAULT;
}
调用copy_to_user 函数将内存中的数据复制到用户层的buffer 中。这里b->start为指向环形缓冲区中第0个缓冲区地址的内存起始地址（虚拟地址），加上s->fragsize -b->size（得0），即还是指向第0个缓冲区地址的内存起始地址（虚拟地址）。
b->size -= chunksize;
buffer += chunksize;
count -= chunksize;
当把一组音频缓冲区片大小的数据从内存读取出来后，将缓冲区地址的偏移量b->size减去已读取数据的长度，即得0。用户层的buffer指针加上已读取数据的长度，即指向了下一组将要读取的数据。所要写入的数据长度count减去已读取数据的长度，为还要读取数据的长度。
if (b->size > 0) {
up(&b->sem);
break;
}
这时缓冲区地址的偏移量b->size 应该为0，如果还是大于0的话就会调用up函数释放信号量，并跳出while 循环。所以在对DMA缓冲区进行读取前，缓冲区地址的偏移量b->size 为一个DMA缓冲区片大小，而读取后，缓冲区地址的偏移量b->size 则为0。
s3c2410_dma_queue_buffer(s->dma_ch, (void *)b,
b->dma_addr, s->fragsize,DMA_BUF_RD);
调用了s3c2410_dma_queue_buffer 函数完成了管理DMA 缓冲区的相关数据结构s3c2410_dma_t和dma_buf_t 进行了设置，并对S3C2410 芯片的DMA 控制器部分的相关寄存器进行了相应配置，不过这里工作模式为读DMA缓冲区。
NEXT_BUF(s, buf);
}
在while大循环最后调用了NEXT_BUF 宏函数来将当前缓冲区的指针指向环形缓冲区中下一个缓冲区地址处。
if ((buffer - buffer0))
ret = buffer - buffer0;
return ret;
当count长度的数据都读完后，就退出while 大循环。一开始定义了一个buffer0 的指针指向了buffer的起始地址，在写数据的过程中，buffer 指针进行过向后移动，而buffer0 指针不变，buffer - buffer0就得到了总共读取的数据长度，并将该长度值返回。
//*******************************************************
//* 2007.7.16
//*******************************************************
经过一个双修日的音频驱动调试，对S3C2410 的IIS 控制器和UDA1341的频率配置有了进一步的了解，对控制放音的写设备文件函数smdk2410_audio_write也有了更深的认识。下面就来总结一下相关的注意要点。
在S3C2410芯片与UDA1341 芯片的连线中，关于时钟信号的连线有：I2SLRCLK 到WS，I2SSCLK 到BCK，CDCLK到SYSCLK。其中CDCLK 为UDA1341 芯片提供系统的同步时钟，也称为编解码时钟，即提供UDA1341芯片进行音频的A/D，D/A 采样时的采样时钟。而其他2组时钟只是在进行IIS总线传输数据时提供串行数据的位时钟和左右声道的切换。
CDCLK是由S3C2410 内部的APH 总线时钟首先经过一个IIS 的模式选择（256fs 或384fs），然后再经过一个IIS的预分频器分频后得到。S3C2410 主频202M，它的APH 总线频率是202/4=50M，在选择IIS的主时钟模式为384fs后，经过IIS 的PSR（分频比例因子）得到的由IPSR_A 分出的一个频率用于IIS时钟输出也可以说是同步，另一个由IPSR_B 分出的频率CDCLK 则直接作为UDA1341的系统时钟，即编解码时钟。
这里在分频前要进行IIS的主时钟频率选择（这里选择了384fs）是因为在分频时会根据384 这个系数和采样频率fs 进行分频，最后将系数384 乘以fs得到CDCLK 时钟输出频率。
而在UDA1341芯片的初始化中也需要进行系统时钟的设置（512fs，384fs 或256fs），在进行音频的编解码时会根据SYSCLK输入的系统时钟除以相应的系数，来得到采样频率fs。所以对于S3C2410 芯片的IIS 控制器和UDA1341芯片，两者相应的CDCLK 和SYSCLK的时钟频率需要设置一致。我在这里都设为了384fs，在调试过程中，我试着将两者设的不一致，结果就放不出声音了。还有一点要注意，由于预分频值与384这个系数和采样频率fs 有关，所以在计算预分频值的函数iispsr_value 中，384 这个系数也要和CDCLK 和SYSCLK设置的系数一致。如果设置不一致的话，会导致声音播放的太快或太慢。 |
