[alsa-devel] [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
moinejf at free.fr
Wed Nov 20 10:23:42 CET 2013
On Tue, 19 Nov 2013 14:12:24 +0200
Jyri Sarha <jsarha at ti.com> wrote:
> Signed-off-by: Jyri Sarha <jsarha at ti.com>
> Documentation/devicetree/bindings/sound/hdmi.txt | 17 +++++++++++++++++
> sound/soc/codecs/hdmi.c | 10 ++++++++++
> 2 files changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
A couple of months ago, I proposed a 'generic DT based simple
codec' (http://www.spinics.net/lists/arm-kernel/msg274322.html) which
was supposed to replace all of the `empty` codecs in a DT context.
These codecs do nothing except defining some audio parameters.
They are mainly spdif tx/rx, hdmi, bt-sco, dmic, wm8727 and wm8782.
This generic codec would have been used for the tda998x which is the
HDMI transmitter of the Cubox. But, as its utility was not clear yet,
I switched to the 'spdif transmitter' codec which has DT support. This
last codec works fine without change, with either i2s or spdif input in
the tda998x. It is well suited to the Cubox because the Marvell Armada
510 audio subsystem does not support sound recording (nor does the
tda998x while the 'hdmi' code provides recording), and also because it
supports a wider range of rates than the 'hdmi'codec (I have no problem
with 22.05kHz audio).
But now, I am wondering again about these `empty`codecs:
- in a DT context, should we continue to add / modify such codecs?
- what do you think about my generic DT codec? (indeed, I would do a new
version according to the previous remarks)
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
More information about the Alsa-devel