I noticed that after the bug, the CPU usage is quite high. I profiled the kernel using perf, and I got the following results:

# Overhead          Command      Shared Object                              Symbol
# ........  ...............  .................  ..................................
# 
    48.77%     kworker/u4:2  [kernel.kallsyms]  [k] u8_writer
               |
               --- u8_writer
                  |
                  |--99.01%-- poll_writer
                  |          process_one_work
                  |          worker_thread
                  |          kthread
                  |          ret_from_kernel_thread
                  |
                   --0.99%-- process_one_work
                             worker_thread
                             kthread
                             ret_from_kernel_thread

    47.15%     kworker/u4:1  [kernel.kallsyms]  [k] u8_reader
               |
               --- u8_reader
                  |
                  |--96.54%-- handle_message
                  |          pump_messages
                  |          process_one_work
                  |          worker_thread
                  |          kthread
                  |          ret_from_kernel_thread
                  |
                   --3.46%-- pump_messages
                             process_one_work
                             worker_thread
                             kthread
                             ret_from_kernel_thread

     2.61%     kworker/u4:1  [kernel.kallsyms]  [k] handle_message

u8_writer and u8_reader are part of spi-pxa2xx (https://github.com/01org/edison-linux/blob/8cd9234c64c584432f6992fe944ca9e46ca8ea76/drivers/spi/spi-pxa2xx.c#L338)
It seems that one thread is polling trying to write while the other one is polling trying to read. Without success.
@westeri @jhnikula @andy-shev @broonie do you have any idea of what could put the SPI logic is such a locked state?

from edison-linux.

from edison-linux.

which mailing list?

from edison-linux.

On Mon, Jan 11, 2016 at 06:50:19AM -0800, Julien Pilet wrote:

which mailing list?

SPI SUBSYSTEM
M: Mark Brown [email protected]
L: [email protected]
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
S: Maintained
F: Documentation/spi/
F: drivers/spi/
F: include/linux/spi/
F: include/uapi/linux/spi/

from edison-linux.

Thanks. My mistake. The problem is most probably not in pxa2xx.c but in drivers/spi/intel_mid_ssp_spi.c, which is not upstream.

from edison-linux.

@jpilet, I would suggest to try my https://github.com/andy-shev/linux/tree/eds branch and continue with upstream.

from edison-linux.

https://github.com/01org/edison-linux/commits/edison-3.10.17

New patch has fixed SPI issue, please refer to commit above.

But user should notice that SPI clock frequency should be set above 1MHz, otherwise DMA will fail to transfer data.

In Yocto release 2, SPI transfer method is polling, and now it has switched to DMA method, and SPI transfer speed could improve a lot.
If Clock Frequency lower than 1MHZ(MAX support up to 24MHZ), data transferring will be failed.
(Actually, data transferring will be failed if set frequence lower than 800KHZ).

If increase working frequency to 1MHZ, the issue will be gone.
//mraa_spi_frequency(spi,10000);
mraa_spi_frequency(spi,1000000);

from edison-linux.

@chenchux In upstream kernel it's fixed. I guess you may transfer even with lower speeds if you want to.

from edison-linux.