ASoC: SOF: Intel: hda: follow strict BDLE address alignment for ACE4 by kv2019i · Pull Request #5684 · thesofproject/linux

kv2019i · 2026-03-05T17:58:06Z

Intel ACE4 based products require host to strictly follow HDA spec guidance on BDLE address alignment. Each BDLE address must be aligned to 128 bytes, and given ALSA periods are directly mapped to BDLEs, period size must be 128 aligned as well.

Reported-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com

ujfalusi · 2026-03-06T09:03:12Z

sound/soc/sof/intel/hda-pcm.c

-	snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
+	if (chip_info->hw_ip_version >= SOF_INTEL_ACE_4_0)
+		snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+					   SOF_HDA_BDLE_ADDRESS_ALIGNMENT);


you also need to fix legacy HDA in sound/hda/controllers/intel.c and add AZX_DCAPS_NO_ALIGN_BUFSIZE to both NVL and NVL_S, probably by:

#define AZX_DCAPS_INTEL_NVL (AZX_DCAPS_INTEL_LNL | AZX_DCAPS_NO_ALIGN_BUFSIZE)

Ack, added a separate commit for this. Note the logic needs to be to clear the bit as default behaviour is to align.

if we use '4' on the else branch, we might be better to use 128 here as well? With a small comment.

Hmm, ok, that is cleaner. The "small comment" took a bit of thinking, but an attempt is in V3 version of the patch,

sound/soc/sof/intel/hda.h

ujfalusi · 2026-03-06T09:54:25Z

sound/soc/sof/intel/hda-pcm.c

+		snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+					   SOF_HDA_BDLE_ADDRESS_ALIGNMENT);
+	else
+		/* minimum as per HDA spec */


I would remove this sentence and/or replace it with something which is correct (also for the legacy comment block, that is wrong in the same way)

Ack, I ended up removing the comment and explaining why in the commit message.

kv2019i

V2 uploaded:

addressed feedback for @ujfalusi
added a separate commit for snd_hda_intel driver
marking as ready for review now

kv2019i · 2026-03-09T12:12:02Z

sound/soc/sof/intel/hda-pcm.c

-	snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
+	if (chip_info->hw_ip_version >= SOF_INTEL_ACE_4_0)
+		snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+					   SOF_HDA_BDLE_ADDRESS_ALIGNMENT);


Ack, added a separate commit for this. Note the logic needs to be to clear the bit as default behaviour is to align.

sound/soc/sof/intel/hda.h

kv2019i · 2026-03-09T12:12:47Z

sound/soc/sof/intel/hda-pcm.c

+		snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+					   SOF_HDA_BDLE_ADDRESS_ALIGNMENT);
+	else
+		/* minimum as per HDA spec */


Ack, I ended up removing the comment and explaining why in the commit message.

ujfalusi · 2026-03-09T12:19:27Z

sound/hda/controllers/intel.c

-	{ PCI_DEVICE_DATA(INTEL, HDA_NVL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) },
-	{ PCI_DEVICE_DATA(INTEL, HDA_NVL_S, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) },
+	{ PCI_DEVICE_DATA(INTEL, HDA_NVL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_NVL) },
+	{ PCI_DEVICE_DATA(INTEL, HDA_NVL_S, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_NVL) },


this will not apply at 9c3af1b (v6.19) because NVL is added later: 7f42828 (v7.0-rc1)

Ack fixed in V3

ujfalusi · 2026-03-09T12:20:56Z

sound/soc/sof/intel/hda-pcm.c

-	snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);
+	if (chip_info->hw_ip_version >= SOF_INTEL_ACE_4_0)
+		snd_pcm_hw_constraint_step(substream->runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+					   SOF_HDA_BDLE_ADDRESS_ALIGNMENT);


if we use '4' on the else branch, we might be better to use 128 here as well? With a small comment.

Intel ACE4 based products require host to strictly follow HDA spec guidance on BDLE address alignment. Each BDLE buffer address must be aligned to 128 bytes, and given ALSA periods are directly mapped to BDLEs, period size must be 128 aligned as well. The commit removes the "minimum as per HDA spec" comment. This comment was misleading as spec actually does allow a 2 byte BDLE length, and more importantly, period size also directly impacts how the BDLE start addresses are aligned, so it is not sufficient just to consider allowed buffer length. Reported-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Intel ACE4 based products require host to strictly follow HDA spec guidance on BDLE address alignment. Each BDLE buffer address must be aligned to 128 bytes, and given ALSA periods are directly mapped to BDLEs, period size must be 128 aligned as well. Modify capability flags to drop AZX_DCAPS_NO_ALIGN_BUFSIZE for Intel Nova Lake platforms. Fixes: 7f42828 ("ALSA: hda: controllers: intel: add support for Nova Lake") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

kv2019i · 2026-03-09T16:39:57Z

V3 uploaded:

fix the "fixes" tag
remove the define in hda.h and just use 128 and 4 (with an inline comment)

kv2019i requested a review from ujfalusi March 5, 2026 17:58

ujfalusi reviewed Mar 6, 2026

View reviewed changes

sound/soc/sof/intel/hda.h Outdated Show resolved Hide resolved

ujfalusi reviewed Mar 6, 2026

View reviewed changes

kv2019i force-pushed the 202603-ace4-strict-bdle-alignment branch from a7bdf49 to 32aa914 Compare March 9, 2026 12:10

kv2019i commented Mar 9, 2026

View reviewed changes

kv2019i marked this pull request as ready for review March 9, 2026 12:13

kv2019i requested review from bardliao, dbaluta, lgirdwood, lyakh, plbossart and ranj063 as code owners March 9, 2026 12:13

ujfalusi reviewed Mar 9, 2026

View reviewed changes

kv2019i added 2 commits March 9, 2026 18:36

kv2019i force-pushed the 202603-ace4-strict-bdle-alignment branch from 32aa914 to 4f36889 Compare March 9, 2026 16:38

Conversation

kv2019i commented Mar 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Mar 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kv2019i left a comment •

edited

Loading