On 20/11/14 12:34, Vincent Yang wrote:
Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
Signed-off-by: Vincent Yang <[email protected]>
Signed-off-by: Tetsuya Nuriya <[email protected]>
---
  .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
  drivers/mailbox/Kconfig                            |   7 +
  drivers/mailbox/Makefile                           |   2 +
  drivers/mailbox/arm_mhu.c                          | 196 +++++++++++++++++++++
  4 files changed, 238 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt
  create mode 100644 drivers/mailbox/arm_mhu.c

diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt 
b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
new file mode 100644
index 0000000..b1b9888
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+
+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has
+3 independent channels/links to communicate with remote processor(s).

I had reviewed this before and I see not all the comments are addressed.
I had mentioned that you can't add support to _SECURE_ channel in Linux
as you need to assume Linux runs in non-secure privilege(and I gather
that's the case even on this platform from other email in the thread)

+ MHU links are hardwired on a platform. A link raises interrupt for any
+received data. However, there is no specified way of knowing if the sent
+data has been read by the remote. This driver assumes the sender polls
+STAT register and the remote clears it after having read the data.

That could be design, interrupt support could be present on some
systems. The bindings should be flexible to add that support in future
if needed along with necessary code.

Regards,
Sudeep

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to