Russell, thank you for the amazing explanation, and for your continued patience.
On Wed, Feb 27, 2019 at 2:56 PM Russell King - ARM Linux admin
<linux@xxxxxxxxxxxxxxx> wrote:
>
> Now, the problem is... there doesn't seem to be an existing hardware
> parameter for the on-wire frame bits
Could a case be made to make the resolution core "bclk_ratio" aware ?
Of course if this is just to support tda998x, it would be like a cannon to
kill a fly...
>
> > So all this kind of suggests to me that the bclk_ratio could be part of the
> > format description, or something?
> >
> > static struct snd_soc_dai_driver acme_cpu_dai = {
> > .playback = {
> > .formats = SNDRV_PCM_FMTBIT_S20_3LE_20 |
> > SNDRV_PCM_FMTBIT_S20_3LE_24,
> > SNDRV_PCM_FMTBIT_S16_LE | //
> > bclk_ratio 16 implied
> > SNDRV_PCM_FMTBIT_S24_LE | //
> > bclk_ratio 24 implied
> > SNDRV_PCM_FMTBIT_S24_LE_32
>
> I don't think this is going to work. Firstly, it'll break userspace,
> becuase userspace would need to be taught about all these new format
> identifiers. Secondly, it massively increases the number of formats
> to number_of_existing_formats * number_of_possible_bclk_ratios.
How about
static struct snd_soc_dai_driver acme_dai_template = {
.playback = {
.stream_name = "CPU-Playback",
.channels_min = 1,
.channels_max = 32,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.formats = FSLSSI_I2S_FORMATS,
.bclk_ratio_min = 8,
.bclk_ratio_max = 64,
or
.bclk_ratios = RATIO_8 | RATIO_16 | RATIO_32 | RATIO_64,
},
};
Then if codec/cpu cares about bclk_ratios, it would have to put rules in place
such as:
- SNDRV_PCM_FMTBIT_S16_LE -> bclk_ratio = 16x2 only
- SNDRV_PCM_FMTBIT_S24_LE -> slave : bclk_ratio = [ 24x2 to 32x2 ]
-> master: bclk_ratio = 32x2 only
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
