蜗窝科技

@linuxer：多谢，你很严谨，希望以后能多跟你交流。

@chunhai：我也是仔细的查了一下。 SPI PPI属于 peripheral interrupts 也是是SPI PPI，N-1的意思我是这样理解的。只有一个CPU 去响应中断，其他的CPU 是不响应中断的，即使是其他的CPU同时响应了，但是过不到锁，也是只有一个CPU 处理中断。 不知我的理解对吗？ In a multiprocessor implementation, the GIC handles: — SGIs using an N-N model, where the acknowledgement of an interrupt by one processor has no effect on the state of the interrupt on other CPU interfaces — peripheral interrupts using a 1-N model, where the acknowledgement of an interrupt by one processor removes the pending status of the interrupt on any other targeted processors, see Implications of the 1-N model on page 3-8. In a multiprocessor implementation, the GIC uses a 1-N model to handle peripheral interrupts that target more than one processor. This means that when the GIC recognizes an interrupt acknowledge from one of the target processors it clears the pending state of the interrupt on all the other targeted processors. This model means an interrupt can be handled by the first available processor. However, the interrupt might generate an interrupt exception on more than one of the targeted processors, for example if two of the targeted processors recognize the interrupt exception request from the GIC at similar times. When multiple target processors attempt to acknowledge the interrupt, the following can occur: • A processor reads the ICCIAR and obtains the interrupt ID of the interrupt to be serviced, see Interrupt Acknowledge Register (ICCIAR) on page 4-56. More than one target processor might have obtained this interrupt ID, if the processors read their ICCIARs at very similar times. The system Interrupt Handling and Prioritization ARM IHI 0048A Copyright © 2008 ARM Limited. All rights reserved. 3-9 Unrestricted Access Non-Confidential might require software on the target processors to ensure that only one processor runs its interrupt service routine. A typical mechanism to achieve this is implementing a lock on the interrupt service routine (ISR), in shared memory. This might operate as follows: — each target processor that obtains the interrupt ID from its read of the ICCIAR runs a semaphore routine, attempting to obtain a lock on the ISR corresponding to the specified ID value — if a processor fails to obtain the lock it does no further processing of the interrupt, but writes the interrupt ID to its ICCEOIR, see End of Interrupt Register (ICCEOIR) on page 4-59 — the processor that obtains the lock handles the interrupt and then writes the interrupt ID to its ICCEOIR. • A processor reads the ICCIAR and obtains the interrupt ID 1023, indicating a spurious interrupt. The processor can return from its interrupt service routine without writing to its ICCEOIR. The spurious interrupt ID indicates that the original interrupt is no longer pending, typically because another target processor is handling it.

@wowo：其实在国外（指那些发达的资本主义社会），程序员和通厕所的工人收入是差不多的，因此，在国外，选择做软件工程师的那些人都是真正热爱这个行业的人，目前，国内很多都是觉得软件工程师的收入不错，就加入这个行业，其并没有发自内心的热爱。 另外，更重要的是国内的环境，我们办这个网站不就是为了改变国内的环境吗？消极的做法是：大环境如此，我们随波逐流就好了，积极的想法是：改变总是有开始，从我做起就OK了。 我们已经选择了积极面对

修改了强制线程化的内容，原来的理解有偏差

@linuxer：确实，如果场景复杂的话，要考虑workqueue，无论到什么时候，driver尽量不去直接使用kthread。

@linuxer：我记得你在讲中断的时候有讲到这一点。 IRQF_ONESHOT one shot本身的意思的只有一次的，结合到中断这个场景，则表示中断是一次性触发的，不能嵌套。对于primary handler，当然是不会嵌套，但是对于threaded interrupt handler，我们有两种选择，一种是mask该interrupt source，另外一种是unmask该interrupt source。一旦mask住该interrupt source，那么该interrupt source的中断在整个threaded interrupt handler处理过程中都是不会再次触发的，也就是one shot了。这种handler不需要考虑重入问题。 具体是否要设定one shot的flag是和硬件系统有关的，我们举一个例子，比如电池驱动，电池里面有一个电量计，是使用HDQ协议进行通信的，电池驱动会注册一个threaded interrupt handler，在这个handler中，会通过HDQ协议和电量计进行通信。对于这个handler，通过HDQ进行通信是需要一个完整的HDQ交互过程，如果中间被打断，整个通信过程会出问题，因此，这个handler就必须是one shot的。

@forion：并不是所有的获取电量都是那么的简单，可以在timer中完成，例如电池中的电量计是HDQ 接口或者I2C接口的，这种情况下，获取电量的函数需要调用HDQ core或者I2C core的接口，而那些接口有可能睡眠的。如果在timer中调用，会死的很难看的（这不是一个100％重现的bug，偶尔会挂掉，发生在无法获取总线访问权限的时候）。 当然，即便如此，使用线程也不是一个好的方法，可以考虑workqueue。

@puppypyb：对，我是从代数和几何的角度来看欧拉公式，其物理意义嘛，我也看不出来，也许它就是一个工具，用于计算，可以解决很多实际的问题

@wowo：wowo是搞power的专家，一般的电量检测都是用timer来做的，开线程实在是太不按套路出牌了。

@duak,我觉这里面可以从3个方面考虑： 1. 定时获取电量，是否有必要开线程？ 线程的开销是比较大的，起一个timer反而会更好。 2. 如果真的需要线程的话，suspend和resume不需要处理，就算你处理了，也是多余的。因为当执行到driver的suspend时，thread早已被PM core freeze掉，当执行到driver的resume时，kthread_start是无法生效的，还得等到PM core后续的处理。 3. 如果真的需要在在suspend和resume中start和stop线程，也没关系，什么意外都不会发生。