arch/alpha/include/asm/core_mcpcia.h
Source file repositories/reference/linux-study-clean/arch/alpha/include/asm/core_mcpcia.h
File Facts
- System
- Linux kernel
- Corpus path
arch/alpha/include/asm/core_mcpcia.h- Extension
.h- Size
- 12229 bytes
- Lines
- 405
- 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
linux/types.hasm/compiler.hasm/mce.hasm/io_trivial.h
Detected Declarations
struct el_MCPCIA_uncorrected_frame_mcheckfunction EV56function __mcpcia_is_mmiofunction mcpcia_ioread8function mcpcia_iowrite8function mcpcia_ioread16function mcpcia_iowrite16function mcpcia_ioread32function mcpcia_iowrite32function mcpcia_ioread64function mcpcia_iowrite64function mcpcia_is_ioaddrfunction mcpcia_is_mmio
Annotated Snippet
struct el_MCPCIA_uncorrected_frame_mcheck {
struct el_common header;
struct el_common_EV5_uncorrectable_mcheck procdata;
};
#ifdef __KERNEL__
#ifndef __EXTERN_INLINE
#define __EXTERN_INLINE extern inline
#define __IO_EXTERN_INLINE
#endif
/*
* I/O functions:
*
* MCPCIA, the RAWHIDE family PCI/memory support chipset for the EV5 (21164)
* and EV56 (21164a) processors, can use either a sparse address mapping
* scheme, or the so-called byte-word PCI address space, to get at PCI memory
* and I/O.
*
* Unfortunately, we can't use BWIO with EV5, so for now, we always use SPARSE.
*/
/*
* Memory functions. 64-bit and 32-bit accesses are done through
* dense memory space, everything else through sparse space.
*
* For reading and writing 8 and 16 bit quantities we need to
* go through one of the three sparse address mapping regions
* and use the HAE_MEM CSR to provide some bits of the address.
* The following few routines use only sparse address region 1
* which gives 1Gbyte of accessible space which relates exactly
* to the amount of PCI memory mapping *into* system address space.
* See p 6-17 of the specification but it looks something like this:
*
* 21164 Address:
*
* 3 2 1
* 9876543210987654321098765432109876543210
* 1ZZZZ0.PCI.QW.Address............BBLL
*
* ZZ = SBZ
* BB = Byte offset
* LL = Transfer length
*
* PCI Address:
*
* 3 2 1
* 10987654321098765432109876543210
* HHH....PCI.QW.Address........ 00
*
* HHH = 31:29 HAE_MEM CSR
*
*/
#define vip volatile int __force *
#define vuip volatile unsigned int __force *
#define vulp volatile unsigned long __force *
#ifndef MCPCIA_ONE_HAE_WINDOW
#define MCPCIA_FROB_MMIO \
if (__mcpcia_is_mmio(hose)) { \
set_hae(hose & 0xffffffff); \
hose = hose - MCPCIA_DENSE(4) + MCPCIA_SPARSE(4); \
}
#else
#define MCPCIA_FROB_MMIO \
if (__mcpcia_is_mmio(hose)) { \
hose = hose - MCPCIA_DENSE(4) + MCPCIA_SPARSE(4); \
}
#endif
extern inline int __mcpcia_is_mmio(unsigned long addr)
{
return (addr & 0x80000000UL) == 0;
}
__EXTERN_INLINE u8 mcpcia_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long)xaddr & MCPCIA_MEM_MASK;
unsigned long hose = (unsigned long)xaddr & ~MCPCIA_MEM_MASK;
unsigned long result;
MCPCIA_FROB_MMIO;
result = *(vip) ((addr << 5) + hose + 0x00);
return __kernel_extbl(result, addr & 3);
}
Annotation
- Immediate include surface: `linux/types.h`, `asm/compiler.h`, `asm/mce.h`, `asm/io_trivial.h`.
- Detected declarations: `struct el_MCPCIA_uncorrected_frame_mcheck`, `function EV56`, `function __mcpcia_is_mmio`, `function mcpcia_ioread8`, `function mcpcia_iowrite8`, `function mcpcia_ioread16`, `function mcpcia_iowrite16`, `function mcpcia_ioread32`, `function mcpcia_iowrite32`, `function mcpcia_ioread64`.
- 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.