drivers/clk/bcm/clk-kona.h
Source file repositories/reference/linux-study-clean/drivers/clk/bcm/clk-kona.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/clk/bcm/clk-kona.h- Extension
.h- Size
- 17180 bytes
- Lines
- 501
- Domain
- Driver Families
- Bucket
- drivers/clk
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/kernel.hlinux/list.hlinux/spinlock.hlinux/slab.hlinux/device.hlinux/of.hlinux/clk-provider.h
Detected Declarations
struct bcm_clk_policystruct bcm_clk_gatestruct bcm_clk_hyststruct bcm_clk_divstruct bcm_clk_selstruct bcm_clk_trigstruct peri_clk_datastruct kona_clkstruct bcm_lvm_enstruct bcm_policy_ctlstruct ccu_policystruct ccu_dataenum bcm_clk_type
Annotated Snippet
struct bcm_clk_policy {
u32 offset; /* first policy mask register offset */
u32 bit; /* bit used in all mask registers */
};
/* Policy initialization macro */
#define POLICY(_offset, _bit) \
{ \
.offset = (_offset), \
.bit = (_bit), \
}
/*
* Gating control and status is managed by a 32-bit gate register.
*
* There are several types of gating available:
* - (no gate)
* A clock with no gate is assumed to be always enabled.
* - hardware-only gating (auto-gating)
* Enabling or disabling clocks with this type of gate is
* managed automatically by the hardware. Such clocks can be
* considered by the software to be enabled. The current status
* of auto-gated clocks can be read from the gate status bit.
* - software-only gating
* Auto-gating is not available for this type of clock.
* Instead, software manages whether it's enabled by setting or
* clearing the enable bit. The current gate status of a gate
* under software control can be read from the gate status bit.
* To ensure a change to the gating status is complete, the
* status bit can be polled to verify that the gate has entered
* the desired state.
* - selectable hardware or software gating
* Gating for this type of clock can be configured to be either
* under software or hardware control. Which type is in use is
* determined by the hw_sw_sel bit of the gate register.
*/
struct bcm_clk_gate {
u32 offset; /* gate register offset */
u32 status_bit; /* 0: gate is disabled; 0: gatge is enabled */
u32 en_bit; /* 0: disable; 1: enable */
u32 hw_sw_sel_bit; /* 0: hardware gating; 1: software gating */
u32 flags; /* BCM_CLK_GATE_FLAGS_* below */
};
/*
* Gate flags:
* HW means this gate can be auto-gated
* SW means the state of this gate can be software controlled
* NO_DISABLE means this gate is (only) enabled if under software control
* SW_MANAGED means the status of this gate is under software control
* ENABLED means this software-managed gate is *supposed* to be enabled
*/
#define BCM_CLK_GATE_FLAGS_EXISTS ((u32)1 << 0) /* Gate is valid */
#define BCM_CLK_GATE_FLAGS_HW ((u32)1 << 1) /* Can auto-gate */
#define BCM_CLK_GATE_FLAGS_SW ((u32)1 << 2) /* Software control */
#define BCM_CLK_GATE_FLAGS_NO_DISABLE ((u32)1 << 3) /* HW or enabled */
#define BCM_CLK_GATE_FLAGS_SW_MANAGED ((u32)1 << 4) /* SW now in control */
#define BCM_CLK_GATE_FLAGS_ENABLED ((u32)1 << 5) /* If SW_MANAGED */
/*
* Gate initialization macros.
*
* Any gate initially under software control will be enabled.
*/
/* A hardware/software gate initially under software control */
#define HW_SW_GATE(_offset, _status_bit, _en_bit, _hw_sw_sel_bit) \
{ \
.offset = (_offset), \
.status_bit = (_status_bit), \
.en_bit = (_en_bit), \
.hw_sw_sel_bit = (_hw_sw_sel_bit), \
.flags = FLAG(GATE, HW)|FLAG(GATE, SW)| \
FLAG(GATE, SW_MANAGED)|FLAG(GATE, ENABLED)| \
FLAG(GATE, EXISTS), \
}
/* A hardware/software gate initially under hardware control */
#define HW_SW_GATE_AUTO(_offset, _status_bit, _en_bit, _hw_sw_sel_bit) \
{ \
.offset = (_offset), \
.status_bit = (_status_bit), \
.en_bit = (_en_bit), \
.hw_sw_sel_bit = (_hw_sw_sel_bit), \
.flags = FLAG(GATE, HW)|FLAG(GATE, SW)| \
FLAG(GATE, EXISTS), \
}
/* A hardware-or-enabled gate (enabled if not under hardware control) */
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/list.h`, `linux/spinlock.h`, `linux/slab.h`, `linux/device.h`, `linux/of.h`, `linux/clk-provider.h`.
- Detected declarations: `struct bcm_clk_policy`, `struct bcm_clk_gate`, `struct bcm_clk_hyst`, `struct bcm_clk_div`, `struct bcm_clk_sel`, `struct bcm_clk_trig`, `struct peri_clk_data`, `struct kona_clk`, `struct bcm_lvm_en`, `struct bcm_policy_ctl`.
- Atlas domain: Driver Families / drivers/clk.
- 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.