Hi Arnd, On Thu, 21 Apr 2016, Arnd Bergmann wrote: > On Thursday 21 April 2016 12:04:26 Peter Griffin wrote: > > uniperiph-id, version and mode are ST specific bindings and > > need the 'st,' prefix. Update the examples, as otherwise copying > > them yields a runtime error parsing the DT node. > > > > Signed-off-by: Peter Griffin <peter.griffin@xxxxxxxxxx> > > Cc: arnaud.pouliquen@xxxxxx > > --- > > .../devicetree/bindings/sound/st,sti-asoc-card.txt | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt b/Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt > > index 028fa1c..ef2e0c6 100644 > > --- a/Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt > > +++ b/Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt > > @@ -67,9 +67,9 @@ Example: > > dmas = <&fdma0 4 0 1>; > > dai-name = "Uni Player #1 (DAC)"; > > dma-names = "tx"; > > - uniperiph-id = <2>; > > - version = <5>; > > - mode = "PCM"; > > + st,uniperiph-id = <2>; > > + st,version = <5>; > > + st,mode = "PCM"; > > }; > > You don't change the binding desciption here, only the example, > so they no longer match. Whoops. Will fix that in v4. > > What is st,uniperiph-id needed for anyway? It's often an indication > that you are doing something wrong if you need this. >From looking at the code in sound/soc/sti/uniperif_player.c, there is one sysconf register called "Audio glue config" which is shared by all of the uniperif IP instances. This binding is being used to generate a bitoffset into this shared register based on the instance of the IP. I guess the alternative is to have an explosion of compatibles? st,sti-uni-player-1 st,sti-uni-player-2 st,sti-uni-player-3 If not what would you recommend instead? :-) I don't currently have access to the functional spec for this IP block, but I have asked ST to send it to me to see if there is any other way to derive this information (although I suspect there won't be). FYI I didn't actually write or upstream that driver. However fdma is a depedency of the ASoC driver and it is required to get working audio upstream. It's also worth pointing out that this ASoC driver has been merged for a while, so I'm not sure what your opinion is of now changing the DT bindings? Obviously it is currently not used by anyone upstream due to the missing fdma depedency. regards, Peter. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
