On Fri, Mar 22, 2013 at 04:48:11PM +0100, Stephen Warren wrote:On 03/22/2013 05:54 AM, Peter De Schrijver wrote:That should be ok. You can enable a clock more than once.The PLL code relies on udelay() which is not available when CCF isNo, this won't work for the audio drivers; they assume the clock is
initialized. Hence we can't enable any PLL during this phase.
Signed-off-by: Peter De Schrijver <pdeschrijver@xxxxxxxxxx>
--
Stephen,
Can you confirm this is ok for the audio drivers?
We used to be lucky that this has worked up to now, but I will introduce some
changes to the pll lock check code which cause this to fail due to the
slight differences in timing.
enabled when they start.
This assumption was made long ago. I know drivers are supposed to assume
that clocks are disabled when they're probed, but historically that
wasn't always the case, so if the audio drivers assumed that, and then
did clk_enable() as the first thing, they got a warning due to the
enabling an already enabled clock and/or later attempts to disable the
clocks wouldn't actually disable them. Perhaps this has changed now, butBut indeed, the clock won't be disabled then when the driver does
either way, audio driver changes would be needed to support this change.
clk_disable(). The reference count will just be decremented. That's however
not a functional problem, just not optimal from a power consumption point of
view. So we could change the drivers first and keep the clocks disabled at
boottime in a second phase.
Perhaps this is due to initializing the Tegra clock driver in theMaybe. But we need the clockframework before the timers are initialized...
machine descriptor's init_irq function, rather than in the init_machine
function? Can this be moved?
So I have to check the dependencies.
Cheers,
Peter.