Message ID | 20200918165558.257086-1-peter.hilber@opensynergy.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | firmware: arm_scmi: Add virtio transport | expand |
On Fri, Sep 18, 2020 at 06:55:58PM +0200, Peter Hilber wrote: > From: Igor Skalkin <igor.skalkin@opensynergy.com> > > Document the properties for arm,scmi-virtio compatible nodes. The > backing virtio SCMI device is described in patch [1]. > > [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html > > Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> > Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> > Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> > --- > .../devicetree/bindings/arm/arm,scmi.txt | 38 ++++++++++++++++++- > 1 file changed, 36 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt > index 55deb68230eb..844ff3c40a49 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt > @@ -13,6 +13,9 @@ the device tree. > Required properties: > > The scmi node with the following properties shall be under the /firmware/ node. > +Some properties are specific to a transport type. > + > +shmem-based transports (mailbox, smc/hvc): > > - compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports > - mboxes: List of phandle and mailbox channel specifiers. It should contain > @@ -21,6 +24,17 @@ The scmi node with the following properties shall be under the /firmware/ node. > supported. > - shmem : List of phandle pointing to the shared memory(SHM) area as per > generic mailbox client binding. > + > +Virtio transport: > + > +- compatible : shall be "arm,scmi-virtio". > +- virtio_transport : phandle of the virtio device. This device must support one > + virtqueue for transmitting commands ("tx", cmdq), and, > + optionally, one more virtqueue for receiving notifications > + and delayed responses ("rx", eventq). Isn't what the virtio device provides discoverable? We don't have virtio protocols in DT for anything else. Why is SCMI special? Rob
On 23.09.20 22:54, Rob Herring wrote: > On Fri, Sep 18, 2020 at 06:55:58PM +0200, Peter Hilber wrote: >> From: Igor Skalkin <igor.skalkin@opensynergy.com> >> >> Document the properties for arm,scmi-virtio compatible nodes. The >> backing virtio SCMI device is described in patch [1]. >> >> [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html >> >> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> >> Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> >> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> >> --- >> .../devicetree/bindings/arm/arm,scmi.txt | 38 ++++++++++++++++++- >> 1 file changed, 36 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt >> index 55deb68230eb..844ff3c40a49 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt >> +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt >> @@ -13,6 +13,9 @@ the device tree. >> Required properties: >> >> The scmi node with the following properties shall be under the /firmware/ node. >> +Some properties are specific to a transport type. >> + >> +shmem-based transports (mailbox, smc/hvc): >> >> - compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports >> - mboxes: List of phandle and mailbox channel specifiers. It should contain >> @@ -21,6 +24,17 @@ The scmi node with the following properties shall be under the /firmware/ node. >> supported. >> - shmem : List of phandle pointing to the shared memory(SHM) area as per >> generic mailbox client binding. >> + >> +Virtio transport: >> + >> +- compatible : shall be "arm,scmi-virtio". >> +- virtio_transport : phandle of the virtio device. This device must support one >> + virtqueue for transmitting commands ("tx", cmdq), and, >> + optionally, one more virtqueue for receiving notifications >> + and delayed responses ("rx", eventq). > > Isn't what the virtio device provides discoverable? We don't have virtio > protocols in DT for anything else. Why is SCMI special? > > Rob > Does your comment refer to the presence of the `virtio_transport' phandle, or to the entire "arm,scmi-virtio" node? The protocol child nodes of "arm,scmi-virtio" can be clock providers, power domain providers, etc. The author and me are currently looking into how to replace the `virtio_transport' phandle. Best regards, Peter
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 55deb68230eb..844ff3c40a49 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -13,6 +13,9 @@ the device tree. Required properties: The scmi node with the following properties shall be under the /firmware/ node. +Some properties are specific to a transport type. + +shmem-based transports (mailbox, smc/hvc): - compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports - mboxes: List of phandle and mailbox channel specifiers. It should contain @@ -21,6 +24,17 @@ The scmi node with the following properties shall be under the /firmware/ node. supported. - shmem : List of phandle pointing to the shared memory(SHM) area as per generic mailbox client binding. + +Virtio transport: + +- compatible : shall be "arm,scmi-virtio". +- virtio_transport : phandle of the virtio device. This device must support one + virtqueue for transmitting commands ("tx", cmdq), and, + optionally, one more virtqueue for receiving notifications + and delayed responses ("rx", eventq). + +Additional required properties: + - #address-cells : should be '1' if the device has sub-nodes, maps to protocol identifier for a given sub-node. - #size-cells : should be '0' as 'reg' property doesn't have any size @@ -42,7 +56,8 @@ Each protocol supported shall have a sub-node with corresponding compatible as described in the following sections. If the platform supports dedicated communication channel for a particular protocol, the 3 properties namely: mboxes, mbox-names and shmem shall be present in the sub-node corresponding -to that protocol. +to that protocol. The virtio transport does not support dedicated communication +channels. Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol ------------------------------------------------------------ @@ -106,7 +121,8 @@ Required sub-node properties: [4] Documentation/devicetree/bindings/sram/sram.yaml [5] Documentation/devicetree/bindings/reset/reset.txt -Example: +Example (mailbox transport): +---------------------------- sram@50000000 { compatible = "mmio-sram"; @@ -195,3 +211,21 @@ thermal-zones { ... }; }; + +Example (virtio transport): +--------------------------- + +virtio_mmio_scmi: virtio_mmio@4b001000 { + compatible = "virtio,mmio"; + ... +}; + +firmware { + ... + scmi { + compatible = "arm,scmi-virtio"; + virtio_transport = <&virtio_mmio_scmi>; + ... + +The rest is similar to the mailbox transport example, when omitting the +mailbox/shmem-specific properties.