Thread (36 messages) 36 messages, 4 authors, 2018-09-18
STALE2823d
Revisions (25)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v2 [diff vs current]
  5. v3 [diff vs current]
  6. v4 [diff vs current]
  7. v4 [diff vs current]
  8. v5 [diff vs current]
  9. v5 [diff vs current]
  10. v5 [diff vs current]
  11. v5 [diff vs current]
  12. v5 [diff vs current]
  13. v5 [diff vs current]
  14. v5 [diff vs current]
  15. v5 [diff vs current]
  16. v5 [diff vs current]
  17. v5 current
  18. v5 [diff vs current]
  19. v5 [diff vs current]
  20. v6 [diff vs current]
  21. v7 [diff vs current]
  22. v7 [diff vs current]
  23. v8 [diff vs current]
  24. v8 [diff vs current]
  25. v9 [diff vs current]

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

From: aisheng.dong@nxp.com (A.s. Dong)
Date: 2018-09-03 08:57:36

Hi Sascha,
-----Original Message-----
From: A.s. Dong
Sent: Wednesday, August 29, 2018 4:35 PM
To: Sascha Hauer <s.hauer@pengutronix.de>
[...]
quoted
quoted
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.
quoted
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.
.
This patch series has been pending for a long time. We need a way out to
speed up the work.

Regards
Dong Aisheng
Regards
Dong Aisheng
quoted
Sascha

--
Pengutronix e.K.                           |
|
Industrial Linux Solutions                 |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
quoted
pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C97
quoted
6c8b12abfc4be67f0708d60d7c2c1e%7C686ea1d3bc2b4c6fa92cd99c5c30163
quoted
5%7C0%7C0%7C636711224308904255&amp;sdata=i2OfGviDpZrpEQVVv51gd
quoted
gu2Cq20aBtRRtzR2wLzr0U%3D&amp;reserved=0  | Peiner Str. 6-8, 31137
Hildesheim, Germany | Phone: +49-5121-206917-0
|
Amtsgericht Hildesheim, HRA 2686           | Fax:
+49-5121-206917-5555 |
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help