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
