今日关键词

 SSA 

cpu

execution barrier  是个啥意思?

笔记笔记

进来部门来了个坡像周笔畅的女孩子。。。。

说正事。。。

每天在本子上写好多笔记,百分之30-50貌似都没什么用。。。

但是至少剩下那些是思想结晶,文化瑰宝吧。。。

怎么把这些笔记循环再吸收呢?

仅仅是学而时习之?

还是要考虑改变一下做笔记的方式了? 

coordinate

两个人分工,可以很顺利的进行么?

各自做好各自的分工,在汇总的时候可以得到彼此的那部分么。。。。

听着这么暧昧呢。。。。 

小组长的烦恼

 想办法帮小弟解决问题  vs   想办法使小弟解决问题

 

何如换个角度?

加入这是一群和你一样平常的并肩战斗的同事,你打算和他们共同分工,并肩战斗。

通过高效的配合完成一个又一个的任务。

这个角度是不是更好一点呢。

 

更深一步,又分两种情况,你知道这件事怎么做,你不知道这件事怎么做,还有就是绝大部分时间,你一知半解。。。。

llvm后端的计划

这次倒是不急着赶快搭调试环境上手调代码了。

首先,有了jedit或ctags之类,看代码也许就不用非得建调试环境了。

另外首先要先学几个语言规范,无非是后端那些模板格式和指令集。

看完这两样,可以先写一个后端模板了,之后就要往上走,进行进一步的优化了。 

AIC

 wordpress一直没建立起来,主要问题是,工作头绪太多总是没有列表和优先级列表,这个东西可以想办法使用calenda来完成。

并且我们貌似还有一个什么plan的软件,也不错。

工具工具工具,被工具锁住的人类,更何况我还是一个工具链工作者。

那个乐队叫什么来着?

ALice In CHains!

但是还是不要忘记建立wordpress哦

沉淀

 每天都盼着工作能有一个新的开始。。。。

不扯淡了。仔细沉淀。

今天的工作有了突破,很高兴。

有很多值得总结的地方,在此,仅指明方向,待以后继续沉淀。

(1)用心。

最近工作遇到了一些瓶颈,这个瓶颈以前不是没遇到过,这次的比较难。

特别是休眠恢复的那个。但是明显可以感觉到,是因为没有用心。

太浮躁,跟大环境有一部分关系,更多的还是内在的修为。

今天也许是巧合,也许是感动上苍,总之,当我发现这个问题在我眼前误解、

当我决心重新审视这个模块,从全局的角度、

当我开始投入的研磨手册中的机关、当我。。。。反正问题突然就明朗化了、也就解决的差不多了。

(2) 方法论。

挑挑大陆同罗马,罗马不是一天建成的,人生没几天好日子。

三理合一,可以知道选择正确的道路是多么重要。

解决pmic不能识别插拔中断的问题,我们分别使用了按图索骥:查DS,顺藤摸瓜:打log,和歪打正着等方法

并最终奏效。

问题代码就是bug,追查bug需要对犯罪现场的了解,需要对作案嫌疑人的了解,需要对作案时间的了解。

更重要的是对第二第三犯罪现场的重现,并找到第一犯罪现场。

最重要的是推断,根据表象推断行为。。

不过这些在追bug的时候都未免太兴师动众了,属于万不得已的方法。

要说最直接的,莫过于看代码。

今天的问题之所以没有找到,一个问题显然在于读代码的时候漏过了一条。

这就是一个积累的问题,对于系统级的代码,有很多结构和机制不熟悉的话,就难辩主次和敌我。

特别是在这个调试过程中,我们往往假设代码本身是没有问题的,只是个别寄存器的设置出了问题。(事实上确实如此。。。。)

但是寄存器设置对于特定设备和驱动而言也是将就时机的,也是要在代码里的,而这部分代码,就成了容易除问题的代码。

bug-prone,所以,如果对系统机制足够了解的话,一些框架性代码就可以认定没有问题,并且可以用来帮助梳理清control path。

这个方向,仍然是我们每天都要面对的问题:系统调试,内核调试,硬件级调试的方法和工具。

(3)新人培养和部门的培训机制:怎样可以让新人更快的上手和融入项目,怎样的组织方式可以更有效的团队开发?

pmic regs

临时记录一下:

interrrupt status    0x000000 

interrrupt mask     0xffff8b

interrupt  sense    0x185200

hald,好滴。

这个hald一点也不好滴。

尤其是底层接口,这个接口很重要,设计到电池充放电的各种状态和统计量。

把这层搞明白了,下面的13892就好捋了。 

近到hald/linux/osspec.c中,可以看到,这明显是OS-Specific 的含义。

在这层中可以看到,hald创建了一个socket用来听消息,来自udev的消息。

并且用g_io_channel 和 g_io_add_watch来添加和回调函数。

这个回调函数就是hald_udev_data,这个函数在受到消息后生成了hotplug_event。

这个event之后被广为传送。

 当然这个传送很简单,就是一个queue:hotplug_event_enqueue();

这个queue的处理在hotplug.c中,有一个hotplug_process_queue。

之后是hotplug_queue_begin,可以看到,这个函数里,对各种hotplug_event进行了分门别类的处理。

就pm而言,其中sys和apm都有接口。

问题在于,我们的系统中两种接口都有,这样会不会引起混乱呢?。。。。

所以我还是倾向于sys接口。

hotplug_event_begin_add()是在hotplug_event_begin函数中专门用来处理add事件的。

当然这个函数根本就不存在,而是实现了不同版本,对于sys而言,就是hotplug_event_begin_add_dev()。

 最贴心的地方马上就要发生啦:就在此时:dev在此文件中被分类了,估计就是根据/sys/class来的,每个类有一个handler

比如我们比较关心的power_supply就有如下dev_handler_power 。

这些handler组成一个数组,每次add remove等等事件中,都轮询一遍该数组。

每个handler又包含add , remove refresh 三个函数。

主要是用来更新数据库。

这样基本就万事大吉了。

可以放心hal这层了,而专注BSP了。

同时hal这层还真是不错,就是命名规则和文档不怎么多,小博也算是小推一下,另外代码也要学学。

话说hal的代码写的还是稍乱滴。。。

 

有了hald的框架,就很容易勾勒出电池管理程序的一个框架:

检测充电器插拔状态,检测电池插拔状态。(可能会有直充启动的情况)。

通过库仑计轮询,累计计算电量:这个环节最关键也最难实现,首先,是取得的值是增量还是绝对值。

显然是后者,这样就很好说了,维持一个最大值就好了,问题在于。。。这个值可能是负的么?