On 12/17/2013 02:43 PM, Mark Brown wrote: > On Tue, Dec 17, 2013 at 03:49:53PM +0100, Lucas Stach wrote: >> Am Dienstag, den 17.12.2013, 14:00 +0000 schrieb Mark Brown: > >>> I don't understand this commit message at all I'm afraid. What does it >>> mean to "be in line with the devicetree" and what is the purpose of this >>> change? > >> Clocks were added to the DT after the Tegra AC97 driver was initially >> pushed upstream and the layout changed a bit in the process. Stephen >> Warren convinced me that it's the right thing to let the Audio PLL be >> controlled by the ASoC machine driver, rather than the AC97 host >> controller driver. > >> So currently the host controller driver asks for clocks that aren't >> there in the DT. This change corrects the clock handling so that the >> host controller driver only ask for it's own clock, but the Audio PLL >> handling is pushed into the machine driver. > > Are we sure this is the best thing to do here? There is standard > clocking behaviour specified in AC'97 so if the machine driver clocking > control includes that it's not clear that we want to vary it. In any > case a clearer changelog explaining that the driver never worked due to > these clocking changes would be good. The Tegra clocking architecture has a shared audio PLL that provides clocks to the various IO controllers (I2S, AC'97, S/PDIF). In order to allow multiple IO controllers to be in use at once, a single SW entity has to manage the clocks, so that it can configure the audio PLL, rather than having each individual IO controller attempt to assert ownership on the shared resource. The centralized PLL management needs to switch the PLL rate between 2 different values for 48-/44.1KHz-based audio for example, and deny requests to switch if already-active audio is running at the other rate. So yes, I think doing this all in the machine driver is the best thing. -- 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
