Hi Rob, > Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Mon, Jul 15, 2019 at 4:10 AM Peng Fan <peng.fan@xxxxxxx> wrote: > > > > From: Peng Fan <peng.fan@xxxxxxx> > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan <peng.fan@xxxxxxx> > > --- > > > > V3: > > Convert to yaml > > Drop interrupt > > Introudce transports to indicate mem/reg The func id is still kept > > as optional, because like SCMI it only cares about message. > > > > V2: > > Introduce interrupts as a property. > > > > .../devicetree/bindings/mailbox/arm-smc.yaml | 124 > +++++++++++++++++++++ > > 1 file changed, 124 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index 000000000000..da9b1a03bc4e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,124 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C0%7C636988070002772705&sdata=DV > stQ%2FhuN > > +c67%2Bt08yXibQrX7sIeocHziYp3dkkeRoJ4%3D&reserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1d3bc2b4 > c6fa92cd9 > > > +9c5c301635%7C0%7C0%7C636988070002782698&sdata=D%2Fa2SU > W%2FCqclJdy > > +RbFggqqL%2BAEumER0K3rAaisY2bMc%3D&reserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@xxxxxxx> > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: > > + compatible: > > + const: arm,smc-mbox > > + > > + "#mbox-cells": > > + const: 1 > > + > > + arm,num-chans: > > + description: The number of channels supported. > > + $ref: /schemas/types.yaml#/definitions/uint32 > > Constraints? 0 is valid? 2^32? 0 is not valid. There should be limited channels, but depends on firmware design. > > > + > > + method: > > + items: > > + - enum: > > + - smc > > + - hvc > > + > > + transports: > > + items: > > + - enum: > > + - mem > > + - reg > > What if someone wants to configure this per channel? Perhaps #mbox-cells > should be 2 and this can be a client parameter. I need to check. Currently I only use one type. There might be people want to use different transports for each channels. > > Minimally, this needs a 'arm' vendor prefix if it stays. "arm,transports" in v4. > > > + > > + arm,func-ids: > > + description: | > > + An array of 32-bit values specifying the function IDs used by each > > + mailbox channel. Those function IDs follow the ARM SMC calling > > + convention standard [1]. > > What's the default if not specified? Or this should be required? If not specified, it means the client firmware driver will pass it to mailbox driver. Thanks, Peng. > > > + > > + There is one identifier per channel and the number of supported > > + channels is determined by the length of this array. > > + minItems: 0 > > + maxItems: 4096 # Should be enough? > > + > > +required: > > + - compatible > > + - "#mbox-cells" > > + - arm,num-chans > > + - transports > > + - method > > + > > +examples: > > + - | > > + sram@910000 { > > + compatible = "mmio-sram"; > > + reg = <0x0 0x93f000 0x0 0x1000>; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges = <0 0x0 0x93f000 0x1000>; > > + > > + cpu_scp_lpri: scp-shmem@0 { > > + compatible = "arm,scmi-shmem"; > > + reg = <0x0 0x200>; > > + }; > > + > > + cpu_scp_hpri: scp-shmem@200 { > > + compatible = "arm,scmi-shmem"; > > + reg = <0x200 0x200>; > > + }; > > + }; > > + > > + firmware { > > + smc_mbox: mailbox { > > + #mbox-cells = <1>; > > + compatible = "arm,smc-mbox"; > > + method = "smc"; > > + arm,num-chans = <0x2>; > > + transports = "mem"; > > + /* Optional */ > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > + }; > > + > > + scmi { > > + compatible = "arm,scmi"; > > + mboxes = <&mailbox 0 &mailbox 1>; > > + mbox-names = "tx", "rx"; > > + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; > > + }; > > + }; > > + > > +... > > -- > > 2.16.4 > >
