The Linux Kernel Module Programming Guide
github.com
github.com
Anyone working with a SOM, for example, will want to customize the DT for their carrier board. And then your EE finds a cheaper controller chip somewhere. And then your display supplier switches captouch parts on you mid-production.
Sorry, was I venting there?
(And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with. And definitely don't make fun of the lack of peripherals on the thing)
Which has nothing to do with RPi or embedded systems... Not sure if I understand.
>And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with.
Ugh... Cell phones? Or any of the zillion of ARM development boards out there.
Is there a guide for that?
This isn't a snarky RTFM comment. The usage model file in the kernel documentation gives good motivation for what device trees are used for and their basic structure, and the APIs to pull data from them are straightforward enough that you can probably figure them out by looking at an example.
This is awesome.. my only comment is the first thing I went to do was to copy and paste the code blocks and found end of line whitespace and double line breaks were included (presumably for the line numbering etc.)
e.g.
sudo apt-get update
apt-cache search linux-headers-`uname -r`
Like let's say I wanted to instantiate an I2C with a custom driver in my device-tree. Can I put the controller's driver in a kernel module that lives in /lib/modules? Or do I need to compile it into the kernel?
Just make sure to run `depmod -a` after copying it into /lib/modules.
As an example, you may want to create a kernel module that can be configured through the device tree (e.g. binds to an arbitrary SPI/I2C bus, requires hardware-specific config). You can add a node for your module to the device tree and assign it a "compatible" property, which is just an arbitrary string you define to represent your module. If you then make your module export the same string using the MODULE_DEVICE_TABLE macro, the kernel will figure out that your module is the one that implements that node in the device tree, and it will call your module's probe callback to initialize the module, passing in the context from the device tree node (e.g. you can get a reference to the SPI/I2C bus hosting your device).
As I understand it, this is the standard way to implement drivers for devices that sit on buses that don't support automatic detection (e.g. not PCIe / USB).
I figure it would be close to mandatory for anyone who wanted to distribute their module to others, without having to tell them to rebuild every time their kernel changed.