| Message ID | 829968f1a6b34176de8a04dd4ad473b2b37be783.1384862950.git.jsarha@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 19, 2013 at 02:12:24PM +0200, Jyri Sarha wrote: > Signed-off-by: Jyri Sarha <jsarha@ti.com> > --- > Documentation/devicetree/bindings/sound/hdmi.txt | 17 +++++++++++++++++ > sound/soc/codecs/hdmi.c | 10 ++++++++++ Device tree bindings need to be sent to the DT folks for review as well. This looks OK but it should still go there.
On Tue, 19 Nov 2013 14:12:24 +0200 Jyri Sarha <jsarha@ti.com> wrote: > Signed-off-by: Jyri Sarha <jsarha@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 [snip] 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)
On Wed, Nov 20, 2013 at 10:23:42AM +0100, Jean-Francois Moine wrote: > 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) We still want to be able to have users just name the CODEC on their board rather than have to type in all the details from the datasheet, if we're going to try to amalgamate the drivers it should still let people do that.
On Wed, 20 Nov 2013 10:09:59 +0000 Mark Brown <broonie@kernel.org> wrote: > On Wed, Nov 20, 2013 at 10:23:42AM +0100, Jean-Francois Moine wrote: > > > 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) > > We still want to be able to have users just name the CODEC on their > board rather than have to type in all the details from the datasheet, > if we're going to try to amalgamate the drivers it should still let > people do that. OK. But it seems to me that the codec is not tied to the board, but rather to the audio connector / transmitter. In the case of the tda998x HDMI transmitter, either i2s or s/pdif may be used, thanks to the actual codecs 'hdmi' and 'spdif tx'. But they don't work the same way: the 'hdmi' codec handles both playback and record, and recording is disabled by program in the sound device, while the 'spdif tx' codec is selected by the codec-dai-name ("dit-hifi" - it is "dir-hifi" for recording). It would be nice if these codecs would have the same behaviour...
On Wed, Nov 20, 2013 at 01:34:58PM +0100, Jean-Francois Moine wrote: > Mark Brown <broonie@kernel.org> wrote: > > We still want to be able to have users just name the CODEC on their > > board rather than have to type in all the details from the datasheet, > > if we're going to try to amalgamate the drivers it should still let > > people do that. > OK. But it seems to me that the codec is not tied to the board, but > rather to the audio connector / transmitter. No, not at all. The majority of these devices are simple CODECs, DACs and ADCs with no register control which are soldered down onto the board. What's connected beyond them is irrelevant. If anything the devices that don't have fixed functions are even more likely to want or need to have specific code, for example code could be written to enforce the results of HDMI capability discovery. > In the case of the tda998x HDMI transmitter, either i2s or s/pdif may > be used, thanks to the actual codecs 'hdmi' and 'spdif tx'. But they > don't work the same way: the 'hdmi' codec handles both playback and > record, and recording is disabled by program in the sound device, > while the 'spdif tx' codec is selected by the codec-dai-name > ("dit-hifi" - it is "dir-hifi" for recording). It would be nice if > these codecs would have the same behaviour... Well, send patches refactoring one or the other then...
diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt b/Documentation/devicetree/bindings/sound/hdmi.txt new file mode 100644 index 0000000..31af7bc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/hdmi.txt @@ -0,0 +1,17 @@ +Device-Tree bindings for dummy HDMI codec + +Required properties: + - compatible: should be "linux,hdmi-audio". + +CODEC output pins: + * TX + +CODEC input pins: + * RX + +Example node: + + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c index 68342b1..6d2fcf1 100644 --- a/sound/soc/codecs/hdmi.c +++ b/sound/soc/codecs/hdmi.c @@ -20,6 +20,7 @@ */ #include <linux/module.h> #include <sound/soc.h> +#include <linux/of_device.h> #define DRV_NAME "hdmi-audio-codec" @@ -60,6 +61,14 @@ static struct snd_soc_dai_driver hdmi_codec_dai = { }; +#ifdef CONFIG_OF +static const struct of_device_id hdmi_audio_codec_ids[] = { + { .compatible = "linux,hdmi-audio", }, + { } +}; +MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids); +#endif + static struct snd_soc_codec_driver hdmi_codec = { .dapm_widgets = hdmi_widgets, .num_dapm_widgets = ARRAY_SIZE(hdmi_widgets), @@ -83,6 +92,7 @@ static struct platform_driver hdmi_codec_driver = { .driver = { .name = DRV_NAME, .owner = THIS_MODULE, + .of_match_table = of_match_ptr(hdmi_audio_codec_ids), }, .probe = hdmi_codec_probe,
Signed-off-by: Jyri Sarha <jsarha@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