SPI Ports not working on Intel Joule

[andrewjaykeller]

SPI ports not working, please see comment on Intel Joule Communities.

Here is the os-release info:

root@intel-5xx-64:~# cat /etc/os-release 
ID="ref-os-iot"
NAME="Ref-Os-Iot"
VERSION="1.0+snapshot-20170419"
VERSION_ID="1.0-snapshot-20170419"
PRETTY_NAME="Ref-Os-Iot 1.0+snapshot-20170419"
BUILD_ID="20170421113711"

[alext-mkrs]

Continuing our discussion from the mraa's repo issue.

TL;DR version

Ref-OS-IoT doesn't by default contain any configuration for "devices" on the SPI bus, which would bind the spidev driver to them. This is generally not a bug and actually a correct behavior from the kernel SPI bus philosophy standpoint (see longer version below for details). Though many boards in this segment neglect that and implement fake configs similar to the one below to activate it.

A quick immediate solution would be to remove this line and rebuild the image (beware - it needs around 135GB of disk space). The patch included on that line removes an existing init hack, which creates a fake configuration of three buses with two devices at each (CS0 and 1).

Long version

In general, AFAIU the kernel devs' philosophy is that SPI bus topology is considered to be static and devices attached should be configured by means of either board config or Device Tree, or ACPI and communication should be done by means of dedicated drivers. spidev is rather intended for prototyping and makes this more dynamic, so it needs some fake device configuration to be activated.

So from the Linux standpoint the right approach for SPI enablement is to create a full, setup-specific config using one of the abovementioned ways, which would specify the exact SPI topogy your system has: which device is at which CS, what frequency and other SPI parameters does it use, which driver to use for communicating with it etc.

For spidev to get into the picture the same set of data is necessary - but as long as there may be different devices connected to the bus when using this driver, it should be sufficiently generic to cover them all (i.e. SPI modes, frequencies, other params should take that into account). More details on this can be found in kernel docs, but that patch mentioned above gives a basic example as well.

I'm not sure what would be the best way to properly implement this in ref-os-iot in the longer run, but hopefully this analysis would help it. Maybe something like Soletta's dedicated platform device module would be a nice, modular, way to do that. When/if someone needs it, they can load it, when "proper" approach is used, it won't get in the way.

[andrewjaykeller]

@alext-mkrs wow thanks! you just taught me a lot in one post! I will try to build an image without the that line.

Moving forward, and after reading those kernel docs, seems like a pretty clear cut answer to just make the SPI device I want to talk to a full configuration and leave it alone. But as you can assume, I have a lot more dev to do before I'm ready to starting messing with the kernel..

[alext-mkrs]

My pleasure :)

[Plafo]

Hi! Just a question, so did it finally work? I've been fighting with Ostro and the SPI interface for quite long, now I was wondering if this workaround did work and if you were able to use SPI on Joule with Ref-OS-Iot.. ???

[alext-mkrs]

The answer is yes to all sub-questions :)

[Plafo]

Oh great! thanks for the answer! so is it still necessary to build the latest release (1706) without the indicated line or does it comes fixed by default?
Thanks again!

[alext-mkrs]

@Plafo, sorry I missed your follow-up question. Yes, you still need to remove it by yourself if you want that behavior - as I, hopefully, explained earlier, having this config is a hack and that's why it's not present in ref-os-iot. Just double-checked to make sure and the line is still there, so nothing has changed since then.