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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
