问题是这样的
带spi master的cpu,外接了3个slave,fpga,dpll,flash
访问3个外设,内核里是靠锁来实现互斥的,而加锁解锁是在用户空间通过ioctl来实现
比如我要访问fpga
open(/dev/spi)
ioctl(OPER_FPGA) //mutex_spi lock
read/write
ioctl(OPER_FPGA_DONE) //mutex_spi unlock
访问dpll
open(/dev/spi)
ioctl(OPER_DPLL) //mutex_spi lock
read/write
ioctl(OPER_DPLL_DONE) //mutex_spi unlock
我承认,这种方式很烂,但前人做成这样,上层的app一直这样用。(我已经在打算将锁移到read/write里面,通过传人read/write的buff来区分上锁)
这样如果在read/write的过程中,Ctrl+C会使进程进入disksleep,死锁在那
那么bug来了,躲不过的
忽然有一天,有人说,写flash失败,而且感觉就像死在那
通过验证,只起kernel,不起app,没有问题,一旦app起来了,写flash一定会失败
关于锁啊,spi这块我已经很熟了,而且用了许久没问题,怎么就忽然出现这个问题呢
有人发话,一定是内核中spi资源冲突的问题,你去查吧
好,那就查吧,虽然对这一块有信心,但我也不能保证不是内核的问题
然后开始研究flash时序,追踪写flash的过程,结果是flash写进一部分后,再也读不出,写不进
懵了...有锁锁着,不应该有冲突,想到一点,flash的片选是通过gpio来选的,难道有人改了gpio?
然而并没有...(打印出问题时gpio的value)
内核这块走不通,我便开始扣app,一个进程一个进程的起,终于定位到一个叫emd.exe的进程
但了解到这个进程就是设备管理,会不断访问fpga,难道真是资源冲突?我不信,看这个进程访问fpga时的代码
尼玛...
open(/dev/spi)
ioctl(OPER_FPGA_DONE) //mutex_spi unlock
ioctl(OPER_FPGA) //mutex_spi lock
read/write
ioctl(OPER_FPGA_DONE) //mutex_spi unlock
ioctl(OPER_FPGA_DONE) //mutex_spi unlock
有人为了调试方便(会经常用到Ctrl+C),减少进程进入disksleep的概率,来了这一出
找到罪魁祸首,就是把问题推给内核的人,唉,有没有考虑过做内核的感受啊
你这样改,我还要锁干啥,干啥,啊?!