drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
Source file repositories/reference/linux-study-clean/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h- Extension
.h- Size
- 10679 bytes
- Lines
- 362
- Domain
- Driver Families
- Bucket
- drivers/gpu
- 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
dpu_hw_mdss.hdpu_hw_util.hdpu_hw_catalog.hdpu_hw_sspp.h
Detected Declarations
struct dpu_hw_ctlstruct dpu_hw_stage_cfgstruct dpu_hw_intf_cfgstruct dpu_hw_ctl_opsstruct dpu_hw_ctlenum dpu_ctl_mode_sel
Annotated Snippet
struct dpu_hw_stage_cfg {
enum dpu_sspp stage[DPU_STAGE_MAX][PIPES_PER_STAGE];
enum dpu_sspp_multirect_index multirect_index
[DPU_STAGE_MAX][PIPES_PER_STAGE];
};
/**
* struct dpu_hw_intf_cfg :Describes how the DPU writes data to output interface
* @intf : Interface id
* @intf_master: Master interface id in the dual pipe topology
* @wb: Writeback mode
* @mode_3d: 3d mux configuration
* @merge_3d: 3d merge block used
* @intf_mode_sel: Interface mode, cmd / vid
* @cdm: CDM block used
* @stream_sel: Stream selection for multi-stream interfaces
* @dsc: DSC BIT masks used
* @cwb: CWB BIT masks used
*/
struct dpu_hw_intf_cfg {
enum dpu_intf intf;
enum dpu_intf intf_master;
enum dpu_wb wb;
enum dpu_3d_blend_mode mode_3d;
enum dpu_merge_3d merge_3d;
enum dpu_ctl_mode_sel intf_mode_sel;
enum dpu_cdm cdm;
int stream_sel;
unsigned int cwb;
unsigned int dsc;
};
/**
* struct dpu_hw_ctl_ops - Interface to the wb Hw driver functions
* Assumption is these functions will be called after clocks are enabled
*/
struct dpu_hw_ctl_ops {
/**
* @trigger_start: kickoff hw operation for Sw controlled interfaces
* DSI cmd mode and WB interface are SW controlled
* @ctx : ctl path ctx pointer
*/
void (*trigger_start)(struct dpu_hw_ctl *ctx);
/**
* @is_started: check if the ctl is started
* @ctx : ctl path ctx pointer
* @Return: true if started, false if stopped
*/
bool (*is_started)(struct dpu_hw_ctl *ctx);
/**
* @trigger_pending: kickoff prepare is in progress hw operation for sw
* controlled interfaces: DSI cmd mode and WB interface
* are SW controlled
* @ctx : ctl path ctx pointer
*/
void (*trigger_pending)(struct dpu_hw_ctl *ctx);
/**
* @clear_pending_flush: Clear the value of the cached pending_flush_mask
* No effect on hardware.
* Required to be implemented.
* @ctx : ctl path ctx pointer
*/
void (*clear_pending_flush)(struct dpu_hw_ctl *ctx);
/**
* @get_pending_flush: Query the value of the cached pending_flush_mask
* No effect on hardware
* @ctx : ctl path ctx pointer
*/
u32 (*get_pending_flush)(struct dpu_hw_ctl *ctx);
/**
* @update_pending_flush: OR in the given flushbits to the cached
* pending_flush_mask.
* No effect on hardware
* @ctx : ctl path ctx pointer
* @flushbits : module flushmask
*/
void (*update_pending_flush)(struct dpu_hw_ctl *ctx,
u32 flushbits);
/**
* @update_pending_flush_wb: OR in the given flushbits to the
* cached pending_(wb_)flush_mask.
* No effect on hardware
* @ctx : ctl path ctx pointer
* @blk : writeback block index
Annotation
- Immediate include surface: `dpu_hw_mdss.h`, `dpu_hw_util.h`, `dpu_hw_catalog.h`, `dpu_hw_sspp.h`.
- Detected declarations: `struct dpu_hw_ctl`, `struct dpu_hw_stage_cfg`, `struct dpu_hw_intf_cfg`, `struct dpu_hw_ctl_ops`, `struct dpu_hw_ctl`, `enum dpu_ctl_mode_sel`.
- Atlas domain: Driver Families / drivers/gpu.
- 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.