include/linux/soc/pxa/mfp.h
Source file repositories/reference/linux-study-clean/include/linux/soc/pxa/mfp.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/soc/pxa/mfp.h- Extension
.h- Size
- 10485 bytes
- Lines
- 471
- Domain
- Core OS
- Bucket
- Core Kernel Interface
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- 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 mfp_addr_map
Annotated Snippet
struct mfp_addr_map {
unsigned int start;
unsigned int end;
unsigned long offset;
};
#define MFP_ADDR_X(start, end, offset) \
{ MFP_PIN_##start, MFP_PIN_##end, offset }
#define MFP_ADDR(pin, offset) \
{ MFP_PIN_##pin, -1, offset }
#define MFP_ADDR_END { MFP_PIN_INVALID, 0 }
void mfp_init_base(void __iomem *mfpr_base);
void mfp_init_addr(struct mfp_addr_map *map);
/*
* mfp_{read, write}() - for direct read/write access to the MFPR register
* mfp_config() - for configuring a group of MFPR registers
* mfp_config_lpm() - configuring all low power MFPR registers for suspend
* mfp_config_run() - configuring all run time MFPR registers after resume
*/
unsigned long mfp_read(int mfp);
void mfp_write(int mfp, unsigned long mfpr_val);
void mfp_config(unsigned long *mfp_cfgs, int num);
void mfp_config_run(void);
void mfp_config_lpm(void);
#endif /* CONFIG_PXA3xx || CONFIG_ARCH_MMP */
#endif /* __ASM_PLAT_MFP_H */
Annotation
- Detected declarations: `struct mfp_addr_map`.
- Atlas domain: Core OS / Core Kernel Interface.
- 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.