[Userspace LL] Make chain-dma compatible with user-space LL build

[kv2019i]

Set of patches to allow chaindma to work in Zephyr user-space threads. Tested as part of #10558

No impact to kernel-LL SOF builds (still the default for all targets).

[Copilot]

Pull request overview

This PR updates the chain-dma audio component to run in Zephyr user-space LL threads by switching to the sof_dma_* userspace-safe DMA APIs and by ensuring chain-dma objects/buffers are allocated from user-accessible heaps/contexts, while keeping kernel-LL builds unaffected.

Changes:

• Replace direct Zephyr dma_* calls and dma_chan_data* usage with sof_dma_* APIs and stored channel indices.
• Allocate comp_dev and chain_dma_data from the user heap under CONFIG_SOF_USERSPACE_LL.
• Allocate the DMA buffer using the LL userspace allocation context (ipc_get()->ll_alloc) when running user-space LL.

Suppressed comments (4)

src/audio/chain_dma.c:105

• chain_link_start() calls sof_dma_start() without verifying dma_link is non-NULL and chan_link_index is valid (>= 0). Since sof_dma_start() takes a uint32_t, a negative chan_link_index will be converted to a large value and may lead to out-of-bounds access/crash (e.g., if PAUSE/STOP is issued before successful init). Add the same initialization guard used in chain_host_start().

static int chain_link_start(struct comp_dev *dev)
{
	struct chain_dma_data *cd = comp_get_drvdata(dev);
	int err;

	err = sof_dma_start(cd->dma_link, cd->chan_link_index);
	if (err < 0)

src/audio/chain_dma.c:120

• chain_link_stop() should validate dma_link and chan_link_index before calling sof_dma_stop(). With the new int->uint32_t channel conversion, an uninitialized/negative index (e.g., stop before start) can turn into a huge channel number and crash. Also the log should use %d for an int index.

static int chain_link_stop(struct comp_dev *dev)
{
	struct chain_dma_data *cd = comp_get_drvdata(dev);
	int err;

	err = sof_dma_stop(cd->dma_link, cd->chan_link_index);
	if (err < 0)
		return err;

src/audio/chain_dma.c:135

• chain_host_stop() no longer checks for incomplete initialization before calling sof_dma_stop(). If chan_host_index is still negative, it will be converted to a large uint32_t channel and can lead to out-of-bounds access/crash. Add a guard (mirroring chain_host_start()) and use a signed format specifier for the int index.

static int chain_host_stop(struct comp_dev *dev)
{
	struct chain_dma_data *cd = comp_get_drvdata(dev);
	int err;

	err = sof_dma_stop(cd->dma_host, cd->chan_host_index);
	if (err < 0)
		return err;

src/audio/chain_dma.c:380

• chain_release() unconditionally calls sof_dma_release_channel() with chan_index, which is now an int initialized to -EINVAL. If chain_release() is ever reached with an invalid index (or dma is NULL), the negative value will be converted to a large uint32_t channel and may crash. Guard the release/put calls and reset indices/pointers after releasing to avoid accidental double-release.

__cold static void chain_release(struct comp_dev *dev)
{
	struct chain_dma_data *cd = comp_get_drvdata(dev);

	assert_can_be_cold();

	sof_dma_release_channel(cd->dma_host, cd->chan_host_index);
	sof_dma_put(cd->dma_host);
	sof_dma_release_channel(cd->dma_link, cd->chan_link_index);
	sof_dma_put(cd->dma_link);

[kv2019i]

Fixed in V2

[kv2019i]

V2 pushed:

• addressing code review comments so far

[kv2019i]

@jsarha @lgirdwood good to go?

[lyakh]

not worth respinning the PR just for this, but maybe just something to agree upon for future PRs - I'd say this commit already does constitute a "functional change?" Personally to me "no functional change" are like moving complete functions around, splitting or merging files, adding comments, etc. Even splitting or merging functions is already not a perfectly clear cut IMHO.