蜗窝科技

如果u-boot是64位的，能用它来启动32位的可执行程序吗？

@melo：..我蠢了 其实我一开始就是没找到对应的寄存器,后来发现msm的spec里面已经把TLMM_MPM_WAKEUP_INT 都给出来了

@melo：不对 HW给我们能用的在先 配置设备树在后 应该没关系

@wowo @linuxer 有个问题请教下博主,最近在接触高通的板子,对于gpio而言,所有的gpio都能产生中断,但是只有MPM interrupt才能wakeup 现在的情况是,spec里msm8909这颗U支持的最大MPM 数目是64个 但是硬件给到我们能用的是42个 这42个所谓的能用的 我的理解是还需要设备树配置加enable_irq_wake申请 也就是硬件支持 加 设备树配置 加 驱动申请么(这里其实我有疑问,因为我半路出家所有对硬件有点茫然,不知道我这里理解的硬件支持和设备树配置是不是同一件事)

@笨叔叔：什么时候有货啊？

蓝牙写的很赞!!如果能增加实例分析就好了.比如什么什么场景用到了什么什么技术. 但也知道开发人员忙.加油哈.

@小B：1.确定你访问的地址在内核空间吗，如果不是，需要进行内存映射才能访问。 2.确定你内核中的物理内存的范围。

@raceant：busybox有源码，你去看看实现就可以了，我都五六年没折腾过busybox了，都记不清了～～～

@melo：其实可以换个思路来理解： 确实，很多情况下只有driver最清楚该做什么。但是，如果上层框架（例如bus）也有事情需要做怎么办？ 假如driver的优先级最高，就需要driver主动的调用上层框架的接口，这样耦合度就增加了。 而按照当前的实现，假如上层框架有事情要做，就把控制权交给它，它做完自己的事情之后，再决定怎么把控制权交接给driver（大不了主动调用一下，可参考platform driver的例子，drivers/base/platform.c）。 这背后的思考就是，上层框架要牢牢掌握总控权，底层driver，填空就行了。

@wowo: 对于内部接口的执行顺序有疑问 原文: 4）根据优先顺序，获得用于prepare的callback函数。由于设备模型有bus、driver、device等多个层级，而prepare接口可能由任意一个层级实现。这里的优先顺序是指，只要优先级高的层级注册了prepare，就会优先使用它，而不会使用优先级低的prepare。优先顺序为：dev->pm_domain->ops、dev->type->pm、dev->class->pm、dev->bus->pm、dev->driver->pm（这个优先顺序同样适用于其它callbacks）。 我看博客的时候实觉得有问题,那么这样我在驱动里还折腾什么,优先级这么低不应该阿. 然后我的版本实android6.0的内核代码,发现 if (dev->pm_domain) { info = "preparing power domain "; callback = dev->pm_domain->ops.prepare; } else if (dev->type && dev->type->pm) { info = "preparing type "; callback = dev->type->pm->prepare; } else if (dev->class && dev->class->pm) { info = "preparing class "; callback = dev->class->pm->prepare; } else if (dev->bus && dev->bus->pm) { info = "preparing bus "; callback = dev->bus->pm->prepare; } if (!callback && dev->driver && dev->driver->pm) { info = "preparing driver "; callback = dev->driver->pm->prepare; } 也就是驱动driver->pm应该可以说是优先度最高嘛,毕竟自己的事自己最清楚.