On Fri, Jun 5, 2015 at 11:47 AM, Robert Nelson <[email protected]> wrote: > 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,
And confirmed.. (nothing connected to mine..) debian@beaglebone:/sys$ 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.000508833 s, 312 kB/s debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1 ^C it's hung pretty good right now.. 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.
