On Thu, Aug 22, 2019 at 5:12 AM Srinivas Kandagatla
<srinivas.kandagatla@xxxxxxxxxx> wrote:
>
>
>
> On 21/08/2019 22:44, Rob Herring wrote:
> > On Fri, Aug 09, 2019 at 02:34:04PM +0100, 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>
> >> ---
> >> .../devicetree/bindings/soundwire/slave.txt | 51 +++++++++++++++++++
> >> 1 file changed, 51 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/soundwire/slave.txt
> >
> > Can you convert this to DT schema given it is a common binding.
> >
>
> I will give that a go in next version!
>
> > What does the host controller look like? You need to define the node
> > hierarchy. Bus controller schemas should then include the bus schema.
> > See spi-controller.yaml.
>
> Host controller is always parent of these devices which is represented
> in the example.
>
> In my previous patches, i did put this slave bindings in bus.txt, but
> Vinod suggested to move it to slave.txt.
>
> Are you suggesting to add two yamls here, one for slave and one for bus
> Or just document this in one bus bindings?
One. Like I said, see spi-controller.yaml.
> >> diff --git a/Documentation/devicetree/bindings/soundwire/slave.txt b/Documentation/devicetree/bindings/soundwire/slave.txt
> >> new file mode 100644
> >> index 000000000000..201f65d2fafa
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/soundwire/slave.txt
> >> @@ -0,0 +1,51 @@
> >> +SoundWire slave device bindings.
> >> +
> >> +SoundWire is a 2-pin multi-drop interface with data and clock line.
> >> +It facilitates development of low cost, efficient, high performance systems.
> >> +
> >> +SoundWire slave devices:
> >> +Every SoundWire controller node can contain zero or more child nodes
> >> +representing slave devices on the bus. Every SoundWire slave device is
> >> +uniquely determined by the enumeration address containing 5 fields:
> >> +SoundWire Version, Instance ID, Manufacturer ID, Part ID
> >> +and Class ID for a device. Addition to below required properties,
> >> +child nodes can have device specific bindings.
> >> +
> >> +Required properties:
> >> +- compatible: "sdw<LinkID><VersionID><InstanceID><MFD><PID><CID>".
> >> + Is the textual representation of SoundWire Enumeration
> >> + address along with Link ID. compatible string should contain
> >> + SoundWire Link ID, SoundWire Version ID, Instance ID,
> >> + Manufacturer ID, Part ID and Class ID in order
> >> + represented as above and shall be in lower-case hexadecimal
> >> + with leading zeroes. Vaild sizes of these fields are
> >> + LinkID is 1 nibble,
> >> + Version ID is 1 nibble
> >> + Instance ID in 1 nibble
> >> + MFD in 4 nibbles
> >> + PID in 4 nibbles
> >> + CID is 2 nibbles
> >> +
> >> + Version number '0x1' represents SoundWire 1.0
> >> + Version number '0x2' represents SoundWire 1.1
> >
> > This can all be a regex.
> >
> >> + ex: "sdw0110217201000" represents 0 LinkID,
> >> + SoundWire 1.0 version slave with Instance ID 1.
> >> + More Information on detail of encoding of these fields can be
> >> + found in MIPI Alliance DisCo & SoundWire 1.0 Specifications.
> >> +
> >> +SoundWire example for Qualcomm's SoundWire controller:
> >> +
> >> +soundwire@c2d0000 {
> >> + compatible = "qcom,soundwire-v1.5.0"
> >> + reg = <0x0c2d0000 0x2000>;
> >> +
> >> + spkr_left:wsa8810-left{
> >> + compatible = "sdw0110217201000";
> >> + ...
> >> + };
> >> +
> >> + spkr_right:wsa8810-right{
> >> + compatible = "sdw0120217201000";
> >
> > The normal way to distinguish instances is with 'reg'. So I think you
> > need 'reg' with Instance ID moved there at least. Just guessing, but
> > perhaps Link ID, too? And for 2 different classes of device is that
> > enough?
>
> In previous bindings ( https://lists.gt.net/linux/kernel/3403276 ) we
> did have instance-id as different property, however Pierre had some good
> suggestion to make it align with _ADR encoding as per MIPI DisCo spec.
>
> Do you still think that we should split the instance id to reg property?
Assuming you could have more than 1 of the same device on the bus,
then you need some way to distinguish them and the way that's done for
DT is unit-address/reg. And compatible strings should be constant for
each instance.
Rob
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
