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

[Oleksij Rempel]

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.


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