Mark Brown wrote: > On Wed, Jan 05, 2011 at 02:58:02PM -0800, Stephen Warren wrote: > > Mark Brown wrote: > > > > 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? > > 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 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 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. 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)... -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html