[alsa-devel] [PATCH] Minor WM8580 enhancements.
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
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.
On Sun, Sep 6, 2009 at 10:22 AM, Mark Brownbroonie@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.
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.
On Sun, Sep 6, 2009 at 8:11 PM, Mark Brownbroonie@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.
On Sun, Sep 06, 2009 at 09:13:14PM +0900, jassi brar wrote:
On Sun, Sep 6, 2009 at 8:11 PM, Mark Brownbroonie@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).
On Sun, Sep 6, 2009 at 10:42 PM, Mark Brownbroonie@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 Brownbroonie@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.
On Mon, Sep 07, 2009 at 11:35:08AM +0900, jassi brar wrote:
On Sun, Sep 6, 2009 at 10:42 PM, Mark Brownbroonie@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.
On Mon, Sep 7, 2009 at 8:58 PM, Mark Brownbroonie@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 Brownbroonie@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.
participants (2)
-
jassi brar -
Mark Brown