Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 64 additions & 30 deletions src/audio/module_adapter/module/dolby/dax.c
Original file line number Diff line number Diff line change
Expand Up @@ -465,7 +465,7 @@ static void check_and_update_settings(struct processing_module *mod)
}
}

static int sof_dax_free(struct processing_module *mod)
static void destroy_instance(struct processing_module *mod)
{
struct sof_dax *dax_ctx = module_get_private_data(mod);

Expand All @@ -476,6 +476,51 @@ static int sof_dax_free(struct processing_module *mod)
dax_buffer_release(mod, &dax_ctx->tuning_file_buffer);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tuning_file_buffer should not be released by destroy_instance (or implements a way to recover the buffer data on establishment). Move to sof_dax_free

dax_buffer_release(mod, &dax_ctx->input_buffer);
dax_buffer_release(mod, &dax_ctx->output_buffer);
Copy link
Contributor

@checkupup checkupup Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since only persist and scratch buffers are allocated during entablishment phase, we could be only responsible for releasing them during the destruction phase:

static void destroy_instance(struct processing_module *mod)
{
	struct sof_dax *dax_ctx = module_get_private_data(mod);

	dax_free(dax_ctx);
	dax_buffer_release(mod, &dax_ctx->persist_buffer);
	dax_buffer_release(mod, &dax_ctx->scratch_buffer);
}

}
}

static int establish_instance(struct processing_module *mod)
{
int ret = 0;
struct comp_dev *dev = mod->dev;
struct sof_dax *dax_ctx = module_get_private_data(mod);
uint32_t persist_sz;
uint32_t scratch_sz;

persist_sz = dax_query_persist_memory(dax_ctx);
if (dax_buffer_alloc(mod, &dax_ctx->persist_buffer, persist_sz) != 0) {
comp_err(dev, "allocate %u bytes failed for persist", persist_sz);
ret = -ENOMEM;
goto err;
}
scratch_sz = dax_query_scratch_memory(dax_ctx);
if (dax_buffer_alloc(mod, &dax_ctx->scratch_buffer, scratch_sz) != 0) {
comp_err(dev, "allocate %u bytes failed for scratch", scratch_sz);
ret = -ENOMEM;
goto err;
}
ret = dax_init(dax_ctx);
if (ret != 0) {
comp_err(dev, "dax instance initialization failed, ret %d", ret);
goto err;
}

comp_info(dev, "allocated: persist %u, scratch %u. version: %s",
persist_sz, scratch_sz, dax_get_version());
return 0;

err:
destroy_instance(mod);
return ret;
}

static int sof_dax_free(struct processing_module *mod)
{
struct sof_dax *dax_ctx = module_get_private_data(mod);

destroy_instance(mod);
Copy link
Contributor

@checkupup checkupup Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if sof_dax_reset can always be called before sof_dax_free phase, destruction may be not necessary here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically yes, but I don't feel we should rely on that assumption.

The memory free() function of C causes no harm if the input pointer is null. Your dax_buffer_release() implementation is handled well so they are good to be called more than once.

My only concern is that I am not sure if calling dax_free() twice is also good because this is a private call

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if so, following releases are also required here:

dax_buffer_release(mod, &dax_ctx->tuning_file_buffer);
dax_buffer_release(mod, &dax_ctx->input_buffer);
dax_buffer_release(mod, &dax_ctx->output_buffer);

dax_free() is safe for multiple frees.


if (dax_ctx) {
mod_data_blob_handler_free(mod, dax_ctx->blob_handler);
dax_ctx->blob_handler = NULL;
mod_free(mod, dax_ctx);
Expand All @@ -486,12 +531,9 @@ static int sof_dax_free(struct processing_module *mod)

static int sof_dax_init(struct processing_module *mod)
{
int ret;
struct comp_dev *dev = mod->dev;
struct module_data *md = &mod->priv;
struct sof_dax *dax_ctx;
uint32_t persist_sz;
uint32_t scratch_sz;

md->private = mod_zalloc(mod, sizeof(struct sof_dax));
if (!md->private) {
Expand All @@ -511,35 +553,12 @@ static int sof_dax_init(struct processing_module *mod)
dax_ctx->blob_handler = mod_data_blob_handler_new(mod);
if (!dax_ctx->blob_handler) {
comp_err(dev, "create blob handler failed");
ret = -ENOMEM;
goto err;
}

persist_sz = dax_query_persist_memory(dax_ctx);
if (dax_buffer_alloc(mod, &dax_ctx->persist_buffer, persist_sz) != 0) {
comp_err(dev, "allocate %u bytes failed for persist", persist_sz);
ret = -ENOMEM;
goto err;
}
scratch_sz = dax_query_scratch_memory(dax_ctx);
if (dax_buffer_alloc(mod, &dax_ctx->scratch_buffer, scratch_sz) != 0) {
comp_err(dev, "allocate %u bytes failed for scratch", scratch_sz);
ret = -ENOMEM;
goto err;
}
ret = dax_init(dax_ctx);
if (ret != 0) {
comp_err(dev, "dax instance initialization failed, ret %d", ret);
goto err;
mod_free(mod, dax_ctx);
module_set_private_data(mod, NULL);
return -ENOMEM;
}

comp_info(dev, "allocated: persist %u, scratch %u. version: %s",
persist_sz, scratch_sz, dax_get_version());
return 0;

err:
sof_dax_free(mod);
return ret;
}

static int check_media_format(struct processing_module *mod)
Expand Down Expand Up @@ -629,6 +648,11 @@ static int sof_dax_prepare(struct processing_module *mod, struct sof_source **so
return -EINVAL;
}

/* dax instance will be established on prepare(), and destroyed on reset() */
ret = establish_instance(mod);
if (ret != 0)
return ret;

Copy link
Contributor

@checkupup checkupup Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to place establish_instance after check_media_format to avoid unnecessary destruction if check_media_format fails.
On the other side, we need to add the option CONFIG_IDC_TIMEOUT_US=50000 to the file app/overlays/[ptl/mtl]/dax_overlay.conf to avoid IPC_TIMEOUT errors, because dax_init takes more than 20 ms, exceeding default IDC_TIMEOUT value (10ms).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's also I worried about. But I don't get why dax_init() takes so long because at that moment DAX didn't even get the configuration data (from dax_param.bin). Or does DAX make the advance calculation on dax_init() such as configuration prediction?

We have verified without changing CONFIG_IDC_TIMEOUT_US and didn't get timeout problem (I assume the timeout should lead to a stable failure if it really cares). Could you check with that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can set DOLBY_DAX_CORE_ID as 1 (or other different cores with pipeline) to trigger IDC timer.
dax_init will perform a large number of initialization operations based on the provided memory and load some static data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. You are correct "IDC" is for the inter-CPU communication.

As for dax_init(), do you mean "loading static data" to memory allocated on runtime for speeding the later computation? I remember we didn't use DRAM for ADSP in the current device so it still sounds weird to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad for clarifying this.This refers to loading static data from RAM (decalared as static arrays and stored in .data section) into runtime buffer and performing initializations for features in it.

ret = check_media_format(mod);
if (ret != 0)
return ret;
Expand Down Expand Up @@ -852,11 +876,21 @@ static int sof_dax_set_configuration(struct processing_module *mod, uint32_t con
return ret;
}

static int sof_dax_reset(struct processing_module *mod) {
struct comp_dev *dev = mod->dev;

/* dax instance will be established on prepare(), and destroyed on reset() */
destroy_instance(mod);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simultaneously release following buffers here:

dax_buffer_release(mod, &dax_ctx->tuning_file_buffer);
dax_buffer_release(mod, &dax_ctx->input_buffer);
dax_buffer_release(mod, &dax_ctx->output_buffer);

Becasue these buffers are also allocated in sof_dax_prepare. If a lifecycle of dax instance is from prepare to reset phrase, then I believe that all resources created in sof_dax_prepare should have the same lifecycle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. The better practice is releasing all runtime buffers when reset.

comp_info(dev, "reset");
return 0;
}

static const struct module_interface dolby_dax_audio_processing_interface = {
.init = sof_dax_init,
.prepare = sof_dax_prepare,
.process = sof_dax_process,
.set_configuration = sof_dax_set_configuration,
.reset = sof_dax_reset,
.free = sof_dax_free,
};

Expand Down
Loading