On 31/3/20 10:13 pm, Mark Brown wrote:
On Tue, Mar 31, 2020 at 06:40:26PM +1100, Matt Flax wrote:
No, my advice is to go down that route if you are doing this. I'm just not convinced that it's going to work reliably since this all sounds rather shaky.
OK - I can try to go down that route. However I would like to confirm that having a codec to codec link doesn't require the original codec or CPU drivers to have separate DAIs for playback and capture ? In my case both the CPU and Codec drivers have single DAIs for both streams.
OK, that probably won't help then :/
OK - well, the codec approach was worth a try. My concerns with the codec API is that it chews resources and clock cycles - if it is possible to work around it, then it is a good idea.
I feel that the best way to reduce resource consumption, complexity and overhead is to allow link formats to be defined based on the stream direction.
I can see why we would want different DAIs if the sample rate is asymmetric, however for word alignment perhaps we should let the stream direction seep into the snd_soc_dai opertions. These days CPU and Codec designers seem to treat both streams independently, which is why their registers can be independently configured.
thanks for the discussion
Matt