问题很奇怪,定位很烦琐,修改很简单!

这个问题困扰了很久,一直奇怪为什么同样的代码,同样的硬件配置,在另一个项目中是正常的,在这个项目中就是不行。不幸啊!

问题是这样的,卡一直在,系统sleep-wakeup之后,卡中的很多文件及目录都没有了。其实,不是没有了,是没有识别了,并且不是全没有,是sleep之前访问到的同级目录之后的都没有了。这个还是可以解释的,文件系统在sleep之前记住了这些目录,至少是所访问到的目录的深度。电是一直供着的,pwr-downpwr-upsd的驱动是没有任何操作的。照正常情况来说,在sleep期间没有拔插卡,醒来之后至少可以读写卡的,但是现在什么都不行。所以这个说来就是奇怪。查遍整个工程,也没有发现哪个针对sdio口在别处被占用了。在wakeup的时候模拟卡的一次拔插,是可以规避解决这个问题,别的问题先不说,就一个速度问题就已经不可忍受了。不过越想越是这个问题,一定是数据口被怎么搞没了。恢复原来的代码,直接在pwr-on的时候重置了数据位的配置。好了!时间急任务重,就先这么着吧。

不过还是高兴的有点早了,在sleep期间拔出sd卡再唤醒系统,在对sd卡操作的时候竟然挂了。但是在sleep期间插入的话,是没有问题的。跟踪代码,结果一无所获。对于上面的问题,是在sdhc的驱动来通知上层unmount的时候挂了,文件系统的东西我是不太会去怀疑的。不同的音频驱动,竟然会影响sd卡唤醒后的不同。可能是注意wakeup时的串口消息注意的太多了,无意间发现了这个:ERROR: Power Handler function yield to low priority thread.救命稻草啊!

In V5.0 MS added a power down thread so that power down handlers are called on a thread instead of in the former no-thread kernel context.

The documented idea is that you can now handle synch objects in powerdown code. (There are still limits to synch objects so CloseHandle is still off limits.)

Unfortunately, they implemented this in a way that generates the error mentioned if the driver's powerdown function blocks on a thread of lower priority, which would be normal for an application that called into the driver and has acquired a lock on the synch object in question.

So the upshot is that you are supposed to be able to do synch stuff in power handlers and under light testing might even seem to work but it is virtually guaranteed to fail at some point in the future, usually well after product release. So don't do that.

 

先将目前的threadpriority 设置为最高,timeslice 为“永远”
调用GWES driverpower off function
调用PowerProc,会一一调用各device driverPowerDown( )
硬件 poweroff ---- suspend,直到有人power - resume
调用PowerProc,会一一调用各device driverPowerUp( )
调用GWES driverPower on function
将目前的thread设回原来的TimeSlice & Priority
Device Driver
PowerUp/Down function 就是在PowerProc( )调用的,也就是run priority 最高,no timeslice consume 的状态。除非该driver funciton 自行release 控制权,否则不会被task switch 掉。

这样说来就比较清楚了,是在power-up的函数中有sleep函数的调用了。还真是,在音频驱动中的。