On Saturday 12 April 2014, 14:48:17 wrote Alexander Shiyan: > Sat, 12 Apr 2014 12:42:18 +0200 от Alexander Stein <alexanders83@xxxxxx>: > > On Saturday 12 April 2014, 14:31:28 wrote Alexander Shiyan: > > > Sat, 12 Apr 2014 11:08:26 +0200 от Alexander Stein <alexanders83@xxxxxx>: > > > > Signed-off-by: Alexander Stein <alexanders83@xxxxxx> > > > > --- > > > > .../devicetree/bindings/sound/atmel_ac97c.txt | 20 +++++++++ > > > > sound/atmel/ac97c.c | 52 ++++++++++++++++++++-- > > > > 2 files changed, 69 insertions(+), 3 deletions(-) > > > > create mode 100644 Documentation/devicetree/bindings/sound/atmel_ac97c.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt b/Documentation/devicetree/bindings/sound/atmel_ac97c.txt > > > > new file mode 100644 > > > > index 0000000..9839403 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/sound/atmel_ac97c.txt > > > > @@ -0,0 +1,20 @@ > > > > +* Atmel AC97 controller > > > > + > > > > +Required properties: > > > > + - compatible: "atmel,atmel_ac97c" > > > > + - reg: Address and length of the register set for the device > > > > + - interrupts: Should contain AC97 interrupt > > > > + - atmel,reset-pin: GPIO for resetting the codec > > > > > > Why standard "gpios" property cannot be used here? > > > > I guess they can. I have no experience defining a devicetree binding, so I just stuck to the platformdata member name. > > If this is the recommended way, I'll gladly change that. > > Another question is whether this property should refer to the controller, > as it is clear that it refers to the codec .... AFAICT the codec itself has no representation in the devicetree. It gets detected by the controller which uses the reset GPIO. Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
