Message-ID: <20190822125145.GO12733@vkoul-mobl.Dlink>
Date:   Thu, 22 Aug 2019 18:21:45 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Banajit Goswami <bgoswami@...eaurora.org>,
        Patrick Lai <plai@...eaurora.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        devicetree@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
        Linux-ALSA <alsa-devel@...a-project.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/4] dt-bindings: soundwire: add slave bindings

On 22-08-19, 07:36, Rob Herring wrote:
> On Thu, Aug 22, 2019 at 5:12 AM Srinivas Kandagatla
> <srinivas.kandagatla@...aro.org> 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@...aro.org>
> > >> ---
> > >>   .../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@...0000 {
> > >> +    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.

That does make sense, we can use unit-address/reg as instance id.

Thanks
-- 
~Vinod

Powered by blists - more mailing lists