From: robh@kernel.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
Date: Mon, 8 Feb 2016 13:37:06 -0600 [thread overview]
Message-ID: <20160208193706.GA333@rob-hp-laptop> (raw)
In-Reply-To: <1454690044-2560-2-git-send-email-nm@ti.com>
On Fri, Feb 05, 2016 at 10:34:03AM -0600, Nishanth Menon wrote:
> Message Manager is a hardware block used to communicate with various
> processor systems within certain Texas Instrument's Keystone
> generation SoCs.
>
> This hardware engine is used to transfer messages from various compute
> entities(or processors) within the SoC. It is designed to be self
> contained without needing software initialization for operation.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../bindings/mailbox/ti,message-manager.txt | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> new file mode 100644
> index 000000000000..f3d73b0b3c66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> @@ -0,0 +1,72 @@
> +Texas Instruments' Message Manager Driver
> +========================================
> +
> +The Texas Instruments' Message Manager is a mailbox controller that has
> +configurable queues selectable at SoC(System on Chip) integration. The Message
> +manager is broken up into queues in different address regions that are called
> +"proxies" - each instance is unidirectional and is instantiated at SoC
> +integration level to indicate receive or transmit path.
> +
> +Message Manager Device Node:
> +===========================
> +
> +Required properties:
> +--------------------
> +- compatible: Shall be:
> + "ti,k2g-message-manager"
> + "ti,message-manager"
Given that queues are configurable at integration time, does a generic
property really make sense here?
> +- reg-names queue_proxy_region - Map the queue Proxy region
> + queue_state_debug_region - Map the queue state debug
> + region.
> +- reg: Contains the register map per reg-names
> +- #mbox-cells Shall be 1
And the value contained is what?
> +
> +Child Nodes:
> +============
> +A child node is used for representing the actual queue device that is
> +used for the communication between the host processor and a remote processor.
> +Each child node should have a unique node name across all the different
> +message manager device nodes.
> +
> +Required Properties:
> +--------------------
> +- ti,queue-id: Indicates the queue number this node represents
> +- ti,proxy-id: Proxy ID representing the processor in the SoC.
What determines these values?
> +
> +Optional Properties:
> +--------------------
> +- interrupt-names: 'rx' - indicates a receive interrupt (mandatory ONLY if
> + this is a receive queue)
Kind of pointless if there is only 1.
> +- interrupts: Contains the interrupt information corresponding to
> + interrupt-names property.
> +
> +Example:
> +--------
> +
> + msgmgr: msgmgr at 02a00000 {
> + compatible = "ti,k2g-message-manager", "ti,message-manager";
> + #mbox-cells = <1>;
> + reg-names = "queue_proxy_region", "queue_state_debug_region";
> + reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
> +
> + msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
> + ti,queue-id = <0>;
> + ti,proxy-id = <0>;
> + };
> +
> + msgmgr_proxy_pmmc_rx: pmmc_rx {
> + ti,queue-id = <5>;
> + ti,proxy-id = <2>;
> + interrupt-names = "rx";
> + interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
> + };
> + };
> +
> +...
> + pmmc {
> + ...
> + mbox-names = "tx", "rx";
> + mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
> + <&msgmgr &msgmgr_proxy_pmmc_rx>;
While I guess this is valid DT, it is a bit strange having the cell
values be phandles. Why not just make the queue and proxy ids be the
cell values? The interrupts could be moved to the parent and the child
nodes eliminated altogether.
The alternative would be just drop msgmgr phandle and point to the child
nodes. I prefer getting rid of the child nodes though.
Rob
next prev parent reply other threads:[~2016-02-08 19:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 16:34 [PATCH 0/2] mailbox: Introduce Texas Instrument's message manager driver Nishanth Menon
2016-02-05 16:34 ` [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager Nishanth Menon
2016-02-08 19:37 ` Rob Herring [this message]
2016-02-08 20:23 ` Suman Anna
2016-02-08 20:31 ` Nishanth Menon
2016-02-09 4:14 ` Jassi Brar
2016-02-09 12:31 ` Nishanth Menon
2016-02-09 14:54 ` Jassi Brar
2016-02-09 15:35 ` Jassi Brar
2016-02-09 15:43 ` Nishanth Menon
2016-02-09 18:10 ` Nishanth Menon
2016-02-10 20:13 ` Suman Anna
2016-02-10 20:51 ` Nishanth Menon
2016-02-11 4:23 ` Jassi Brar
2016-02-11 5:03 ` Nishanth Menon
2016-02-26 11:59 ` Jassi Brar
2016-02-26 22:30 ` Nishanth Menon
2016-02-05 16:34 ` [PATCH 2/2] mailbox: Introduce TI message manager driver Nishanth Menon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160208193706.GA333@rob-hp-laptop \
--to=robh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox