[alsa-devel] [PATCH 07/11] ASoC: tegra: Add tegra-das driver

[Stephen Warren]

Mark Brown wrote:
> On Wed, Dec 22, 2010 at 10:30:15AM -0800, Stephen Warren wrote:
> > Mark Brown wrote:
> 
> > > Reading this it's essentially just exporting point to point switches
> > > within the DAS block.  This really feels like it ought to be represented
> > > as a CODEC driver to give runtime flexibility to userspace to control
> > > the mux - it looks like the AP part of the system streams data into this
> > > block which then has very flexible switching on to the externally
> > > connected audio devices.
> 
> > Hmm. I don't see any examples of anything like Tegra's DAS in the existing
> > ASoC code-base. So, I'm slightly unsure how to recast the DAS driver as
> > a codec. In particular, in the machine driver, would I do something like:
> 
> The closest thing in the tree at the minute is WM8994 and WM8995 - both
> of these have multiple audio interfaces plus a DAC/ADC/DMIC block
> connected together via a digital mixing block.
> 
> > static struct snd_soc_dai_link *harmony_links[] = {
> > 	& harmony_i2s_das_link,
> > 	& harmony_das_wm8903_link,
> > };
> 
> Essentially, yes.
> 
> > Wouldn't that end up exposing two streams to user-space, one for each entry
> > in harmony_links[]?
> 
> Yeah, that's the unfortunate bit - it doesn't work ideally well right
> now.  We actually need to take care of this anyway (it's also an issue
> for things like phones as you get the same structure for the link
> between a digital baseband and the CODEC it's connected to) and
> something like this that really strongly benefits from the feature would
> be a good thing to use to get that working.
> 
> I guess for now setting up a 1:1 mapping between the CPU DAIs and the
> physical ports would get the CPU driver going, then I can do the
> framework work required to make sure DAPM propagates nicely over the
> mux.  Does that sound reasonable?

So I'm clear, I'm interpreting that as meaning the existing tegra_das.c
driver that I sent to the list is acceptable for now. Then, once that's
merged in, we can add in the infra-structure to recast it as a codec/...
Or, were you asking for some kind of structural change?

Thanks.

-- 
nvpublic