arch/alpha/kernel/pci_impl.h
Source file repositories/reference/linux-study-clean/arch/alpha/kernel/pci_impl.h
File Facts
- System
- Linux kernel
- Corpus path
arch/alpha/kernel/pci_impl.h- Extension
.h- Size
- 6398 bytes
- Lines
- 194
- Domain
- Architecture Layer
- Bucket
- arch/alpha
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct pci_devstruct pci_controllerstruct pci_iommu_arenastruct pci_iommu_arena
Annotated Snippet
struct pci_dev;
struct pci_controller;
struct pci_iommu_arena;
/*
* We can't just blindly use 64K for machines with EISA busses; they
* may also have PCI-PCI bridges present, and then we'd configure the
* bridge incorrectly.
*
* Also, we start at 0x8000 or 0x9000, in hopes to get all devices'
* IO space areas allocated *before* 0xC000; this is because certain
* BIOSes (Millennium for one) use PCI Config space "mechanism #2"
* accesses to probe the bus. If a device's registers appear at 0xC000,
* it may see an INx/OUTx at that address during BIOS emulation of the
* VGA BIOS, and some cards, notably Adaptec 2940UW, take mortal offense.
*/
#define EISA_DEFAULT_IO_BASE 0x9000 /* start above 8th slot */
#define DEFAULT_IO_BASE 0x8000 /* start at 8th slot */
/*
* We try to make the DEFAULT_MEM_BASE addresses *always* have more than
* a single bit set. This is so that devices like the broken Myrinet card
* will always have a PCI memory address that will never match a IDSEL
* address in PCI Config space, which can cause problems with early rev cards.
*/
/*
* An XL is AVANTI (APECS) family, *but* it has only 27 bits of ISA address
* that get passed through the PCI<->ISA bridge chip. Although this causes
* us to set the PCI->Mem window bases lower than normal, we still allocate
* PCI bus devices' memory addresses *below* the low DMA mapping window,
* and hope they fit below 64Mb (to avoid conflicts), and so that they can
* be accessed via SPARSE space.
*
* We accept the risk that a broken Myrinet card will be put into a true XL
* and thus can more easily run into the problem described below.
*/
#define XL_DEFAULT_MEM_BASE ((16+2)*1024*1024) /* 16M to 64M-1 is avail */
/*
* APECS and LCA have only 34 bits for physical addresses, thus limiting PCI
* bus memory addresses for SPARSE access to be less than 128Mb.
*/
#define APECS_AND_LCA_DEFAULT_MEM_BASE ((16+2)*1024*1024)
/*
* Because MCPCIA and T2 core logic support more bits for
* physical addresses, they should allow an expanded range of SPARSE
* memory addresses. However, we do not use them all, in order to
* avoid the HAE manipulation that would be needed.
*/
#define MCPCIA_DEFAULT_MEM_BASE ((32+2)*1024*1024)
#define T2_DEFAULT_MEM_BASE ((16+1)*1024*1024)
/*
* Because CIA and PYXIS have more bits for physical addresses,
* they support an expanded range of SPARSE memory addresses.
*/
#define DEFAULT_MEM_BASE ((128+16)*1024*1024)
/* ??? Experimenting with no HAE for CIA. */
#define CIA_DEFAULT_MEM_BASE ((32+2)*1024*1024)
#define IRONGATE_DEFAULT_MEM_BASE ((256*8-16)*1024*1024)
#define DEFAULT_AGP_APER_SIZE (64*1024*1024)
/*
* A small note about bridges and interrupts. The DECchip 21050 (and
* later) adheres to the PCI-PCI bridge specification. This says that
* the interrupts on the other side of a bridge are swizzled in the
* following manner:
*
* Dev Interrupt Interrupt
* Pin on Pin on
* Device Connector
*
* 4 A A
* B B
* C C
* D D
*
* 5 A B
* B C
* C D
* D A
*
* 6 A C
* B D
Annotation
- Detected declarations: `struct pci_dev`, `struct pci_controller`, `struct pci_iommu_arena`, `struct pci_iommu_arena`.
- Atlas domain: Architecture Layer / arch/alpha.
- Implementation status: source implementation candidate.
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.