[PATCH V5 0/5] soc: imx: add scu firmware api support
s.hauer at pengutronix.de
Mon Sep 3 04:44:39 PDT 2018
On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:
> Hi Sascha,
> > -----Original Message-----
> > From: A.s. Dong
> > Sent: Wednesday, August 29, 2018 4:35 PM
> > To: Sascha Hauer <s.hauer at pengutronix.de>
> > > > The original point is to separate the SCU service API implementation
> > > > from the client drivers. Client drivers don't have to know the
> > > > internal details of the API implementation, they just use the
> > > > service API provided by SCU firmware. API implementation and client
> > > > users will be
> > > maintained independently.
> > >
> > > I would buy this argument if the 'API implementation' was more than a
> > > shim layer that directly translates between function arguments and a
> > message struct.
> > > With this you effectively can't change the API implementation without
> > > changing the API you provide to the client drivers.
> > >
> > In reality, the API implementation could change without changing the API
> > prototype.
> > The API is defined in a more generic way and less possible to change.
> > But the internal implementation is allowed to change if the firmware updates.
> > e.g. protocol params layout and size and etc.
> > This way give us a clear separation between API internals and client users
> > which are more like to be maintained independently.
> > And it may also help if we want to support old firmware due to API internal
> > implementation changes. (And note that SCU firmware supports many
> > functions, distribute them into various drivers may cause a bit mess. Some of
> > them may get troubles on finding a proper place to put.)
> > So aren't those more valuable comparing to move SCU APIs into client drivers?
> > And current kernel users (arm scpi/scmi, ti sci) already do like this... why not
> > i.MX?
> > Sorry if I still not get your point.
> > Please help clarify a bit more if I missed something..
> Please let me know if you still believe moving SCU API implementation into
> each client driver is a more reasonable way to go, then i will do it as I trust
> your professionality.
Yes, I still think that. I still think the 1:1 mapping between messages
and function calls is an unnecessary overhead.
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the linux-arm-kernel