On 02.05.2018 20:54, A.s. Dong wrote:

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

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/37fecab4/attachment.sig>