• Linux设备驱动编程之内存与I/O操作


    Linux设备驱动编程之内存与I/O操作

    2006-10-27 13:35作者:宋宝华出处:天极开发责任编辑:方舟

      (2)内存映射方式(Memory-mapped)

      RISC指令系统的CPU(如ARM、PowerPC等)通常只实现一个物理地址空间,外设I/O端口成为内存的一部分。此时,CPU可以象访问一个内存单元那样访问外设I/O端口,而不需要设立专门的外设I/O指令。

      但是,这两者在硬件实现上的差异对于软件来说是完全透明的,驱动程序开发人员可以将内存映射方式的I/O端口和外设内存统一看作是"I/O内存"资源。

      一般来说,在系统运行时,外设的I/O内存资源的物理地址是已知的,由硬件的设计决定。但是CPU通常并没有为这些已知的外设I/O内存资源的物理地址预定义虚拟地址范围,驱动程序并不能直接通过物理地址访问I/O内存资源,而必须将它们映射到核心虚地址空间内(通过页表),然后才能根据映射所得到的核心虚地址范围,通过访内指令访问这些I/O内存资源。Linux在io.h头文件中声明了函数ioremap(),用来将I/O内存资源的物理地址映射到核心虚地址空间(3GB-4GB)中,原型如下:

    void * ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags);

      iounmap函数用于取消ioremap()所做的映射,原型如下:

    void iounmap(void * addr);

      这两个函数都是实现在mm/ioremap.c文件中。

      在将I/O内存资源的物理地址映射成核心虚地址后,理论上讲我们就可以象读写RAM那样直接读写I/O内存资源了。为了保证驱动程序的跨平台的可移植性,我们应该使用Linux中特定的函数来访问I/O内存资源,而不应该通过指向核心虚地址的指针来访问。如在x86平台上,读写I/O的函数如下所示:

    #define readb(addr) (*(volatile unsigned char *) __io_virt(addr))
    #define readw(addr) (*(volatile unsigned short *) __io_virt(addr))
    #define readl(addr) (*(volatile unsigned int *) __io_virt(addr))

    #define writeb(b,addr) (*(volatile unsigned char *) __io_virt(addr) = (b))
    #define writew(b,addr) (*(volatile unsigned short *) __io_virt(addr) = (b))
    #define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))

    #define memset_io(a,b,c) memset(__io_virt(a),(b),(c))
    #define memcpy_fromio(a,b,c) memcpy((a),__io_virt(b),(c))
    #define memcpy_toio(a,b,c) memcpy(__io_virt(a),(b),(c))

      最后,我们要特别强调驱动程序中mmap函数的实现方法。用mmap映射一个设备,意味着使用户空间的一段地址关联到设备内存上,这使得只要程序在分配的地址范围内进行读取或者写入,实际上就是对设备的访问。

      笔者在Linux源代码中进行包含"ioremap"文本的搜索,发现真正出现的ioremap的地方相当少。所以笔者追根索源地寻找I/O操作的物理地址转换到虚拟地址的真实所在,发现Linux有替代ioremap的语句,但是这个转换过程却是不可或缺的。

      譬如我们再次摘取S3C2410这个ARM芯片RTC(实时钟)驱动中的一小段:

    static void get_rtc_time(int alm, struct rtc_time *rtc_tm)
    {
     spin_lock_irq(&rtc_lock);
     if (alm == 1) {
      rtc_tm->tm_year = (unsigned char)ALMYEAR & Msk_RTCYEAR;
      rtc_tm->tm_mon = (unsigned char)ALMMON & Msk_RTCMON;
      rtc_tm->tm_mday = (unsigned char)ALMDAY & Msk_RTCDAY;
      rtc_tm->tm_hour = (unsigned char)ALMHOUR & Msk_RTCHOUR;
      rtc_tm->tm_min = (unsigned char)ALMMIN & Msk_RTCMIN;
      rtc_tm->tm_sec = (unsigned char)ALMSEC & Msk_RTCSEC;
     }
     else {
      read_rtc_bcd_time:
      rtc_tm->tm_year = (unsigned char)BCDYEAR & Msk_RTCYEAR;
      rtc_tm->tm_mon = (unsigned char)BCDMON & Msk_RTCMON;
      rtc_tm->tm_mday = (unsigned char)BCDDAY & Msk_RTCDAY;
      rtc_tm->tm_hour = (unsigned char)BCDHOUR & Msk_RTCHOUR;
      rtc_tm->tm_min = (unsigned char)BCDMIN & Msk_RTCMIN;
      rtc_tm->tm_sec = (unsigned char)BCDSEC & Msk_RTCSEC;

      if (rtc_tm->tm_sec == 0) {
       /* Re-read all BCD registers in case of BCDSEC is 0.
       See RTC section at the manual for more info. */
       goto read_rtc_bcd_time;
      }
     }
     spin_unlock_irq(&rtc_lock);

     BCD_TO_BIN(rtc_tm->tm_year);
     BCD_TO_BIN(rtc_tm->tm_mon);
     BCD_TO_BIN(rtc_tm->tm_mday);
     BCD_TO_BIN(rtc_tm->tm_hour);
     BCD_TO_BIN(rtc_tm->tm_min);
     BCD_TO_BIN(rtc_tm->tm_sec);

     /* The epoch of tm_year is 1900 */
     rtc_tm->tm_year += RTC_LEAP_YEAR - 1900;

     /* tm_mon starts at 0, but rtc month starts at 1 */
     rtc_tm->tm_mon--;
    }

      I/O操作似乎就是对ALMYEAR、ALMMON、ALMDAY定义的寄存器进行操作,那这些宏究竟定义为什么呢?

    #define ALMDAY bRTC(0x60)
    #define ALMMON bRTC(0x64)
    #define ALMYEAR bRTC(0x68)

      其中借助了宏bRTC,这个宏定义为:

    #define bRTC(Nb) __REG(0x57000000 + (Nb))

      其中又借助了宏__REG,而__REG又定义为:

    # define __REG(x) io_p2v(x)

      最后的io_p2v才是真正"玩"虚拟地址和物理地址转换的地方: 

    #define io_p2v(x) ((x) | 0xa0000000)

      与__REG对应的有个__PREG:

    # define __PREG(x) io_v2p(x)

      与io_p2v对应的有个io_v2p:

    #define io_v2p(x) ((x) & ~0xa0000000)

      可见有没有出现ioremap是次要的,关键问题是有无虚拟地址和物理地址的转换!
  • 相关阅读:
    linux ss 网络状态工具
    如何安装最新版本的memcached
    如何通过XShell传输文件
    mysql主从复制原理
    聊聊IO多路复用之select、poll、epoll详解
    聊聊 Linux 中的五种 IO 模型
    pytorch中使用cuda扩展
    pytorch中调用C进行扩展
    双线性插值
    python中的装饰器
  • 原文地址:https://www.cnblogs.com/yuzaipiaofei/p/4124224.html
Copyright © 2020-2023  润新知