Linux machine board file
This wiki is an example to show how to add the necessary information to a Linux machine board file so that a Linux driver is associated with a chip that is always on the board. The Texas Instruments TPS65073 multi-function regulator, touch screen controller, and GPIO chip is used for this example.
TPS65073 chip overview
The TPS65073 is a multi-function device chip, so an MFD driver is used to coordinate access to the chip and route interrupts from the chip to the correct sub-driver.
The Linux files of interest include:
| File | Purpose |
|---|---|
| include/linux/mfd/tps6507x.h | Multi-function device specific data structures used by board file |
| include/linux/regulator/tps6507x.h | Regulator specific data structures used by board file |
| include/linux/input/tps6507x-ts.h | Touch screen specific data structures used by board file |
| arch/arm/mach-davinci/board-*.c | Machine/platform/board specific |
| drivers/mfd/tps6507x.c | Multi-function (access control) driver |
| drivers/regulator/tps6507x-regulator.c | Regulator sub-driver |
| drivers/input/touchscreen/tps6507x-ts.c | Touch screen sub-driver |
| include/linux/gpio/tps6507x.h | GPIO specific data structures used by board file Does not exist Likely not needed |
| drivers/gpio/tps6507x.c | GPIO sub-driver Not written yet |
Kernel matching hardware with driver
The kernel needs to handle two different interactions between new hardware being discovered and new drivers being loaded:
- Hardware is known to the kernel (e.g. built onto the board) and the user loads the driver after boot (using insmod or modprobe).
- Kernel has initialized driver, (e.g. driver built into kernel or already loaded via insmod or modprobe) and user adds hardware (e.g. plugs in SD card or USB device).
How does the kernel connect the driver to the hardware in such a way that it works for both of these cases? The kernel keeps two lists - (a) all the known drivers and (b) all the known devices. Both lists are available from sysfs (/sys/modules and /sys/devices). When a device is connected, device_attach() in drivers/base/dd.c is called, which checks the list of drivers to see if any support the device. When a driver is loaded, driver_attach() in the same file is called, and in a similar way walks the list of devices to see if the driver can support that device. At the driver level, this process is called probing.
You can enable CONFIG_DEBUG_DRIVER to see all driver / device interaction in action.
Platform devices
If a device is built into the base hardware, it is called a platform device. The platform devices are exposed to the kernel (meaning get added to the kernel's list of known devices) via the board file for that specific hardware. For example, for the LeopardBoard 365, the board file is arch/arm/mach-davinci/board-dm365-leopard.c
Kernel support for multi-function devices
Typically when a device driver writer creates code to support a particular device (chip), they assume their driver is the only code talking to the chip. If the chip supports more than one function, say touch screen and GPIOs, then we have two choices. Either one driver can be written to support all parts of the chip, or several sub-drivers can be written. If one driver is written, then where does it go? In the drivers/input/touchscreen directory or the drivers/gpio directory? This also effects where the user looks to enable a driver, etc. The driver is also more complex and intertwined if it supports more than one logical function.
Instead, the kernel supports a multi-function device (mfd) driver, where the mfd driver coordinates sub-driver probing, interrupt routine, and serializing interaction with the chip.