Re: [PATCH] ASoC: snd_soc_dai_set_fmt add substream independence.

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

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 ?

> I can see a much better solution (then the one I posted here) which is also
> very simple to solve this problem 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.

> > 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]