| Message ID | 1563184103-8493-2-git-send-email-peng.fan@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mailbox: arm: introduce smc triggered mailbox | expand |
On Mon, Jul 15, 2019 at 4:10 AM Peng Fan <peng.fan@nxp.com> wrote: > > From: Peng Fan <peng.fan@nxp.com> > > 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@nxp.com> > --- > > 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@nxp.com> > + > +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? > + > + 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. Minimally, this needs a 'arm' vendor prefix if it stays. > + > + 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? > + > + 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 >
This looks much better now. On Mon, Jul 15, 2019 at 10:10:10AM +0000, Peng Fan wrote: > From: Peng Fan <peng.fan@nxp.com> > > 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@nxp.com> > --- > > 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@nxp.com> > + > +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
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@nxp.com> wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > 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@nxp.com> > > --- > > > > 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@nxp.com> > > + > > +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 > >
Hi Sudeep, > Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > This looks much better now. > > On Mon, Jul 15, 2019 at 10:10:10AM +0000, Peng Fan wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > 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@nxp.com> > > --- > > > > 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%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C636989812923178414&sdata=UT > 7r2vOLX4a > > +tv7Yfh750wdSXSh2ZPxeJOXLWl5yACK0%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%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1d3bc2b4c > 6fa92cd9 > > > +9c5c301635%7C0%7C1%7C636989812923178414&sdata=3Gjn1NQtO > PbvfTvyN3X > > +b89%2BvvGO2ff6DpGQUQejGAzU%3D&reserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@nxp.com> > > + > > +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 ? I am also new to yaml, Rob might have ideas. > > > + > > +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 ? In the v3 patchset, Jassi expected the id be passed from client firmware driver, but you said scmi is expected a only message protocol. So here I still keep this as optional, if specified in dts, the mailbox driver will use it. If not specificed in dts, the mailbox driver expect the client firmware driver pass the func id to mailbox driver. Thanks, Peng. > > -- > Regards, > Sudeep
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@nxp.com> + +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? + +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>; + }; + }; + +...