Re: [RESEND PATCH v4 1/4] dt-bindings: soundwire: add slave bindings

From: Srinivas Kandagatla
Date: Tue Aug 27 2019 - 16:29:03 EST


thanks for reviewing the patch!

On 27/08/2019 21:20, Rob Herring wrote:
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?

Highly unlikely!



+
+ "#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.

okay, will fix that in next version!



+ 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. :)

:-)

thanks,
srini

+ reg = <0x0c2d0000 0x2000>;
+
+ speaker@1 {
+ compatible = "sdw10217201000";
+ reg = <1 0>;
+ };
+
+ speaker@2 {
+ compatible = "sdw10217201000";
+ reg = <2 0>;
+ };
+ };
+
+...
--
2.21.0

--
~Vinod