search

eclipse / mraa

Linux Library for low speed IO Communication in C with bindings for C++, Python, Node.js & Java. Supports generic io platforms, as well as Intel Edison, Intel Joule, Raspberry Pi and many more.
http://mraa.io
MIT License
1.38k stars 615 forks source link

spi: mraa does not support dynamic SPI bus enumeration (Linux Kernel 3.19) #316

Open xbolshe opened 9 years ago

xbolshe commented 9 years ago

There is no static SPI bus in Kernel 3.19. MRAA does not support a dynamic SPI bus enumeration. Boards: Galileo Gen1 & Gen2

spibusenum

alext-mkrs commented 9 years ago

My first question would be - where did you get a 3.19-based image for Galileos (or even Edison)? :smiley:, I haven't seen any official release with that one.

xbolshe commented 9 years ago

Actually I have own release :) https://github.com/xbolshe/galileo-custom-images/tree/master/iot_1.1.0_dirty_kernel_3.19.2

arfoll commented 9 years ago

So essentially your spidev device is turning up on /dev/spidev169.0 instead of spidev0.0. I'm curious though why does yours turn up there?

I guess the solution would be to check /sys for where the device node is and enumerate them dynamically. I'd be happy to take a patch to do this.

xbolshe commented 9 years ago

spidev0.0 / spidev168.0 is used for ADC on Galileo board. spidev1.0 / spidev169.0 is used for an external SPI connection.

Last kernel versions like 3.19 have a feature: https://www.kernel.org/doc/Documentation/spi/spi-summary

NON-STATIC CONFIGURATIONS

Developer boards often play by different rules than product boards, and one example is the potential need to hotplug SPI devices and/or controllers.

For those cases you might need to use spi_busnum_to_master() to look up the spi bus master, and will likely need spi_new_device() to provide the board info based on the board that was hotplugged. Of course, you'd later call at least spi_unregister_device() when that board is removed.

When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those configurations will also be dynamic. Fortunately, such devices all support basic device identification probes, so they should hotplug normally.

There is a minimal core of SPI programming interfaces, focussing on using the driver model to connect controller and protocol drivers using device tables provided by board specific initialization code. SPI shows up in sysfs in several locations:

/sys/devices/.../CTLR ... physical node for a given SPI controller

/sys/devices/.../CTLR/spiB.C ... spi_device on bus "B", chipselect C, accessed through CTLR.

/sys/bus/spi/devices/spiB.C ... symlink to that physical .../CTLR/spiB.C device

/sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver that should be used with this device (for hotplug/coldplug)

/sys/bus/spi/drivers/D ... driver for one or more spi. devices

/sys/class/spi_master/spiB ... symlink (or actual device node) to a logical node which could hold class related state for the controller managing bus "B". All spiB.* devices share one physical SPI bus segment, with SCLK, MOSI, and MISO.

Note that the actual location of the controller's class state depends on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, the only class-specific state is the bus number ("B" in "spiB"), so those /sys/class entries are only useful to quickly identify busses.

http://lxr.free-electrons.com/source/drivers/spi/spidev.c#L52