[PATCH V3 2/5] soc: imx: add mu library functions support

-----Original Message-----
From: A.s. Dong
Sent: Monday, June 25, 2018 7:59 PM
To: Sascha Hauer <s.hauer@pengutronix.de>
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 V3 2/5] soc: imx: add mu library functions support

quoted

-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, June 25, 2018 5:35 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

quoted

[off-list ref]; shawnguo at kernel.org
Subject: Re: [PATCH V3 2/5] soc: imx: add mu library functions support

On Fri, Jun 22, 2018 at 10:11:57PM +0800, Dong Aisheng wrote:

quoted

This is used for i.MX multi core communication.
e.g. A core to SCU firmware(M core) on MX8.

I still believe that a generic driver for the MU should be used here.
Handling hardware resources under the hood of the driver framework is
a hack. Preventing the generic driver from matching against the SCU MU
by adding some #mbox-cells = <0>; to the MU device node is even more a

hack.

quoted

That is not a hack from a HW point of view. The MU HW does not have multi
channels according to Reference Manual. Even we switch to mailbox, we
probably may still prefer mbox-cell = <0> as the virtual channels do not fit for
SCU MU.

quoted

We should really handle the MU in a driver and look for a way how the
SCU case can coexist with other usages of the MUs.

Your main argument against using the mailbox framework is that it
can't handle polling in the way you need it and that the mailbox
framework provides things that you do not need. I don't buy this
argument. In the end the mailbox framework is around 500 lines of
code, it shouldn't be that hard to add the missing features. From the
transmit side I don't see any showstoppers, the mailbox frameworks
could be used as ist. What is missing is a synchronous
wait-for-new-messages and receive-message call, the currently existing

asynchronous rx callback is indeed not suitable for the SCU.

quoted

But as said, it should be doable to add that.

Besides the mailbox framework may not suitable for SCU, another important
Reason is that even we force to switch to mailbox, it's still can't be generic
driver and it can only be used by SCU MU.

Let's see the mailbox doc where it also highlights it may somehow depend on
mailbox communication protocol.

Documentation/mailbox.txt
----------------------------------------------------------------------------------------
This document aims to help developers write client and controller drivers for
the API. But before we start, let us note that the client (especially) and
controller drivers are likely going to be very platform specific because the
remote firmware is likely to be proprietary and implement non-standard
protocol.
.....
----------------------------------------------------------------------------------------

So the question to us is: If it can't be generic driver which can be used by
others as well and it introduces much unnecessary complexities, why do we
need do that? What's real benefits we can have?

Another option is we can try to improve mailbox framework to fit
for SCU MU user case, but that may be a long time which will block all
QXP bits upstreaming as most QXP parts are based on SCU API call.
How about do that as an improvement investigation later? As the underlying
IPC communication mechanism is somehow separate and independent of
the high layer service and client users and current implementation is quite
light one, won't cause much extra code.
That won't block QXP upstream and can also have an in-tree comparison
to the old ways.

How do you think of it?

Regards
Dong Aisheng

Regards
Dong Aisheng

quoted

Sascha

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 |

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww

quoted

w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7Cfe5

quoted

2cb3aecd3461fab3d08d5da7eefc6%7C686ea1d3bc2b4c6fa92cd99c5c301635%

7C0%7C0%7C636655161075403401&sdata=bRnnlrq82OAlxoli5IHAtXuwieLGJM

quoted

4raDRvaV8y5gs%3D&reserved=0  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |