Re: [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
On Tue, 19 Nov 2013 14:12:24 +0200 Jyri Sarha jsa...@ti.com wrote: Signed-off-by: Jyri Sarha jsa...@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) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
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. signature.asc Description: Digital signature
Re: [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
On Wed, 20 Nov 2013 10:09:59 + Mark Brown broo...@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... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
On Wed, Nov 20, 2013 at 01:34:58PM +0100, Jean-Francois Moine wrote: Mark Brown broo...@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... signature.asc Description: Digital signature
Re: [PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
On Tue, Nov 19, 2013 at 02:12:24PM +0200, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@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. signature.asc Description: Digital signature
