[alsa-devel] Choosing the sysclk in simple-card looks broken to me.

jonsmirl at gmail.com jonsmirl at gmail.com
Mon Aug 11 13:56:12 CEST 2014


On Mon, Aug 11, 2014 at 3:28 AM, Nicolin Chen
<Guangyu.Chen at freescale.com> wrote:
> On Sun, Aug 10, 2014 at 10:10:51PM -0400, jonsmirl at 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



-- 
Jon Smirl
jonsmirl at gmail.com


More information about the Alsa-devel mailing list