-----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@nxp.com>
Cc: dongas86 at gmail.com; dl-linux-imx <redacted>;
kernel at pengutronix.de; Fabio Estevam [off-list ref];
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:

quoted

quoted

-----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@nxp.com>
Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
dl-linux-imx [off-list ref]; kernel at pengutronix.de; Fabio
Estevam [off-list ref]; 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:

quoted

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

quoted

quoted

and

quoted

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 :)

quoted

"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. 

quoted

"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