***无法关闭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中的调式开关全数打开,类似一些警告之类的提示我们都要看。
问题分析与定位:我们经过反复的复现问题,查看日志,终于锁定到一个地方,有一个驱动文件中工程师写的代码存在安全隐患,可能造成内存访问出错,踩错内存。
问题解决:最终问题得到解决,修正了代码的编写错误。
=======================================================================================================
问题描述:在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中的调式开关全数打开,类似一些警告之类的提示我们都要看。
问题分析与定位:我们经过反复的复现问题,查看日志,终于锁定到一个地方,有一个驱动文件中工程师写的代码存在安全隐患,可能造成内存访问出错,踩错内存。
问题解决:最终问题得到解决,修正了代码的编写错误。
=======================================================================================================