book

Mastering Linux Device Driver Development

by John Madieu

January 2021

Intermediate to advanced

646 pages

13h 48m

English

Packt Publishing

Read now

Unlock full access

Why subscribe?ContributorsAbout the authorAbout the reviewersPackt is searching for authors like you
Who this book is forWhat this book coversTo get the most out of this bookDownload the color imagesConventions usedGet in touchReviews
Technical requirementsThe kernel locking API and shared objectsSpinlocksMutexesThe try-lock methodWaiting, sensing, and blocking in the Linux kernelWork deferring mechanismsSoftIRQsTaskletsWorkqueuesWorkqueues – a new generationLinux kernel interrupt managementDesigning an interrupt handlerSummary
Technical requirementsIntroduction to regmap and its data structures – I2C, SPI, and MMIOAccessing device registersQuick recap on Linux kernel IRQ managementRegmap IRQ API and data structuresSummary
Technical requirementsIntroducing the MFD subsystem and Syscon APIsDevice tree binding for MFD devicesUnderstanding Syscon and simple-mfdIntroducing simple-mfdSummary
Technical requirementsCCF data structures and interfacesUnderstanding struct clk_hw and its dependenciesRegistering/unregistering the clock providerExposing clocks to others (in detail)Writing a clock provider driverProviding clock opsPutting it all together – global overviewGrabbing and releasing clocksPreparing/unpreparing clocksRate functionsParent functionsPutting it all together
Technical requirementsIntroduction to ASoCASoC Digital Audio InterfaceASoC sub-elementsWriting codec class driversCodec DAI and PCM (AKA DSP) configurationsThe concept of controlsThe concept of DAPMWriting the platform class driverThe CPU DAI driverThe platform DMA driver AKA PCM DMA driverSummary
Technical requirementsIntroduction to machine class driversThe DAI linkMachine routing considerationCodec pinsBoard connectorsMachine routingClocking and formatting considerationsSound card registrationLeveraging the simple-card machine driverCodec-less sound cardsSummary

Technical requirementsFramework architecture and the main data structuresInitializing and registering a V4L2 deviceIntroducing video device drivers – the bridge driverInitializing and registering the video deviceVideo device file operationsV4L2 ioctl handlingThe videobuf2 interface and APIsThe concept of sub-devicesSub-device initializationSub-device operationsTraditional sub-device (un)registrationV4L2 controls infrastructureA word about control inheritanceSummary
Technical requirementsThe V4L2 async interface and the concept of graph bindingGraph bindingThe V4L2 async and graph-oriented APIV4L2 asyncThe Linux media controller frameworkThe media controller abstraction modelIntegrating media controller support in the driverMedia controller from user spaceSummary
Technical requirementsIntroduction to V4L2 from user spaceThe V4L2 user space APIVideo device opening and property managementQuerying the device capabilitiesBuffer management Image (buffer) formatRequesting buffersEnqueueing the buffer and enabling streamingDequeuing buffersV4L2 user space toolsUsing v4l2-ctlDebugging V4L2 in user spaceSummary
Technical requirementsThe concept of power management on Linux-based systemsRuntime power managementSystem power management sleep statesAdding power management capabilities to device driversImplementing runtime PM capabilitySystem suspend and resume sequencesImplementing system sleep capabilityBeing a source of system wakeupWakeup source and sysfs (or debugfs)The IRQF_NO_SUSPEND flagSummary
Technical requirementsIntroduction to PCI buses and interfacesTerminologyPCI bus enumeration, device configuration, and addressingPCI address spacesInterrupt distributionThe Linux kernel PCI subsystem and data structuresPCI data structuresOverview of the PCI driver structurePCI and Direct Memory Access (DMA)PCI coherent (aka consistent) mappingStreaming DMA mappingSummary
Technical requirementsIntroducing NVMEM data structures and APIsWriting the NVMEM provider driverNVMEM device (un)registrationImplementing NVMEM read/write callbacksDevice tree bindings for NVMEM providersNVMEM consumer driver APIsNVMEM in user spaceSummary
Technical requirementsWatchdog data structures and APIsRegistering/unregistering a watchdog deviceHandling pretimeouts and governorsGPIO-based watchdogsThe watchdog user space interfaceStarting and stopping the watchdogGetting watchdog capabilities and identitySetting and getting the timeout and pretimeoutGetting the (boot/reboot) statusThe watchdog sysfs interfaceSummary
Technical requirementsUnderstanding the Linux kernel release processLinux kernel development tipsMessage printingLinux kernel tracing and performance analysisUsing Ftrace to instrument the codeLinux kernel debugging tipsOops and panic analysisUsing objdump to identify the faulty code line in the kernel moduleSummary
Leave a review - let other readers know what you think

Content preview from Mastering Linux Device Driver Development

Chapter 2: Leveraging the Regmap API and Simplifying the Code

This chapter introduces the Linux kernel register mapping abstraction layer and shows how to simplify and delegate I/O operations to the regmap subsystem. Dealing with devices, whether they are built-in in the SoC (memory mapped I/O, also known as MMIO) or seated on I2C/SPI buses, consists of accessing (reading/modifying/updating) registers. Regmap became necessary because a lot of device drivers open-coded their register access routines. Regmap stands for Register Map. It was primarily developed for ALSA SoC (ASoC) in order to get rid of redundant open-coded SPI/I2C register access routines in codec drivers. At its origin, regmap provided a set of APIs for reading/writing non-memory-map ...