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@armlinux.org.uk 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