[PATCH] Minor WM8580 enhancements.

[PATCH] Minor WM8580 enhancements.

[jassi brar]

Add more options to select clock source for various blocks
in WM8580.
Also, explicitly set defaults for the sake of consistency.

Signed-off-by: Jassi <jassi.brar@samsung.com>
---
 sound/soc/codecs/wm8580.c |  133 +++++++++++++++++++++++++++++++++++++++++++--
 sound/soc/codecs/wm8580.h |   25 +++++----
 2 files changed, 144 insertions(+), 14 deletions(-)

diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c
index 6bded8c..276bc8e 100644
--- a/sound/soc/codecs/wm8580.c
+++ b/sound/soc/codecs/wm8580.c
@@ -95,6 +95,7 @@

 /* PLLB4 (register 7h) */
 #define WM8580_PLLB4_MCLKOUTSRC_MASK   0x60
+#define WM8580_PLLB4_MCLKOUTSRC_MCLK   0x00
 #define WM8580_PLLB4_MCLKOUTSRC_PLLA   0x20
 #define WM8580_PLLB4_MCLKOUTSRC_PLLB   0x40
 #define WM8580_PLLB4_MCLKOUTSRC_OSC    0x60
@@ -106,9 +107,16 @@

 /* CLKSEL (register 8h) */
 #define WM8580_CLKSEL_DAC_CLKSEL_MASK 0x03
+#define WM8580_CLKSEL_DAC_CLKSEL_MCLK 0x00
 #define WM8580_CLKSEL_DAC_CLKSEL_PLLA 0x01
 #define WM8580_CLKSEL_DAC_CLKSEL_PLLB 0x02

+#define WM8580_CLKSEL_ADC_CLKSEL_MASK     0x0c
+#define WM8580_CLKSEL_ADC_CLKSEL_ADCMCLK  0x00
+#define WM8580_CLKSEL_ADC_CLKSEL_PLLA     0x04
+#define WM8580_CLKSEL_ADC_CLKSEL_PLLB     0x08
+#define WM8580_CLKSEL_ADC_CLKSEL_MCLK     0x0c
+
 /* AIF control 1 (registers 9h-bh) */
 #define WM8580_AIF_RATE_MASK       0x7
 #define WM8580_AIF_RATE_128        0x0
@@ -121,15 +129,16 @@

 #define WM8580_AIF_BCLKSEL_MASK   0x18
 #define WM8580_AIF_BCLKSEL_64     0x00
-#define WM8580_AIF_BCLKSEL_128    0x08
-#define WM8580_AIF_BCLKSEL_256    0x10
+#define WM8580_AIF_BCLKSEL_32    0x08
+#define WM8580_AIF_BCLKSEL_16    0x10
 #define WM8580_AIF_BCLKSEL_SYSCLK 0x18

 #define WM8580_AIF_MS             0x20

 #define WM8580_AIF_CLKSRC_MASK    0xc0
+#define WM8580_AIF_CLKSRC_ADCMCLK 0x00
 #define WM8580_AIF_CLKSRC_PLLA    0x40
-#define WM8580_AIF_CLKSRC_PLLB    0x40
+#define WM8580_AIF_CLKSRC_PLLB    0x80
 #define WM8580_AIF_CLKSRC_MCLK    0xc0

 /* AIF control 2 (registers ch-eh) */
@@ -604,12 +613,13 @@ static int wm8580_set_dai_clkdiv(struct
snd_soc_dai *codec_dai,

 		switch (div) {
 		case WM8580_CLKSRC_MCLK:
-			/* Input */
+			reg |= WM8580_PLLB4_MCLKOUTSRC_MCLK;
 			break;

 		case WM8580_CLKSRC_PLLA:
 			reg |= WM8580_PLLB4_MCLKOUTSRC_PLLA;
 			break;
+
 		case WM8580_CLKSRC_PLLB:
 			reg |= WM8580_PLLB4_MCLKOUTSRC_PLLB;
 			break;
@@ -630,6 +640,7 @@ static int wm8580_set_dai_clkdiv(struct
snd_soc_dai *codec_dai,

 		switch (div) {
 		case WM8580_CLKSRC_MCLK:
+			reg |= WM8580_CLKSEL_DAC_CLKSEL_MCLK;
 			break;

 		case WM8580_CLKSRC_PLLA:
@@ -646,6 +657,59 @@ static int wm8580_set_dai_clkdiv(struct
snd_soc_dai *codec_dai,
 		snd_soc_write(codec, WM8580_CLKSEL, reg);
 		break;

+	case WM8580_ADC_CLKSEL:
+		reg = snd_soc_read(codec, WM8580_CLKSEL);
+		reg &= ~WM8580_CLKSEL_ADC_CLKSEL_MASK;
+
+		switch (div) {
+		case WM8580_CLKSRC_ADCMCLK:
+			reg |= WM8580_CLKSEL_ADC_CLKSEL_ADCMCLK;
+			break;
+
+		case WM8580_CLKSRC_MCLK:
+			reg |= WM8580_CLKSEL_ADC_CLKSEL_MCLK;
+			break;
+
+		case WM8580_CLKSRC_PLLA:
+			reg |= WM8580_CLKSEL_ADC_CLKSEL_PLLA;
+			break;
+
+		case WM8580_CLKSRC_PLLB:
+			reg |= WM8580_CLKSEL_ADC_CLKSEL_PLLB;
+			break;
+
+		default:
+			return -EINVAL;
+		}
+		snd_soc_write(codec, WM8580_CLKSEL, reg);
+		break;
+
+	case WM8580_PAIF_CLKSEL:
+		reg = snd_soc_read(codec, WM8580_PAIF1 + codec_dai->id);
+		reg &= ~WM8580_AIF_CLKSRC_MASK;
+		switch (div) {
+		case WM8580_CLKSRC_ADCMCLK:
+			reg |= WM8580_AIF_CLKSRC_ADCMCLK;
+			break;
+
+		case WM8580_CLKSRC_PLLA:
+			reg |= WM8580_AIF_CLKSRC_PLLA;
+			break;
+
+		case WM8580_CLKSRC_PLLB:
+			reg |= WM8580_AIF_CLKSRC_PLLB;
+			break;
+
+		case WM8580_CLKSRC_MCLK:
+			reg |= WM8580_AIF_CLKSRC_MCLK;
+			break;
+
+		default:
+			return -EINVAL;
+		}
+		snd_soc_write(codec, WM8580_PAIF1 + codec_dai->id, reg);
+		break;
+
 	case WM8580_CLKOUTSRC:
 		reg = snd_soc_read(codec, WM8580_PLLB4);
 		reg &= ~WM8580_PLLB4_CLKOUTSRC_MASK;
@@ -672,6 +736,67 @@ static int wm8580_set_dai_clkdiv(struct
snd_soc_dai *codec_dai,
 		snd_soc_write(codec, WM8580_PLLB4, reg);
 		break;

+	case WM8580_MCLKRATIO:
+		reg = snd_soc_read(codec, WM8580_PAIF1 + codec_dai->id);
+		reg &= ~WM8580_AIF_RATE_MASK;
+		switch(div) {
+		case 128:
+			reg |= WM8580_AIF_RATE_128;
+			break;
+
+		case 192:
+			reg |= WM8580_AIF_RATE_192;
+			break;
+
+		case 256:
+			reg |= WM8580_AIF_RATE_256;
+			break;
+
+		case 384:
+			reg |= WM8580_AIF_RATE_384;
+			break;
+
+		case 512:
+			reg |= WM8580_AIF_RATE_512;
+			break;
+
+		case 768:
+			reg |= WM8580_AIF_RATE_768;
+			break;
+
+		case 1152:
+			reg |= WM8580_AIF_RATE_1152;
+			break;
+
+		default:
+			return -EINVAL;
+		}
+		snd_soc_write(codec, WM8580_PAIF1 + codec_dai->id, reg);
+		break;
+
+	case WM8580_BCLKRATIO:
+		reg = snd_soc_read(codec, WM8580_PAIF1 + codec_dai->id);
+		reg &= ~WM8580_AIF_BCLKSEL_MASK;
+		switch(div) {
+		case 64:
+			reg |= WM8580_AIF_BCLKSEL_64;
+			break;
+
+		case 32:
+			reg |= WM8580_AIF_BCLKSEL_32;
+			break;
+
+		case 16:
+			reg |= WM8580_AIF_BCLKSEL_16;
+			break;
+
+		default:
+			reg |= WM8580_AIF_BCLKSEL_SYSCLK;
+			break;
+		}
+		snd_soc_write(codec, WM8580_PAIF1 + codec_dai->id, reg);
+		break;
+
 	default:
 		return -EINVAL;
 	}
diff --git a/sound/soc/codecs/wm8580.h b/sound/soc/codecs/wm8580.h
index 0dfb5dd..0ecdbfa 100644
--- a/sound/soc/codecs/wm8580.h
+++ b/sound/soc/codecs/wm8580.h
@@ -18,16 +18,21 @@
 #define WM8580_PLLA  1
 #define WM8580_PLLB  2

-#define WM8580_MCLK       1
-#define WM8580_DAC_CLKSEL 2
-#define WM8580_CLKOUTSRC  3
-
-#define WM8580_CLKSRC_MCLK 1
-#define WM8580_CLKSRC_PLLA 2
-#define WM8580_CLKSRC_PLLB 3
-#define WM8580_CLKSRC_OSC  4
-#define WM8580_CLKSRC_NONE 5
-
+#define WM8580_MCLK        1
+#define WM8580_DAC_CLKSEL  2
+#define WM8580_ADC_CLKSEL  3
+#define WM8580_PAIF_CLKSEL 4
+#define WM8580_CLKOUTSRC   5
+#define WM8580_MCLKRATIO   6
+#define WM8580_BCLKRATIO   7
+
+#define WM8580_CLKSRC_ADCMCLK 0
+#define WM8580_CLKSRC_MCLK    1
+#define WM8580_CLKSRC_PLLA    2
+#define WM8580_CLKSRC_PLLB    3
+#define WM8580_CLKSRC_OSC     4
+#define WM8580_CLKSRC_NONE    5
+
 #define WM8580_DAI_PAIFRX 0
 #define WM8580_DAI_PAIFTX 1

-- 
1.6.2.5

Re: [PATCH] Minor WM8580 enhancements.

[Mark Brown]

On Sun, Sep 06, 2009 at 09:09:41AM +0900, jassi brar wrote:

> +	case WM8580_MCLKRATIO:
> +	case WM8580_BCLKRATIO:

There should be no need for machine drivers to configure any of this,
there's already enough information in the CODEC driver to figure out
this configuration without their help.  Having the machine drivers do it
manually simply forces each machine driver using the chip to repeat the
same logic which is at best redundant and at worst makes machine drivers
harder to write.

As mentioned previously this driver could use a bit of modernisation in
general, including with regard to clocking, which I had already been
planning to do as part of working on the SMDK boards.  As a result of
some work on another chip with a very similar clocking structure I have
a rough draft of what needs doing for the clocks already.  This is part
of why in my earlier mail I had recommended focusing on the CPU DAI
drivers for now - the lack of them is the biggest obstacle to getting
that work cleaned up and tested.

Re: [PATCH] Minor WM8580 enhancements.

[jassi brar]

On Sun, Sep 6, 2009 at 10:22 AM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Sep 06, 2009 at 09:09:41AM +0900, jassi brar wrote:
>
>> +     case WM8580_MCLKRATIO:
>> +     case WM8580_BCLKRATIO:
>
> There should be no need for machine drivers to configure any of this,
> there's already enough information in the CODEC driver to figure out
> this configuration without their help.
Not all combinations of BFS and RFS are possible at all LRCLK values
for CPU_DAI, not for Samsung SoCs those I am aware of.
So, i think the machine driver, as a link between Codec and Cpu Dai, has the
job of figuring out values for BFS and RFS that are compatible to
_both_ the CPU and the CODEC.
If CODEC driver, with disregard to the CPU, chooses values for
BCLK/MCLK-Ratio that are incompatible
with CPU, i don't know how that will work out.
Please correct, if i am missing something.

> As mentioned previously this driver could use a bit of modernisation in
> general, including with regard to clocking, which I had already been
> planning to do as part of working on the SMDK boards.  As a result of
> some work on another chip with a very similar clocking structure I have
> a rough draft of what needs doing for the clocks already.  This is part
> of why in my earlier mail I had recommended focusing on the CPU DAI
> drivers for now - the lack of them is the biggest obstacle to getting
> that work cleaned up and tested.
I get your recommendation, but i am already in the middle of
submitting I2S machine
driver for 6410-WM8580 mainline and that is one of the tasks i am assigned.
Ofcourse, after 6410-wm8580 driver is all up and available to our
users, i can switch to AC97.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] Minor WM8580 enhancements.

[Mark Brown]

On Sun, Sep 06, 2009 at 10:50:26AM +0900, jassi brar wrote:

> Not all combinations of BFS and RFS are possible at all LRCLK values
> for CPU_DAI, not for Samsung SoCs those I am aware of.

These things are all sufficiently constrained by other factors - for
example, the MCLK to sample rate ratio is fixed by those two parameters
which are already known.  The Samsung CPUs aren't particularly
restrictive here as far as I remember, the fact that they implement
standard I2S helps a lot.  If you have datasheet references for any
restrictions you're concerned about please let me know.

> I get your recommendation, but i am already in the middle of
> submitting I2S machine
> driver for 6410-WM8580 mainline and that is one of the tasks i am assigned.
> Ofcourse, after 6410-wm8580 driver is all up and available to our
> users, i can switch to AC97.

All I'm saying is do the CPU drivers first - like I say, the main
obstacle to finishing off refreshing the CODEC driver has been having
the CPU driver to work off.  I'd expect to have something quickly given
that.  There shouldn't be much overall delay to getting the boards fully
supported.

Re: [PATCH] Minor WM8580 enhancements.

[jassi brar]

On Sun, Sep 6, 2009 at 8:11 PM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Sep 06, 2009 at 10:50:26AM +0900, jassi brar wrote:
>
>> Not all combinations of BFS and RFS are possible at all LRCLK values
>> for CPU_DAI, not for Samsung SoCs those I am aware of.
>
> These things are all sufficiently constrained by other factors - for
> example, the MCLK to sample rate ratio is fixed by those two parameters
> which are already known.  The Samsung CPUs aren't particularly
> restrictive here as far as I remember, the fact that they implement
> standard I2S helps a lot.  If you have datasheet references for any
> restrictions you're concerned about please let me know.
Some SoC may recommend 'preferred' RFS for a given BFS selection.

For ex, @16bits/sample in either Master or Slave mode:-
    SoC recommends     - BCLK={32}         RFS={256, 384}
    Codec recommends  - BCLK={32, 48}   RFS={384}

How and what values wud the codec and cpu driver choose if not the
machine driver?

A codec driver is supposed to work with any SoC and
an SoC can "recommend" any combination of RFS-BFS selection.
If not for machine driver, how will this thing work out?


>> I get your recommendation, but i am already in the middle of
>> submitting I2S machine
>> driver for 6410-WM8580 mainline and that is one of the tasks i am assigned.
>> Ofcourse, after 6410-wm8580 driver is all up and available to our
>> users, i can switch to AC97.
>
> All I'm saying is do the CPU drivers first - like I say, the main
> obstacle to finishing off refreshing the CODEC driver has been having
> the CPU driver to work off.  I'd expect to have something quickly given
> that.  There shouldn't be much overall delay to getting the boards fully
> supported.
It seems basic features(play and capture) may simply work with
existing Samsung cpu drivers,
all we need to do is write the missing machine driver for 6410(as Ben noted).
Only after we have _some_ support for 6410 I2S in mainline, we shud go on to
implement v40 features in the cpu driver (assuming we are to keep the
status quo with Samsung SoCs' I2S architecture).
And if the cpu driver isn't good enough, i can only test it if i have
the machine driver.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] Minor WM8580 enhancements.

[Mark Brown]

On Sun, Sep 06, 2009 at 09:13:14PM +0900, jassi brar wrote:
> On Sun, Sep 6, 2009 at 8:11 PM, Mark
> Brown<broonie@opensource.wolfsonmicro.com> wrote:

> > which are already known.  The Samsung CPUs aren't particularly
> > restrictive here as far as I remember, the fact that they implement
> > standard I2S helps a lot.  If you have datasheet references for any
> > restrictions you're concerned about please let me know.

> Some SoC may recommend 'preferred' RFS for a given BFS selection.

> For ex, @16bits/sample in either Master or Slave mode:-
>     SoC recommends     - BCLK={32}         RFS={256, 384}
>     Codec recommends  - BCLK={32, 48}   RFS={384}

I'm not sure where these CODEC recommendations come from?

> How and what values wud the codec and cpu driver choose if not the
> machine driver?

It looks like by "RFS" you mean the MCLK/sample rate ratio?  As
mentioned in my previous e-mail this is fixed by those two parameters.

The BCLK required is fixed by the number of clocks required to transfer
the samples.  Mostly this is a minimum but there are some CPUs that
can't tolerate any extra cycles at all (generally due to being generic
synchronous serial ports simulating an I2S mode) which means that
selecting the minimum BCLK is generally what you want.

Anything else can be dealt with if something needs it but should only be
visible to those systems - the overwhelming majority of systems that
just need to transfer the data should never need to deal with this at
all.

> > All I'm saying is do the CPU drivers first - like I say, the main
> > obstacle to finishing off refreshing the CODEC driver has been having
> > the CPU driver to work off.  I'd expect to have something quickly given
> > that.  There shouldn't be much overall delay to getting the boards fully
> > supported.

> It seems basic features(play and capture) may simply work with
> existing Samsung cpu drivers,
> all we need to do is write the missing machine driver for 6410(as Ben noted).

> Only after we have _some_ support for 6410 I2S in mainline, we shud go on to
> implement v40 features in the cpu driver (assuming we are to keep the
> status quo with Samsung SoCs' I2S architecture).

The lack of IISv4 support is the major issue with these machines - I'd
be quite surprised to see the machine driver without the 6 channel
interface, it's the major reason I've not already merged something.

> And if the cpu driver isn't good enough, i can only test it if i have
> the machine driver.

I'm saying don't spend too much time on it - you'll certainly need
something to test with but you should be able to get a long way with 
a basic connection to the existing CODEC driver.  I wouldn't want to see
you spend much effort on the machine driver only to have changes in the
CODEC driver cause substantial reworking of the machine driver.

How about starting off with an initial machine driver which runs IISv4
in master mode using the existing CODEC driver?  That's not the ideal
configuration but it will allow you to work on the CPU support without
needing to do too much to the CODEC.  I will then try to get the updates
for the CODEC which would allow the machine driver to be finished off
done as quickly as possible.  Does that sound like a reasonable plan -
it should allow us both to work on this without much duplication?

If you do want to work on the CODEC driver then the clocking needs to be
redone more in line with one of the modern CODEC drivers.  Unfortunately
I can't point you at a specific one which is quite as flexible to use as
an example but something more like WM8903 is more what we're looking
for.  This will need to take account of digital routing for the device
(which also needs to be implemented).

Re: [PATCH] Minor WM8580 enhancements.

[jassi brar]

On Sun, Sep 6, 2009 at 10:42 PM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Sep 06, 2009 at 09:13:14PM +0900, jassi brar wrote:
>> On Sun, Sep 6, 2009 at 8:11 PM, Mark
>> Brown<broonie@opensource.wolfsonmicro.com> wrote:
>
>> > which are already known.  The Samsung CPUs aren't particularly
>> > restrictive here as far as I remember, the fact that they implement
>> > standard I2S helps a lot.  If you have datasheet references for any
>> > restrictions you're concerned about please let me know.
>
>> Some SoC may recommend 'preferred' RFS for a given BFS selection.
>
>> For ex, @16bits/sample in either Master or Slave mode:-
>>     SoC recommends     - BCLK={32}         RFS={256, 384}
>>     Codec recommends  - BCLK={32, 48}   RFS={384}
>
> I'm not sure where these CODEC recommendations come from?

Well, my example was inspired from one recommendation/constraint i
found at Page-23, of WM8580A manual Rev-4.7 March-2009.
It indicates that we can't have BCLK as 16fs if RFS(MCLK/LRCLK) is
either 128fs or 192fs.

In WM8580-Master mode and 8-bits/sample playback, where the
attached SoC(Slave) takes in MCLK too and supports 192fs but not
128fs mclk/lrclk and support 16fs and 128fs as bclk/lrclk.
Who decides what MCLK and BCLK ratio shud be?

Independently, SoC will come to choose 16fs BCLK @192fsMCLK
while WM8580 sets 128fs BCLK @128fsMCLK.
Obviously these 'usual' settings won't work whereas it was supposed
to work (@128fs-BCLK, 192fs-MCLK).

Btw, without the patch there is no way to set MCLK and BCLK ratios.
How and where are they taken care of?

>> How and what values wud the codec and cpu driver choose if not the
>> machine driver?
>
> It looks like by "RFS" you mean the MCLK/sample rate ratio?  As
> mentioned in my previous e-mail this is fixed by those two parameters.

Further to my above stated situation, there is no way of knowing the
MCLK value for the WM8580 driver, if its MCLK pin is directly input
8.4672MHz clock.
There I think we need to set the MCLK-Ratio explicitly.

> The BCLK required is fixed by the number of clocks required to transfer
> the samples.  Mostly this is a minimum but there are some CPUs that
> can't tolerate any extra cycles at all (generally due to being generic
> synchronous serial ports simulating an I2S mode) which means that
> selecting the minimum BCLK is generally what you want.
Generally, but not always. For aberrations, let there be a way to set
'unusual' but supported BCLK Ratios.
Just as WM8580 has a constraint on BCLK(128fs) at MCLK=128,192fs, some
SoC may have a constraint of using BCLK=48fs for MCLK=384fs
@16-bits/sample.

>> > All I'm saying is do the CPU drivers first - like I say, the main
>> > obstacle to finishing off refreshing the CODEC driver has been having
>> > the CPU driver to work off.  I'd expect to have something quickly given
>> > that.  There shouldn't be much overall delay to getting the boards fully
>> > supported.
>
>> It seems basic features(play and capture) may simply work with
>> existing Samsung cpu drivers,
>> all we need to do is write the missing machine driver for 6410(as Ben noted).
>
>> Only after we have _some_ support for 6410 I2S in mainline, we shud go on to
>> implement v40 features in the cpu driver (assuming we are to keep the
>> status quo with Samsung SoCs' I2S architecture).
>
> The lack of IISv4 support is the major issue with these machines - I'd
> be quite surprised to see the machine driver without the 6 channel
> interface, it's the major reason I've not already merged something.
Ok but the first requirement of our users is having mainline support
for simple Stereo operations in the mainline. 5.1 support comes next.

> How about starting off with an initial machine driver which runs IISv4
> in master mode using the existing CODEC driver?  That's not the ideal
> configuration but it will allow you to work on the CPU support without
> needing to do too much to the CODEC.
Yes, that is what i am doing.(i made changes to wm8580 not recently).
I have CPU, CODEC and MACHINE driver for 6410 in my tree, i am
adjusting them to fit in mainline code.
I hope to end up with small patches for CPU and CODEC(this patch)
drivers and submitting a new MACHINE driver.

>  I will then try to get the updates
> for the CODEC which would allow the machine driver to be finished off
> done as quickly as possible.  Does that sound like a reasonable plan -
> it should allow us both to work on this without much duplication?
Fine.


> If you do want to work on the CODEC driver
I do not plan to work on the CODEC driver.
I just tried to push the changes I had made while implementing and
testing 2channel SoC drivers with Master/Slave, suspend/resume and
FullDuplex features in the Samsung tree.
I have no more patches for any CODEC driver.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] Minor WM8580 enhancements.

[Mark Brown]

On Mon, Sep 07, 2009 at 11:35:08AM +0900, jassi brar wrote:
> On Sun, Sep 6, 2009 at 10:42 PM, Mark
> Brown<broonie@opensource.wolfsonmicro.com> wrote:

> >>     Codec recommends  - BCLK={32, 48}   RFS={384}

> > I'm not sure where these CODEC recommendations come from?

> Well, my example was inspired from one recommendation/constraint i
> found at Page-23, of WM8580A manual Rev-4.7 March-2009.
> It indicates that we can't have BCLK as 16fs if RFS(MCLK/LRCLK) is
> either 128fs or 192fs.

That's not a recommendation, that's a hardware limit.  Though I still
don't see how we get to a 48fs BCLK (which could only be generated with
a 48fs system clock) or a recommendation for a 384fs MCLK in particular.
This is all a bit of a sidetrack anyway.

> In WM8580-Master mode and 8-bits/sample playback, where the
> attached SoC(Slave) takes in MCLK too and supports 192fs but not
> 128fs mclk/lrclk and support 16fs and 128fs as bclk/lrclk.
> Who decides what MCLK and BCLK ratio shud be?

The CODEC driver, though to be frank I'd be astonished to see a CPU
that was limited to 128fs BCLK.  This is what I was saying about about
allowing an override from the machine driver for special cases.

> Btw, without the patch there is no way to set MCLK and BCLK ratios.
> How and where are they taken care of?

They aren't currently, this is why I'm saying that for the time being
you should run the CODEC as slave; it will work well enough to test most
of the CPU support.

> > It looks like by "RFS" you mean the MCLK/sample rate ratio?  As
> > mentioned in my previous e-mail this is fixed by those two paameters.

> Further to my above stated situation, there is no way of knowing the
> MCLK value for the WM8580 driver, if its MCLK pin is directly input
> 8.4672MHz clock.
> There I think we need to set the MCLK-Ratio explicitly.

This is what the set_sysclk() operation is for - specifying the input
clocks to the device.

> Just as WM8580 has a constraint on BCLK(128fs) at MCLK=128,192fs, some
> SoC may have a constraint of using BCLK=48fs for MCLK=384fs
> @16-bits/sample.

Like I say, I'd be very surprised to see any such constraint - the
restriction on not having any extra BCLKs with I2S is fairly common
with the CPUs that simulate I2S with a generic synchronous serial
controller but it would be very unusual to see anything that actually
implements I2S caring either way about extra clocks when running as
slave.  The CPUs that do care generally work a lot better if you use one
of the DSP modes since those have no gap between the two data samples.

The goal is that the only machine drivers that should have to worry
about unusual clocking restrictions are those who are affected by them.
The majority of systems won't be affected so there is no gain from
forcing each machine driver to deal with it.  Having to do this manually
just makes things harder to use since it means users have to learn about
more of the details of audio hardware configuration.

> >  I will then try to get the updates
> > for the CODEC which would allow the machine driver to be finished off
> > done as quickly as possible.  Does that sound like a reasonable plan -
> > it should allow us both to work on this without much duplication?

> Fine.

OK, sounds like we have a good plan here.

Re: [PATCH] Minor WM8580 enhancements.

[jassi brar]

On Mon, Sep 7, 2009 at 8:58 PM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Sep 07, 2009 at 11:35:08AM +0900, jassi brar wrote:
>> On Sun, Sep 6, 2009 at 10:42 PM, Mark
>> Brown<broonie@opensource.wolfsonmicro.com> wrote:
>
>> >>     Codec recommends  - BCLK={32, 48}   RFS={384}
>
>> > I'm not sure where these CODEC recommendations come from?
>
>> Well, my example was inspired from one recommendation/constraint i
>> found at Page-23, of WM8580A manual Rev-4.7 March-2009.
>> It indicates that we can't have BCLK as 16fs if RFS(MCLK/LRCLK) is
>> either 128fs or 192fs.
>
> That's not a recommendation, that's a hardware limit.
Another way of putting it.
When we can't do somthing, it is recommended otherwise :)

> Though I still
> don't see how we get to a 48fs BCLK (which could only be generated with
> a 48fs system clock) or a recommendation for a 384fs MCLK in particular.
> This is all a bit of a sidetrack anyway.
Yes, a badly put example.

>> Just as WM8580 has a constraint on BCLK(128fs) at MCLK=128,192fs, some
>> SoC may have a constraint of using BCLK=48fs for MCLK=384fs
>> @16-bits/sample.
> Like I say, I'd be very surprised to see any such constraint
This was just an example.
I once had to set non-obvious values of BCLK+MCLK on the codec due to the clock
I had that ran the SoC in Master mode. Will let you know the real life
example if i cud dig that up again.

I think i have made whatever points i had. Am at peace now :)
Do as u wish appropriate with the patch.

Regards.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel