On Mon, Jul 15, 2013 at 11:58:36PM +0100, Mark Brown wrote:
On Mon, Jul 15, 2013 at 10:37:27PM +0100, Russell King - ARM Linux wrote:
I suggest you go back and re-read the driver because it most certainly does use extclk. What makes you think it won't?
The only thing I can see which is pushing a constraint up the stack is KIRKWOOD_I2S_RATES in the DAIs which only allows 44.1kHz, 48kHz and 96kHz, the rates for which the internal clock is used. The driver will
Ugh, I just saw the dai_extclk stuff. That's probably also problematic the other way - it'll break if someone decides to put a non-programmable clock on there, or something that can't generate arbatrary frequencies like a crystal plus divider. It's also not clear to me why the driver ever uses the internal clocks if something external has been provided.
This does mean the change is safe, though - but it needs to be called out in both the code and the changelog how this is happening.