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.