[PATCH] ASoC: snd_soc_dai_set_fmt add substream independence.

[Matt Flax]

On 31/3/20 3:31 am, Mark Brown wrote:
> On Mon, Mar 30, 2020 at 11:28:26PM +1100, Matt Flax wrote:
>> On 30/3/20 9:32 pm, Mark Brown wrote:
>>> On Sat, Mar 28, 2020 at 12:58:31PM +1100, Matt Flax wrote:
>>>> This patch is aims to start a stronger discussion on allowing both CPU
>>>> and Codec dais to set formats independently based on direction.
>>> If the DAIs support completely separate formats they're not a single DAI
>>> and should be represented as two DAIs.
>> I understand, however having two DAIs produces subdevices and pushes the
>> overhead of managing registers to the end user in the form of two sub
>> devices.
> I think that's a swings and roundabouts thing where it really depends on
> your use case - for example if the DAIs can be organized however people
> like then people can come up with creative ways to wire things that
> don't pair things in the way that makes sense for userspace.  Ideally
> we'd be able to match up any playback only stream with any capture only
> stream which would help a much wider range of systems.
>
>> Is everyone firm on the concept that a DAI's playback and capture stream has
>> to have the same format in the same DAI ?
> It does push a requirement for dealing with asymmetric setups including
> validation that nobody did anything that can't be supported onto all
> users to at least some extent, even if standard stuff were factored out
> into the core (which didn't happen yet).  This is for a *very* unusual
> requiremenet.


ok, I don't quite follow you, but I think what you are saying is that 
there is a trade off between simplifying things for the end user and 
core complexity leading to developer sloppiness ?

I believe you are saying that it is a rare case to require format 
asymmetry in the same DAI link. For that reason introducing extra 
functionality into the core may not be worth while ?


>>> having an asymmetric configuration.  You probably need to represent
>>> these isolators as a CODEC and do a CODEC to CODEC link and even then it
>>> seems worrying.
>> I like to think of isolation as innovative, not worrying :)
>> However w.r.t. the codec to codec link approach, I will take your advice and
>> not go down that route.
> 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.

For example, my virtual codec DAI would have symmetric formats with the 
original CPU and asymmetric formats with the target codec. However the 
target codec only has one DAI defined, and thus I can't understand how 
to setup the virtual codec DAI to have an asymmetric link with the 
actual single codec DAI !


Matt