From: Tushar K <tushar.2nov@gmail.com>
To: Tushar Khandelwal <Tushar.Khandelwal@arm.com>
Cc: Sudeep Holla <Sudeep.Holla@arm.com>,
Jassi Brar <jassisinghbrar@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"morten_bp@live.dk" <morten_bp@live.dk>, nd <nd@arm.com>,
Morten Petersen <Morten.Petersen@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <Mark.Rutland@arm.com>,
Devicetree List <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
Date: Wed, 7 Aug 2019 12:32:45 +0100 [thread overview]
Message-ID: <CAEVvzVRdbyYGLA1tnO5ZJyhUVjBMqKBSz5m23QicjPebgfwFpQ@mail.gmail.com> (raw)
In-Reply-To: <998A97B0-D9D3-4F01-B5D4-56F875D38FC8@arm.com>
[-- Attachment #1: Type: text/plain, Size: 7885 bytes --]
Please ignore the disclaimers in the previous replies. This is a problem
with the server which I am looking into.
On Wed, 7 Aug 2019 at 12:17, Tushar Khandelwal <Tushar.Khandelwal@arm.com>
wrote:
>
>
> On 02/08/2019, 11:59, "Sudeep Holla" <sudeep.holla@arm.com> wrote:
>
> On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote:
> > On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
> > <tushar.khandelwal@arm.com> wrote:
> >
> > > diff --git
> a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > > new file mode 100644
> > > index 000000000000..3a05593414bc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > > @@ -0,0 +1,108 @@
> > > +Arm MHUv2 Mailbox Driver
> > > +========================
> > > +
> > > +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox
> controller that has
> > > +between 1 and 124 channel windows to provide unidirectional
> communication with
> > > +remote processor(s).
> > > +
> > > +Given the unidirectional nature of the device, an MHUv2 mailbox
> may only be
> > > +written to or read from. If a pair of MHU devices is implemented
> between two
> > > +processing elements to provide bidirectional communication, these
> must be
> > > +specified as two separate mailboxes.
> > > +
> > > +A device tree node for an Arm MHUv2 device must specify either a
> receiver frame
> > > +or a sender frame, indicating which end of the unidirectional MHU
> device which
> > > +the device node entry describes.
> > > +
> > > +An MHU device must be specified with a transport protocol. The
> transport
> > > +protocol of an MHU device determines the method of data
> transmission as well as
> > > +the number of provided mailboxes.
> > > +Following are the possible transport protocol types:
> > > +- Single-word: An MHU device implements as many mailboxes as it
> > > + provides channel windows. Data is transmitted
> through
> > > + the MHU registers.
> > > +- Multi-word: An MHU device implements a single mailbox. All
> channel windows
> > > + will be used during transmission. Data is
> transmitted through
> > > + the MHU registers.
> > > +- Doorbell: An MHU device implements as many mailboxes as
> there are flag
> > > + bits available in its channel windows. Optionally,
> data may
> > > + be transmitted through a shared memory region,
> wherein the MHU
> > > + is used strictly as an interrupt generation
> mechanism.
> > > +
> > > +Mailbox Device Node:
> > > +====================
> > > +
> > > +Required properties:
> > > +--------------------
> > > +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
> > > +- reg: Contains the mailbox register address range (base
> > > + address and length)
> > > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > > +- mhu-frame Frame type of the device.
> > > + Shall be either "sender" or "receiver"
> > > +- mhu-protocol Transport protocol of the device. Shall be one of
> the
> > > + following: "single-word", "multi-word", "doorbell"
> > > +
> > > +Required properties (receiver frame):
> > > +-------------------------------------
> > > +- interrupts: Contains the interrupt information corresponding
> to the
> > > + combined interrupt of the receiver frame
> > > +
> > > +Example:
> > > +--------
> > > +
> > > + mbox_mw_tx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x10000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + mhu-protocol = "multi-word";
> > > + mhu-frame = "sender";
> > > + };
> > > +
> > > + mbox_sw_tx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x11000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + mhu-protocol = "single-word";
> > > + mhu-frame = "sender";
> > > + };
> > > +
> > > + mbox_db_rx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x12000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + interrupts = <0 45 4>;
> > > + interrupt-names = "mhu_rx";
> > > + mhu-protocol = "doorbell";
> > > + mhu-frame = "receiver";
> > > + };
> > > +
> > > + mhu_client: scb@2e000000 {
> > > + compatible = "fujitsu,mb86s70-scb-1.0";
> > > + reg = <0 0x2e000000 0x4000>;
> > > + mboxes =
> > > + // For multi-word frames, client may only
> instantiate a single
> > > + // mailbox for a mailbox controller
> > > + <&mbox_mw_tx 0>,
> > > +
> > > + // For single-word frames, client may instantiate
> as many
> > > + // mailboxes as there are channel windows in the
> MHU
> > > + <&mbox_sw_tx 0>,
> > > + <&mbox_sw_tx 1>,
> > > + <&mbox_sw_tx 2>,
> > > + <&mbox_sw_tx 3>,
> > > +
> > > + // For doorbell frames, client may instantiate as
> many mailboxes
> > > + // as there are bits available in the combined
> number of channel
> > > + // windows ((channel windows * 32) mailboxes)
> > > + <mbox_db_rx 0>,
> > > + <mbox_db_rx 1>,
> > > + ...
> > > + <mbox_db_rx 17>;
> > > + };
> >
> > If the mhuv2 instance implements, say, 3 channel windows between
> > sender (linux) and receiver (firmware), and Linux runs two protocols
> > each requiring 1 and 2-word sized messages respectively. The hardware
> > supports that by assigning windows [0] and [1,2] to each protocol.
> > However, I don't think the driver can support that. Or does it?
> >
>
> FWIW, the IP is designed to cover wide range of usecase from IoT to
> servers
> with variable window length. I don't see the need to complicate the
> driver
> supporting mix-n-match at the cost of latency. Each platform choose one
> transport protocol for all it's use.
>
> The driver design is to address the most probable scenarios and not all.
> Single-word : Client gets one 32-bit window
> Doorbell : Client gets 32 data pointers (arm_message)
> Multi-word: Client gets all channels available in the platform.
>
> --Tushar
> --
> Regards,
> Sudeep
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
[-- Attachment #2: Type: text/html, Size: 10436 bytes --]
next prev parent reply other threads:[~2019-08-07 11:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190717192616.1731-1-tushar.khandelwal@arm.com>
2019-07-17 19:26 ` [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation Tushar Khandelwal
2019-07-21 21:58 ` Jassi Brar
2019-07-25 5:49 ` Jassi Brar
2019-07-28 21:28 ` Morten Borup Petersen
2019-07-31 7:31 ` Jassi Brar
2019-08-02 10:41 ` Morten Borup Petersen
2019-08-13 16:36 ` Jassi Brar
2019-08-14 10:05 ` Sudeep Holla
2019-08-14 14:52 ` Jassi Brar
2019-08-14 16:51 ` Sudeep Holla
2019-08-14 22:22 ` tushar.khandelwal
2019-08-14 22:20 ` tushar.khandelwal
2019-08-02 10:53 ` Sudeep Holla
2019-08-07 11:11 ` Tushar Khandelwal
2019-07-28 21:27 ` Morten Borup Petersen
2019-08-02 10:59 ` Sudeep Holla
2019-08-07 11:17 ` Tushar Khandelwal
2019-08-07 11:32 ` Tushar K [this message]
2019-08-08 10:31 ` Morten Borup Petersen
2019-07-17 19:26 ` [PATCH 2/4] mailbox: arm_mhuv2: add arm mhuv2 driver Tushar Khandelwal
2019-07-17 19:26 ` [PATCH 3/4] mailbox: arm_mhuv2: add doorbell transport protocol operations Tushar Khandelwal
2019-07-17 19:26 ` [PATCH 4/4] mailbox: arm_mhuv2: add multi word " Tushar Khandelwal
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=CAEVvzVRdbyYGLA1tnO5ZJyhUVjBMqKBSz5m23QicjPebgfwFpQ@mail.gmail.com \
--to=tushar.2nov@gmail.com \
--cc=Mark.Rutland@arm.com \
--cc=Morten.Petersen@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=Tushar.Khandelwal@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=morten_bp@live.dk \
--cc=nd@arm.com \
--cc=robh+dt@kernel.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;
as well as URLs for NNTP newsgroup(s).