解决了USB中suspend和resume的一个问题

      我们公司GSM部门有个双模智能手机的项目。MTK平台和EVDO平台通过USB进行通信。结果在项目测试过程中发现，当MTK做HOST控制EVDO做Device时，HOST控制Device进行suspend和resume状态切换过程中发现状态出现故障。即设备进入suspend之后无法被唤醒。刚开始MTK认为是我们的问题。我们自己验证发现，该功能没有问题。于是让对方换PC做HOST验证。但是因为手机终端的特点和PC大不相同。因此MTK认为无法定位问题在他们。后来我们提供了串口打印设备状态的接口给他们，发现设备状态和现象是一致的。

      MTK仍然不确信我们的终端驱动没有问题。本着能定位和解决问题的目的，就专门出差到深圳。经过两天的联调测试，终于发现MTK的HOST实现suspend和resume中的remote wake up不符合USB协议规范。在咨询公司的一位技术专家后，更加确认了。MTK工程师修改了HOST代码后再次测试，果然发现问题没有出现了。现在就只需要在MTK的质检部门经过验证测试就能最终关闭该问题。经过这个事情后，证明高通的底层驱动还是十分可靠的。

      最新更新：

      后来测试发现上次修改的办法似乎还是有点问题。这个时候我已经对HOST端处理USB协议规范性已经产生了怀疑。因此不主张从设备端的代码来分析问题了，我强烈要求对比USB分析仪日志，分析正常和异常情况，协议包的差异。可是问题有时候总会朝意料之外发展。分析仪好像无法正常工作了，怎么都不能抓到所需的数据包。在和MTK工程师邮件交流的过程中，我开始怀疑他们resume信号的时间是否符合规范的要求。MTK工程师后来反馈，他们这个时间是靠硬件来保证的，但似乎太过临界了。于是他认为用软件做了个信号冗余，从实际效果来看问题概率似乎降到了零。所以这也印证了我的猜想。而高通对该SR的回复也没什么新意，和我的意见一样，让我们提供USB协议包。本来我对这一块并不是很懂的，但这次借助这个机会把这块的代码和基本原理摸了一遍，对自己也是有益无害的。不过这次机会给我最大的锻炼是系统分析能力，至少在之前对这块不是很清楚的情况下能尽快分析出并定位问题。本来之前我对高通驱动部分还是有一丝怀疑的，不过现在我开始相信他们驱动的可靠性了。