[alsa-devel] [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 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?

> 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).