蜗窝科技

@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层。

请教各位： 我现在用的一个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是最少的，但是我很难找到其它平台使用类似的代码，因此我想是不是还有更好的解决方式？

@shoujixiaodao：可能是新事物吧，被接受需要一定的过程，我也不是很清楚。

不过我看到kernel里面使用QOS的地方太少了。不知为何，wowo大神知道吗？多谢！

@linuxer：嗯，这下子明白了，谢谢wowo和linuxer两位大神！