Hi,

On 11/25/07, Michael Lorenz <macallan@netbsd.org> wrote:
> >> The intention was to factor out all the DBDMA goo that's more or less
> >> the same in snapper and awacs so we can also have:
> >> snapper* at audiodma?
> >> daca* at audiodma?
> >> dumbcodec* at audiodma?
> >> g3audio* at audiodma?
> >
> > Then the i2s driver could be attached to audiodma too... so the i2s
> > driver would only need to do things like setting up the I2S clocks
> > and configuring or
> > dealing with the gpio stuff (headphones, lineouts, etc.).
>
> Something like that - I'm not sure they all use the same gpios.

As far as I know they are more or less the same in all I2S configurations
except minor differences (for example `audio-hw-reset' ond older machines
vs. `hw-reset' on newer machines). Also older machines have a `APPL,address'
property with an absolute address of the GPIO control, while newer machines
only have a `reg' property with a relative address.
Also newer machines have `platform-foo' properties on the 'i2s' node that
point to the GPIO nodes, so it's not necessary to look manually for them.

Other differences are that some machines have a line-out output with all its
associated gpio nodes and interrupts; while other machines have only
headphones and speaker.

There are also other subtle differences in the `i2s' node and the I2C nodes
-- some have a `i2c-address' property, some have a `reg' property... :-S .

I have tried to address all of this subtle differences, but at the moment I
couldn't test it on any of the said 'newer machines'.

> also didn't get around to write snapper at audiodma either so I don't
> have a sane opinion on that problem yet. On awacs clock selection is
> part of the codec's interface, maybe it would be easiest to do the
> same on i2s

The controller clock configuration stuff is the same in all configs,
but the codec should also be informed of the choosen settings (sampling
rate and I2S bitclock).
For example the 'daca' wants to be informed of the band of the sampling
rate setting.

> ( maybe put the i2s clock and gpio stuff - if it really
> is the same on all i2s - into a separate source file and just pull it
> in with those codecs that need it so the DMA engine driver can stay
> nice and clean )

So it would consist of three parts: audiodma, i2s (I2S controller) and then
the codec.
So we could have the following configurations:
- audiodma + awacs
- audiodma + awacs + sgsmix (beige G3)
- audiodma + i2s + {texasdsp, daca, pcm3052, etc.}

> I'm not quite sure what to do about the beige G3's audio - it's a
> bastardized awacs with an i2c mixer on its auxillary output and the
> regular outputs going nowhere. Right now it's a bunch of #if NSGSMIX
> and similar ugliness in awacs.c which I'd like to get rid of.

Yeah, it doesn't sound easy to get rid of the ifdefs without duplicating
code...  :-(

> >> For now there are two drivers that attach as i2c codecs - deq and
> >> sgsmix. Deq is a simple marker with no real code while sgsmix exports
> >> a bunch of functions to control volume, bass/treble etc. - not sure
> >> which approach is better.
> >
> > In the experiment I did the i2c drivers (currently 'texasdsp')
> > exported
> > a 'codec' interface that contains a bunch of methods ('configure',
> > 'reset', etc.).
> > Then i2s(4) calls the methods as appropriate.
>
> Sounds like the right thing to do. Do you think it would make sense
> to have the codec driver fill in the mixer-related methods in
> audio_attach_data instead? I did something like that in my experiment
> but awacs is rather simplistic, not sure if I'd run into trouble with
> that later on.

That would be flexible; so each device could put its own specific controls
(bass/treble, gains and maybe other things such as DRC).  However the
output selection is done by the I2S controller with GPIO controls and not by
the codec. On the other hand the input selection is done by the codec :-S .

My current experimental 'i2s' driver just uses methods in the 'codec'
interface for common attributes (volume, bass/treble etc.). However this is
not as flexible.

Greetings,
Marco.