要点亮一块驱动ic为ILI9881C的屏幕，看了soc的屏幕配置目录，发现有带该ic的屏幕配置，估计一两个小时就能完成移植。配置了相应的复位脚，上电脚后，发现在uboot阶段读不了id。当然，可以先在读id函数中直接返回0，先发屏幕配置，看能不点亮屏幕，点亮屏幕后，再来解决id问题。发现在uboot阶段没有点亮屏幕，但进内核后，能概率性的点亮屏幕(通过input keyevent 26，模拟电源键，重新初始化屏幕)。
能想到的，应该是时序不满足要求，导致发配置失败。找相应的规格书看下https://download.csdn.net/download/mike8825/12503211，这里用的是Power Mode 3，时序如下
时序要求不高，且代码已按时序进行了配置，但为什么概率性的点不亮屏幕呢。
再看下屏厂提供的规格书，写着驱动IC:天钰 9365AA(也就是JD9365AA)，难道项目组那边搞错了，发来的配置不对，导致概率性无法点亮屏幕的情况。一翻联系后，屏厂那边确认ic是ili9881c，jd9365aa缺货导致更换成了ili9881c，也就是发来的规格书有误。
当然，屏厂的话也不能全信，不排除他们那边会弄错，如果能读到屏的id，那不就能消除疑虑了吗。
也就是写0xff寄存器为98h 81h 01h，先切换到page1，再来读00h 01h 02h寄存器即可。因为soc厂商有提供sys接口来写寄存器，在正常显示的情况下，读写00h-03h，返回的值分别是98h 81h 1ch，那驱动ic也就确认是ili9881c了。
但为什么概率性无法正常点亮屏幕呢。
难道是延时的时间不够，把上电和复位的时间都加大了，神奇的事情发生了，概率性无法点亮屏幕的情况消失了。最终定位到是复位脚拉低的时间不够，但规格书里写着大于10us就行了，程序里默认是5ms，改到10ms才能正常点亮屏幕。
接下来的工作是在uboot阶段点亮屏幕。参考kernel的点屏经验，把复位脚拉低的时间加长，能读到屏的id，但屏幕依然无法正常点亮，看log也没有相应的通信错误。于是在发送每条命令后，都延时一会，屏幕又点亮了，最终发现发送0x11加点延时就能点亮屏幕了，但给的屏幕配置了也没看到延时，规格书了也没有写。
总结就是，延迟不够导致调试时间加长。所以在调屏阶段，遇到无法正常显示的情况，可以使劲加点延时，没准屏幕就亮了呢。