[alsa-devel] at91 SoC Modifications

[Paul Kavan]

On 6/20/07, Paul Kavan <pkavan at gmail.com> wrote:
>
> Hello:
>
> Okay, so after probing the various pcm lines, I think I see that the
> format used for the pcm is a little bit off of what my codec likes to play
> nice. In my machine/codec driver, I see that I have some lines:
>
>     /* set cpu DAI configuration */
>     ret = cpu_dai->dai_ops.set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A |
>         SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS);
>
> I believe this is where it is selecting the format. In at91-ssc.c, I see
> that this format is given as:
>
>     case SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBS_CFS:
>         /*
>          * DSP/PCM Mode A format, SSC provides BCLK and LRC clocks.
>          *
>          * The SSC transmit and receive clocks are generated from the
>          * MCK divider, and the BCLK signal is output on the SSC TK line.
>          */
>         rcmr =      (( ssc_p->rcmr_period        << 24) & AT91_SSC_PERIOD)
>             | (( 1                << 16) & AT91_SSC_STTDLY)
>             | (( AT91_SSC_START_RISING_RF         ) & AT91_SSC_START)
>             | (( AT91_SSC_CK_RISING             ) & AT91_SSC_CKI)
>             | (( AT91_SSC_CKO_NONE             ) & AT91_SSC_CKO)
>             | (( AT91_SSC_CKS_DIV             ) & AT91_SSC_CKS);
>
>         rfmr =      (( AT91_SSC_FSEDGE_POSITIVE         ) &
> AT91_SSC_FSEDGE)
>             | (( AT91_SSC_FSOS_POSITIVE         ) & AT91_SSC_FSOS)
>             | (( 0                << 16) & AT91_SSC_FSLEN)
>             | (((channels - 1)        <<  8) & AT91_SSC_DATNB)
>             | (( 1                <<  7) & AT91_SSC_MSBF)
>             | (( 0                <<  5) & AT91_SSC_LOOP)
>             | (((bits - 1)            <<  0) & AT91_SSC_DATALEN);
>
>         tcmr =      (( ssc_p->tcmr_period        << 24) & AT91_SSC_PERIOD)
>
>             | (( 1                << 16) & AT91_SSC_STTDLY)
>             | (( AT91_SSC_START_RISING_RF        ) & AT91_SSC_START)
>             | (( AT91_SSC_CK_RISING             ) & AT91_SSC_CKI)
>             | (( AT91_SSC_CKO_CONTINUOUS         ) & AT91_SSC_CKO)
>             | (( AT91_SSC_CKS_DIV             ) & AT91_SSC_CKS);
>
>         tfmr =      (( AT91_SSC_FSEDGE_POSITIVE         ) &
> AT91_SSC_FSEDGE)
>             | (( 0                << 23) & AT91_SSC_FSDEN)
>             | (( AT91_SSC_FSOS_POSITIVE         ) & AT91_SSC_FSOS)
>             | (( 0                << 16) & AT91_SSC_FSLEN)
>             | (((channels - 1)        <<  8) & AT91_SSC_DATNB)
>             | (( 1                <<  7) & AT91_SSC_MSBF)
>             | (( 0                <<  5) & AT91_SSC_DATDEF)
>             | (((bits - 1)            <<  0) & AT91_SSC_DATALEN);
>
>
>
>             break;
>
> I should have caught this before--I spent enough time dealing with the HW
> registers. The simple ssc pcm driver I wrote sets the regs a little
> differently to get the peak performance out of the codec, e.g.
>
> In RCMR, I have STTDLY=0, AT91_SSC_CKI_FALLING, AT91_SSC_CKS_PIN.
>
> In RFMR everything looks okay except that I have FSOS_NONE as I borrow it
> from TF0
>
> In TCMR the STTDLY=0 in mine
>
> In TFMR I do nothing with the FSEDGE and FSDEN and I have FSLEN=7 and
> DATADEF=1.



I did a test using a configuration that worked for my previous ssc driver
and the clock and data lines now look a little more like what I would
expect. The sine wave sounds a little better, but when I put in:

speaker-test -r8000 -f1000 -FS8 -tsine -l1

I am getting a sine wave that is at f=2k and but has some of the 1k wave in
there. Hard to explain, so I will see if I can determine it mathematically
and produce a waveform for you--I do not have the ability to export scope
plots to a pc here (grrr), nor do I have a spectrum analyzer. What I am
wondering about that is that my codec expects data in u-law companded
format. Is that what speaker-test produces....I am guessing not.

With the clock and data lines looking fine, I think it is purely a software
issue now. I am using the default conf still as I cannot make any other
work. I am not savvy enough with alsa to determine what the problem could be
with the conf file. That discussion is probably more appropriate to separate
thread though.

Paul


-- 
***************************************
Paul David Kavan
Project Engineer
GRH Electronics, Inc.
402-734-4900
pkavan at gmail.com
***************************************