Documentation/sound/soc/dapm.rst
Source file repositories/reference/linux-study-clean/Documentation/sound/soc/dapm.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/sound/soc/dapm.rst- Extension
.rst- Size
- 13463 bytes
- Lines
- 423
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- 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
function SND_SOC_DAPM_MIXERfunction connected
Annotated Snippet
===================================================
Dynamic Audio Power Management for Portable Devices
===================================================
Description
===========
Dynamic Audio Power Management (DAPM) is designed to allow portable
Linux devices to use the minimum amount of power within the audio
subsystem at all times. It is independent of other kernel power
management frameworks and, as such, can easily co-exist with them.
DAPM is also completely transparent to all user space applications as
all power switching is done within the ASoC core. No code changes or
recompiling are required for user space applications. DAPM makes power
switching decisions based upon any audio stream (capture/playback)
activity and audio mixer settings within the device.
DAPM is based on two basic elements, called widgets and routes:
* a **widget** is every part of the audio hardware that can be enabled by
software when in use and disabled to save power when not in use
* a **route** is an interconnection between widgets that exists when sound
can flow from one widget to the other
All DAPM power switching decisions are made automatically by consulting an
audio routing graph. This graph is specific to each sound card and spans
the whole sound card, so some DAPM routes connect two widgets belonging to
different components (e.g. the LINE OUT pin of a CODEC and the input pin of
an amplifier).
The graph for the STM32MP1-DK1 sound card is shown in picture:
.. kernel-figure:: dapm-graph.svg
:alt: Example DAPM graph
:align: center
You can also generate compatible graph for your sound card using
`tools/sound/dapm-graph` utility.
DAPM power domains
==================
There are 4 power domains within DAPM:
Codec bias domain
VREF, VMID (core codec and audio power)
Usually controlled at codec probe/remove and suspend/resume, although
can be set at stream time if power is not needed for sidetone, etc.
Platform/Machine domain
physically connected inputs and outputs
Is platform/machine and user action specific, is configured by the
machine driver and responds to asynchronous events e.g when HP
are inserted
Path domain
audio subsystem signal paths
Automatically set when mixer and mux settings are changed by the user.
e.g. alsamixer, amixer.
Stream domain
DACs and ADCs.
Enabled and disabled when stream playback/capture is started and
stopped respectively. e.g. aplay, arecord.
Annotation
- Detected declarations: `function SND_SOC_DAPM_MIXER`, `function connected`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
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.