2.2.2 集群读写的实现
传统的块设备驱动程序中每次发布读写命令都只对一个buffer_head缓冲而导致块设备性能下降。针对这一问题，我们对传统块设备进行改进，实现了集群读写。由于每一个request结构的buffer_head结构链对应的物理块都是相邻的，因此为进行集群读写创造了条件。request结构中的nr_sectors表示该request结构需要读写的块数。进行读写时，一次性发布读写块数为nr_seetors，读入块设备内容到requem结构指向的第一个buffer_head结构对应的内存区域。在一个buffer_head结构的缓冲区读写满了以后，就调整读写缓冲区地址为下一个buffer_head所指向的缓冲区，同时配合DMA进行数据传输，提高了读写速度。对一个request结构操作完成以后，释放request结构资源。实现集群读操作伪码如下：
Read_mmc(){
发布读写命令，读入的数据块数为一个rcquest一>nr_sectors的块数；
缓冲区的指针指向第1个bh结构所指的缓冲区；
while(数据还没有读完){
读入数据到buffer_head结构所指定的缓冲区；／*调用Pxa_read_mmc()*／
调整缓冲区的指针到下一个buffer_head结构所指向的缓冲区；
}
}
2019-6-24 11:21:26
2．2．3集群读写中的并发控制
如果I／O请求队列request_queue_t是在内核中的许多地方都被访问的，则该队列就成为了临界资源。为了对该队列进行互斥保护，Linux2．4中所有的请求队列都受一个单独的全局自旋锁io_request_lock的保护。所有对清求队列的操作必须要求拥有该锁并禁止中断，然而，在驱动程序拥有这个锁的同时，其他任何读写请求不能排队到系统的任何块设备上，其他读写处理函数也不能运行。为了尽量减轻由于驱动程序长期的拥有该锁而导致系统性能下降的问题，在实现集群读写时必须遵循以下原则：
①对请求队列进行读写操作时要获得锁；
②对请求队列操作完毕后释放请求锁；
③为了减少占用锁的时间，可先把队列中的request结构从队列中取下来，再打开锁，然后在开锁的情况下对取下的request结构进行操作。
基于以上原则，读／写处理函数的伪码如下所示：
mmc_request_fn()
whilc(1){
加锁io_request_lock;
读取当前MMC卡请求队列的第一个请求结构request；
释放锁io_request_lock;
if(request为空)
cxit(O)； ／*没有可以处理的队列，返回*/
read_mmc()； /*调用集群读写函数*/
加锁io_request_lock；
在queue结构中取处理完毕的request结构，释放request资源；
释放锁io_request_lock；
}
}
2．2．3集群读写中的并发控制
如果I／O请求队列request_queue_t是在内核中的许多地方都被访问的，则该队列就成为了临界资源。为了对该队列进行互斥保护，Linux2．4中所有的请求队列都受一个单独的全局自旋锁io_request_lock的保护。所有对清求队列的操作必须要求拥有该锁并禁止中断，然而，在驱动程序拥有这个锁的同时，其他任何读写请求不能排队到系统的任何块设备上，其他读写处理函数也不能运行。为了尽量减轻由于驱动程序长期的拥有该锁而导致系统性能下降的问题，在实现集群读写时必须遵循以下原则：
①对请求队列进行读写操作时要获得锁；
②对请求队列操作完毕后释放请求锁；
③为了减少占用锁的时间，可先把队列中的request结构从队列中取下来，再打开锁，然后在开锁的情况下对取下的request结构进行操作。
基于以上原则，读／写处理函数的伪码如下所示：
mmc_request_fn()
whilc(1){
加锁io_request_lock;
读取当前MMC卡请求队列的第一个请求结构request；
释放锁io_request_lock;
if(request为空)
cxit(O)； ／*没有可以处理的队列，返回*/
read_mmc()； /*调用集群读写函数*/
加锁io_request_lock；
在queue结构中取处理完毕的request结构，释放request资源；
释放锁io_request_lock；
}
}
举报
2019-6-24 11:21:43
2.3 守护线程
在MMC卡驱动程序初始化的时候，启动守护线程mme_block_thread。它平时处于睡眠状态，当有对MMC卡的读／写请求时，mmc_blok_thread被唤醒。该线程调用上述读／写处理函数mmc_request_fn()，处理完毕后再进入睡眠状态。
2.3 守护线程
在MMC卡驱动程序初始化的时候，启动守护线程mme_block_thread。它平时处于睡眠状态，当有对MMC卡的读／写请求时，mmc_blok_thread被唤醒。该线程调用上述读／写处理函数mmc_request_fn()，处理完毕后再进入睡眠状态。
举报
2019-6-24 11:21:51
2.4 电源管理
嵌入式系统一般有低功耗要求，当某设备长期没有运行时，就应该停止给该设备供电，以减少电能消耗。在内核中有一个需要注册的电源管理设备的队列pm_list，同时也有电源管理线程kpowered，它的优先级是所有运行进程中最低的。当系统长时间没有进程运行时，kpowered被唤醒，扫描pm_list队列各个注册的设备。如果发现该设备长期没有运行，则向该设备发出PM_SUSPEND事件；而当设备重新开始使用时，则向pm_list队列发出：PM_RESUME事件。
在MMC卡驱动模块中注册了电源管理的回调函数mme_block_callback，即pm_register(PM_UNKNOWN_DEV，0，mme_pm_callback)。这样MMC卡就注册到了pm_list队列中去了。当有电源事件时，就触发mmc_pm_callback函数。该函数处理各种电源事件。
程序中的电源事件有两种：
①PM_SUSPEND事件。该事件使MMC卡进入省电模式。这时驱动程序保存MMC卡的当前状态和重要寄存器的内容，如时钟寄存器MMC_CLKRT和状态寄存器MMC_STAT等。然后，设置MMC卡的供电GPIO为高电平，关闭MMC卡的电源供应，没置MMC卡在时钟使能寄存器CKEN的相应位为O，关闭MMC卡的时钟脉冲。这时，MMC卡就进入了省电模式。
②PM_RESUME事件。该事件使MMC卡进入正常工作模式。这时程序恢复在进入省电模式前保存的寄存器，打开电源供应和时钟脉冲，MMC卡恢复到正常的工作模式。
当然电源事件也可以由用户进程自愿触发。在文件系统的接口file_operaion io_control中留有电源理管理接口，用户可以通过io_contol向卡发送电源事件请求。
2.4 电源管理
嵌入式系统一般有低功耗要求，当某设备长期没有运行时，就应该停止给该设备供电，以减少电能消耗。在内核中有一个需要注册的电源管理设备的队列pm_list，同时也有电源管理线程kpowered，它的优先级是所有运行进程中最低的。当系统长时间没有进程运行时，kpowered被唤醒，扫描pm_list队列各个注册的设备。如果发现该设备长期没有运行，则向该设备发出PM_SUSPEND事件；而当设备重新开始使用时，则向pm_list队列发出：PM_RESUME事件。
在MMC卡驱动模块中注册了电源管理的回调函数mme_block_callback，即pm_register(PM_UNKNOWN_DEV，0，mme_pm_callback)。这样MMC卡就注册到了pm_list队列中去了。当有电源事件时，就触发mmc_pm_callback函数。该函数处理各种电源事件。
程序中的电源事件有两种：
①PM_SUSPEND事件。该事件使MMC卡进入省电模式。这时驱动程序保存MMC卡的当前状态和重要寄存器的内容，如时钟寄存器MMC_CLKRT和状态寄存器MMC_STAT等。然后，设置MMC卡的供电GPIO为高电平，关闭MMC卡的电源供应，没置MMC卡在时钟使能寄存器CKEN的相应位为O，关闭MMC卡的时钟脉冲。这时，MMC卡就进入了省电模式。
②PM_RESUME事件。该事件使MMC卡进入正常工作模式。这时程序恢复在进入省电模式前保存的寄存器，打开电源供应和时钟脉冲，MMC卡恢复到正常的工作模式。
当然电源事件也可以由用户进程自愿触发。在文件系统的接口file_operaion io_control中留有电源理管理接口，用户可以通过io_contol向卡发送电源事件请求。
举报
2019-6-24 11:21:58
2.5 热插拔管理
在手机、PDA等嵌入式系统中，都要求提供对设备的即插即用功能，使用户无须安装驱动程序就可以即时使用设备。Linux在系统层和应用层都要对热插拔事件进行处理。在系统层，一方面要探测MMC卡的热插拔事件，分配或释放系统资源，并驱动MMC卡；另一方面，要将此事件准确及时地通知给应用层，应用层则根据热插拔事件作相应的处理。
在操作系统层，需要注册一个字符型设备mmc_plug文件，用于应用层探测MMC卡的热插拔事什。CPU通过GPIO12引脚与MMC卡相连，用于卡插拔的中断探测。同时驱动程序巾设置一个信号量MMC_EVENT，它取MMC_INSERT和MMC_REMOVAL两个值。当卡插入和或者拔出时，在中断处理程序中被分别设置为MMC_INSERT和MMC_REMCOVAL；并同时传给字符设备mmc_plug，供上层的应用程序使用。为了让应用层能够知晓卡的拔插事件，在字符设备mmc_plug使用异步I／O机制poll，需要接收内核拔插事件的进程通过poll在一个等待队列上睡眠，当有卡拔插事件时产生中断，中断处理程序唤醒在队列上等待的进程。上层进程在被唤醒后就读取字符设备，获取所发生的事件。
在应用层，进程通过select机制监听MMC卡所发生的热插拔事件，在没有拔插事件的时候，进程进入阻塞状态，让出CPU资源；当发生热拔插事件时，系统唤醒通过poll加入到等待队列中的进程，然后应用层通过read函数得到MMC卡的热插拔事件，进行相应的应用层处理。当然，应用层也可以通过write方法通知系统层对卡进行处理。
2.5 热插拔管理
在手机、PDA等嵌入式系统中，都要求提供对设备的即插即用功能，使用户无须安装驱动程序就可以即时使用设备。Linux在系统层和应用层都要对热插拔事件进行处理。在系统层，一方面要探测MMC卡的热插拔事件，分配或释放系统资源，并驱动MMC卡；另一方面，要将此事件准确及时地通知给应用层，应用层则根据热插拔事件作相应的处理。
在操作系统层，需要注册一个字符型设备mmc_plug文件，用于应用层探测MMC卡的热插拔事什。CPU通过GPIO12引脚与MMC卡相连，用于卡插拔的中断探测。同时驱动程序巾设置一个信号量MMC_EVENT，它取MMC_INSERT和MMC_REMOVAL两个值。当卡插入和或者拔出时，在中断处理程序中被分别设置为MMC_INSERT和MMC_REMCOVAL；并同时传给字符设备mmc_plug，供上层的应用程序使用。为了让应用层能够知晓卡的拔插事件，在字符设备mmc_plug使用异步I／O机制poll，需要接收内核拔插事件的进程通过poll在一个等待队列上睡眠，当有卡拔插事件时产生中断，中断处理程序唤醒在队列上等待的进程。上层进程在被唤醒后就读取字符设备，获取所发生的事件。
在应用层，进程通过select机制监听MMC卡所发生的热插拔事件，在没有拔插事件的时候，进程进入阻塞状态，让出CPU资源；当发生热拔插事件时，系统唤醒通过poll加入到等待队列中的进程，然后应用层通过read函数得到MMC卡的热插拔事件，进行相应的应用层处理。当然，应用层也可以通过write方法通知系统层对卡进行处理。
举报
