Topology: Multiple configurations for SSP DAIs

[plbossart]

We need the ability to expose multiple configurations per DAI in the topology file, and means for the driver to pass the relevant configuration over IPC to the firmware.
One example is support for 8 or 16 kHz for a Bluetooth HFP link.

this was filed initially as thesofproject/soft#11, moving to SOF issues since it was missed as reported by @dragosht
The matching kernel issue is thesofproject/linux#697

[lgirdwood]

This also needs to export an enum kcontrol for each SSP port that has > 1 configuration in order for userspace to select the correct configuration based on use case.

[plbossart]

that's not the ask for now. The topology can pass multiple configurations to the kernel (32 IRRC), but we only deal with the first in the kernel. We would want to limit any userspace interaction and possibly select the configuration based e.g. on sampling frequency and channels.

[dragosht]

@plbossart I have some changes available for this issue at dragosht@2c4b7a2 . Basically, generating multiple HWConfig sections and referencing those from the BE section seems to work, but I haven't yet figured out how to deal with having multiple SOF_TKN_INTEL_SSP_SAMPLE_BITS values.

So for instance, having 2 HW configs like this:

DAI_CONFIG(SSP, 5, 5, SSP5-Codec, 6,
           SSP_CONFIG(I2S, SSP_CLOCK(mclk, 24576000, codec_mclk_in),
                      SSP_CLOCK(bclk, 1536000, codec_slave),
                      SSP_CLOCK(fsync, 48000, codec_slave),
                      SSP_TDM(2, 16, 3, 3),
                      SSP_CONFIG_DATA(SSP, 5, 16)),
           SSP_CONFIG(I2S, SSP_CLOCK(mclk, 24576000, codec_mclk_in),
                      SSP_CLOCK(bclk, 3072000, codec_slave),
                      SSP_CLOCK(fsync, 48000, codec_slave),
                      SSP_TDM(2, 32, 3, 3),
                      SSP_CONFIG_DATA(SSP, 5, 32)))

would require for the config->ssp.sample_valid_bits to get initialized to either 16 or 32 bits, based on what configuration is being used. But I see the driver is currently getting it from some per-SSP generated vendor tuple in the topology file.

[ranj063]

@dragosht please take a look at dmic.m4 for an example of how we add 2 sets of PDM_TUPLES() for the DMIC's. You might have to do something similar to it. Basically, if you have the same set of tokens, you need to have something like this ine the conf file: ie tuples."short.pdm0" and tuples."short.pdm1".
Is this helpful?
SectionVendorTuples."DAICONFIG.DMIC0_pdm_tuples" {
tokens "sof_dmic_pdm_tokens"
tuples."short.pdm0" {
SOF_TKN_INTEL_DMIC_PDM_CTRL_ID "0"
SOF_TKN_INTEL_DMIC_PDM_MIC_A_Enable "1"
SOF_TKN_INTEL_DMIC_PDM_MIC_B_Enable "1"
SOF_TKN_INTEL_DMIC_PDM_POLARITY_A "0"
SOF_TKN_INTEL_DMIC_PDM_POLARITY_B "0"
SOF_TKN_INTEL_DMIC_PDM_CLK_EDGE "0"
SOF_TKN_INTEL_DMIC_PDM_SKEW "0"
}

tuples."short.pdm1" {
	SOF_TKN_INTEL_DMIC_PDM_CTRL_ID		"1"
	SOF_TKN_INTEL_DMIC_PDM_MIC_A_Enable	"1"
	SOF_TKN_INTEL_DMIC_PDM_MIC_B_Enable	"1"
	SOF_TKN_INTEL_DMIC_PDM_POLARITY_A	"0"
	SOF_TKN_INTEL_DMIC_PDM_POLARITY_B	"0"
	SOF_TKN_INTEL_DMIC_PDM_CLK_EDGE	"0"
	SOF_TKN_INTEL_DMIC_PDM_SKEW		"0"
}

}

[dragosht]

@ranj063 Yes, this will probably be the way to deal with it. And then the driver will somehow need to get the right value of ssp.sample_valid_bits based on which hw_config it is using ...

[wenqingfu]

thesofproject/linux#758

[lgirdwood]

@slawblauciak I've put you down as the FW owner since the PR is almost done now. It looks like @fredoh9 ran out of time.