[PATCH] ASoC: generic: Add generic DT based simple codec
broonie at kernel.org
Thu Sep 19 14:05:40 EDT 2013
On Thu, Sep 19, 2013 at 07:34:03PM +0200, Jean-Francois Moine wrote:
> Well, first, the codecs hdmi and dmic have no DT support.
> Then, from the Cubox point of vue, the codec hdmi offers playback
> and capture while the Cubox has only playback (via the tda998x HDMI
> transmitter), and, also, the codec spdif transmitter has a lot of
> sample rates while the Dove audio device supports only 44.1, 48 and 96
All those restrictions should be constrained by either the machine
binding or the driver for the SoC side though. I do see why you might
want this, I'm just a bit ambivalent about the merits.
> So, instead of adding new hdmi and spdif_transmitter codecs,
> I thought it could be useful to have a generic codec with DT support.
> On the other hand, as the first use of this codec is for the Cubox,
> an other solution could be to have the codec included in the kirkwood
> driver (declared by DT as either i2s or s/pdif). This would simplify
> the use or not of s/pdif in this driver.
That'd work too.
> > > +Child 'capture' and 'playback' required properties:
> > > +- stream-name: name of the stream
> > What does this mean in the binding?
> Indeed, the stream name could be implicit (either "Playback" or
> "Capture"), but, as the users are aware of it, a more friendly
> name is nicer ("S/PDIF Playback").
So you need to say that it's for display purposes.
> I have no idea about which format is used or not, and there is no
> explanation about their meanings in the uapi (but I can search them..).
> Otherwise, for Dove, we need at least "s16_le", "s24_le" and "s32_le"
> and, perhaps, "iec958_subframe_le" and "iec958_subframe_be".
> So, what do you think should be the format set?
PCM plus IEC seems fine, it's more the more obscure formats that ring
> > > +Rates:
> > > + 5512
> > > + 8000
> > This shouldn't be a list of defined rates, it should allow any number,
> > and it should support ranges since while some devices do enumerate
> > specific rates simpler devices often just support a continuous range of
> > rates.
> There cannot be any number because the rates are coded by discrete
> values in a bitmap.
Not quite - _KNOT and _CONTINUOUS are options in that bitmap... in
any case this would be a Linux implementation thing.
> For the continuous range, I was thinking about the value '0' followed
> by the min and max rates. Have you any other syntax in mind?
That'd probably work, not sure if there's a more idiomatic way of doing
that in DT though.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the linux-arm-kernel