module: memory: partition out memory APIs from generic.c

[lgirdwood]

Move all the module memory APIs into common and heap specific files with no other changes.

This is to enable easier abstraction and partitioning around memory for modules and userspace going forward.

[softwarecki]

I can understand extracting functions related to memory allocation (mod_alloc, mod_free, etc.) into a separate file. However, the rest of the changes do not make sense in my opinion. Moving functions like module_init, module_free, module_adapter_mem_alloc, and module_adapter_mem_free seems unnecessary and introduces more confusion. Can you provide a clear justification for these relocations? Could you share what the next steps are in this refactoring? It would help clarify the overall direction.

[lgirdwood]

I see that these two functions are the only places in module_adapter where sof_heap_alloc and sof_heap_free are called. I assume this was the criterion for moving them. Does the plan include forking these new files later to use the new allocator you are working on? If so, feel free to admit it, I will not mind at all.

Yes your right, so anywhere we use the sof_heap_alloc()/free() is where I'm splitting today. However, the vregion is partitioned to include zephyr heaps for interim usage so it may well be as we integrate more code from memory-heap.c to memory-common.c as we go, its just we can easily do this today without breaking too much (and we depend on kernel patches too). Hence the need for a memory-region.c in a future PR which we can then incrementally move common code in memory-common.c and keep the heap/region specific code apart where needed.