SPI driver for communication

Question

I want to load my kernel module which communicates with my device over spi interface. I have tried loading my modules but it's showing spidev is already installed.

I see 2 modules named spidev and spi_bcm2835 already installed. Can I know what does these modules do and help me in running my use case?

Also, I have tried removing spidev module but only driver is getting registered but probe is not getting called.

Answer 1

Congratulations on writing a kernel module. That is quite hard.

The only thing which loads SPI on a modern Linux system will be device tree. You need to search /boot/config.txt and comment out or remove all SPI related lines. I believe most such lines will contain spi. You then need to reboot.

Answer 2

Question

1. I want to load my kernel module which communicates with my device over spi interface. I have tried loading my modules but it's showing spidev is already installed.

2. I see 2 modules named spidev and spi_bcm2835 already installed. Can I know what does these modules do and help me in running my use case?

3. Also, I have tried removing spidev module but only driver is getting registered but probe is not getting called.

4. I'm very new to work on SPI as well as Raspberry. What do you mean by conflicting? Is there anything that I have to change in my driver?

Answer

Brief description of the OP's question.

He has developed a kernel module and wishes to run in Rpi Raspbian with SPI interface. He found that Raspboian already has two drivers installed:

(1) spidev,

(2) spi_bcm2835.

He was wondering if he should

(a) remove those two SPI drivers, or

(b) interface with those two drivers.

/ to continue, ...

References

/ to add later, ...

Appendices

Appendix A - What is the difference between kernel drivers and kernel modules?

Reading notes

A kernel module is a bit of compiled code that can be inserted into the kernel at run-time, such as with insmod or modprobe.

A driver is a bit of code that runs in the kernel to talk to some hardware device. It "drives" the hardware. Most every bit of hardware in your computer has an associated driver. A large part of a running kernel is driver code.

A driver may be built statically into the kernel file on disk. A driver may also be built as a kernel module so that it can be dynamically loaded later. (And then maybe unloaded.)

Standard practice is to build drivers as kernel modules where possible, rather than link them statically to the kernel, since that gives more flexibility. There are good reasons not to, however:

Sometimes a given driver is absolutely necessary to help the system boot up. That doesn't happen as often as you might imagine, due to the initrd feature.

Statically built drivers may be exactly what you want in a system that is statically scoped, such as an embedded system. That is to say, if you know in advance exactly which drivers will always be needed and that this will never change, you have a good reason not to bother with dynamic kernel modules.

If you build your kernel statically and disable Linux's dynamic module loading feature, you prevent run-time modification of the kernel code. This provides additional security and stability at the expense of flexibility.

Not all kernel modules are drivers. For example, a relatively recent feature in the Linux kernel is that you can load a different process scheduler. Another example is that the more complex types of hardware often have multiple generic layers that sit between the low-level hardware driver and userland, such as the USB HID driver, which implements a particular element of the USB stack, independent of the underlying hardware

Appendix B - Example of a statically bound driver module

Reading Notes

To add the DS18B20 One Wire Temperature Sensor driver module to the device tree, add the following line in /boot/config.txt

dtoverlay=w1-gpio,gpiopin=14

Appendix C - Example of a dynamically bound kernel module

Reading notes

To launch the ILI9342 touch LCD kernel module at startup, add a line in the file /etc/rc.local

sudo /path/to/fbcp-ili9341/build/fbcp-ili9341 &

Appendix D - Device Tree Overlays (DT, DTB, DTO, Boot Loader etc) - Android Source

Reading Notes

A device tree (DT) is a data structure of named nodes and properties that describe non-discoverable hardware. Operating systems, such as the Linux kernel used in Android, use DTs to support a wide range of hardware configurations used by Android-powered devices. Hardware vendors supply their own DT source files, which Linux then compiles into the Device Tree Blob (DTB) file used by the bootloader.

A device tree overlay (DTO) enables a central device tree blob (DTB) to be overlaid on the device tree. A bootloader using DTO can maintain the system-on-chip (SoC) DT and dynamically overlay a device-specific DT, adding nodes to the tree and making changes to properties in the existing tree.

This page details a typical bootloader workflow for loading a DT and provides a list of common DT terms. Other pages in this section describe how to implement bootloader support for DTO, how to compile, verify, and optimize your DTO implementation, and how to use multiple DTs. You can also get details on DTO syntax and required DTO/DTBO partition formatting.

Appendix E - Python SPI Kernel Driver [Project]

This project contains a python module for interfacing with SPI devices from user space via the spidev linux kernel driver.

import spidev

spi = spidev.SpiDev()

spi.open(bus, device)

to_send = [0x01, 0x02, 0x03]

spi.xfer(to_send)

/ to continue, ...