Re: Separate dma driver for cpu_dais

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

On Tue, Feb 23, 2010 at 02:45:47PM +0900, jassi brar wrote:

> Okay. Here's another perspective ...
> If a dai can have further parallel sub-configurations, perhaps it should
> be further divided into more dais.
> So, I see a snd_soc_dai as the simplest h/w unit in the system and
> presumably  already fully exploited by the active dai_link i.e, none of
> its bits can be changed without disturbing the active stream. The
> number of shares should be transparent to a dai.
> If this assumption is valid please read on, otherwise correct me.

That doesn't map too well to hardware - it's relatively rare for devices
to require complete symmetry between the playback and capture portions
of the device, though often there are some constraints.  Usually there
is sufficient overlap in the hardware and documentation to describe them
as a single interface but not so much as to force the same configuration
for playback and record.

> The set of {rate, sample size & format, channels} defines one active
> dai. The second stream sharing this dai can not change any of these
> parameters without spoiling the active playback/capture - we can allow
> this configuration overriding as a feature or prevent as a bug. I
> prefer latter. Since there isn't anything new to do now, the ASoC core
> can
> simply avoid calling hooks in drivers rather than having 50 drivers
> implement a check.

If we were to go down this route it'd mean changing the existing drivers
to split their DAIs, which seems like a lot of work and doesn't save us
from having to implement the constraints that do exist.  This would be
pretty invasive and I can't clearly see if either approach gives much of
a win in itself.

It seems easier to approach this by providing ways for drivers to
communicate common constraints to the core with things like flags.
That'd at least mean less change for existing code.