[alsa-devel] Multiple codecs on the same DAI

[Ricard Wanderlof]

On Fri, 24 Nov 2017, Mark Brown wrote:

> On Thu, Nov 23, 2017 at 03:51:19PM +0100, Ricard Wanderlof wrote:
> 
> > I'm studying a hardware implementation where an S/PDIF receiver is on the 
> > same I2S connection as codec. Essentially, the S/PDIF receiver echos the 
> > I2S capture data from the codec unless there is a digital input signal 
> > which it can lock on to. For playback, the I2S output from the CPU DAI 
> > goes directly to the codec.
> 
> I take it this is a TDM setup?

No, it is not.

The S/PDIF receiver chip contains a mux, that switches between the 
capture data generated by the codec and the decoded S/PDIF data. By 
default, the chip automatically switches over from echoing the codec data 
to the decoded S/PDIF data when valid S/PDIF data is present, and back to 
the codec data when S/PDIF lock is lost.

So what comes out of the conglomeration is standard stereo I2S, which has 
originated either from the codec or the S/PDIF receiver. Furthermore, the 
S/PDIF receiver generates the clocking for the codec (using either the 
clock derived from the incoming S/PDIF signal, or an internal crystal 
oscillator), so it can (and does apparantly, looking at the signals on a 
'scope) more or less seemlessly segue between the two sources.

> The capture CODEC is the problem here.  If we had digital domain stuff
> working well then we could model this easily enough by showing a
> loopback within the S/PDIF chip but that's not there yet.  As it is it
> sounds like the easiest thing is just going to be to ignore the S/PDIF
> CODEC in software and fudge things by telling the SoC to read the TDM
> slot that it is sending on.  That way the regular CODEC will get set up
> normally and the S/PDIF device can transparently handle the switching.

What I've done so far is to ignore the S/PDIF chip, and that approach 
works well to start with, but I'd really like to link it into the machine 
driver somehow, so that any ALSA controls for the S/PDIF receiver can be 
exposed as being part of the same sound card as the codec. I haven't tried 
adding the S/PDIF receiver into the dai_link in my snd_soc_card as I think 
that would problematic for instance since the S/PDIF receiver only 
supports capture, not playback.

In a sense, what I'd want would be to bring in the S/PDIF receiver as a 
codec driver, but separate from the ordinary chain of sound drivers 
(codec, platform, etc). I suppose one way would be to somehow (via 
platform data or DT) pass a reference to the S/PDIF receiver to the 
machine driver, which would then somehow convert this to a snd_soc_codec 
*, and then have it explicitly call the the snd_soc_codec_driver.probe 
function set up by the S/PDIF receiver driver to initialize it much the 
way ALSA would have done if it had been part of a dai_link for card. 

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30