[alsa-devel] ASoC HDMI codec location
Mark,
I'm looking at enabling audio-over-HDMI on Tegra in the ChromeOS kernel. This will use the SPDIF controller as the CPU DAI. Right now, I have things working with the stub SPDIF codec (codecs/spdif_transciever.c), but to support a non-hard-coded sample rate, need a real codec driver that writes registers in the HDMI controller.
I see that a Samsung chip has such a codec in drivers/video/sh_mobile_hdmi.c. The equivalent for Tegra would be drivers/video/tegra/dc/hdmi.c. Note that this location doesn't yet exist upstream. I just wanted to confirm that this location makes sense to you, vs. implementing a codec in sound/soc/tegra/hdmi.c, and having that call functions exposed by the Tegra dc/hdmi.c driver?
Note that the SPDIF controller isn't involved in the Tegra Digital Audio Switch muxing/switching module at all.
Thanks.
On Tue, Feb 15, 2011 at 12:29:59PM -0800, Stephen Warren wrote:
I see that a Samsung chip has such a codec in drivers/video/sh_mobile_hdmi.c.
That's not Samsung, that's Renesas' SuperH.
The equivalent for Tegra would be drivers/video/tegra/dc/hdmi.c. Note that this location doesn't yet exist upstream. I just wanted to confirm that this location makes sense to you, vs. implementing a codec in sound/soc/tegra/hdmi.c, and having that call functions exposed by the Tegra dc/hdmi.c driver?
Note that the SH code has code in *both* locations - there's an ASoC driver that calls into the video driver as well under sound/soc/sh.
Note that the SPDIF controller isn't involved in the Tegra Digital Audio Switch muxing/switching module at all.
Is the DMA shared?
Mark Brown wrote at Tuesday, February 15, 2011 4:59 PM:
On Tue, Feb 15, 2011 at 12:29:59PM -0800, Stephen Warren wrote:
I see that a Samsung chip has such a codec in drivers/video/sh_mobile_hdmi.c.
That's not Samsung, that's Renesas' SuperH.
Yes, of course. I'd been looking at samsung/smdk_spdif.c and got the two confused.
The equivalent for Tegra would be drivers/video/tegra/dc/hdmi.c. Note that this location doesn't yet exist upstream. I just wanted to confirm that this location makes sense to you, vs. implementing a codec in sound/soc/tegra/hdmi.c, and having that call functions exposed by the Tegra dc/hdmi.c driver?
Note that the SH code has code in *both* locations - there's an ASoC driver that calls into the video driver as well under sound/soc/sh.
I see there's a machine driver there, which refers to the codec that's implemented in drivers/video/sh_mobile_hdmi.c. I assume that's all you mean.
Note that the SPDIF controller isn't involved in the Tegra Digital Audio Switch muxing/switching module at all.
Is the DMA shared?
Yes, I'm using the existing DMA driver unmodified (although this allocates a separate DMA channel through the DMA controller's API), and currently lumping the two dai_links into the same card.
On Wed, Feb 16, 2011 at 08:41:58AM -0800, Stephen Warren wrote:
Mark Brown wrote at Tuesday, February 15, 2011 4:59 PM:
The equivalent for Tegra would be drivers/video/tegra/dc/hdmi.c. Note that this location doesn't yet exist upstream. I just wanted to confirm that this location makes sense to you, vs. implementing a codec in sound/soc/tegra/hdmi.c, and having that call functions exposed by the Tegra dc/hdmi.c driver?
Note that the SH code has code in *both* locations - there's an ASoC driver that calls into the video driver as well under sound/soc/sh.
I see there's a machine driver there, which refers to the codec that's implemented in drivers/video/sh_mobile_hdmi.c. I assume that's all you mean.
Hrm, I remembered that differently. I'd prefer it if more of the code were in ASoC, otherwise we're going to get build breakages when APIs change.
participants (2)
-
Mark Brown -
Stephen Warren