蜗窝科技

能否请教一个问题： 在dts文件中指定了中断: qcom,mdss_mdp@1a00000{ interrupts = <0x0 0x48 0x0> ..... } 在代码中使用res = platform_get_resource(ofdev,IORESORCE_IRQ,0). 得到的res->start和dts中的不一样(0x48)。 中间有什么转换步骤么？ 感谢

期待~

@wowo：感觉网络这方面的内容相比其他内容，实用性更强一些，就技术角度来说，也是最重要最复杂的一个子系统，或许什么时候有精力了，wowo和linuxer就可以下笔了，哈哈~~

@C：suspend-to-idle是很诱人的，我们在很久之前一个项目中也想这样做，但是迫于框架的不完善，最终没敢行动。我觉得它的好处主要是在于便利性，随时睡，随时醒。如果省电效果不错的话，还是很好用的。

@Daniel Shieh：精力实在有限的，估计一时半会不会涉及这方面的东西。

今年CLK南京的会议上的topic就是suspend-to-idle。 freeze task的一个重要作用就是支持s2i。 因为freeze task之后一些有趣的优化就成为了可能，比如cpu可能进入更深的cstate，可以停掉timer，timekeeping module甚至tsc，达到进一步节能。主要是，suspend to idle可以替代suspend to mem，毕竟后者需要firmware支持。

网络子系统有没有什么规划？嘻嘻......

看了楼主的三篇文章，对设备树有更深刻的理解。不过本人还在学习中。还望楼主有空的时候能不能讲一些，设备树最终演化为平台设备端的时候，它的那些属性是plat_device下的res或者dev.platform_data，他们对应关系如何的呢？

@descent：上面的回答稍显敷衍，主要是快下班了，着急着回家，现在老婆孩子睡了，可以安安静静的针对这个问题胡思乱考了，呵呵~~~ /dev/mem这个设备节点可以让用户空间建立页表并mapping到任意的系统中的物理地址上去，如果这个设备节点提供O_SYNC这种接口来控制映射的cache属性，那么这个接口是否是一个好的接口呢？ 对于普通的memory而言，可以映射为non cached（例如DMA buffer，framebuffer等），也可以映射为cached（大部分的普通的data和heap上的memory都是cached），因此，通过O_SYNC来控制映射的cache属性是OK的，但是，对于IO memory而言，设置为cached真的适合吗？这可能会引入很多不必要的麻烦，因此，这种情况下，通过O_SYNC来控制映射的cache属性是徒增user的烦恼。而且，一旦提供了这样的接口，实际上用户空间的进程可以把多个虚拟地址映射到一个物理地址上去（建立多个页表，把不同的虚拟地址映射到同一个物理地址），并且指定不同的属性。软件这么任性，有没有和硬件商量呢？ 这个问题转换成了cpu设计的问题了，即硬件如何处理同一个物理地址不同属性的访问，对于ARM64处理器而言，一个物理地址有memory type的设定（体现在页表中的描述符中的某些bit），要么是device，要么是memory。如果virtual_A地址被mapping到physical_A并通过页表设定为device，同时virtual_B地址也被mapping到physical_A并通过页表设定为memory，那么估计ARM处理的内心是崩溃的。ARM64处理器不愿意浪费多余的晶体管来处理这些破事，因此规定软件符合一定的规则，如果打破这个规则，那么cpu的执行逻辑是未知的。不同的cpu有不同的设计理念，因此phys_mem_access_prot是architecture specific的。ARM64的phys_mem_access_prot函数会根据硬件的要求，对页表进行的设定，确保符合处理器的要求。

@descent：首先声明：我的回答是基于linux 4.1.10下的ARM64代码的，其他的情况我没有去看代码，估计类似。 对"/dev/mem"这个设备的使用一般包括两步： （1）open并获取一个fd （2）通过mmap将该fd mapping到该进程的一段虚拟地址空间上去，当程序实际访问这段虚拟地址空间的时候，就象访问了fd指向的那个对象。对于"/dev/mem"的fd而言，其指向了系统中的物理地址空间 如何建立进程虚拟地址空间（vma）和"/dev/mem"设备fd之间的mapping是通过其驱动file operations数据结构中的mmap成员函数来完成的，在该函数中会建立页表，从而控制cache write buffer等的设定。该函数的代码如下： static int mmap_mem(struct file *file, struct vm_area_struct *vma) { size_t size = vma->vm_end - vma->vm_start; if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size)) return -EINVAL; if (!private_mapping_ok(vma)) return -ENOSYS; if (!range_is_allowed(vma->vm_pgoff, size)) return -EPERM; if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size, &vma->vm_page_prot)) return -EINVAL; vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff, size, vma->vm_page_prot); vma->vm_ops = &mmap_mem_ops; /* Remap-pfn-range will mark the range VM_IO */ if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, size, vma->vm_page_prot)) { return -EAGAIN; } return 0; } 其中，phys_mem_access_prot函数定义了页表中的memory attribute以及memory type的信息，代码如下： pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, unsigned long size, pgprot_t vma_prot) { if (!pfn_valid(pfn)) return pgprot_noncached(vma_prot); else if (file->f_flags & O_SYNC) return pgprot_writecombine(vma_prot); return vma_prot; } 对于ARM64的处理器而言，其物理地址空间有两种： （1）memory （2）device 从上面的代码可以看到，实际上O_SYNC这个flag只会在你要mapping的物理地址是memroy的时候才是有效的，如果你要mapping的物理地址本身就是IO（这也是/dev/mem的大多数的应用场合），那么页表项中的内容是pgprot_noncached，即： #define pgprot_noncached(prot) \ __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN) 这时候，无论是否有O_SYNC，页表的属性都是device类型的，而对于memory type是device类型的地址影响，uncache是必须的。