[alsa-devel] [PATCH] Minor WM8580 enhancements.

[jassi brar]

On Sun, Sep 6, 2009 at 10:42 PM, Mark
Brown<broonie at 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 at 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.