蜗窝科技

@ooonebook：通过arm-none-linux-gnueabi-objdump把uboot-spl反汇编出来看了一下，sp里的堆栈地址确实是有问题的 00000110 <_main>: 110: e59fd01c ldr sp, [pc, #28] ; 134 <_main+0x24> 114: e3cdd007 bic sp, sp, #7 118: e1a0000d mov r0, sp 11c: eb000012 bl 16c <board_init_f_alloc_reserve> 120: e1a0d000 mov sp, r0 124: e1a09000 mov r9, r0 128: eb000012 bl 178 <board_init_f_init_reserve> 12c: e3a00000 mov r0, #0 130: eb000009 bl 15c <board_init_f> 134: 20ffff40 rscscs pc, pc, r0, asr #30 110: e59fd01c ldr sp, [pc, #28] ; 134 <_main+0x24> 所以堆栈的地址是134: 20ffff40，这个确实是DRAM的地址，所以是有问题的。 但是从反汇编出来的文件中可以看出来，C函数可以正常的原因是因为没有汇编的过程中并没有被解析出push和pop指令： 0000015c <board_init_f>: 15c: e3a00001 mov r0, #1 160: eafffff4 b 138 <tiny210_early_debug> 00000164 <lowlevel_init>: 164: e3a00004 mov r0, #4 168: eafffff2 b 138 <tiny210_early_debug> 00000138 <tiny210_early_debug>: 138: e350000f cmp r0, #15 13c: c3a00000 movgt r0, #0 140: e59f3010 ldr r3, [pc, #16] ; 158 <tiny210_early_debug+0x20> 144: e3012111 movw r2, #4369 ; 0x1111 148: e1e00000 mvn r0, r0 14c: e5832280 str r2, [r3, #640] ; 0x280 150: e5830284 str r0, [r3, #644] ; 0x284 154: e12fff1e bx lr 158: e0200000 eor r0, r0, r0 并且反汇编出来的汇编文件中，都没有看到push和pop的指令，这也许就是sp设置错误但是还是可以正常调用C函数的原因吧。 不过我还是把CONFIG_SPL_STACK设置成正确的RAM地址比较靠谱吧。

hi,wowo,目前开始移植uboot.bin了，然后看到sp的设置，想对比一下uboot.spl的堆栈设置，但是发现有个问题实在搞不清楚。 在之前uboot.spl中还没有移植DDR初始化代码的时候，就已经在board_init_f点亮LED了。 但是在arch/arm/lib/crt0.S中 73 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) 74 ldr sp, =(CONFIG_SPL_STACK) 75 #else 76 ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) 77 #endif 但是其实我现在发现CONFIG_SPL_STACK我并没有配置，编译uboot-spl的时候，也确实是ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)，但是这个地址其实是在DRAM空间，也就是我还没初始化的那部分DDR的空间，理论上堆栈的使用应该会有问题才对，C函数应该也不能调用，但是为什么board_init_f却可以正常调用呢？？？ 这个问题昨天研究了一天了还是没搞清楚。 怎么去查这个堆栈地址呢？

@bubble：有可能其他cpu摘下的clock_event_device在这个cpu还可以再抢救一下

@狼花1997：大致的过程，是：spi_add_device-->device_add，具体可以拔拔spi的代码： https://github.com/wowotechX/linux/blob/x_integration/drivers/spi/spi.c 刚好可以借助理解设备模型的概念~

我想问一下sys/bus/spi/devices/spi1.0 这个spi1.0 是如何注册得来的啊

@junjun：它的意思是，当调到各个driver的suspend_noirq时，系统的irq已经被disable了，你可以放心的做你想做的事情。 当然，什么事情需要在中断被disable的时候做，只有这个driver自己知道了。

linux kernel documen文档devices.txt里有说"The suspend_noirq phase occurs after IRQ handlers have been disabled, "， 没有明白这里的IRQ handler怎么对应到我的platform_device上，我现在platform_driver的suspned_noirq会被调用到，但并没有相关的IRQ啊，当然也没有IRQ handler disable。求博主解惑啊，暂时还没有能力研究PM内部的代码。

@hongxiaoh：假设combined_event_count是32bit wakeup events in progress和registered wakeup events各占16bit，即：wakeup events in progress | registered wakeup events. 注：上面有一个隐含的规则：registered wakeup events > wakeup events in progress（很重要，不然会有问题） 而MAX_IN_PROGRESS等于((1 << 16) - 1)，即0xffff 那么combined_event_count + MAX_IN_PROGRESS = ？ 假设combined_event_count=0x0 0001，则为0x1 0000 假设combined_event_count=0x5 0009，则为0x6 0008 实际上就利用了简单的进位操作~~~

cec = atomic_add_return(MAX_IN_PROGRESS, &combined_event_count); wakeup events in progress减1，registered wakeup events加1 请问这个具体是怎么实现加减的？

@wowo：多谢了，我试试