On Tue, Dec 01, 2015 at 12:27:47PM +0000, Mark Brown wrote:
On Tue, Dec 01, 2015 at 08:26:54AM +0530, Vinod Koul wrote:
On Mon, Nov 30, 2015 at 04:25:48PM +0000, Mark Brown wrote:
Can we make the temporary hack be to check if there's a CODEC defined in the DAI? It's nasty and fragile but it keeps the hack much better isolated.
The flag added here, cpu_loopback would do that and keep this isolated from the rest. The problem with checking if codec is defined will be for dsp
No, it means that the drivers need to set the flag to work around the core which is what I want to avoid.
ok fine then
based loops which terminate in codec. It will not work as we will find codec in the dailink for the voice call (modem-dsp-codec) loop
I'm confused about the situation you're describing here. The connections are DAI to DAI so why would any CODEC behind the CPU DAI have an impact?
let me try again,
So I would like to for example do a voice call. So I need to DAIlinks for this. First one is modem-SSP-A and second SSP-B to codec.
I am taking example of SSP-B to codec for configuration
Currently the code envisions that loop is connected as modem-codec, so DAI links are linked per this assumption
Modem Tx (Pb) ----------> Rx Codec (Cap) Modem Rx (Cap) <---------- Tx Codec (Pb)
So we link pb-cap and cap-pb connected
But if we do wrt from CPU the situation is different
CPU Tx (Pb) -----------> Codec Tx (Pb) CPU Rx (Cap) <----------- Codec Rx (Cap)
Since this follows normal playback kind of scenario, we need to link pb-pb and cap-cap
Now we cannot change this unilaterally so added a flag to signify we want second mapping for dailink rather then first one
Am okay to change this to something different way, which results in second mapping from CPU based loops, pls do suggest :)
Thanks