On Sat, Aug 31, 2013 at 10:05:18PM +0100, Russell King - ARM Linux wrote:
I'm not the only one: I've heard other people complain about the _exact_ same issue with ASoC: ASoC is difficult to work with, and many people just seem to give up with it - or keep their stuff in their own trees locally. I can very well see why that happens.
We do appear to have a fairly good success rate with systems working with mainline; I can only think of one driver that didn't make it in and that was one where we had a bit of an issue getting the code to visually resemble Linux code so I don't feel too bad about it. I am aware of some people who didn't work upstream, we've generally had some useful discussions with them once we've found each other.
As for "This is the either/or approach I've been suggesting." No, that's another false statement from Mark. What Mark has been suggesting all along is to use DPCM - and that's something which I tried for ages to get working, and it just doesn't work (as evidenced by the oopses and warnings that get spat out of the kernel.)
While it is correct that I have been saying the final result should use DPCM (since this is what the hardware looks like) you will recall that I did recently suggest either/or as a stepping stone towards a full implementation, allowing systems with only S/PDIF to be supported while the other issues are still being worked on.
There are two choices in how the hardware is used: either one output only is used, or if both outputs are used, they must be used "as one" - both outputs must be simultaneously enabled and disabled. As far as I know, that's not possible with two DAIs.
That is correct, this is why I call it an either/or approach - a system would be able to use either I2S or S/PDIF but not both. For systems with both I2S and S/PDIF connected one or the other would have to be chosen by the machine driver.
And here's the patch I tried.
Ah, I'm not sure that I have seen this before (it's certainly not been submitted). Just looking at the diff this all seems fine for an either/or approach though...
index 2c459c1..62e5b62 100644 --- a/sound/soc/kirkwood/kirkwood-spdif.c +++ b/sound/soc/kirkwood/kirkwood-spdif.c @@ -61,7 +61,7 @@ static struct snd_soc_dai_link kirkwood_spdif_dai0[] = { .name = "S/PDIF0", .stream_name = "S/PDIF0 PCM Playback", .platform_name = "kirkwood-pcm-audio.0",
.cpu_dai_name = "kirkwood-i2s.0",
.codec_dai_name = "dit-hifi", .codec_name = "spdif-dit", .ops = &kirkwood_spdif_ops,.cpu_dai_name = "kirkwood-spdif.0",
@@ -73,7 +73,7 @@ static struct snd_soc_dai_link kirkwood_spdif_dai1[] = { .name = "S/PDIF1", .stream_name = "IEC958 Playback", .platform_name = "kirkwood-pcm-audio.1",
.cpu_dai_name = "kirkwood-i2s.1",
.codec_dai_name = "dit-hifi", .codec_name = "spdif-dit", .ops = &kirkwood_spdif_ops,.cpu_dai_name = "kirkwood-spdif.1",
...this file does not appear to be in mainline and some of the rest of the context suggested this was based off something old.