[Sound-open-firmware] System Controller Unit firmware code inside SOF
Hi Liam / Pierre,
I want to hear your take on the following.
On some of our i.MX platforms most of the critical functions like PM, clocks, interrupts are handled by a special core name SCU (System Controller Unit).
It runs a special firmware (SCFW). In order for our DSP core to communicate with SCU it needs to use a special interface exported by the SCFW.
The interface is BSD-3 Clause licensed. Anyhow, as you might expect the coding style / file naming / organization is firmware like. That means very very different from what we have in SOF.
Do you think such an interface would be acceptable to be merged in SOF? Or should we spent some time to rewrite it from scratch to match the quality of the existing SOF code?
The bad part in rewriting it from scratch is that we need to update-it by hand each time the SCFW interface changes.
thanks, Daniel.
On 9/3/19 9:28 AM, Daniel Baluta wrote:
Hi Liam / Pierre,
I want to hear your take on the following.
On some of our i.MX platforms most of the critical functions like PM, clocks, interrupts are handled by a special core name SCU (System Controller Unit).
It runs a special firmware (SCFW). In order for our DSP core to communicate with SCU it needs to use a special interface exported by the SCFW.
The interface is BSD-3 Clause licensed. Anyhow, as you might expect the coding style / file naming / organization is firmware like. That means very very different from what we have in SOF.
Do you think such an interface would be acceptable to be merged in SOF? Or should we spent some time to rewrite it from scratch to match the quality of the existing SOF code?
The bad part in rewriting it from scratch is that we need to update-it by hand each time the SCFW interface changes.
Just to be clear, you are talking about a header file as well as the library implementing the interface to the SCU?
In the latter case, do we need to import it in the SOF project, which means periodic PRs to update it, or could you just link against it?
FWIW, Intel has two cases where we'd like to add the header files in the SOF project so that the integration is not an issue. However the libraries will not be part of the SOF tree, maybe something similar could apply here. we want it to make it easier to use additional libraries, but whether the code for those libraries belongs in SOF should be a case-by-case discussion.
My 2 cents.
-Pierre
On Tue, Sep 3, 2019 at 7:12 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 9/3/19 9:28 AM, Daniel Baluta wrote:
Hi Liam / Pierre,
I want to hear your take on the following.
On some of our i.MX platforms most of the critical functions like PM, clocks, interrupts are handled by a special core name SCU (System Controller Unit).
It runs a special firmware (SCFW). In order for our DSP core to communicate with SCU it needs to use a special interface exported by the SCFW.
The interface is BSD-3 Clause licensed. Anyhow, as you might expect the coding style / file naming / organization is firmware like. That means very very different from what we have in SOF.
Do you think such an interface would be acceptable to be merged in SOF? Or should we spent some time to rewrite it from scratch to match the quality of the existing SOF code?
The bad part in rewriting it from scratch is that we need to update-it by hand each time the SCFW interface changes.
Just to be clear, you are talking about a header file as well as the library implementing the interface to the SCU?
In the latter case, do we need to import it in the SOF project, which means periodic PRs to update it, or could you just link against it?
Ideally, I think would be to have the library implementing the interface inside the SOF project.
At least, we can keep the code there and link against it. Like we do it in Linux kernel with the SCU interface.
I don't want users to clone another repo just for that. The library is quite stable after initial versions. For i.MX8 boards we are adding now support (8QXP/8QM) we don't expect any major updates.
FWIW, Intel has two cases where we'd like to add the header files in the SOF project so that the integration is not an issue. However the libraries will not be part of the SOF tree, maybe something similar could apply here. we want it to make it easier to use additional libraries, but whether the code for those libraries belongs in SOF should be a case-by-case discussion.
I am not against on keeping the library outside of the SOF code base, I think it is a little bit easier for user to have the code in one repo.
We are internally still discussing which is the best way to do that, first lets see how code the intial version of the code turns out :).
Thanks for your comments.
daniel.
participants (3)
-
Daniel Baluta -
Daniel Baluta -
Pierre-Louis Bossart