Chapter 3: Delving into the MFD Subsystem and Syscon API

The increasingly dense integration of devices has led to a kind of device that is made up of several other devices or IPs that can achieve a dedicated function. With the advent of this device, a new subsystem appeared in the Linux kernel. These are MFDs, which stands for multi-function devices. These devices are physically seen as standalone devices, but from a software point of view, these are represented in a parent-child relationship, where the children are subdevices.

While some I2C- and SPI-based devices/subdevices might need either some hacks or configurations prior to being added to the system, there are also MMIO-based devices/subdevices where zero conf/hacks are required as they just need to share the main device's register region between subdevices. The simple-mfd helper has then been introduced to handle zero conf/hacks subdevice registering, and syscon has been introduced for sharing a device's memory...

Technical requirements

In order to leverage this chapter, you will need the following:

• C programming skills
• Good knowledge of Linux device driver models
• Linux kernel v4.19.X sources, available at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/refs/tags

Introducing the MFD subsystem and Syscon APIs

Prior to delving into the syscon framework and its APIs, we will cover MFDs. There are peripherals or hardware blocks exposing more than a single functionality by means of subdevices they embed into them and that are handled by separate subsystems in the kernel. That being said, a subdevice is a dedicated entity in a so-called multifunction device, responsible for a specific task, and managed through a reduced set of registers, in the chip's register map. ADP5520 is a typical example of an MFD device, as it contains a backlight, a keypad, LEDs, and GPIO controllers. Each of these is then considered as a subdevice, and as you can see, each of these falls into a different subsystem. The MFD subsystem, defined in include/linux/mfd/core.h and implemented in drivers/mfd/mfd-core.c, has been created to deal with these devices, allowing the following features:

• Registering the same device with multiple subsystems
• Multiplexing bus...

Device tree binding for MFD devices

Even though we have the necessary tools and inputs to write our own MFD driver, it is important for the underlying MFD device to have its description defined in the device tree, since this lets the MFD core know what our MFD device is made of and how to deal with it. Moreover, the device tree remains the right place to declare devices, whether they are MFD or not. Please keep in mind that its purpose is only to describe devices on the system. As subdevices are children of the MFD device into which they are built (there is a parent-and-child bond of belonging), it is good practice to declare these subdevice nodes beneath their parent node, as in the following example. Moreover, the resources used by the subdevices are sometimes part of the resources of the parent device. So, it enforces the idea of putting the subdevice node beneath the main device node. In each subdevice node, the compatible property should match either both the subdevice's...

Understanding Syscon and simple-mfd

Syscon stands for system controller. SoCs sometimes have a set of MMIO registers dedicated to miscellaneous features that don't relate to a specific IP. Clearly, there can't be a functional driver for this as these registers are neither representative nor cohesive enough to represent a specific type of device. The syscon driver handles this kind of situation. Syscon permits other nodes to access this register space through the regmap mechanism. It is actually just a set of wrapper APIs for regmap. When you request access to syscon, the regmap is created, if it doesn't exist yet.

The header required for using the syscon API is <linux/mfd/syscon.h>. As this API is based on regmap, you must also include <linux/regmap.h>. The syscon API is implemented in drivers/mfd/syscon.c in the kernel source tree. Its main data structure is struct syscon, though this structure is not to be used directly:

struct syscon {
  ...

Summary

This chapter dealt with MFD devices, along with the syscon and regmap APIs. Here, we discussed how MFD devices work and how deep regmap is embedded into syscon. Having reached the end of this chapter, we can assume that you are able to develop regmap-enabled IRQ controllers, as well as to design and use syscon to share register regions between devices. The next chapter will deal with the common clock framework and how this framework is organized, its implementation, how to use it, and how to add your own clocks.