[alsa-devel] [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

On Sun, Aug 15, 2010 at 06:00:50PM +0900, Seungwhan Youn wrote:
> On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown

> > +
> > +       switch (dai->driver->id) {
> > +       case WM8580_DAI_PAIFTX:
> > +               sel_mask = 0x3;
> > +               sel_shift = 0;
> > +               break;
> > +
> > +       case WM8580_DAI_PAIFRX:
> > +               sel_mask = 0xc;
> > +               sel_shift = 3;
> > +               break;

> These CLKSEL settings looks different with my WM8580 datasheet
> (released March 2009, Rev 4.7).
> I think these codes look...
> +       case WM8580_DAI_PAIFRX:
> +               sel_mask = 0x3;
> +               sel_shift = 0;
> +               break;

This one is exactly what's above as far as I can tell?....

> +       case WM8580_DAI_PAIFTX:
> +               sel_mask = 0xc;
> +               sel_shift = 2;
> +               break;

...but the shift is typoed here, yes.

> > +       switch (clk_id) {
> > +       case WM8580_CLKSRC_ADCMCLK:
> > +               if (dai->id != WM8580_DAI_PAIFTX)
> > +                       return -EINVAL;
> > +               sel = 0 << sel_shift;
> > +               break;

> During my test case with smdk6410 board, clock source of ADC should be
> set by ADCMCLK, if we want to hear a correct sound on playback and
> capture. And when ADC select MCLK or PLLA, source clock was broken
> both of playback and capture.
> Can you verify this(set source clock of ADC set to ADCMCLK) is right
> or is there something missing on other settings?

This should not be required in general.  Without knowing anything about
the tests you did, the problems you observed or why you believe this
configuration helps it's a bit hard to comment in detail.  I did test
briefly since I remembered the use of this from your code.

My best guess would be that this is related to the issue I mentioned in
the cover mail with multiple DAI links on one physical DAI.  Since the
DAIs are cross wired we really shouldn't have both CODEC interfaces
driving the audio interface simultaneously.  

What would be much more straightforward for this configuration is to run
the PLL output from the CODEC into the CPU and then have the CPU master
the actual audio interface but Jassi was fairly insistent on having the
CODEC master the bus and I'd need to verify again with the schematic if
the appropriate clock lines are run.  Actually, I think I'll just do
that if the hardware allows.