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?
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