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