On Sun, Sep 6, 2009 at 10:42 PM, MarkBrown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 ifound 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) iseither 128fs or 192fs.
In WM8580-Master mode and 8-bits/sample playback, where theattached SoC(Slave) takes in MCLK too and supports 192fs but not128fs 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 @192fsMCLKwhile WM8580 sets 128fs BCLK @128fsMCLK.Obviously these 'usual' settings won't work whereas it was supposedto 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 theMCLK value for the WM8580 driver, if its MCLK pin is directly input8.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, someSoC 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 supportfor 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 amadjusting 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 driverI do not plan to work on the CODEC driver.I just tried to push the changes I had made while implementing andtesting 2channel SoC drivers with Master/Slave, suspend/resume andFullDuplex features in the Samsung tree.I have no more patches for any CODEC driver._______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
