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
