AnsweredAssumed Answered

A bug in the SPI bus driver (iMX6 BSP 4.0.0/4.1.0)

Question asked by brianwu on Feb 12, 2014
Latest reply on Apr 8, 2014 by S M

On our custom iMX6Q board, we use the SPI1 and SPI2 to communicate with other devices.

Currently, we write a program with many threads to access SPI1 and SPI2 simultaneously to do the burn-in test.

And we found that sometimes the one of these two SPI bus will hang on "__spi_sync" function. (use "cat /proc/xxxx/wchan" to check)

After we trace the SPI driver source code in the kernel, we found that:

 

In the "spi_imx.c" and in the function "spi_imx_transfer", you call the "clk_enable" and "clk_disable" function.

But the function "spi_imx_transfer" is protected by a spinlock(see the "spi_async_locked" function in "spi.c")

I also check the source code "clock.c" and fount that the "clk_enable" and "clk_disable" function use mutex to protect.

It means you use mutex in the wrong context.

 

Now, I have modified the driver to fix the problem and start test again. The board still alive for 16 hours.

 

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

Update:

I found that the "clk_enable" and "clk_disable" were just called in the work queue. It seems OK to use the mutex lock inside the work queue.

But I think there still have problems in the SPI bus driver.

I have tried two methods to fix the SPI hang issue:

1. Modify the SPI bus driver. We just enable the clock at probe function and delete the "clk_enable" and "clk_disable" in the "spi_imx_transfer" and "spi_imx_setupxfer".

2. Modify the clk_enable and clk_disable function. Using the spin lock to protect (not use the mutex lock).

Both of them can fix the hang issue on my test.

 

 

 

BR

Brian

 

消息编辑者为:brian wu

Outcomes