Engineering journal
PCI Driver vs Platform Driver: What Changes Between x86-64 and ARM64?
Compare two explicit virtual-device contracts across discovery, MMIO, interrupts and evidence without confusing CPU architecture with bus type.
Source: https://louijiecompo.com/writing/pci-driver-vs-platform-driver/
About 3 min read
Compare the device contracts, not just the CPUs
The title describes the two paths in this lab, not a rule that an instruction set determines a bus. The Yocto and QEMU lab (opens in a new tab) pairs its x86-64 machine with a PCI peripheral and its ARM64 machine with an independent platform peripheral. The comparison is about those selected compositions.
Both paths share locked build inputs and an image target. They do not share one interchangeable device ABI. That distinction is the starting point for deciding which parts of a driver exercise can transfer and which need to be reconsidered.
Follow discovery into resource ownership
The architecture record (opens in a new tab) traces PCI enumeration through ID matching and the driver probe. The ARM64 path instead uses a generated Device Tree node and Linux's platform-device path. Register mapping and interrupt acquisition then follow the resources supplied by that discovery mechanism.
| Boundary | x86-64 PCI lab | ARM64 platform lab |
|---|---|---|
| Device description | PCI device identity | Generated Device Tree node |
| Register resource | BAR MMIO | Described MMIO resource |
| Interrupt contract | MSI or INTx | One level interrupt |
| DMA exercise | Bounded round trip | No DMA surface |
| Validation | PCI runtime evidence | Separate platform evidence |
This is a comparison of the pinned lab revision. It is not a capability matrix for every PCI or platform device.
Port the reasoning before the code
A useful first question is: who tells the driver that this device exists? Next ask where its register range comes from, how its interrupt is represented, and what must be acknowledged when an operation finishes. Only then compare the API calls.
The project's hardware mapping guide (opens in a new tab) relates PCI resource operations to platform resource operations, including managed mapping and interrupt lookup. It also preserves the distinction between a generated virtual description and a board's actual hardware description.
That is why replacing a driver structure or a mapping helper is not the whole exercise. The peripheral contract, resource ownership and cleanup obligations need to agree. A feature such as the PCI lab's DMA exercise cannot be inferred for the platform path just because both drivers participate in the same build.
Keep each result attached to its lab
The architecture describes separate evidence contracts for the two paths. A report should identify its selected machine, source revision and executed suite before interpreting a pass. Shared tooling helps reproduce the setup; it does not make one lab's result evidence for the other.
The hardware mapping guide explicitly leaves physical integration unresolved. A virtual exercise does not establish real cache coherency, interrupt wiring, firmware handoff or silicon behavior. Those require their own hardware and observations.
The comparison here comes from documentation, not a fresh build or board test. Continue through the case study, the independent-paths engineering note, or the evidence and validation topic.