On Fri, Aug 23, 2019 at 12:23:40PM +0530, Vinod Koul wrote: > On 23-08-19, 00:37, Srinivas Kandagatla wrote: > > This patch adds bindings for Soundwire Slave devices that includes how > > SoundWire enumeration address and Link ID are used to represented in > > SoundWire slave device tree nodes. > > > > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> > > --- > > .../soundwire/soundwire-controller.yaml | 75 +++++++++++++++++++ > > 1 file changed, 75 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml > > > > diff --git a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml > > new file mode 100644 > > index 000000000000..91aa6c6d6266 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml > > @@ -0,0 +1,75 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/soundwire/soundwire-controller.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: SoundWire Controller Generic Binding > > Controller does not make sense here, why not use spec terminology and > say "SoundWire Slave Generic Binding" It's both IMO. It's describing the structure of child devices of a controller (aka a bus). > > > + > > +maintainers: > > + - Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> > > + > > +description: | > > + SoundWire busses can be described with a node for the SoundWire controller > > + device and a set of child nodes for each SoundWire slave on the bus. > > + > > +properties: > > + $nodename: > > + pattern: "^soundwire(@.*|-[0-9a-f])*$" '-[0-9a-f]' was to handle cases like spi-gpio or i2c-gpio. Would a bit banged interface be possible here? > > + > > + "#address-cells": > > + const: 2 > > + > > + "#size-cells": > > + const: 0 > > + > > +patternProperties: > > + "^.*@[0-9a-f]+$": If there are distinct fields in the address, they are typically comma separated in the unit-address. > > + type: object > > + > > + properties: > > + compatible: > > + pattern: "^sdw[0-9][0-9a-f]{4}[0-9a-f]{4}[0-9a-f]{2}$" > > + description: > > + Is the textual representation of SoundWire Enumeration > > + address. compatible string should contain SoundWire Version ID, > > + Manufacturer ID, Part ID and Class ID in order and shall be in > > + lower-case hexadecimal with leading zeroes. > > + Valid sizes of these fields are > > + Version ID is 1 nibble, number '0x1' represents SoundWire 1.0 > > + and '0x2' represents SoundWire 1.1 and so on. > > + MFD is 4 nibbles > > + PID is 4 nibbles > > + CID is 2 nibbles > > + More Information on detail of encoding of these fields can be > > + found in MIPI Alliance DisCo & SoundWire 1.0 Specifications. > > + > > + reg: > > + maxItems: 1 > > + description: > > + Instance ID and Link ID of SoundWire Device Address. > > This looks better :) Thanks. > > Apart from the minor nit above this looks good to me, I can merge the > sdw parts if Rob is fine with them. > > Thanks > > > + > > + required: > > + - compatible > > + - reg > > + > > +examples: > > + - | > > + soundwire@c2d0000 { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + compatible = "qcom,soundwire-v1.5.0"; This will probably change once I review it. :) > > + reg = <0x0c2d0000 0x2000>; > > + > > + speaker@1 { > > + compatible = "sdw10217201000"; > > + reg = <1 0>; > > + }; > > + > > + speaker@2 { > > + compatible = "sdw10217201000"; > > + reg = <2 0>; > > + }; > > + }; > > + > > +... > > -- > > 2.21.0 > > -- > ~Vinod
