beaglebone black: hung task in SPI code

[pdp7]

I've run into a problem with getting the mainline drivers/staging/fbtft drivers to work with BeagleBone Black. I know this repo is no longer under development, so please advise if there there is a better venue to raise this issue (maybe devel@driverdev.osuosl.org or linux-fbdev@vger.kernel.org?).

I compiled the fbtft kernel modules directly from this repo for 3.8.13-bone79, and it does work OK for me with 1.8" & 2.2" TFT LCD displays:

https://gist.github.com/pdp7/2fba066dcf23b049781a

Photos of displays working:

https://plus.google.com/photos/+DrewFustini/albums/6211546193314906001

I compiled Linux 4.3-rc7 with staging fbtft modules enabled using the am33x-v4.3 branch of bb-kernel:

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.3

I load the SPIDEV1 cape OK after compiling the Device Tree Overlay file from:

https://github.com/beagleboard/bb.org-overlays

I modprobe the fbtft_device module for adafruit18 like I did in v3.8.13, but this time the SPI code hangs. Here is the stack trace from kernel log:

https://gist.github.com/pdp7/579c1d5c48670c92db44

It seems the hang occurs in omap2_mcspi_driver. A summary of the stack trace:

__schedule
schedule
schedule_timeout
wait_for_common
wait_for_completion
omap2_mcspi_transfer_one
spi_transfer_one_message
__spi_pump_messages
__spi_sync
spi_sync
fbtft_write_spi
fbtft_write_vmem16_bus8
fbtft_update_display
fbtft_register_framebuffer
fbtft_probe_common
<snip>

I can post more details, but I thought I would first see if anyone has run into this. I will continue troubleshooting and followup if I figure out a solution.

[notro]

modprobe fbtft_device [...] debug=7 will give transfer details in the kernel log. It would be interesting to know if it is the first transfer that fails.
If it hangs on the first transfer I suggest trying spidev_test.c to see if that works.

[pdp7]

thanks @notro
Here is the fbtft output from the kernel log yesterday running 4.3.0-rc7-bone1:
https://gist.github.com/pdp7/d6a63300b6650c7a55bb

I will try out spidev_test.c. Thanks for the tip.

However, I found this beagleboard mailing list discussion which indicates that this is an issue in the BeagleBone SPI driver and not related to fbtft:
https://groups.google.com/forum/#!topic/beagleboard/udVR5aJvifg

[notro]

From the log I see that it hangs on the first transfer that is big enough to trigger a dma transfer in the spi master driver.
spidev_test.c will not trigger that.

You should be able to force pio on all transfers by doing this in spi-omap2-mcspi:

-#define DMA_MIN_BYTES          160
+#define DMA_MIN_BYTES          ~0

If it works, then it's a dma problem like the report you linked to indicates.

[pdp7]

Thanks @notro , it worked!
https://gist.github.com/pdp7/18c46d89b341dd47a543
I loaded the SPIDEV1 overlay ok and then loaded fb_st7735r for adafruit18 via modprobe of fbtft_device. I was able to display an image ok with "fbi".

[pdp7]

I'm going to close this now. This issue is due to the driver for BeagleBone's SPI bus, and @notro's tip to disable DMA is sufficient for my needs.

For those interested, Robert C Nelson noticed this FIXME comment for spi-omap2-mcspi in mainline Linux kernel:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-omap2-mcspi.c?id=refs/tags/v4.3#n440

Robert C Nelson has a repo that offers Texas Instrument's Linux 4.1.x kernel for BeagleBone:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.1.y

Here is a patch he created for this SPI DMA issue:
RobertCNelson/ti-linux-kernel-dev@92b9a64