On Mon, Aug 11, 2014 at 3:28 AM, Nicolin Chen Guangyu.Chen@freescale.com wrote:
On Sun, Aug 10, 2014 at 10:10:51PM -0400, jonsmirl@gmail.com wrote:
As I debug further I am getting a better understanding of the problem. This is my simple-audio binding.
sound { compatible = "simple-audio-card"; simple-audio-card,format = "i2s";
simple-audio-card,cpu { sound-dai = <&iis0>; };
simple-audio-card,codec { clocks = <&iis0>; sound-dai = <&sgtl5000>; }; };
I'm having trouble with the simple-audio-card,cpu node, not the simple-audio-card,codec node. As simple-audio is currently implemented when simple-audio-card,cpu is processed it will pick up my 80Mhz apb clock and set it as sysclk.
It looks like the problem is that Simple Card also configures cpu-dai via set_sysclk() with direction SND_SOC_CLOCK_IN while it fetches the sysclk rate not from MCLK source but from 'sound-dai' -- cpu-dai node itself, when the binding for sound-dai doesn't have clock or frequency assignment, although this fetching works out for codec-dai side.
In your case, Simple Card sets both sides of dai with different sysclk rates, and meanwhile the sysclk rate for cpu-dai is incorrect.
Is it true?
Yes, that is what is going on. Trying to use sgtl5000 with simple-audio exposed that issue. Without removing that 'else' clause there is no way to tell simple-audio just to leave the cpu-dai alone.
After spending all day trying to fix that else clause, I'm coming to the conclusion that the else clause simply shouldn't be there at all. I just hit this because I had code checking for bogus values in setsysclk.
Well, even if there's a problem at this point for Simple Card, I'm still curious for the reason why setting cpu-dai with an incorrect rate but direction SND_SOC_CLOCK_IN would result some breaks here.
The sysclk direction is only valid when indicating MCLK as sysclk (FSYNC or BCLK shall follow CBS_CFS/CBM_CFM setting).So basically if cpu-dai driver gets sysclk configuration with SND_SOC_CLOCK_IN, shouldn't it just set the internal direction for MCLK's PAD and return the call directly? (I'm guessing there also might be some tiny work for your cpu-dai driver to enhance the validation part.)
Best regards, Nicolin