蜗窝科技

@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，我还真是想不出其他方法了。

@linuxer：我之前接触的soc里面，GIC在system suspend的时候会掉电，suspend之后会用系统的一个独立的PMU来接管唤醒的中断源。假设RTC可以触发MPU，MPU再唤醒AP，然后AP经过了ROM code之后回到了resume的流程，那么在resume的早期中有一步是去重新初始化GIC的，RTC的中断理论上来说在这一步会被恢复，于是应该会在之后的某一个时间点被触发。 不过我有另外一个问题，是对android的alarm system的： 假设RTC的irq没有连接到GIC，但是连接到了PMU，那么当RTC里面设置的闹钟时间到了之后，系统是可以从suspend状态被唤醒的，AP也可以走进resume的过程，只是RTC的irq在AP也就是kernel这边不存在，那么这种情况下android的闹钟应用是否还能正常判断出来自己设置的闹钟到期了？

@linuxer：是SOC上的RTC，不过芯片设计人员给出了这样子的解释，由于CPU和RTC模块的clock差太多，CPU在1ghz，RTC在32KHz，所以RTC在收到寄存器写入之后需要很久(相对于cpu的cycle来说很久，相对于rtc自己的cycle来说其实不久)才能拉irq pin。

@buyit：这个RTC HW block不是SOC上的吗？为何如此之慢？硬件拓扑是怎样的？RTC和Processor是通过什么bus连接的？

@buyit：我先说一下我的看法，稍后再去查证。 当系统进入suspend状态的时候，为了节省GIC的大部分功能都是disable的，因为大部分的中断都不需要响应了，需要响应的的一般只剩下RTC、或者一两个GPIO的中断（多半是和power key以及charger相关），对于gic而言，其内部也可以分成中断检测HW block和wakeup功能HW block，在suspend的时候，中断检测相关的HW block被disable了，而保留了wakeup功能HW block以便检测到唤醒事件，从而wakup processor。 对于RTC hw block而言，一旦到期会立刻触发level电平通知GIC（应该是SPI类型的），在suspend状态的时候，不会导致GIC向processor报告中断事件，但是可以唤醒processor，当cpu执行resume的过程中，恢复了GIC的中断检测HW block的功能之后，GIC立刻可以检测到RTC的电平事件（没有clear interrupt，这个level 电平可以保持住），从而触发一个中断。

@linuxer：可以在上半部清中断，不过RTC模块要等几万个cycle之后才会真正把连到GIC的那个irq信号变成inactive

@buyit：为何在bottom half中去清中断呢？那个操作RTC寄存器的动作真的很慢吗？

@passerby：还有点补充，如果是local timer，那CP15寄存器访问形式注册为PPI形式。那么每个CORE都会产生中断并且执行中断服务函数，local timer应该只会让它对应的CORE中断，而让其他CORE也中断？这里不太理解

@linuxer，有个关于system counter local timer的问题。我以高通的代码作为例子 enum ppi_nr { PHYS_SECURE_PPI, PHYS_NONSECURE_PPI, VIRT_PPI, HYP_PPI, MAX_TIMER_PPI }; 35 timer { 36 compatible = "arm,armv7-timer"; 37 interrupts = <1 2 0xff08>, 38 <1 3 0xff08>, 39 <1 4 0xff08>, 40 <1 1 0xff08>; 41 clock-frequency = <19200000>; 42 }; 高通以ppi中断的形式用request_percpu_irq注册了四个ppi中断，我想问这个注册四个具体作用是什么？我有点迷惑这个是global timer还是local timer，而且为什么要以PPI形式注册。 timer@b120000 { 142 #address-cells = <1>; 143 #size-cells = <1>; 144 ranges; 145 compatible = "arm,armv7-timer-mem"; 146 reg = <0xb120000 0x1000>; 147 clock-frequency = <19200000>; 148 149 frame@b121000 { 150 frame-number = <0>; 151 interrupts = <0 8 0x4>, 152 <0 7 0x4>; 153 reg = <0xb121000 0x1000>, 154 <0xb122000 0x1000>; 155 }; 156 157 frame@b123000 { 158 frame-number = <1>; 159 interrupts = <0 9 0x4>; 160 reg = <0xb123000 0x1000>; 161 status = "disabled"; 162 }; 163 164 frame@b124000 { 165 frame-number = <2>; 166 interrupts = <0 10 0x4>; 167 reg = <0xb124000 0x1000>; 168 status = "disabled"; 169 }; ................ 而这几个按照你上面所说的MMIO注册的timer，这几个timer我能够理解是以SPI形式注册不同core的system counter和local timer，但对于cp15上面注册的4个PPI确实不太能理解原理，能解释下吗

请教一个RTC设计的问题： 假设一款SOC里面没有外接的RTC，只有内部的RTC，这个内部的RTC是用timer和counter来模拟的，并不是一个真正的可以设置年月日的RTC。 SOC内部的RTC放在always on的domain里面，系统suspend的时候继续运行。 假设现在android的闹钟设置了一个5分钟之后的唤醒时间，然后全系统进入suspend，那么等闹钟时间到了，假设这个RTC有能力让系统的PMU先收到通知，然后PMU有能力唤醒AP，通常情况下AP core的resume过程是先走一遍ROM code，然后再运行kernel 的resume 过程。kernel resume的时候会把GIC 中断控制器恢复，当GIC 恢复的时候，请问RTC的中断会瞬间被触发从而调用到它的中断处理函数吗？ 假设RTC的irq pin是level-triggered并且在系统resume的过程中irq pin一直处于active状态。 1. 假设RTC的中断处理函数在系统resume的过程中不会被触发，那么很显然系统需要在RTC driver自己的resume函数里面想办法通知RTC framework: RTC到期的事件已经发生了。比如说在RTC driver的resume函数里面呼叫rtc_update_irq() ? kernel里面很难看到类似的实现。。。 2. 假设RTC的中断处理函数在系统resume的过程中被触发，那么看上去一切和系统不睡眠的时候处理RTC事件是一样的，在中断处理函数中呼叫rtc_update_irq()把事件上报给RTC framework层。