On Fri, Jun 5, 2015 at 11:01 AM, <[email protected]> wrote: > I saw that DT overlay support was re-introduced in the recent pre-4.1 kernel > drop, and testing was requested ... > > I have a prototype cape with a SPI interface that works well with spidev in > the 3.14 kernel line, so thought I'd try the new version. The kernel update, > dtc install and the existing overlays installed smoothly, and I added a > spidev dts overlay without any issues. However, the SPI driver appears to > have an issue. > > Basically, doing transfers using the user space spidev interface seems to > reliably hang as soon as the transfer size causes a switch to DMA mode (160 > bytes). This doesn't require a cape at all, just doing any transfer seems to > readily reproduce the problem. > > The user space program hangs hard, and the spi1 kernel thread hangs as well. > Eventually the kernel detects the hang - dmesg output: > [ 360.663769] INFO: task spi1:565 blocked for more than 120 seconds. > [ 360.670334] Not tainted 4.1.0-rc6-bone6 #1 > [ 360.675277] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 360.683573] spi1 D c05e5585 0 565 2 0x00000000 > [ 360.683680] [<c05e5585>] (__schedule) from [<c05e57b3>] > (schedule+0x2f/0x64) > [ 360.683732] [<c05e57b3>] (schedule) from [<c05e6e1d>] > (schedule_timeout+0x109/0x14c) > [ 360.683778] [<c05e6e1d>] (schedule_timeout) from [<c05e5e35>] > (wait_for_common+0x5d/0xd0) > [ 360.683845] [<c05e5e35>] (wait_for_common) from [<bf99c0d3>] > (omap2_mcspi_transfer_one_message+0x706/0xdf4 [spi_omap2_mcspi]) > [ 360.683922] [<bf99c0d3>] (omap2_mcspi_transfer_one_message > [spi_omap2_mcspi]) from [<c041a201>] (__spi_pump_messages+0x275/0x3d0) > [ 360.683970] [<c041a201>] (__spi_pump_messages) from [<c00401e1>] > (kthread_worker_fn+0x49/0xf4) > [ 360.684009] [<c00401e1>] (kthread_worker_fn) from [<c0040327>] > (kthread+0x9b/0xb0) > [ 360.684055] [<c0040327>] (kthread) from [<c000e601>] > (ret_from_fork+0x11/0x30) > > This is easily reproduced with dd - a working write at 159 bytes: > root@arm:/home/debian# dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1 > 1+0 records in > 1+0 records out > 159 bytes (159 B) copied, 0.00497733 s, 31.9 kB/s > > And a hang at 160 bytes: > root@arm:/home/debian# dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1 > <hangs permanently> > > Kernel version: > $ cat /proc/version > Linux version 4.1.0-rc6-bone6 (root@b2-omap5-uevm-2gb) (gcc version 4.9.2 > (Debian 4.9.2-10) ) #1 Mon Jun 1 21:27:44 UTC 2015 > > It is fairly obvious in linux/drivers/spi/spi-omap2-mcspi.c::170 "#define > DMA_MIN_BYTES 160" that the problem is with DMA mode transfers. > > I'm not sure this is the right forum for reporting driver issues like this - > if anyone can point me to a more appropriate venue, please feel free ...
Hi Matt, Thanks for testing.. What do you have connected? If it's just free, i wonder if your hitting: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-omap2-mcspi.c?id=3d0763c006f8da1b44a9f5f9a21187f5b8f674f4 Looking at next, just gpio changes.. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/spi/spi-omap2-mcspi.c?id=refs/tags/next-20150604 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
