drivers/pci/controller/pci-v3-semi.c
Source file repositories/reference/linux-study-clean/drivers/pci/controller/pci-v3-semi.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/pci/controller/pci-v3-semi.c- Extension
.c- Size
- 27359 bytes
- Lines
- 908
- Domain
- Representative Device Path
- Bucket
- PCIe NVMe Storage Path
- Inferred role
- Representative Device Path: implementation source
- Status
- source implementation candidate
Why This File Exists
Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.
- Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/init.hlinux/interrupt.hlinux/io.hlinux/kernel.hlinux/of.hlinux/of_pci.hlinux/pci.hlinux/platform_device.hlinux/slab.hlinux/bitops.hlinux/irq.hlinux/mfd/syscon.hlinux/regmap.hlinux/clk.h../pci.h
Detected Declarations
struct v3_pcifunction neededfunction v3_unmap_busfunction v3_pci_read_configfunction v3_pci_write_configfunction v3_irqfunction v3_integrator_initfunction v3_pci_setup_resourcefunction v3_get_dma_range_configfunction v3_pci_parse_map_dma_rangesfunction resource_list_for_each_entryfunction v3_pci_probe
Annotated Snippet
struct v3_pci {
struct device *dev;
void __iomem *base;
void __iomem *config_base;
u32 config_mem;
u32 non_pre_mem;
u32 pre_mem;
phys_addr_t non_pre_bus_addr;
phys_addr_t pre_bus_addr;
struct regmap *map;
};
/*
* The V3 PCI interface chip in Integrator provides several windows from
* local bus memory into the PCI memory areas. Unfortunately, there
* are not really enough windows for our usage, therefore we reuse
* one of the windows for access to PCI configuration space. On the
* Integrator/AP, the memory map is as follows:
*
* Local Bus Memory Usage
*
* 40000000 - 4FFFFFFF PCI memory. 256M non-prefetchable
* 50000000 - 5FFFFFFF PCI memory. 256M prefetchable
* 60000000 - 60FFFFFF PCI IO. 16M
* 61000000 - 61FFFFFF PCI Configuration. 16M
*
* There are three V3 windows, each described by a pair of V3 registers.
* These are LB_BASE0/LB_MAP0, LB_BASE1/LB_MAP1 and LB_BASE2/LB_MAP2.
* Base0 and Base1 can be used for any type of PCI memory access. Base2
* can be used either for PCI I/O or for I20 accesses. By default, uHAL
* uses this only for PCI IO space.
*
* Normally these spaces are mapped using the following base registers:
*
* Usage Local Bus Memory Base/Map registers used
*
* Mem 40000000 - 4FFFFFFF LB_BASE0/LB_MAP0
* Mem 50000000 - 5FFFFFFF LB_BASE1/LB_MAP1
* IO 60000000 - 60FFFFFF LB_BASE2/LB_MAP2
* Cfg 61000000 - 61FFFFFF
*
* This means that I20 and PCI configuration space accesses will fail.
* When PCI configuration accesses are needed (via the uHAL PCI
* configuration space primitives) we must remap the spaces as follows:
*
* Usage Local Bus Memory Base/Map registers used
*
* Mem 40000000 - 4FFFFFFF LB_BASE0/LB_MAP0
* Mem 50000000 - 5FFFFFFF LB_BASE0/LB_MAP0
* IO 60000000 - 60FFFFFF LB_BASE2/LB_MAP2
* Cfg 61000000 - 61FFFFFF LB_BASE1/LB_MAP1
*
* To make this work, the code depends on overlapping windows working.
* The V3 chip translates an address by checking its range within
* each of the BASE/MAP pairs in turn (in ascending register number
* order). It will use the first matching pair. So, for example,
* if the same address is mapped by both LB_BASE0/LB_MAP0 and
* LB_BASE1/LB_MAP1, the V3 will use the translation from
* LB_BASE0/LB_MAP0.
*
* To allow PCI Configuration space access, the code enlarges the
* window mapped by LB_BASE0/LB_MAP0 from 256M to 512M. This occludes
* the windows currently mapped by LB_BASE1/LB_MAP1 so that it can
* be remapped for use by configuration cycles.
*
* At the end of the PCI Configuration space accesses,
* LB_BASE1/LB_MAP1 is reset to map PCI Memory. Finally the window
* mapped by LB_BASE0/LB_MAP0 is reduced in size from 512M to 256M to
* reveal the now restored LB_BASE1/LB_MAP1 window.
*
* NOTE: We do not set up I2O mapping. I suspect that this is only
* for an intelligent (target) device. Using I2O disables most of
* the mappings into PCI memory.
*/
static void __iomem *v3_map_bus(struct pci_bus *bus,
unsigned int devfn, int offset)
{
struct v3_pci *v3 = bus->sysdata;
unsigned int address, mapaddress, busnr;
busnr = bus->number;
if (busnr == 0) {
int slot = PCI_SLOT(devfn);
/*
* local bus segment so need a type 0 config cycle
*
* build the PCI configuration "address" with one-hot in
* A31-A11
*
Annotation
- Immediate include surface: `linux/init.h`, `linux/interrupt.h`, `linux/io.h`, `linux/kernel.h`, `linux/of.h`, `linux/of_pci.h`, `linux/pci.h`, `linux/platform_device.h`.
- Detected declarations: `struct v3_pci`, `function needed`, `function v3_unmap_bus`, `function v3_pci_read_config`, `function v3_pci_write_config`, `function v3_irq`, `function v3_integrator_init`, `function v3_pci_setup_resource`, `function v3_get_dma_range_config`, `function v3_pci_parse_map_dma_ranges`.
- Atlas domain: Representative Device Path / PCIe NVMe Storage Path.
- Implementation status: source implementation candidate.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.