arch/mips/include/asm/octeon/cvmx-asm.h
Source file repositories/reference/linux-study-clean/arch/mips/include/asm/octeon/cvmx-asm.h
File Facts
- System
- Linux kernel
- Corpus path
arch/mips/include/asm/octeon/cvmx-asm.h- Extension
.h- Size
- 5200 bytes
- Lines
- 140
- Domain
- Architecture Layer
- Bucket
- arch/mips
- 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.
Dependency Surface
asm/octeon/octeon-model.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef __CVMX_ASM_H__
#define __CVMX_ASM_H__
#include <asm/octeon/octeon-model.h>
/* other useful stuff */
#define CVMX_SYNC asm volatile ("sync" : : : "memory")
/* String version of SYNCW macro for using in inline asm constructs */
#define CVMX_SYNCW_STR "syncw\nsyncw\n"
#ifdef __OCTEON__
/* Deprecated, will be removed in future release */
#define CVMX_SYNCIO asm volatile ("nop")
#define CVMX_SYNCIOBDMA asm volatile ("synciobdma" : : : "memory")
/* Deprecated, will be removed in future release */
#define CVMX_SYNCIOALL asm volatile ("nop")
/*
* We actually use two syncw instructions in a row when we need a write
* memory barrier. This is because the CN3XXX series of Octeons have
* errata Core-401. This can cause a single syncw to not enforce
* ordering under very rare conditions. Even if it is rare, better safe
* than sorry.
*/
#define CVMX_SYNCW asm volatile ("syncw\n\tsyncw" : : : "memory")
/*
* Define new sync instructions to be normal SYNC instructions for
* operating systems that use threads.
*/
#define CVMX_SYNCWS CVMX_SYNCW
#define CVMX_SYNCS CVMX_SYNC
#define CVMX_SYNCWS_STR CVMX_SYNCW_STR
#else
/*
* Not using a Cavium compiler, always use the slower sync so the
* assembler stays happy.
*/
/* Deprecated, will be removed in future release */
#define CVMX_SYNCIO asm volatile ("nop")
#define CVMX_SYNCIOBDMA asm volatile ("sync" : : : "memory")
/* Deprecated, will be removed in future release */
#define CVMX_SYNCIOALL asm volatile ("nop")
#define CVMX_SYNCW asm volatile ("sync" : : : "memory")
#define CVMX_SYNCWS CVMX_SYNCW
#define CVMX_SYNCS CVMX_SYNC
#define CVMX_SYNCWS_STR CVMX_SYNCW_STR
#endif
/*
* CVMX_PREPARE_FOR_STORE makes each byte of the block unpredictable
* (actually old value or zero) until that byte is stored to (by this or
* another processor. Note that the value of each byte is not only
* unpredictable, but may also change again - up until the point when one
* of the cores stores to the byte.
*/
#define CVMX_PREPARE_FOR_STORE(address, offset) \
asm volatile ("pref 30, " CVMX_TMP_STR(offset) "(%[rbase])" : : \
[rbase] "d" (address))
/*
* This is a command headed to the L2 controller to tell it to clear
* its dirty bit for a block. Basically, SW is telling HW that the
* current version of the block will not be used.
*/
#define CVMX_DONT_WRITE_BACK(address, offset) \
asm volatile ("pref 29, " CVMX_TMP_STR(offset) "(%[rbase])" : : \
[rbase] "d" (address))
/* flush stores, invalidate entire icache */
#define CVMX_ICACHE_INVALIDATE \
{ CVMX_SYNC; asm volatile ("synci 0($0)" : : ); }
/* flush stores, invalidate entire icache */
#define CVMX_ICACHE_INVALIDATE2 \
{ CVMX_SYNC; asm volatile ("cache 0, 0($0)" : : ); }
/* complete prefetches, invalidate entire dcache */
#define CVMX_DCACHE_INVALIDATE \
{ CVMX_SYNC; asm volatile ("cache 9, 0($0)" : : ); }
#define CVMX_CACHE(op, address, offset) \
asm volatile ("cache " CVMX_TMP_STR(op) ", " CVMX_TMP_STR(offset) "(%[rbase])" \
: : [rbase] "d" (address) )
/* fetch and lock the state. */
#define CVMX_CACHE_LCKL2(address, offset) CVMX_CACHE(31, address, offset)
Annotation
- Immediate include surface: `asm/octeon/octeon-model.h`.
- Atlas domain: Architecture Layer / arch/mips.
- 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.