蜗窝科技

@画像：是的，这样理解也没问题。每个人都可以有自己的理解，只要把事情搞懂就行了:-)

博主真的写的很好, 赞一个! 对于文中"用Device（struct device）和Device Driver（struct device_driver）两个数据结构，分别从“有什么用”和“怎么用”两个角度描述硬件设备" 对于这句话我感觉和机制与策略比较类似, device的数据结构提供了有什么功能, device driver的数据结构则说明了怎么用这些功能, 这不就是机制和策略吗, 新手一个, 不知道这样理解是否正确.

@smcdef：我由衷的佩服你, 短短工作几年, linux造诣已经如此之深, 如果有更加合适的平台你会腾飞的; ps:我经常和你们公司打交道

@dkfdhrsn：又跟了下代码，在irq_exit里面会执行这个流程： tick_irq_exit->tick_nohz_irq_exit 如果还是idle，里面会检测是否有新的timer，然后将sched_timer加进去~ 估计还是要加log看到底跑哪去了，从之前debug的表象来看，timer是add进去，但就是没执行到，不知道哪里流程出问题了

@linuxer,有个问题请教下，最近发现了个add_timer无法执行的问题，感觉和dynamic tick有关： -------------- 1.high res mode下，clockevent的handler是hrtimer_interrupt,里面会执行expires到达的hrtimer_callback 2.higg_res里面会构建一个特殊的hrtimer:sched_timer来模拟periodic tick，expires会reprogram来模拟 3.当进入tickless mode时，比如是通过idle进入，里面会停掉periodic tick,当然这里会遍历time wheel来设置最近一次的trigger event时间点，不过这里会设置tick_sched->is_stopped=1，表示stop periodic tick 4.假设现在已经停掉了periodic tick，最近一次的event也到来了，那么会执行hrtimer_interrupt,一些关键的flow如下： hrtimer_interrupt->__hrtimer_run_queues->__run_hrtimer->这里遍历执行hrtimer的callback，以sched_timer为例，那么执行的是tick_sched_timer 这里面有个判断如下： if(ts->tick_stopped) return HRTIMER_NORESTART, 也就是前面提到的因为进入了tickless，这个不需要再次trigger了 但是在hrtimer执行的过程中： __run_hrtimer __remove_hrtimer rlt = hrtimer->function() if (rlt != HRTIMER_NORESTART) __enqueue_hrtimer 这就是说一旦进入了tickless，sched_timer就被从hrtimer_list里面remove掉了，当然再退出idle的时候会再次加进来 但是问题就在于此，假如idle持续一段时间，add_timer这种形式添加的low resolution岂不是无法执行了？ 虽然oneshot还在更新time wheel的trigger时间点，但是add_timer这种是属于SOFTIRQ_TIMER类型的软中断，执行时机是在irq_exit的时候判断对应type的pending状态位， 而对于high res mode，这个raise_softirq(SOFTIRQ_TIMER)的地方是在如下地方： tick_sched_timer->tick_sched_handle->update_process_times->run_local_timers->raise_softirq(SOFTIRQ_TIMER)， 而在tickless模式，这个sched_timer已经被拿掉了，也就是说没有地方进行raise设置pending了，所以就无法执行了？ 不知道上面的逻辑有问题没，因为加log看到的现象差不多就是如此，如果理解没有问题的话，那么这是个bug吗？还是说在high res mode下这种是预期的，现在这边产品是利用add_timer来进行喂狗操作[先不管是否合理]，有时候会出现咬狗复位，感觉就是这个问题导致的 PS:现在论坛注册被关闭了，不知道放在这里大神还能看见不，求解答啊 0.0

很遗憾今天才看到你的网站，相当给力

@ailon：说下个人理解： 每个UART的中断输出都是连接到同一个中断控制器吗？ 如果是的话，应该是不同的中断引脚，其硬件中断编号必定不同。 如果不是，中断控制器是多个，那么中断Domain不同。 更甚，多个UART share一个中断Pin，那么就要看中断控制器本身有没有区分方法，知道是哪一路过来的中断

hello，问下哈 我在用imx6做linux开发， 系统可以睡眠，但唤醒时有时会系统reset。您知道是为什么么

@unisch：先留着疑问，往后看这系列的文章。第四篇PELT看完，应该就能理解，差不多是可以近似的。 http://www.wowotech.net/process_management/450.html

``` .macro svc_entry, stack_hole=0 sub sp, sp, #(S_FRAME_SIZE + \stack_hole - 4)－－－－sp指向struct pt_regs中r1的位置 stmia sp, {r1 - r12} －－－－－－寄存器入栈。 ldmia r0, {r3 - r5} add r7, sp, #S_SP - 4 －－－－－－r7指向struct pt_regs中r12的位置 mov r6, #-1 －－－－－－－－－－orig r0设为-1 add r2, sp, #(S_FRAME_SIZE + \stack_hole - 4)－－－－r2是发现中断那一刻stack的现场 str r3, [sp, #-4]! －－－－保存r0，注意有一个！，sp会加上4，这时候sp就指向栈顶的r0位置了 mov r3, lr －－－－保存svc mode的lr到r3 stmia r7, {r2 - r6} －－－－－－－－－压栈，在栈上形成形成struct pt_regs .endm ``` ------------------------------------------------------------------------------- linuxer 您好，我认为这里的 `add r7, sp, #S_SP - 4` 应该是让 r7 指向 ARM_sp 。如果是指向 ARM_r12 , 应该是 add r7, offsetof(ARM_r11) 即可。 这里之所以是 add r7, offsetof(ARM_SP)-4 ,我个人理解是因为此前 sp_svc 指向 ARM_r1 , 在此基础上 + offsetof(ARM_SP) 会让 r7 指向到 ARM_lr ,所以需要 -4 以修复偏差。请您看看我的理解对否。