This looks much better now. On Mon, Jul 15, 2019 at 10:10:10AM +0000, Peng Fan 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: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +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 > + > + method: > + items: > + - enum: > + - smc > + - hvc > + > + transports: > + items: > + - enum: > + - mem > + - reg > + > + 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]. > + > + 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? I am new to yaml, is there a way to say the number of entries here must match arm,num-chans ? And not sure if min/maxItems matter then ? > + > +required: > + - compatible > + - "#mbox-cells" > + - arm,num-chans > + - transports > + - method > + Why is arm,func-ids optional ? Is there any standard arm,func-ids we can resort to. Sorry I know you expect ARM Ltd to answer that, but I just want to raise the point that we don't have one today and hence it can't be optional. Or I am missing something ? -- Regards, Sudeep
