ALSA/ASoC: Fix HDMI ELD/capability loss on SOF DPCM backends via hw_constraints - #5913
Open
ujfalusi wants to merge 2 commits into
Open
ALSA/ASoC: Fix HDMI ELD/capability loss on SOF DPCM backends via hw_constraints#5913ujfalusi wants to merge 2 commits into
ujfalusi wants to merge 2 commits into
Conversation
hdmi_pcm_open() reports what the converter and the sink's ELD allow by updating substream->runtime->hw. That works for a codec driven by the HDA controller, but not for one exposed by a DSP driver as an ASoC dynamic PCM backend: the ASoC core sets up the runtime->hw of the frontend from topology after the backends have been opened, overwriting everything the codec placed there. Userspace then negotiates against topology and only finds out at hw_params time, or not at all, that the sink cannot do what it asked for. The hw_constraints are not overwritten, and the final runtime->hw is merged into them by snd_pcm_hw_constraints_complete(), so a constraint added at open time composes with topology instead of being lost. Repeat the narrowing there for a codec which asks for it with the new constrain_pcms flag, which no codec sets yet. The ELD is applied with snd_pcm_hw_constraint_eld(), which keeps the correlation between the rates and the channel count of each SAD, so it is a finer restriction than struct hda_pcm_stream can express. The rates a converter supports are a mask, which no constraint can take, so those are left to the caps the PCM was created with. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Every HDA codec probed here is exposed as an ASoC dynamic PCM backend, so the runtime->hw a codec sets up at open time is overwritten by the core with what topology says about the frontend, and the codec's own view of what the hardware can do is lost. Set constrain_pcms so that the codec adds it as hw_constraints as well, which survive and are merged with the topology capabilities. For HDMI this means the sink's ELD finally reaches the frontend that userspace negotiates against, instead of the mismatch showing up as a failing hw_params. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
ujfalusi
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
plbossart and
ranj063
as code owners
September 3, 2026 13:57
There was a problem hiding this comment.
🔵 Needs a closer look
The change affects PCM capability negotiation across HDA↔ASoC DPCM integration paths and is hardware/topology dependent, making it difficult to validate correctness and regressions without targeted platform testing.
Pull request overview
This PR ensures HDMI sink ELD-driven capabilities (formats/channels and ELD-derived rate/channel coupling) are preserved when an HDA HDMI codec is exposed as an ASoC dynamic PCM backend (e.g., SOF), by expressing those restrictions via hw_constraints rather than relying solely on runtime->hw (which ASoC DPCM topology rebuilding can overwrite).
Changes:
- Introduces an opt-in
struct hda_codec::constrain_pcmsflag to request codec-side PCM narrowing viahw_constraints. - Applies HDMI PCM constraints (format mask, channel min/max, and optional ELD constraint) in
sound/hda/codecs/hdmi/hdmi.cwhenconstrain_pcmsis set. - Enables
constrain_pcmsfor SOF-probed HDA codecs insound/soc/sof/intel/hda-codec.c.
File summaries
| File | Description |
|---|---|
| sound/soc/sof/intel/hda-codec.c | Enables opt-in PCM constraining for SOF-exposed HDA codecs used as ASoC DPCM backends. |
| sound/hda/codecs/hdmi/hdmi.c | Adds conditional HDMI-format/channel/ELD constraints via hw_constraints during PCM open. |
| include/sound/hda_codec.h | Adds the constrain_pcms flag to struct hda_codec for cross-driver coordination. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an HDA HDMI codec is exposed as an ASoC dynamic PCM backend (as all codecs under sound/soc/sof/intel/hda-codec.c are), the ASoC core rebuilds the DPCM frontend's runtime->hw from topology after backend .open() runs, silently discarding whatever the codec wrote there. In practice this means the HDMI sink's ELD (its actual supported rate/format/channel combinations) never reaches the frontend that userspace negotiates against — a mismatch either surfaces late as a failing hw_params(), or doesn't surface at all.
hw_constraints, unlike runtime->hw, are not touched by the core and are correctly merged with the final topology-derived runtime->hw in snd_pcm_hw_constraints_complete(). This series adds an opt-in constrain_pcms flag so the HDMI codec can additionally express its FORMAT/CHANNELS/ELD limits as constraints, and turns that flag on for every codec SOF probes, since they're all DPCM backends.