Closed pdp7 closed 7 years ago
On face value a different bus number means a different physical SPI bus.
About numbering: spi0.1 -> bus number 0, chip select 1
Unless an alias is used, the first SPI master/bus driver in the DT gets bus number 0, the next 1 etc. Look at bus_num in http://lxr.free-electrons.com/ident?i=spi_register_master /sys/class/spi_master/ will list your SPI busses.
When the master driver is probed, it looks at the DT subnodes and adds spi devices using the reg property as the chip select value. See http://lxr.free-electrons.com/ident?i=of_register_spi_devices /sys/bus/spi/devices/ will list your SPI devices.
/proc/device-tree/ contains a filesystem representation of your active DT (if enabled).
Closing issue since there has been no activity in a long time. Reopen if needed.
Sorry for not following up. Thanks for closing.
I believe this issue resolved by loading the SPI cape (device tree overlay) via /boot/uEnvt.txt to that it was configured correctly at boot. The issue wasn't related to anything in the fbtft code.
I'm not sure whether or not this is a fbtft issue. However, I'm not sure how to proceed at this point, and would welcome any troubleshooting advice.
I'm using Debian 8.5 (2016-08-14) image on BeagleBone Black.
I can not get fbtft working for Adafruit 1.8" LCD (ST7735R) on SPI1 when using
4.1.15-bone18
or any newer kernel packages.However, fbtft works OK on the earlier
4.1.14-bone17 kernel
.I have noticed that:
BB-SPIDEV1
cape will create/dev/spidev1.x
when running4.1.14-bone17 kernel
however:
BB-SPIDEV1
cape will create/dev/spidev2.x
when running4.1.15-bone18 kernel
I have tried
busnum=2
instead ofbusnum=1
param forfbtft_device
but that did not appear to help.Full details in this gist