蜗窝科技

感谢分享，希望楼主有时间可以写写classic BT 部分的东西，毕竟两者的差异还是比较大。

@linux_tt：往简单的说，是要的。 往复杂的说，要看是什么样的arch和platform，相关的设计是怎样的（例如怎么样才算是disabled？在硬件上的行为是什么？）。 我们以简单的为例（arm64），大概的过程就是： 1. cpu只能自己死掉。 2. 当其它cpu调用disable_noboot_cpus disable某一个cpu时候，实际的过程是： 设置offline标记； 执行migrate task； 使该cpu idle； 该cpu的idle thread中在进入idle之前，检查offline标记，如果有，自杀，如果没有，进idle（从这里可以看到，自杀也是有工作量的，不能在idle的时候自杀啊）。

@wyn93：1、在看这个文件的过程中发现它其实就是在配置管脚（复用寄存器）的复用功能！ 是的。 2、这个文件中需要列出那些设备有什么决定？ 由硬件决定。 3、您说pin有几种功能是没有关系的，但是我们在区分功能的时候是什么依据？ 你是指状态吗？“default”之类的？状态是根据工作状态，例如正常工作和suspend状态，有些设备可能需要不同的管脚配置。

@wowo: 很漂亮的文章。 另请教个问题， 对于smp多核系统， 如果其他cpu当前进入cpuidle状态，当前cpu执行disable_noboot_cpus， 是否需要把其他cpu从cpuidle状态中唤醒过来，然后再执行migrate task和halt其他cpu的动作等,这里面的流程是怎样的？谢谢。

@linux_fans：其实arch/arm下的代码不乱，你们使用的是老kernel,新的kernel把平台相关的代码都放在dtsi中（即：arch/arm64/boot/dts）;

1. “work item” 是什么？“work item" 指work_struct 这个结构体， ret = queue_work(lsm_workqueue, &sdata->input_work); if (!ret) LOG_INFO("work was already on the queue.\n"); 如果上次提交的work没有执行，而再次调用queue_work，则这个应该是同一个”work item“ 还是不同的”work item“? 即同一个work_struct 是否可以被提交多次，处于pending状态的work就没法再提交了？ 我的需求是每10ms执行一次work，即100Hz，读数据并上报给用户空间， 通过加log发现好像是如果上次提交的work没有执行完，则无法提交；造成的结果就是在上层看来丢数据了， 读数据的频率不是100Hz。 但我觉得不应该这样设计的，不是可以一直提交才更合理吗，类似链表管理一个work_struct的各个提交项目 请帮忙解答下，谢谢~ 2. 关于 @max_active: 如下解释 @max_active determines the maximum number of execution contexts per CPU which can be assigned to the work items of a wq. For example, with @max_active of 16, at most 16 work items of the wq can be executing at the same time per CPU. 我的场景是driver中创建一个workqueue_struct，有两个work_struct A和B，A和B的执行逻辑一样，对应同一个call back 所以问题是： lsm_workqueue = alloc_workqueue("%s", WQ_HIGHPRI | WQ_UNBOUND | WQ_MEM_RECLAIM, 2, "lsm_wq"); 这个参数max_active应该传入2 更合适吗？

最近在做pinctrl这相关的内容，对于xxx-pinctrl.dtsi这个文件的编写中有几个问题，希望可以解惑。 1、在看这个文件的过程中发现它其实就是在配置管脚（复用寄存器）的复用功能！ 2、这个文件中需要列出那些设备有什么决定？ 3、您说pin有几种功能是没有关系的，但是我们在区分功能的时候是什么依据？ 比如： pmx0: pinconf@f8a21000 { pinctrl-names = "default"; pinctrl-0 = < &emmc_p1_pmx_cfg &emmc_p2_pmx_cfg &emmc_p3_pmx_cfg **** >; 其中的属性值，在driver中会读取其中的内容吧！谢谢！

@javier：多谢建议，您说的非常对。不过牵涉到memory、中断等事情，比较复杂，还没有功力把它们融会贯通啊。会朝着这个目标努力的~~

@随风律动：可以参考一下这篇文章：http://www.wowotech.net/gpio_subsystem/pinctrl-driver-summary.html

@lpy ------------------------------------------------------- @wowo：你好，我想问一下，上面提到slave在传输窗口内没有收到包，那会在下一个窗口继续进行接收。那我想问的是如果master在第一个传输窗口发了一个包，slave也收到包了，只是master没有收到slave的发的包，那下一步怎么进行？ ------------------------------------------------------- 1. 无论怎么样，master发包的时间点都是固定的（不管slave收到与否）。因此，master有没有收到slave的发包，是一个“无关紧要”的事情。 2. slave之所以要等master的发包，是为了确定收发数据的时间点（这个是master决定的，参考上1的说明）。 3. 最后，master无法收到slave发包，或者slave无法收到master的发包，都会走后续的超时断开流程（connSupervision）。