Re: ASoC: Dynamic CODEC DAI

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Dec 01, 2011 at 06:56:18PM -0800, Patrick Lai wrote:

> driver developer. Instead, each slimbus port on the CODEC, by
> definition, is a mono CODEC DAI. Extending DAI link definition to take
> a list of CODEC dais allows machine driver to group the ports. Passing

Why do this in the machine driver?  That's going to be limiting, it'll
mean that you've got a fixed allocation of channels at the time the
driver is written and can't restructure things on the fly as you switch
between use cases.  I'd much rather just describe the Slimbus link (and
possibly even let it be automatically enumerated) and keep as much
flexibility as possible.

Like I say everything involved is going to have to understand that it's
constructing a multi-channel link (even a fairly dumb CODEC is going to
have to know that the samples for a given multi channel audio stream
should be synchronized) so it seems better to actually implement this
properly rather than trying to keep the knowledge out of the core.

>  I'm
> >not sure it's worth trying to be too non-invasive, anything controlling
> >hardware is going to have to understand what's going on at the physical
> >level anyway and the host side is going to have to interoperate with the's
> >Slimbus framework.  The core is also going to need to know about the
> >channel groups to allocate and destroy them as required.

> I presume you are referring to soc-core, with the approach I propose
> above, I think soc-core does not have to be aware of SLIMBUS framework.

I think it needs to be able to understand the concept of a multi-drop
flexible link; I don't think it needs to know anything specific about
Slimbus but I think to fully exploit Slimbus (and any similar buses that
come along) it's going to have to be extended.  If it were a case of
doing something tasteful that's transparent to the core but was limited
in feature set that'd be one thing but once we start to extend the core
specifically for the limited solution we should at the very least be
making sure that the APIs we're offering drivers will allow us to do a
good solution later on without churning them too much.

> >Also note that the work on submitting your Silmbus driver core to
> >mainline appears totally stalled, there was just an initial posting but
> >no followup.

> I guess slimbus driver guy is completely swamped now as SLIMBUS is new
> and it takes a lot of effort to stablize.

Well, it's pretty important that that stuff goes in - if the underlying
APIs for Slimbus turn out not to match the model we've come up with well
then that'd cause problems too.