Managing Interrupts and Concurrency

When implementing a device driver, a developer has to resolve two main problems:

• How to exchange data with peripherals
• How to manage interrupts that peripherals generate to the CPU

The first point was covered (at least for char drivers) in previous chapters, while the second one (and its related matter) will be the main topic of this chapter.

In the kernel, we can consider the CPU (or the internal core executing some code) running in two main execution contexts — the interrupt context and the process context. The interrupt context is very easy to understand; in fact, the CPU is in this context each time it executes an interrupt handler (that is, special code the kernel executes each time an interrupt occurs). In addition to this, interrupts can be generated by the hardware or even by the software; that's why we talk about hardware...

Technical requirements

For more information on this chapter, you can visit the Appendix.

The code and other files used in this chapter can be downloaded from GitHub at https://github.com/giometti/linux_device_driver_development_cookbook/tree/master/chapter_05.

Implementing an interrupt handler

Inside the kernel, an interrupt handler is a function associated with a CPU interrupt line (or pin) that Linux executes whenever the peripheral connected with this line changes the pin status; when this happens, an interrupt request is generated for the CPU, and it's captured by the kernel, which in turn executes the proper handler.

In this recipe, we will see how to install an interrupt handler which the kernel executes each time an interrupt occurs on a well-defined line.

Getting ready

The simplest code to implement an interrupt handler is the code in linux/drivers/misc/dummy-irq.c. Here is the handler:

static int irq = -1;

static irqreturn_t dummy_interrupt(int irq, void *dev_id)
{
...

Deferring work

Interrupts are events generated by peripherals, but, as said earlier, they are not the only events that the kernel can handle. In fact, software interrupts exist, which are similar to hardware interrupts but generated by software. In this book, we'll see two examples of such software interrupts; both of them can be used to safely defer a job for a future time. We'll also have a look at a useful mechanism that a device driver developer can use to catch special kernel events and perform actions as a consequence (for instance, when a network device is enabled, or the system is doing a reboot, and so on).

In this recipe, we will see how to defer a job when a specific event happens within the kernel.

Getting ready

...

Managing time with kernel timers

During the device driver development, it may be necessary to perform several repeated operations at specific moments in time, or we may have to postpone the execution of some code after a well-defined delay. In these situations, kernel timers come to help the device driver developer.

In this recipe, we will see how to use kernel timers to do repeated jobs at well-defined periods of time, or to defer a job until after a well-defined time interval.

Getting ready

For a simple example of kernel timers, we can still use a kernel module where we define a kernel timer during a module's initialization function.

In the chapter_05/timer directory of GitHub resources, there are two simple examples...

Waiting for an event

In previous sections, we saw how to manage an interrupt directly in its handler or by deferring the interrupt activities by using tasklets, workqueues, and so on. Also, we saw how to do periodic operations or how to delay an action forward in time; however, a device driver may need to wait for a specific event, such as waiting for some data, waiting for a buffer to become full, or a for a variable to reach a desired value.

Please don't confuse events managed by the notifiers, we saw before, which are kernel related, with generic events for a specific driver.

When there is no data to be read from a peripheral, the reading process must be put on sleep and then awakened when the "data ready" event arrives. Another example is when we start a complex job and we wish to be signaled when it's finished; in this case, we start the job and then we...

Performing atomic operations

Atomic operations are a crucial step during device driver development. In fact, a driver is not like a normal program that executes from the beginning till the end, as it provides several methods (for example, read or write data to a peripheral, or set some communication parameters), which can be called asynchronously one to another. All these methods operate concurrently on common data structures that must be modified in a consistent manner. That's why we need to be able to perform atomic operations.

The Linux kernel uses a large variety of atomic operations. Each is used for different operations, depending on whether the CPU is running in an interrupt or process context.

When the CPU is in the process context, we can safely use mutexes, which can put the current running process to sleep if the mutex is locked; however, in an interrupt context...