From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20190717192616.1731-1-tushar.khandelwal@arm.com> <20190717192616.1731-2-tushar.khandelwal@arm.com> <20190802105938.GG23424@e107155-lin> <998A97B0-D9D3-4F01-B5D4-56F875D38FC8@arm.com> In-Reply-To: <998A97B0-D9D3-4F01-B5D4-56F875D38FC8@arm.com> From: Tushar K Date: Wed, 7 Aug 2019 12:32:45 +0100 Message-ID: Subject: Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation Content-Type: multipart/alternative; boundary="000000000000798add058f854d47" To: Tushar Khandelwal Cc: Sudeep Holla , Jassi Brar , Linux Kernel Mailing List , "morten_bp@live.dk" , nd , Morten Petersen , Rob Herring , Mark Rutland , Devicetree List List-ID: --000000000000798add058f854d47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > > =EF=BB=BFOn 02/08/2019, 11:59, "Sudeep Holla" wrot= e: > > On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote: > > On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal > > 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 > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > + > > > +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, thes= e > 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 MH= U > 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: > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > + > > > +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 =3D "arm,mhuv2","arm,primecell"; > > > + reg =3D <0x10000000 0x1000>; > > > + clocks =3D <&refclk100mhz>; > > > + clock-names =3D "apb_pclk"; > > > + #mbox-cells =3D <1>; > > > + mhu-protocol =3D "multi-word"; > > > + mhu-frame =3D "sender"; > > > + }; > > > + > > > + mbox_sw_tx: mhu@10000000 { > > > + compatible =3D "arm,mhuv2","arm,primecell"; > > > + reg =3D <0x11000000 0x1000>; > > > + clocks =3D <&refclk100mhz>; > > > + clock-names =3D "apb_pclk"; > > > + #mbox-cells =3D <1>; > > > + mhu-protocol =3D "single-word"; > > > + mhu-frame =3D "sender"; > > > + }; > > > + > > > + mbox_db_rx: mhu@10000000 { > > > + compatible =3D "arm,mhuv2","arm,primecell"; > > > + reg =3D <0x12000000 0x1000>; > > > + clocks =3D <&refclk100mhz>; > > > + clock-names =3D "apb_pclk"; > > > + #mbox-cells =3D <1>; > > > + interrupts =3D <0 45 4>; > > > + interrupt-names =3D "mhu_rx"; > > > + mhu-protocol =3D "doorbell"; > > > + mhu-frame =3D "receiver"; > > > + }; > > > + > > > + mhu_client: scb@2e000000 { > > > + compatible =3D "fujitsu,mb86s70-scb-1.0"; > > > + reg =3D <0 0x2e000000 0x4000>; > > > + mboxes =3D > > > + // 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) > > > + , > > > + , > > > + ... > > > + ; > > > + }; > > > > If the mhuv2 instance implements, say, 3 channel windows between > > sender (linux) and receiver (firmware), and Linux runs two protocol= s > > each requiring 1 and 2-word sized messages respectively. The hardwa= re > > 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 o= ne > 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 th= e > information in any medium. Thank you. > --000000000000798add058f854d47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please ignore the disclaimers in the previous rep= lies. This is a problem with the server which I am looking into.

On We= d, 7 Aug 2019 at 12:17, Tushar Khandelwal <Tushar.Khandelwal@arm.com> wrote:


=EF=BB=BFOn 02/08/2019, 11:59, "Sudeep Holla" <sudeep.holla@arm.com> wro= te:

=C2=A0 =C2=A0 On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote: =C2=A0 =C2=A0 > On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
=C2=A0 =C2=A0 > <tushar.khandelwal@arm.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > diff --git a/Documentation/devicetree/bindings/mail= box/arm,mhuv2.txt b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt=
=C2=A0 =C2=A0 > > new file mode 100644
=C2=A0 =C2=A0 > > index 000000000000..3a05593414bc
=C2=A0 =C2=A0 > > --- /dev/null
=C2=A0 =C2=A0 > > +++ b/Documentation/devicetree/bindings/mailbox/arm= ,mhuv2.txt
=C2=A0 =C2=A0 > > @@ -0,0 +1,108 @@
=C2=A0 =C2=A0 > > +Arm MHUv2 Mailbox Driver
=C2=A0 =C2=A0 > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +The Arm Message-Handling-Unit (MHU) Version 2 is a= mailbox controller that has
=C2=A0 =C2=A0 > > +between 1 and 124 channel windows to provide unidi= rectional communication with
=C2=A0 =C2=A0 > > +remote processor(s).
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +Given the unidirectional nature of the device, an = MHUv2 mailbox may only be
=C2=A0 =C2=A0 > > +written to or read from. If a pair of MHU devices = is implemented between two
=C2=A0 =C2=A0 > > +processing elements to provide bidirectional commu= nication, these must be
=C2=A0 =C2=A0 > > +specified as two separate mailboxes.
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +A device tree node for an Arm MHUv2 device must sp= ecify either a receiver frame
=C2=A0 =C2=A0 > > +or a sender frame, indicating which end of the uni= directional MHU device which
=C2=A0 =C2=A0 > > +the device node entry describes.
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +An MHU device must be specified with a transport p= rotocol. The transport
=C2=A0 =C2=A0 > > +protocol of an MHU device determines the method of= data transmission as well as
=C2=A0 =C2=A0 > > +the number of provided mailboxes.
=C2=A0 =C2=A0 > > +Following are the possible transport protocol type= s:
=C2=A0 =C2=A0 > > +- Single-word: An MHU device implements as many ma= ilboxes as it
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0provides channel windows. Data is transmitted through
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the MHU registers.
=C2=A0 =C2=A0 > > +- Multi-word:=C2=A0 An MHU device implements a sin= gle mailbox. All channel windows
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0will be used during transmission. Data is transmitted through
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the MHU registers.
=C2=A0 =C2=A0 > > +- Doorbell:=C2=A0 =C2=A0 An MHU device implements = as many mailboxes as there are flag
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0bits available in its channel windows. Optionally, data may
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0be transmitted through a shared memory region, wherein the MHU
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is used strictly as an interrupt generation mechanism.
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +Mailbox Device Node:
=C2=A0 =C2=A0 > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +Required properties:
=C2=A0 =C2=A0 > > +--------------------
=C2=A0 =C2=A0 > > +- compatible:=C2=A0 Shall be "arm,mhuv2"= & "arm,primecell"
=C2=A0 =C2=A0 > > +- reg:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Contains t= he mailbox register address range (base
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0address and length)
=C2=A0 =C2=A0 > > +- #mbox-cells=C2=A0 Shall be 1 - the index of the = channel needed.
=C2=A0 =C2=A0 > > +- mhu-frame=C2=A0 =C2=A0 Frame type of the device.=
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Shall be either "sender" or "receiver"
=C2=A0 =C2=A0 > > +- mhu-protocol Transport protocol of the device. S= hall be one of the
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0following: "single-word", "multi-word", "doo= rbell"
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +Required properties (receiver frame):
=C2=A0 =C2=A0 > > +-------------------------------------
=C2=A0 =C2=A0 > > +- interrupts:=C2=A0 Contains the interrupt informa= tion corresponding to the
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0combined interrupt of the receiver frame
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +Example:
=C2=A0 =C2=A0 > > +--------
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0mbox_mw_tx: mhu@1000000= 0 {
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0compatible =3D "arm,mhuv2","arm,primecell";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0reg =3D <0x10000000 0x1000>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clocks =3D <&refclk100mhz>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clock-names =3D "apb_pclk";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0#mbox-cells =3D <1>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-protocol =3D "multi-word";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-frame =3D "sender";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0mbox_sw_tx: mhu@1000000= 0 {
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0compatible =3D "arm,mhuv2","arm,primecell";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0reg =3D <0x11000000 0x1000>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clocks =3D <&refclk100mhz>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clock-names =3D "apb_pclk";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0#mbox-cells =3D <1>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-protocol =3D "single-word";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-frame =3D "sender";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0mbox_db_rx: mhu@1000000= 0 {
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0compatible =3D "arm,mhuv2","arm,primecell";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0reg =3D <0x12000000 0x1000>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clocks =3D <&refclk100mhz>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0clock-names =3D "apb_pclk";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0#mbox-cells =3D <1>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0interrupts =3D <0 45 4>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0interrupt-names =3D "mhu_rx";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-protocol =3D "doorbell";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0mhu-frame =3D "receiver";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0mhu_client: scb@2e00000= 0 {
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D "fu= jitsu,mb86s70-scb-1.0";
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0reg =3D <0 0x2e00000= 0 0x4000>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0mboxes =3D
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// For multi-word frames, client may only instantiate a single
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// mailbox for a mailbox controller
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<&mbox_mw_tx 0>,
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// For single-word frames, client may instantiate as many
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// mailboxes as there are channel windows in the MHU
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <&mbox_sw_tx 0>,
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <&mbox_sw_tx 1>,
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <&mbox_sw_tx 2>,
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <&mbox_sw_tx 3>,
=C2=A0 =C2=A0 > > +
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// For doorbell frames, client may instantiate as many mailboxes
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// as there are bits available in the combined number of channel
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0// windows ((channel windows * 32) mailboxes)
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <mbox_db_rx 0>,
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <mbox_db_rx 1>,
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ...
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <mbox_db_rx 17>;
=C2=A0 =C2=A0 > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If the mhuv2 instance implements, say, 3 channel windows= between
=C2=A0 =C2=A0 > sender (linux) and receiver (firmware), and Linux runs t= wo protocols
=C2=A0 =C2=A0 > each requiring 1 and 2-word sized messages respectively.= The hardware
=C2=A0 =C2=A0 > supports that by assigning windows [0] and [1,2] to each= protocol.
=C2=A0 =C2=A0 > However, I don't think the driver can support that. = Or does it?
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 FWIW, the IP is designed to cover wide range of usecase from = IoT to servers
=C2=A0 =C2=A0 with variable window length. I don't see the need to comp= licate the driver
=C2=A0 =C2=A0 supporting mix-n-match at the cost of latency. Each platform = choose one
=C2=A0 =C2=A0 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
=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Sudeep


IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.
--000000000000798add058f854d47--