[Sound-open-firmware] System Controller Unit firmware code inside SOF

[Daniel Baluta]

On Tue, Sep 3, 2019 at 7:12 PM Pierre-Louis Bossart
<pierre-louis.bossart at 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.