Converged SOF dependencies and their management

[mwasko]

Zephyr integration will begin a new chapter in SOF that will introduce external project dependencies. The direction is to re-use Zephyr 'west' tool for projects synchronization and compatibility management.

For Intel next-gen platforms, Zephyr will not be the only dependency that we would like to add. To support Intel next-gen HW architecture we need to include Intel HAL library that currently can only be shared with community as a binary. That library will be a dependency only for Intel next-gen target builds. All the existing Intel cAVS and non-intel configurations will continue to rely on existing SOF/Zephyr HAL layer. The Intel HAL library in a binary form is expected to be a temporary solution and in a long-term will be open sourced and upstream into Zephyr project.

                      SOF repository
                      [west manifest]
                     /               \
                    /                 \
                 Zephyr            Intel next-gen HAL

Purpose of the Intel HAL library integration is to early enable community and Intel partners to build SOF FW for Intel next-gen platforms. Along with that we would like to extend SOF CI for Intel next-gen platforms that will cover new IPC4 protocol and Windows compatibility testing.

The Intel HAL library will be released and shared under Intel binary redistribution license.

Feel free to add your comments and questions.

As a summary from this conversation I would like to ask you to fill in a short survey:
https://forms.gle/UpmFERoaBtz5sgHLA

[cujomalainey]

Is there a spec published for the converged modules API anywhere? I want to understand how it operates in advanced use cases.

[mwasko]

Is there a spec published for the converged modules API anywhere? I want to understand how it operates in advanced use cases.

@cujomalainey there is an API and integration description in https://github.com/thesofproject/converged-sof-modules repo. Currently it apply to close source FW but this is what we would like to support in Converged SOF.

In the process of convergence the module examples will be merged to SOF repository (as soon as we add support), that will include sof docs update. In result the FW build will output base FW for specific target and loadable processing modules as a separate binaries that can be dynamically loaded by SOF driver depending on topology configuration file.

[mwasko]

I will appreciate a feedback from each of each of the company that is part of SOF TSC to make sure that we have an alignment on SOF directions and incoming dependencies.

@cujomalainey as we have a chance to discussed this topic then I am assume Google is ok with the presented approach. Please let me know if there are any further questions.

@dbaluta, @iuliana-prodan please share with me NXP feedback

@bhiregou, @cwakeland , @vp-arya let me know AMD take on this

If it will be necessary we can also schedule a meeting to discuss this topic.

[dbaluta]

@mwasko Looking at input/output pins does the interface supports other stream types than "pcm"? E.g will it allow modules used for compress streams.
Where is the sof-docs update, or it's just the documentation found in PR you mentioned.

How do you see the integration of converged modules with Codec Adapter? I'm in favor of scheduling a meeting to discuss this, somewhere after December 6.

[mwasko]

@mwasko Looking at input/output pins does the interface supports other stream types than "pcm"? E.g will it allow modules used for compress streams.

I don't see any limitation in converged loadable modules API to support compress streams.

Where is the sof-docs update, or it's just the documentation found in PR you mentioned.

The sof-docs will be updated along with integration of loadable modules support into SOF.

How do you see the integration of converged modules with Codec Adapter? I'm in favor of scheduling a meeting to discuss this, somewhere after December 6.

I should have more technical details of integration loadable modules into SOF and how it affect Codec Adapter at the beginning of next year. Let me then schedule a meeting for discussion and review.

@dbaluta do you have any feedback on HAL library integration for Intel next-gen platforms support?

[dbaluta]

@mwasko for the integration of HAL library can you point me the the interface?

We could have two approaches:

• smilar with rimage make hal a separate submodule.
• add HAL library as a module HAL in zephyr (similar with zephyr/modules/hal_nxp) but the problem is that this will work only when SOF is build as a zephyr module.

[mwasko]

@mwasko for the integration of HAL library can you point me the the interface?

We would like to proceed with Zephyr based support for Intel next-gen targets so the approach will be to add HAL library as a module in Zephyr. The difference in compare to HAL NXP is that Intel HAL library will be linked as a binary (temporary solution) until we open source it content.

I am assuming that for Zephyr supported configurations we will use SOF compiled as a Zephyr module. I would also recommend, at least for transition stage, to use Zephyr fork for integration purpose (until all SOF target configurations switch to Zephyr).

Currently I am looking for agreement on general approach with introducing west manifest to SOF along with Zephyr and Intel next-gen HAL library dependency. We will submit interface details along with the convergence progress for review and community discussion.

[plbossart]

I am having a hard-time following this thread.
Can someone clarify for me the relationship between HAL and processing module interfaces? To me these topics are orthogonal, aren't they?

[mwasko]

Can someone clarify for me the relationship between HAL and processing module interfaces? To me these topics are orthogonal, aren't they?

Yes they are orthogonal, so we should move the discussion on Converged Modules to separate topic and focus here on HAL integration.

[cujomalainey]

Google's overall thoughts:

The converged module APIs will free up a lot of pain points we have seen when working the software. Zephyr we believe will also do the same (in relieving some pain points) while also making our schedulers more robust. We do agree the churn is going to be larger than ideal over the course of the project but we believe the gains outweigh the benefits.

As for the HAL, the agreement has been that the blob will be burned down and converted into open source code. We strongly discourage putting blobs in SOF upstream so please note this option was not taken lightly. This was seen as the fastest way to get these new features to everyone in SOF without the overhead of completely re-writing the HAL for everyone all at once.

[mwasko]

Friendly reminder for feedback on HAL integration - I would like to have an agreement on the direction.

@dbaluta, @iuliana-prodan please share with me NXP feedback

@bhiregou, @cwakeland , @vp-arya let me know AMD take on this

[dbaluta]

@mwasko I somehow thought that we agreed on adding HAL library as a module in Zephyr (maybe just a binary blob for now).

For the convereged modules lets discuss this on another topic because it gets confusing.

[mwasko]

@mwasko I somehow thought that we agreed on adding HAL library as a module in Zephyr (maybe just a binary blob for now).

Thank you for confirmation.

For the convereged modules lets discuss this on another topic because it gets confusing.

We are planning to submit RFC at the beginning of next year with technical details for converged modules support in SOF so stay tuned and we will get back to this topic.