module_adapter: Count sinks/sources during bind

[ranj063]

In preparation for preparing modules during the bind phase instead of pipeline trigger, move the code to count of the sinks/sources as and when they are connected.

[Copilot]

Pull Request Overview

This PR moves the counting of sink and source connections from the prepare phase to the bind phase in the module adapter. The change counts sinks and sources as they are connected during the bind operation instead of iterating through connected buffers during the prepare phase.

• Remove sink/source counting code from the prepare phase
• Add increment counters during bind operations for both sinks and sources

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/audio/module_adapter/module_adapter.c	Removes the code that counts sources and sinks during prepare phase
src/audio/module_adapter/module/generic.c	Adds increment operations for sink/source counters during bind operations

Comments suppressed due to low confidence (1)

src/audio/module_adapter/module/generic.c:766

• The unbind function increments counters during bind but doesn't decrement them during unbind. This will cause incorrect counts when components are unbound and rebound. Add mod->num_of_sinks-- and mod->num_of_sources-- in the respective unbind cases.

int module_unbind(struct processing_module *mod, struct bind_info *unbind_data)
{
	int ret;
	const struct module_interface *const ops = mod->dev->drv->adapter_ops;

	switch (unbind_data->bind_type) {
	case COMP_BIND_TYPE_SINK:
		ret = sink_unbind(unbind_data->sink);
		break;
	case COMP_BIND_TYPE_SOURCE:
		ret = source_unbind(unbind_data->source);
		break;
	default:
		ret = -EINVAL;
	}
	if (ret)
		return ret;

	if (ops->unbind)
		ret = ops->unbind(mod, unbind_data);

	return ret;
}

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[softwarecki]

Do I understand correctly that modules are ultimately to be initialized during binding instead of triggering the pipeline?

[ranj063]

Do I understand correctly that modules are ultimately to be initialized during binding instead of triggering the pipeline?

@softwarecki yes, thats the intention.

[dbaluta]

@ranj063 This breaks any IPC3 topology. I propose to temporarily revert this once we figure out a better solution:

#10252

Will try to test every change related to module_adapter as of now, it looks like Intel doesn't use IPC3 anymore.

[ranj063]

@ranj063 This breaks any IPC3 topology. I propose to temporarily revert this once we figure out a better solution:

#10252

Will try to test every change related to module_adapter as of now, it looks like Intel doesn't use IPC3 anymore.

@dbaluta Im good with the revert. I will start working on a better separation between IPC3 and IPC4 before I make invasive changes wrt pipeline prepare for IPC4.

[dbaluta]

@dbaluta Im good with the revert. I will start working on a better separation between IPC3 and IPC4 before I make invasive changes wrt pipeline prepare for IPC4.

Thanks @ranj063 . Let sync and ping me to test each change before merging. Unfortunately we only are able to see our CI results just after the PR is merged.