[PATCH 0/4] soc: imx: add scu firmware api support

[A.s. Dong]

> -----Original Message-----
> From: Oleksij Rempel [mailto:o.rempel at pengutronix.de]
> Sent: Thursday, May 3, 2018 2:24 PM
> To: A.s. Dong <aisheng.dong at nxp.com>
> Cc: dongas86 at gmail.com; dl-linux-imx <linux-imx at nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam at nxp.com>;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 0/4] soc: imx: add scu firmware api support
> 
> 
> 
> On 02.05.2018 20:54, A.s. Dong wrote:
> >> -----Original Message-----
> >> From: Oleksij Rempel [mailto:o.rempel at pengutronix.de]
> >> Sent: Tuesday, May 1, 2018 1:59 PM
> >> To: A.s. Dong <aisheng.dong at nxp.com>
> >> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> >> dl-linux-imx <linux-imx at nxp.com>; kernel at pengutronix.de; Fabio
> >> Estevam <fabio.estevam at nxp.com>; shawnguo at kernel.org
> >> Subject: Re: [PATCH 0/4] soc: imx: add scu firmware api support
> >>
> >> Hi,
> >>
> >> On Sat, Apr 28, 2018 at 02:46:12AM +0800, Dong Aisheng wrote:
> >>> Unlike the former i.MX Architectures, the new generation i.MX8 SoCs
> >>> (e.g. MX8QXP and MX8QM) contain a system controller which runs on a
> >>> dedicated Cortex-M core to provide power, clock, Pad, and resource
> >>> management. Communication between the host processor running an
> OS
> >> and
> >>> the system controller happens through a SCU protocol.
> >>> This patchset adds the SCU APIs which is implemented based on MU and
> >>> will be used by different system components.
> >>>
> >>> It mainly consists of below parts:
> >>> 1) MU library calls
> >>> 1) Implementation of the IPC functions based on MUs (client side).
> >>> 2) SCU firmware services APIs implementation ased on RPC calls which
> >>>    are mostly generated by SCU firmware
> >>
> >>
> >> Hm... I fail to see the difference between remoteproc, virtio, rpmsg
> >> and other existing frameworks in kernel with this functionality. Why
> >> do we need vendor/soc specific framework once again?
> >>
> >
> > Hmm.. It seems like not a vendor specific framework...
> > It mainly SCU firmware APIs generated by SCU firmware script for Linux
> > OS components to use.
> > And those APIs are implemented base on MU simple polling mode With
> > better performance.
> >
> > NXP internally has tried mailbox but got performance regression, So
> > we're still not sure whether Mailbox is quit suitable for i.MX SCU
> > Firmware. Needs more time to investigate.
> >
> > And I'm still not quite familiar with remoteproc, virtio, rpmsg.
> > May need spend more time to investigate later.
> > And it would be good if you can provide suggestions and sharing
> > Informations about them.
> > e.g. what's requirement of i.MX to switch to them? Benefit? Or
> > something else valuable?
> 
> Before starting with suggestions I would like to get some more information :)
> 
> > "And those APIs are implemented base on MU simple polling mode With
> > better performance."
> 
> was this implementation tested in complex system configuration? Mostly
> polling is a one task optimization. All other corners of the system usually get
> dramatic performance degradation.
> 

Yes, the whole MX8QM/QXP system actually is very complicated already when
busy running with Graphic & Video IO features (e.g. GPU/VPU/HDMI and etc.)
But we did not make specific comparing of another IPC handling way. E.g. mailbox
Or rpmsg.

We actually tried mailbox before but see boot time regression(no much more features test).
AFAIK SCU message handling usually is quite fast in micro seconds. So simple polling may
be a better choice.

If we want to switch to Mailbox or something else, we probably need do robust investigation
to void any performance regression. That may need a lot time.

So maybe we can go with the current simple way to make QXP upstreamed first.
Then we can have more time to investigate it carefully later, and better for comparison.

Anyway, even if we want to switch to Mailbox, that seems to be just a IPC implementation
Change(ipc.c), won't affect other part. So looks like a applicable way to me
which won't block QXP support too long. 

> 
> > "All other files actually are generated by SCU firmware script
> > automatically for Linux OS. They're tightly couple with SCU firmware
> > side implementation. In order to gain better maintainability (easy
> > upgrade and sync with SCU firmware), we're trying to not change those
> > APIs too much unless we have strong reasons."
> 
> Means, updates and changes of Firmware API are already included by design?
> Since it is start-of-life for this SoC family, number of API changes is expected
> risk?

The SCU firmware protocol (API) usually won't change.  It did happen during
early time development internally. But it's much stable now after years
of evolution . From what I see, we may need update it if we need a new feature
supported by a new version of SCU firmware.

Regards
Dong Aisheng