On Wed, May 02, 2012 at 12:41:22PM +0100, Mark Brown wrote: > We generally try to keep the clock API out of CODEC drivers due to the > issues with the clock API that the generic implementation is intended to > help us solve. > > The major problem here is that we can't rely on having the clock API > present at all on most platforms so as soon as we start adding clock > support into things we have to do a performance with HAVE_CLK which is > at best annoying. > Is this something that the series below tries to solve? http://thread.gmane.org/gmane.linux.ports.arm.kernel/163652 Regards, Shawn > There's also the fact that even if the clock API is available we've no > way to register a clock consistently and since the audio clock tree > often needs management off-SoC for at least some components when the > clock API is in use you end up having to handle clock trees that go into > and out of the clock API. > > The upshot of this is that while we really should be using the clock API > for clocks the API as it stands is somewhat difficult to deploy in cross > platform code. What I'd suggest is connecting the clock to the CODEC in > the device tree but actually doing the clk_get() in the machine driver. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
