memory: Add virtual memory regions gathering and structs

[dabekjakub]

Add virtual memory regions info gathering from zephyr and introduce structs agregating this information.
Add proper defines for memory managment.

Signed-off-by: Jakub Dabek jakub.dabek@intel.com

[marc-hb]

To please checkpatch and fix https://github.com/thesofproject/sof/actions/runs/3886647798/jobs/6631992187 please have a look at brand new

• [SKIP CI] github: add new SPDX-README.md and show it when checkpatch fails #6934

[marc-hb]

Not a single configuration compiled in https://github.com/thesofproject/sof/actions/runs/3886647797/jobs/6631994411

Please submit as a Github "draft" and keep it a draft until compilation issues are fixed to avoid spamming reviewers, thanks!

[dabekjakub]

I can build the changes localy with no problem that is why i pushed it - was doing checkpatch errors first didn't think it would spam reviewers - sorry.

[marc-hb]

I can build the changes localy with no problem that is why i pushed it -

Configuration differences happen no matter how hard we try to chase them: that's one of the reasons why I start ALL my pull requests as "drafts". It's a no-brainer, "draft" should be the default.

[dabekjakub]

Current Ci problems seem to be generic - I am currently resolving those offline with CI owners.

[lyakh]

You're overwriting vm_heaps[i].memory_caps in each of these ifs, right? Can .attr have more than one of these flags set? If so, it seems that MEM_REG_ATTR_OPPORTUNISTIC_MEMORY has the highest priority, since it overrides the other two, and MEM_REG_ATTR_CORE_HEAP has the lowest priority. So you revert the order and use else if to make the priorities clearer.

[dabekjakub]

Each of those regions is a distinct entity so none of these has a priority perse. Zephyr provides information and i translate it here so we can use it further in allocation.
Those Attributes are work in progress - they are due to change if future implementation uses theme. However elseif is a good point.

[lyakh]

but you should clearly define (1) whether those attributes are mutually exclusive and (2) what are their priorities. The way you had it implemented in the previous version meant, that they possibly weren't mutually exclusive and the priorities were (from the highest to the lowest):

MEM_REG_ATTR_OPPORTUNISTIC_MEMORY
MEM_REG_ATTR_SHARED_HEAP
MEM_REG_ATTR_CORE_HEAP

In your today's version you exactly reverted priorities. Is this intended? OTOH, if these attributes are mutually exclusive, then priorities don't matter, then I would suggest to do

switch (virtual_memory_regions[i].attr & MEM_REG_ATTR_MASK) {
case MEM_REG_ATTR_SHARED_HEAP:
...

[dabekjakub]

Yea they are actually mutually exclusive and there are no priorities - need to change zephyr implementation to enum later or is there any other way You suggest ?

[lyakh]

oh, so it's not just a bit set in the attribute, the attribute is actually equal to one of those bits. I thought you'd need to do something like

#define MEM_REG_ATTR_MASK (MEM_REG_ATTR_OPPORTUNISTIC_MEMORY | MEM_REG_ATTR_SHARED_HEAP | MEM_REG_ATTR_CORE_HEAP)
switch (virtual_memory_regions[i].attr & MEM_REG_ATTR_MASK) {

but if you don't - all the better

[dabekjakub]

Can anyone rerun the CI on this pr ? @lgirdwood@mengdonglin I am 99% sure that it was an issue with CI not with the commit. (CI passed some time back but failed again after cosmetic changes)

[kv2019i]

@dabekjakub wrote:

Can anyone rerun the CI on this pr ? @lgirdwood@mengdonglin I am 99% sure that it was an issue with CI not with the commit. (CI passed some time back but failed again after cosmetic changes)

I think we can merge without a full rerun. The CI failures are known failures in the ADLP SDW configuration and not related to this PR.