omap 3530 kernel i2c 调试笔记

i2c一次完整的驱动读写

 

结合调试过程分析，加上打印信息更加直观。

 

文件：drivers/i2c/busses/i2c-omap.c

所有的调试代码以及注释都写在了这个文件中。以下主要是以文字记录了调试的过程以及一些疑问。在最后的分析中结合了其他芯片的操作。还是得到了一定的解释。这里把所有的想法直接记录在.c文件中。

 

omap_i2c_xfer_msg 430

0x5400 ：101010000000000

omap_i2c_isr 665

omap_i2c_isr 736

 

omap_i2c_xfer_msg 465

0x1004 ：1000000000100

omap_i2c_isr 665

omap_i2c_isr 690

 

omap_i2c_xfer_msg 472

0x104  ：100000100

omap_i2c_isr 665

omap_i2c_isr 690

 

omap_i2c_xfer_msg 512

 

首先是trace。这个trace纪录发送函数的过程。在发送函数的过程中伴随着中断的处理。在每一次处理的过程中把函数以及行号打印出来。可以直观的看出内核和中断的上下文切换。

下面的bits是STAT寄存器的使用。判断哪些位发生了变化。具体的内容查看OMAP3530 datasheet。

bit[ 14 - 0]

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

-----------------------------------

STAT REG

1  0  1  0  1  0 0 0 0 0 0 0 0 0 0

      1  0  0  0 0 0 0 0 0 0 1 0 0

                 1 0 0 0 0 0 1 0 0

1  0  0  0  0  0 0 0 0 0 0 0 0 0 0

-----------------------------------

IE REG （init status）

1  1  0  0  0  0 0 0 0 0 1 1 1 1 1

-----------------------------------

IE REG （runtime status）

1  1  0  0  0  0 0 0 0 0 1 1 1 1 1

-----------------------------------

 

函数分别是：

问题 1 ： 触发中断前后中断寄存器的变化 STAT REG 内容比较。

对于一次常规的I2C的读写触发了三次中断，每一次中断的中断源定位。

中断源的定位可以参考上面图标的STAT REG中的内容。

对于每一次i2c的操作是如何初始化中断寄存器。

没有初始化STAT REG寄存器的内容。每一次中断中都判断STAT REG的内容，并把最新的内容拿来作比较。

对于哪个寄存器的操作可以引发i2c的中断。

首先要查看的是中断控制寄存器的初始化内容：分别初始化的中断位是：IE REG（init）中的“1”位。

对于第一次中断主要是由于bit[14] = 1而导致。 TRANSMIT DRAIN。

对于第二次中断主要是由于问题 3 讨论的结果。ACCESS REGISTER READY。

       

问题 2 ： 触发中断后，关于STAT REG内容和IE REG内容做逻辑与，后发现内容不可靠。

使用十六进制的打印后发现内容逻辑运算后不匹配。

对于这个问题，解释是打印的关键信息有误。在STAT REG 和 IE REG内容比较的时候发生了错误。

       

问题 3 ： 触发中断后，CNT REG内容是否会判断。

    是否存在这样的一种中断，当CNT的值减少为“0”后，触发一次中断，在这样的中断后是通过STAT REG哪一位表示的。

    中断函数立刻返回kernel空间后，如何响应第二次，第三次中断？

    对于这个问题，CNT REG 的内容的递减到“0”，却是会导致中断。但是这个中断发生在中断处理函数中，是不是会再次响应中断。

    这个就是中断嵌套的问题。这个中断实不会中断ARM CORE正在处理IRQ的代码。

 

问题 4 ：STP bit是不是导致第三次中断的主要原因。

在三次中断函数处理中。每一次都会伴随的一种中断的中断源。

还有存在的一个疑问：在中断类型中有一个类型叫做bit[2] ARDY REG。描述如下：

        1，CON REG stop bit清除时。

        2，CNT REG 中数值变为“0”时。

    会产生一个中断，中断状态描述为，ARDY ACCESSE READY，并且前面的操作是正常的。

    对于以上第二点。变为的理解，在中断函数处理中对DATA REG有过两次操作。分别是把reg-address和data写入

    DATA REG（参考I2C的报文格式）。那么每一次写操作，都会使CNT REG的内容递减，但是没有递减到“0”。

那么现在STP 出现在CON REG后，会不会把CNT REG减少为“0”。

 

在上述的过程里面，唯一不能确定的是第二次中断。STAT[ARDY]表示的是那种类型的中断导致的。看了datasheet没有得到确切的答案。在自己的调试过程中，也没有理出头绪。还望高手大侠指点。但是对于CNT寄存器的设置会导致不一样的后果。结果就是kernel死在那里不运行了。这里仅仅是猜测。具体的后果到底是卡在中断里面了还是在内核的环境不从知晓。

 

试验：

为了验证CNT寄存器的设置影响了I2C的性能。通过GPIO的灯演示程序的可执行地点。

首先通过试验指导GPIO-LED 4-6分别对应的数据结构。

发现在I2C中断之后没有再次点亮LED。这里的分析和没有中断的uboot的情况下一致。

 

总结：

分析了这些内容在实际的工作和应用中帮助，但是还是带着好奇心调试下来。希望给自己有个交待。

关键是硬件的属性和行为不从得知。只好边察看Datasheet，边验证自己的理解。

 

谢谢