On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote: > That's a very good point too. In light of this, I struggle to understand how > the ssl_ssi can specify this:
> static struct snd_soc_dai_driver fsl_ssi_dai_template = {
> .playback = {
> .stream_name = "CPU-Playback",
> .channels_min = 1,
> .channels_max = 32,
> },
> There is talk in the manual about "network mode", which could work by changing
> the LRCLK only at the first slot - thereby allowing clients to receive all
> slots just by counting, as long as they know the slot size?
That's basically what the FSL controllers want to support - they're
generic programmable serial ports, their most native formats are the DSP
modes which only pay attention to one edge of LRCLK and then just have
however many samples one after another. Several other devices like the
PXA SSP ports are similar. They can generate I2S style LRCLKs but many
implementations struggle to interpret incoming I2S properly, they often
have issues with triggering on both rising and falling edges so get
confused if there's any unused clock cycles.
For a DSP mode it's more:
LRCLK /\______________________/\____
DATA |SLOT1|SLOT2|SLOT3|SLOT4|SLOT1
I2S style it'd end up as more like:
LRCLK /-------------\_____________/------
DATA |SLOTL1|SLOTL2|SLOTR1|SLOTR2|SLOTL1
This sort of stuff is why ASoC has a preference for exact clocking - it
improves interoperability with hardware that's generic serial ports as
it means that you only need to pay attention to one edge of the LRCLK
even if it's doing something more than just a simple pulse.
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
