***无法关闭LCD电压
问题描述：在LK里面，为了实现开机显示动画，LCD的IC初始化和引脚上电都放在LK里，并且打出第一张开机LOGO。问题是在这里上电以后，进入系统，机器进入睡眠状态后，LCD相关引脚电压没有关闭。
问题进展：通过和高通支持的沟通，发现在LK和kernel中两种上电方式不一致，在LK里面上电后，kernel根本无法再操作。
在LK中(bootable/bootloader/lk/platform/msm7x30/panel.c)上电的操作代码：
------------------------------------------------------
pmic_write(LDO15_CNTRL, 0x1E | LDO_LOCAL_EN_BMSK);
mdelay(5);
------------------------------------------------------
LK这里是通过I2C接口去写寄存器。
在kernel中(kernel/arch/arm/mach-msm/vreg.c)上电操作代码：
------------------------------------------------------
int vreg_set_level(struct vreg *vreg, unsigned mv)
{
unsigned id = vreg->id;


vreg->status = msm_proc_comm(PCOM_VREG_SET_LEVEL, &id, &mv);
return vreg->status;
}
------------------------------------------------------
kernel这里是通过proc_comm调用bp的接口去操作。
问题解决：尝试在LK里面也采用同样的接口去上电，结果在进入系统，第一次系统睡眠时，LCD相关引脚电压还是未能关闭，当系统被唤醒后，接着睡眠，LCD电压就都可以关闭。所以现在又遇到一个问题是如何解决第一次睡眠就让其LCD电压关闭，因为你不能保证用户在第一次开机，然后长时间让手机处于睡眠状态(比如晚上睡觉)，这样，当用户再次开启屏幕会发现电少了很多，这是个比较严重的问题。但是为什么只有第一次不能关闭，这个现象很奇怪。最终方案是，在第一次睡眠前，进入关电压操作时，我们先在kernel里面对其上一次电，接着再关闭，问题得到解决。
在kernel/arch/arm/mach-msm/board-msm7x30.c中：
-----------------------------------------------------
    if(display_common_power_save_on == 0xff){
rc = vreg_enable(vreg_ldo15);
mdelay(5);
rc = vreg_enable(vreg_ldo20);
mdelay(5);
}
-----------------------------------------------------
问题就此解决。
===================================================================================================
***浏览某些图片会出现flicker现象
问题描述：参见bug:201341.在浏览有些图片，会明显看出LCD有亮点在闪烁。
问题分析：通过分析，这个问题应该是LCD关于极性翻转的问题，在参考其datasheet，在其中找出了关于极性翻转的相关oxB4寄存器。
我们的LCD支持四种极性翻转方式：
1.Column inversion
2.1-dot inversion
3.2-dot inversion
4.Zig-zag inversion
在当前采用的极性翻转方式为两点翻转(2-dot inversion).在浏览某些图片时，两点间液晶分子的翻转互相干扰到了，尝试将其更改为单点翻转(1-dot inversion)，问题得到解决。
====================================================================================================
***优化开关屏唤醒系统的速度
问题描述：在系统进入睡眠状态，按powerkey，系统唤醒要大概1S-1.5S左右的时间。希望能优化到1S之内。我们参照了三星的机器，唤醒时间在1S内。
问题分析：通过对系统唤醒流程的追踪和分析，系统在睡眠是个低功耗模式，在进入睡眠时会把许多外围设备关闭掉，比如LCD,背光，camera，触摸屏等外设。当有唤醒请求时，这些外设要重新进入工作模式就必须对其进行初始化操作，初始化操作就会涉及到时间的消耗。因此我们通过对唤醒过程中哪些设备初始化消耗时间最大，我们就优化哪个。
1.触摸屏唤醒过程可以优化。
---------------------------------------------------------
static void ft5306_reset_func(void)
{
gpio_set_value_cansleep(PM8058_GPIO_PM_TO_SYS(TS_RESET_PMIC_GPIO), 1);
msleep(1);
gpio_set_value_cansleep(PM8058_GPIO_PM_TO_SYS(TS_RESET_PMIC_GPIO), 0);
msleep(1);
gpio_set_value_cansleep(PM8058_GPIO_PM_TO_SYS(TS_RESET_PMIC_GPIO), 1);
msleep(200); //这里将时间降低为50ms
}
---------------------------------------------------------
2.LCD IC初始化可以优化。通过跟LCD IC提供商咨询，LCD初始化序列中有一个睡眠可以取消掉。
3.通过分析和代码跟踪，整个唤醒流程都是在一个suspend进程里面完成，我们尝试将这个进程的执行优先级调高。
通过以上3种方式的优化，我们可以看到唤醒速度是很快的。
问题：在我们后续的测试中，我们发现，如果开一些大应用，让CPU负载很高，比如游戏等。在玩游戏过程中，如果关屏，接着开屏，我们发现整个唤醒过程是很快，但是在屏幕背光打开时，上层应用并没有来得及把相应的LockScreen界面刷下来，于是造成屏幕有Snow Points现象。基于此现象，我们认为，不能把唤醒线程的优先接提高，因为在CPU负载很高的情况下，应用层要获取到CPU是比较困难的，而底层唤醒操作完成以后，就会出现此现象。
最终我们只能做简单的时间优化，线程优先级调整作罢。
=======================================================================================================
***adb和fastboot工具之间的切换问题分析解决。
问题描诉：进入系统，使用adb reboot-bootloader进入fastboot模式烧写镜像，但在烧写完成使用fastboot reboot命令重启，会出现反复的重启，不能正常进入系统。
问题分析与定位：首先要确定要确定系统走到哪一步，由于没有串口(这是个很麻烦的事情)，然后想了个笨办法，直接在LK中把运行到哪一步全部通过文字打印到屏幕(因为LCD已经在BP/LK初始化完成了，可以显示)，通过这样，终于定位到是在LK中有个平台匹配的地方(unsigned board_machtype(void)函数中)，在读取BP通过USB电压采集到的平台信息后，因为BP采集的错误，造成LK读取信息的错误，LK通过cmdline传递参数到kernel时，kernel在使用LK读取的平台信息时出现不匹配，接着kernel停止运行，然后系统重启，反复重启。
问题解决：已经清楚了是平台信息的读取造成的系统挂住，所以可以在BP的平台采集模块做些修正，使其能够正确将平台信息传递到LK以便读取。因此，我们在BP将平台信息写定为某个值，然后传递给LK，问题得到解决。
=======================================================================================================
***机子首次开机出现长震不起
问题描述：使用手机，全擦除后烧写镜像，首次开机出现长震直到系统时钟超时重启，反复如此。
问题分析与定位：从这个现象看起来真有点无从下手，只是一个马达一直震动。我们求助了高通，发过case，但都没有明显的解决问题的方法和思路，也没有有用的建议。我们认为是AP与BP的同步造成的。理论上讲，单独的AP启动后应该不会自动挂起，除非和BP的通讯时等待BP回应，BP如果超时回应就会造成AP超时，接着系统挂起然后重启。BP只是一个功能性的模块，供AP来调用和通讯，所以应该是AP发出调用BP的命令，但是BP没有反应，造成AP的超时等待，最后死掉。但是从log日志来看却找不到一点线索。最后，我们回忆之前的软件版本都没有这个问题，为何会突然冒出来，那么采用最极端的方式——版本回退测试。我通过这个方法，一步步排查，最后在一个驱动文件里面发现了有通过RPC调用BP的命令，一步步跟踪到BP后发现，此调用是在一个task任务里面，问题就是为什么这个task一直没有被执行呢？通过代码跟踪，原来这个task优先级不高。然后查看相关的文档和代码，确定可以将此命令的执行通过中断来，于是改成中断方式调用就OK了。
问题结论：此问题确实让我们对高通平台AP与BP通讯机制以及BP关于task知识的了解更加深刻。
=======================================================================================================
***开机偶尔出现hang住并最终crash掉
问题描述：使用手机，开机过程中会小概率的出现手机挂起直到crash掉，但是都看不出什么问题。查看日志也是一样，没有太多线索。于是我们将kernel中的调式开关全数打开，类似一些警告之类的提示我们都要看。
问题分析与定位：我们经过反复的复现问题，查看日志，终于锁定到一个地方，有一个驱动文件中工程师写的代码存在安全隐患，可能造成内存访问出错，踩错内存。
问题解决：最终问题得到解决，修正了代码的编写错误。
=======================================================================================================