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

[Stephen Warren]

Mark Brown wrote:
> On Wed, Jan 05, 2011 at 03:27:17PM -0800, Stephen Warren wrote:
> > Mark Brown wrote:
> 
> > > No, I don't think this should be made visible to machine drivers at all
> > > - they should just see a straight through mapping from the DMA channels
> > > to the ports in the first instance.
> 
> > Oh. So what should set up this 1:1 mapping then; what module should the
> > DAS register writes be contained in? And later, what module should
> 
> I guess the I2S driver?
> 
> > configure the DAS with the mux configuration that is appropriate for
> > the board? It seems like the machine driver is the only place with the
> 
> My suggestion would only work for very simple boards like Harmony.
> 
> > knowledge to define what the routing should be. Whether the machine driver
> > calls tegra_das_* vs. some codec/mux API to set this up seems like a
> > different issue to whether the machine driver or something else should
> > contain this knowledge.
> 
> The end result would be that this would all be done in the application
> layer, potentially dynamically.

Hmmm.

One of the nice things about ALSA on desktop is that everything just works
without having to fiddle around setting up routing etc. from user-space e.g.
using alsamixer or custom code.

Isn't ASoC attempting to set up a reasonably good routing/configuration on a
per-board basis, driven by knowledge in the machine (board?) driver? Then,
let people tweak it /if/ they want? It kinda sounds like you're pushing for a
model where simply loading the driver may or may not have things set up right,
then one has to configure everything from user-space before audio will work.
Am I grossly misunderstanding?

Something else I was holding off on asking, but may as well now:

Related to this, there's a lot of code in the-original-Tegra-driver-that-I-
based-my-submission-on which pokes all kinds of registers in the codec from
the machine driver to set up recording; e.g. mic mux selection, mic volume
or gain, bias on/off, mono/stereo etc. based off detailed knowledge of the
Harmony board. Seaboard, Ventana, ... would have similar but subtly different
configuration logic. I stripped this out to simplify things initially. Is
such configuration not meant to be part of the machine driver, but provided
by manually setting everything up with alsamixer for example (and perhaps
shipping a saved alsamixer state file)?

> > In the short-term, are you expecting the I2S driver to expose a CPU DAI for
> > each audio controller and port? The number of audio controllers and ports
> > isn't equal, and hence it wouldn't be possible to support a board using just
> > port 5 since there's no controller 5 (and even audio controller 3 I think is
> > SPDIF not I2S)...
> 
> Oh, hrm.  That wasn't clear from your code.  Would mapping controller n
> to port n work for Harmony?

Yes, Harmony just happens to use controller ID 1 and port ID 1.

-- 
nvpublic