platform
[TOC] drivers/base/platform.c 平台设备模型(Platform Device Model) 描述SoC内部设备历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/base/platform.c 文件实现了Linux内核中的“平台设备模型”（Platform Device Model）。这项技术是为了解决嵌入式系统（特别是基于ARM等SoC的设备）中如何描述和管理那些不通过标准总线（如PCI, USB, I2C, SPI）枚举，而是直接由系统集成商（SoC厂商）通过内存映射地址或其他固定方式连接到CPU总线上的设备的问题。 在没有平台设备模型之前，这些SoC内部的设备（如GPIO控制器、UART控制器、时钟控制器、中断控制器、DMA控制器等）的驱动程序通常是零散地被编写的，并且管理方式非常底层和不统一。开发者需要手动解析设备树（Device Tree）或其他平台数据，获取设备的基地址、长度、中断号等信息，然后手动映射内存、申请中断，并将这些信息传递给驱动。这种方式存在以下问题： 代码冗余：每种类型的设备驱动都需要...
dma-buf
[TOC] Linux 内核 dma-buf 核心实现（drivers/dma-buf/dma-buf.c）全面解析[drivers/dma-buf/dma-buf.c] [dma-buf 共享缓冲区框架核心] [跨子系统/设备共享 DMA 缓冲区 + 同步与 CPU 访问支持的核心对象与文件接口]介绍dma-buf 子系统提供一种跨多个驱动/子系统共享同一块底层缓冲区的内核框架，并配套处理异步硬件访问的同步（基于 dma-resv/dma-fence）以及CPU 访问一致性（begin/end CPU access、mmap、poll/notify 等）。官方文档把其定位为：共享用于硬件（DMA）访问的缓冲区，并同步异步硬件访问。drivers/dma-buf/dma-buf.c 则是**dma-buf 核心对象（struct dma_buf）与其“文件描述符语义”**的主要实现：全局跟踪、fd 导出、attachment 管理、map/unmap、CPU access、p...
clk
[TOC] drivers/clk 时钟管理框架(Common Clock Framework) SoC时钟资源的统一抽象历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/clk 目录中的代码实现了Linux内核的“通用时钟框架”（Common Clock Framework, CCF）。这项技术的诞生是为了解决在现代片上系统（SoC）中一个极其复杂且普遍存在的问题：时钟资源的管理混乱、缺乏统一抽象和代码不可移植。 一个现代SoC内部包含着一个庞大而复杂的时钟树，里面有成百上千个独立的时钟源，用于驱动不同的硬件模块（CPU核、GPU、内存控制器、UART、I2C、SPI、显示引擎等）。在CCF出现之前： ** vendor特定实现**：每个SoC厂商（如TI, NXP, Samsung, Rockchip）都在其BSP（板级支持包）中实现一套自己独有的、非标准的API来管理时钟。 驱动不可移植：一个为TI芯片编写的UART驱动，如果想移植到NXP的芯片上，其所有与时钟相关的代码（如何使能时钟、如何设置波特率所需的时钟频率）都必须完全重写。 电源管理...
coherent
[TOC] kernel/dma DMA引擎(DMA Engine)与DMA映射(DMA Mapping)框架历史与背景这项技术是为了解决什么特定问题而诞生的？kernel/dma 目录下的代码是为了解决一个计算机体系结构中的核心问题：如何让外围设备（Peripherals）高效地与主内存（Main Memory）进行数据交换，而无需中央处理器（CPU）的持续干预。 在没有DMA（Direct Memory Access，直接内存访问）的系统中，当一个设备（如网卡）需要发送数据时，CPU必须亲自逐字节或逐字地从内存中读取数据，然后再写入到网卡的寄存器中。这个过程称为PIO（Programmed I/O）。对于大量数据的传输，这会完全占用CPU，使其无法执行其他计算任务，极大地降低了系统效率。 DMA技术引入了一个专门的硬件单元——DMA控制器（DMAC）。CPU只需配置好DMAC（告诉它源地址、目标地址、传输长度），然后就可以去做其他事情了。DMAC会接管总线控制权，直接在设备和内存之间搬运数据，传输完成后再通过中断通知CPU。 kernel/dma 子...
dma
[TOC] drivers/dma DMA引擎与映射(DMA Engine & Mapping) 内核统一的直接内存访问框架历史与背景这项技术是为了解决什么特定问题而诞生的？DMA（Direct Memory Access，直接内存访问）框架的诞生是为了解决一个根本性的性能瓶颈问题，并为内核提供一个统一、可移植的解决方案。 解决CPU性能瓶颈：在没有DMA的系统中，当外设（如网卡、磁盘）需要与内存交换大量数据时，CPU必须亲自担当“搬运工”的角色。这种方式被称为PIO（Programmed I/O），CPU需要逐字节或逐字地从设备读取数据再写入内存，或者反之。对于高速设备，这会消耗大量的CPU周期，导致CPU无暇处理其他计算任务，严重影响系统整体性能。DMA技术通过引入一个专门的硬件控制器（DMAC），允许外设在没有CPU干预的情况下直接与内存进行数据传输，从而将CPU解放出来。 抽象硬件差异：不同的CPU架构和SoC平台，其DMA控制器的设计和编程接口千差万别。如果没有一个统一的软件框架，设备驱动程序的开发者将不得不为每一种不同的DMAC编写...
include
[TOC] arch/arm/include/asm/cache.h__read_mostly 大多数读取 __read_mostly用于标记大多数读取的变量,在编译时会将该变量放到.data..read_mostly段中 1#define __read_mostly __section(".data..read_mostly") __read_mostly的作用是将变量放到.data..read_mostly段中,该段在内核启动时会被清零,所以该变量在内核启动时会被清零 arch/arm/include/asm/cmpxchg.harch_xchg_relaxed __arch_xchg 交换数据的逻辑都一样 使用ldrexb加载数据,它还会设置一个标志，表示该地址被标记为“独占访问”，以便后续的存储操作可以检查是否有其他处理器访问了该地址。 使用strexb存储数据,如果成功，返回0；如果失败，返回1，并且会清除“独占访问”标志。 如果strexb失败，循环会重新尝试加载...
bus
[TOC] 全面解析Linux设备模型的核心枢纽：drivers/base/bus.cdrivers/base/bus.c 是Linux内核设备模型中负责实现**总线（Bus）**这一核心概念的代码文件。它提供了一套通用的API和数据结构，用于管理系统中的各种总线类型，其最核心的职责是充当设备（Device）和驱动（Driver）之间的“撮合者”（Matchmaker），建立它们之间的连接。 历史与背景这项技术是为了解决什么特定问题而诞生的？ 在统一设备模型（详见drivers/base的解析）被引入之前，不同类型的总线（如PCI、USB）各自为政，都有一套自己独立的逻辑来注册设备、注册驱动，并进行匹配。这导致了以下问题： 代码冗余：每种总线都需要重复实现相似的设备列表管理、驱动列表管理以及遍历匹配的逻辑。 缺乏统一性：没有一个统一的接口来查询系统中所有的总线类型，或者在不同总线之间建立关联。 管理复杂：向系统中添加一种全新的总线类型，需要从头编写大量的管理和匹配代码，而非复用现有框架。 drivers/base/bus.c 的诞生，正是为了将这种...
gpio
[TOC] drivers/gpio GPIO子系统(General Purpose Input/Output) 内核与硬件I/O引脚交互的通用框架历史与背景这项技术是为了解决什么特定问题而诞生的？GPIO（通用输入/输出）子系统是为了在Linux内核中创建一个统一、抽象、可移植的框架来管理和控制硬件的GPIO引脚而诞生的。 在此框架出现之前，对GPIO的操作是混乱且与平台高度绑定的。每个SoC（片上系统）或主板都有自己独特的GPIO控制方式，驱动程序必须编写大量特定于硬件的代码才能操作一个引脚。 该子系统的诞生解决了以下核心问题： 消除平台特定代码：为内核提供一个标准的API，使得驱动程序（称为“消费者”）可以不用关心底层GPIO控制器（称为“提供者”或gpio_chip）的具体实现，就能请求、配置和读写一个GPIO引脚。 资源管理与冲突避免：一个GPIO引脚在系统中是独占性资源。 该框架提供了一套请求（request）和释放（free）机制，确保一个引脚在同一时间只能被一个驱动程序使用，从而避免了硬件冲突。 抽象硬件差异：不同的...
input
[toc] drivers/input/input.c 输入子系统核心(Input Subsystem Core) 统一所有输入设备的事件处理框架历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术以及它所构建的整个输入子系统，是为了解决在Linux早期一个极其混乱的问题：缺乏一个统一的、标准化的方式来处理各种各樣的输入设备。 接口不统一：在输入子系统出现之前，每一种输入设备（PS/2鼠标、串口鼠标、AT键盘等）都有其自己独特的驱动程序，这些驱动会创建各自不同的设备文件（如/dev/psaux, /dev/mouse），并使用自己私有的数据协议。 应用程序复杂性：这意味着用户空间的应用程序（尤其是X Window System）必须编写大量复杂的、针对特定硬件的代码，才能从这些不同的设备文件中读取和解析输入数据。更换一个鼠标，就可能需要重新配置X Window。 可扩展性差：每当出现一种新的输入设备，不仅需要编写内核驱动，还需要修改上层的应用程序才能支持它。 输入子系统（由Vojtech Pavlik创建）的诞生，就是为了彻底解决这个乱...
mmc
[toc] drivers/mmc 多媒体卡(MultiMediaCard)子系统 SD/eMMC/SDIO设备驱动框架历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/mmc 子系统是为了给Linux内核提供一个统一的、可扩展的框架来支持一整类基于**多媒体卡（MultiMediaCard）**规范及其衍生协议的设备而诞生的。这些设备包括： MMC (MultiMediaCard)：一种早期的闪存卡标准。 SD (Secure Digital) Card：在MMC基础上发展而来的、目前最普及的移动存储卡，增加了安全特性和更高的性能。 eMMC (embedded MMC)：将MMC控制器和NAND闪存封装在同一个BGA芯片中，作为一种“嵌入式”存储解决方案，被广泛用作智能手机、平板电脑和许多嵌入式设备的“硬盘”。 SDIO (Secure Digital Input/Output)：一种扩展规范，允许SD插槽除了支持存储卡外，还能连接I/O设备，如Wi-Fi模块、蓝牙模块、GPS接收器等。 在没有这个统...