ASoC: davinci: fixes for multi-component
Multi-component commit f0fba2ad broke a few things which this patch should
fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be
good if those with access to other Davinci boards could test.
--
The multi-component commit put the initialisation of
snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the
McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c).
The initialisation had to be moved from the probe function in these drivers
because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver.
Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in
davinci-pcm.c) before hw_params is called. I have moved the initialisation to
a new snd_soc_dai_ops.startup function in each of these drivers. This fix
indicates that all platforms that use davinci-pcm must have been broken and
need to test with this fix.
--
The multi-component commit also changed the McBSP driver name from
"davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board
level references to the driver name. This change is understandable, as there
is a similarly named "davinci-mcasp" driver in davinci-mcasp.c.
There is probably no 'correct' name for this driver. The DM6446 datasheet
calls it the "ASP" and describes it as a "specialised McBSP". The DM355
datasheet calls it the "ASP" and describes it as a "specialised ASP". The
DM365 datasheet calls it the "McBSP". Rather than fix this problem by
reverting to "davinci-asp", I've elected to avoid future confusion with the
"davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also
consistent with the names of the functions in the driver. There are other
fixes required, so it was never going to be as simple as a revert anyway.
--
The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has
2 ports), so I've changed the the id of the platform_device from 0 to -1.
--
In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link
structure with the DM355 EVM as they use different cpu DAI names (the DM355
has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port).
This also means that the 2 boards need different snd_soc_card structures.
--
The codec_name entries in davinci-evm.c didn't match the i2c ids in the board
files. I have only checked and fixed the details of the names used for the
McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should
check the others.
Signed-off-by: Chris Paulson-Ellis <chris@edesix.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index d46b545..9e0e565 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -426,9 +426,6 @@
snd_pcm_format_t fmt;
unsigned element_cnt = 1;
- dai->capture_dma_data = dev->dma_params;
- dai->playback_dma_data = dev->dma_params;
-
/* general line settings */
spcr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
@@ -601,6 +598,15 @@
return ret;
}
+static int davinci_i2s_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct davinci_mcbsp_dev *dev = snd_soc_dai_get_drvdata(dai);
+
+ snd_soc_dai_set_dma_data(dai, substream, dev->dma_params);
+ return 0;
+}
+
static void davinci_i2s_shutdown(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
@@ -612,6 +618,7 @@
#define DAVINCI_I2S_RATES SNDRV_PCM_RATE_8000_96000
static struct snd_soc_dai_ops davinci_i2s_dai_ops = {
+ .startup = davinci_i2s_startup,
.shutdown = davinci_i2s_shutdown,
.prepare = davinci_i2s_prepare,
.trigger = davinci_i2s_trigger,
@@ -749,7 +756,7 @@
.probe = davinci_i2s_probe,
.remove = davinci_i2s_remove,
.driver = {
- .name = "davinci-i2s",
+ .name = "davinci-mcbsp",
.owner = THIS_MODULE,
},
};