* Peter Ujfalusi peter.ujfalusi@ti.com [200214 13:30]:
Hi Tony,
On 12/02/2020 16.46, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200212 09:18]:
On 11/02/2020 20.10, Tony Lindgren wrote:
+static int cpcap_voice_set_tdm_slot(struct snd_soc_dai *dai,
unsigned int tx_mask, unsigned int rx_mask,int slots, int slot_width)+{
- struct snd_soc_component *component = dai->component;
- struct cpcap_audio *cpcap = snd_soc_component_get_drvdata(component);
- int err, ts_mask, mask;
- bool voice_call;
- /*
* Primitive test for voice call, probably needs more checks* later on for 16-bit calls detected, Bluetooth headset etc.*/- if (tx_mask == 0 && rx_mask == 1 && slot_width == 8)
voice_call = true;- else
voice_call = false;You only have voice call if only rx slot0 is in use?
Yeah so it seems. Then there's the modem to wlcore bluetooth path that I have not looked at. But presumably that's again just configuring some tdm slot on the PMIC.
If you record mono on the voice DAI, then rx_mask is also 1, no?
It is above :) But maybe I don't follow what you're asking here
If you arecrod -Dvoice_pcm -c1 -fS8 > /dev/null then it is reasonable that the machine driver will set rx_mask = 1
and maybe you have some better check in mind.
Not sure, but relying on set_tdm_slots to decide if we are in a call case does not sound right.
OK yeah seems at least bluetooth would need to be also handled in the set_tdm_slots.
You will also set the sampling rate for voice in cpcap_voice_hw_params(), but that is for normal playback/capture, right?
Yeah so normal playback/capture is already working with cpcap codec driver with mainline Linux. The voice call needs to set rate to 8000.
But if you have a voice call initiated should not the rate be set by the set_sysclk()?
Hmm does set_sysclk called from modem codec know that cpcap codec is the clock master based on bitclock-master and set the rate for cpcap codec?
It feels like that these should be done via DAPM with codec to codec route?
Sure if you have some better way of doing it :) Do you have an example to point me to?
Something along the lines of: https://mailman.alsa-project.org/pipermail/alsa-devel/2020-February/162915.h...
The it is a matter of building and connecting the DAPM routes between the two codec and with a flip of the switch you would have audio flowing between them.
Sounds good to me.
Tony