Mark Brown wrote: > On Fri, Dec 17, 2010 at 10:16:16PM -0800, Stephen Warren wrote: > > The root of the audio clocks is a single PLL, pll_a, with one output, > > pll_a_out0. This one output feeds the audio module clock and both > > I2S controllers. While the feed to at least each I2S controller has a > > Separate divider per controller, the PLL can't run fast enough to be a > > multiple of both the two clock rates the driver currently uses[1]. So, > > once we've pick a 44.1KHz-class clock rate for one I2S controller, that > > clock also applies to the other I2S controller, albeit perhaps with a > > different divider. > > Ah, right - the two interfaces have to be synchronous. That does limit > things rather. I take it this restriction applies even if the Tegra is > not clock master on the I2S interface? I believe if Tegra is the slave, the two I2S ports can operate at completely unrelated frequencies. However, there's also that audio/audio_2x clock. I'm not sure of the requirements for that clock e.g. if it must be in the same clock domain as the/both I2S bit clocks in use or not, or simply some faster rate, or... I'm beginning a conversation with some of the HW designers to find out exactly what the requirements are. > What you should also do here is when one of the interfaces is active set > constraints on the other interface in its startup() so userspace knows > it can't select a sample rate that's not supported by the currently > active clock rate. OK. > > Perhaps the I2S driver can still manage all this though, and simply > > apply PCM constraints to any subsequent I2S controller's streams when > > one stream/controller is configured for the first time? > > That'd probably be too restrictive - it'd mean that if you only have one > of the ports in use (like on Harmoney) you couldn't switch between the > two different clock ratios. I must be misunderstanding that comment; what I meant by it is basically exactly what you suggested in the paragraph I quoted just before. (by "configured for the first time", I was talking about stream lifetime not I2S driver lifetime. I.e. I meant during hw_params or similar, and that the constraints would be removed later, e.g. during close?) -- 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
