留言板
路过的蜗牛们，在这里留个脚印吧～
蜗窝欢迎各种言论，谈天说地、技术交流、问题求救、跳槽招聘、牢骚抱怨……哈哈。
评论：
buyit
2015-07-14 10:03
2015-07-14 10:03
@linuxer：是SOC上的RTC，不过芯片设计人员给出了这样子的解释，由于CPU和RTC模块的clock差太多，CPU在1ghz，RTC在32KHz，所以RTC在收到寄存器写入之后需要很久(相对于cpu的cycle来说很久，相对于rtc自己的cycle来说其实不久)才能拉irq pin。
linuxer
2015-07-14 12:37
2015-07-14 12:37
@buyit：对level类型的中断而言，基本上在interrupt handler（top half）中需要完成clear interrupt的动作，否则，在执行完成interrupt handler之后会unmask该irq（参考handle_level_irq函数），如果没能清中断，那么中断会立刻再次进入的。
如果外设和CPU是通过慢速总线连接，那么这个clear interrupt的动作的确会比较慢，例如通过I2C接口访问寄存器来清除外设的中断。针对这种情况，基本上linux kernel中可以使用threaded interrupt handler，并且将flag设定为oneshot。当然，你这个场景的总线其实并不慢，慢的是外设的clock。不过，你说的场景有点怪，我倒是置疑硬件的设计。本质上，软件写寄存器来clear rtc interrupt，那么其irq signal应该立刻deasserted，也就是说寄存器和irq signal应该是同步的，否则，难道硬件人员还需要提供一个状态寄存器来说明rtc irq signal的状态？这太奇怪了。另外，对于RTC hw block，其包括两个clock domain，一个慢速的、驱动RTC自身功能运作的那个32768 clock，另外一个clock domain是来自和CPU 连接的bus上的clock，我认为清除硬件的中断信号这个HW功能不应该位于slow clock上。可能硬件设计有困难吧，anyway，你说的这种情况，除了在rtc interrupt handler中disable该irq，我还真是想不出其他方法了。
如果外设和CPU是通过慢速总线连接，那么这个clear interrupt的动作的确会比较慢，例如通过I2C接口访问寄存器来清除外设的中断。针对这种情况，基本上linux kernel中可以使用threaded interrupt handler，并且将flag设定为oneshot。当然，你这个场景的总线其实并不慢，慢的是外设的clock。不过，你说的场景有点怪，我倒是置疑硬件的设计。本质上，软件写寄存器来clear rtc interrupt，那么其irq signal应该立刻deasserted，也就是说寄存器和irq signal应该是同步的，否则，难道硬件人员还需要提供一个状态寄存器来说明rtc irq signal的状态？这太奇怪了。另外，对于RTC hw block，其包括两个clock domain，一个慢速的、驱动RTC自身功能运作的那个32768 clock，另外一个clock domain是来自和CPU 连接的bus上的clock，我认为清除硬件的中断信号这个HW功能不应该位于slow clock上。可能硬件设计有困难吧，anyway，你说的这种情况，除了在rtc interrupt handler中disable该irq，我还真是想不出其他方法了。
wowo
2015-07-07 12:28
2015-07-07 12:28
@paul_chen：ALSA框架，我们在公司的时候，写过一些分析文档，要整理出来的话也不难，只是时间不是很多。不知道paul同学有没有兴趣帮忙整理一下？我可以把那些文档给你分享一下（有一两百页呢）。
wowo
2015-07-07 12:25
2015-07-07 12:25
@passerby：以前的时候，能够主动访问memory的，只有CPU、DMA等少数器件，因此MMU大多是把CPU看到的虚拟地址转换为实际的物理地址。
而现在，为了减轻CPU的压力，很多外设，也具备访问memory的能力，如GPU、codec等等。正常情况下，这些外设看到的是物理地址，因此直接使用物理地址操作memory。
使用物理地址的一个缺点是，地址必须是连续的，如果memory的需求较大（如显示相关的器件），则对内存管理形成了压力。因而很多外设本身也支持MMU功能，这时，外设看到的是连续的IO虚拟地址，经过MMU转换为不连续的物理地址。
因此，位于外设中的MMU模块，就称作IOMMU。
现在IOMMU应用比较多的地方，是GPU，另外一些显示控制器、视频codec等，也有。
而现在，为了减轻CPU的压力，很多外设，也具备访问memory的能力，如GPU、codec等等。正常情况下，这些外设看到的是物理地址，因此直接使用物理地址操作memory。
使用物理地址的一个缺点是，地址必须是连续的，如果memory的需求较大（如显示相关的器件），则对内存管理形成了压力。因而很多外设本身也支持MMU功能，这时，外设看到的是连续的IO虚拟地址，经过MMU转换为不连续的物理地址。
因此，位于外设中的MMU模块，就称作IOMMU。
现在IOMMU应用比较多的地方，是GPU，另外一些显示控制器、视频codec等，也有。
wowo
2015-07-07 10:46
2015-07-07 10:46
@Robert：对mmc驱动而言，只需要实现一个MMC host（struct mmc_host），并提供相应的ops（struct mmc_host_ops）即可。后续的操作逻辑，都由mmc core负责，大概包括：
启动一个用于detect的work，检测MMC card的插入（由mmc_rescan完成，会调用host->bus_ops->detect接口）；
调用mmc_rescan_try_freq，根据卡的类型，使用不同的速率，扫描ｍｍc卡；
以MMC卡为例，会调用mmc_attach_mmc，最终会调用mmc_add_card添加一个card（struct mmc_card）；
card driver在系统初始化的时候，已经注册了一个mmc driver（struct mmc_driver），每当有新的card加入时，会调用mmc_blk_probe接口，进而创建一个block device；
block device之上，就是文件系统。
因此，回答您的问题：狭义的mmc driver（指的是mmc host driver），是由mmc core调用；广义的mmc driver（一些wifi卡除外），由block device调用。
希望能给您提供一点帮助。
启动一个用于detect的work，检测MMC card的插入（由mmc_rescan完成，会调用host->bus_ops->detect接口）；
调用mmc_rescan_try_freq，根据卡的类型，使用不同的速率，扫描ｍｍc卡；
以MMC卡为例，会调用mmc_attach_mmc，最终会调用mmc_add_card添加一个card（struct mmc_card）；
card driver在系统初始化的时候，已经注册了一个mmc driver（struct mmc_driver），每当有新的card加入时，会调用mmc_blk_probe接口，进而创建一个block device；
block device之上，就是文件系统。
因此，回答您的问题：狭义的mmc driver（指的是mmc host driver），是由mmc core调用；广义的mmc driver（一些wifi卡除外），由block device调用。
希望能给您提供一点帮助。
ZZ
2015-06-03 21:09
2015-06-03 21:09
@wowo and linuxer
请教一个问题，怎么保存内核 coredump（gdb专用core-file）,
大致思路，系统发生panic的时候，调用panic函数的同时，能否把 从coredump保存下来；供后面用gdb + vmlinux+ core-file 来恢复死机现场，调试panic debug
请教一个问题，怎么保存内核 coredump（gdb专用core-file）,
大致思路，系统发生panic的时候，调用panic函数的同时，能否把 从coredump保存下来；供后面用gdb + vmlinux+ core-file 来恢复死机现场，调试panic debug
功能
最新评论
- wangjing
写得太好了 - wangjing
写得太好了！ - DRAM
圖面都沒辦法顯示出來好像掛點了。 - Simbr
bus至少是不是还有个subsystem？ - troy
@testtest：只要ldrex-modify-strex... - gh
Linux 内核在 sparse 内存模型基础上实现了vme...
文章分类
随机文章
文章存档
- 2025年4月(5)
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2015-07-13 11:04
我现在用的一个soc有个RTC，它的中断类型是level的，当它产生中断之后，我在中断下半部去写rtc的一个寄存器去clear这个level-triggered irq，但是由于bus和时钟同步的原因，这个写的动作比较慢，所以当我从下半部的irq handler里面返回的时候并不能保证rtc到gic的中断信号已经清除了，所以有可能会造成level irq的中断仍然没有被清除，这样系统就有可能会不停进入这个level irq。 请问这种情况下有什么好办法吗？ 我看到pxa的平台在处理mmc插拔的时候使用了如下方法：
1. 中断产生
2. disable_irq，
3. 启动一个timer，设置一个经验值作为到期时间，比如1s
4. 退出中断处理函数，本次中断处理完成，但是这个mmc irq处于disable状态。
5, timer到期之后，在timer handler里面polling mmc的一个寄存器，确定irq状态清除之后，enable_irq
这种方式消耗cpu是最少的，但是我很难找到其它平台使用类似的代码，因此我想是不是还有更好的解决方式？