[原创]AC In/Out OS Slow Response
AC In/Out OS Slow Response[*]Phenomenon
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
图 1[*]Why???
刚看到这条bug时，我有点不以为然，因为有些机种也有这样的状况，所以我以为这个有可能是不同的测试人员认知上差异。而且超薄NB为了解决好功耗、导热的问题都使用比较低的配置，我最初还觉得可能跟配置有关。但是他们找了个相同chipset的机器去试，反应很流畅没有这样的现象L!我的猜测站不住脚了，这时我觉得应该是FW有些地方没有处理好导致的了。随后我们开始debug，首先我们要理清AC in/out 过程中EC、BIOS、OS都做了哪些动作,我所知道的状况是这样：1. EC检测到AC in/out的中断，更新EC ram中的AC状态并引发SCI IRQ通知OS。2.OS收到SCI IRQ后调用BIOS中的_Q method并通过Notify function通知OS power source change。3.OS调用_PSR function获取AC的状态并据此更新power icon显示。上述過程sample code 如下述所示：
// AC Change event
Method(_QXX)
{
Store(0x09, DBG8)
Notify(\_SB. ADP,0x80)
//Power Source status changed
Store(0x0A, DBG8)
}
Method(_PSR,0)
{
Store(0x0B, DBG8)
If(ACST)
//check AC status
{
return(One)
// AC Present
}
else
{
return(Zero)
// AC Not Present
}
Store(0x0C, DBG8)
}
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
Method(_BST)
{
Store(BSTS,Local0)
If(LEqual(Local0,1)) //Check Battery Present Bit
{
//Read Battery information from EC
… …
}
Store(0x0D, DBG8)
}
那么问题好像是由读EC ram导致的，ACPI中读取EC内容的方式是发0x80 cmd到ox66 port，随后EC产生一个SCI通知OS，接着OS将EC ram index发给0x62 port，EC将数据送给0x62 port再产生一个SCI通知0S，接着OS读0x62 port就获得了EC ram指定位置的数据了。我在EC 端加入debug信息，发现出现状况时0x80 cmd EC很晚才收到，0x80 cmd是OS发的，所以貌似和EC也没什么关系吗？继续思考，EC产生一个SCI的目的应该是产生一个IRQ让ACPI driver获悉前面的指令已经完成，ACPI driver可以继续送指令下来了。如果某一条指令慢则有可能是前一个SCI IRQ通知 ACPI drive而 driver还没有处理好导致，也有可能ACPI driver已经处理好但是EC没有ready所致。
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
而BIOS对SB SCI pin通常配置成low edge trig， SCI的pulse trig有个优点就是它能够自动复位，产生一个中断后SCI pin会pull high。可是因为BIOS是下降沿触发，所以EC SCI保持64us低电平会不会太长呢？会不会导致ACPI driver收到IRQ后下命令给EC,而EC SCI pin还没有复位而太久才收到？又或者说EC SCI pin保持低会影响到ACPI driver IRQ latency？有了这个想法以后，我就开始放大它，修改EC SCICFG将SCI IRQ配置成128 us pulse trig，然后再做AC in/out的实验，嘿嘿病情加重了，fail率接近了80%之前只有10%；那我再将pulse width调整为16us再试，结果200次竟然没有一次出现症状J.
[*]Solution
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
That’s all!
Peter 原来如此！！！
谢谢！ Bug起因为本 好帖，学习了 谢谢！！！！！
好贴
感谢分享！真的很有用，以前我也遇到这个问题，还以为是OS的问题呢！真的好贴啊！我看了您的分析代码，好像不是EC的代码吧！我现在就是OS-BIOS-EC三者的关系有点迷糊，版主能否指点一下！谢谢 hehe...
很高心这篇文章能够对你有帮助。
上述代码是BIOS中的ASL code，理清OS-BIOS-EC之间的关系的最好途径就是
ACPI spec，没事翻翻ACPI spec会有不少收获的。
谢谢
感谢指导！谢谢！有时间经常关注你帖子。请教一下，关于oemmain.c中的几毫秒中断问题
您好！我现在手上有一个小本项目！用的是华邦的代码！我发现在oemmain.c中的几毫秒中断中是不是不能添加太多的代码啊！打个比方我就在一毫秒中断里加的代码，而这些代码是执行时间加入超过了一毫秒，是不是会造成EC死掉啊！因为在我修改后的代码发现有时很不稳定！我想了想是不是问题出现在这！请指教一下 中断的处理通常分顶半部和底半部,很多driver都是这样处理的.简单来讲就是在中断到来时置flag,后续再处理(DPC).
感谢回复
谢谢了！刚才我又仔细的查看了一下我的代码！终于找到了！EC死掉的原因了，就是我在上电时序那加了一个类似看门狗的小程序！来保证开机的效率。结果硬件始终有一个S电没有上来才导致我EC死在那里。对于您的解释我还是有点迷糊！对winbond的EC他的oemmain.c中的1MS，10MS，100MS，500MS，1000MS。它用的是中断还是轮询！！中断和轮询是不是没有什么太大的区别啊！我现在就是担心我在比如1MS的函数里加的代码太多，会不会出现在这段代码执行一半的时候，1MS的中断又来了。那代码不就不能完全执行了吗？
回复 10# zhanghmjm 的帖子
oemmain.c的是service，是具体的执行处理过程，而实际的中断呢，是由Timer 来触发的（有定时1ms），只要不在中断的Routine 里加太多东西，在 service 里加，应该没事。个人看法，呵呵 谢谢了！明天有时间我做个小的实验！我想就应该清楚了，到时与您分享！呵呵 为啥你们的是C，我的是汇编啊，:'(回复 13# amty.wang 的帖子
用汇编写才牛呢，呵呵 文章很精采,分析很透彻!:victory: conol你也來這里了
呵呵...
请教一个关于重启的问题
您好！不好意思又打扰你了，我现在遇到一个问题就是在重启电脑时EC为什么会几率性的死掉！在重启的时候我们EC都做什么啊！现在真的有点头痛了！！！ 之前有追过reboot它的大致过程是这样的：
1.BIOS发FE给KBC,KBC pull low KBRST#一段时间，然后sb会将init# pin pull low 16个pci clock
chipset reset pci reset系统重启。
2.一旦重启后面的动作看上去正常开机没多少差别，对ec来讲无非是keyboard init、进出idle（update escd）
等等一些琐碎的动作。
之前碰到问题比较多的地方就在idle这部分了。
你所说的EC死掉指的是所有的function 都失效吗？keyboard能不能用，hot key能用吗，四秒关机呢...
还有如果单台fail几率比较高，建议你接串口debug去看EC死在哪里。
以上希望对你有所帮助。
重启死机
谢谢您的答复！我在做重启的时候EC是死掉的，四秒不能关机。键盘和热键无效！至于死机的原因真的很难找的。因为串口debug调试的功能我还没有弄呢！
对了您说的BIOS发ＦＥ给我们ＥＣ应该是通过SCI吧！请指教一下！ to zhanghmjm:
BIOS发FE不是通过SCI,而是透过60h，64h port。
BIOS应该没有办法发SCI给EC，而EC是可以发SCI给BIOS的。
页:
[1]
2