On Wed, Aug 13, 2014 at 12:35 PM, Mark Brown broonie@kernel.org wrote:
On Wed, Aug 13, 2014 at 08:25:22AM -0400, jonsmirl@gmail.com wrote:
On Tue, Aug 12, 2014 at 2:20 PM, Mark Brown broonie@kernel.org wrote:
- Should sysclk for the cpu-dai and codec-dai be set independently?
In simple-card they can be set to conflicting values on the two nodes in the DTS. Should sysclk be a single property for the machine?
No, clocks might be at different rates for different devices. One device might divide down the clock to the other.
What do you think about adding fields for min/max allowed sysclk to snd_soc_dai_driver? In my case the SOC can run the sysclk at 100Mhz, but the attached codec can only handle 27Mhz.
If we're going to do constraints they should be done properly so need to be able to represent specific numbers too. It's probably a clock API problem, independently implementing it seems redundant. Doing simple things in simple-card for the common cases makes sense while the clock API isn't something we can rely on but equally we don't want to be doing huge amounts, and of course simple-card is just a subset of what people are doing.
Right now I could make the set_sysclk implementations return -EINVAL if the clock is out of range. Then add some logic to simple-card to try again with a different FS multipler. Or at least I can print some error message to give a clue as to why the song won't play.
What ASoC platforms haven't implemented the clock API? Using the clock API, simple-card would have a phandle to the clock master. Then it could set the proposed rate into it. Codec and CPU would have clk_notifier implemented so that they could reject the proposed change based on their constraints. Simple could then adjust the FS multiple until both devices are happy.
// from clock API struct clk_notifier_data { struct clk *clk; unsigned long old_rate; unsigned long new_rate; };