Hi,

On 11/25/07, Michael Lorenz <macallan@netbsd.org> wrote:
> On Nov 23, 2007, at 16:23, Marco Trillo wrote:
>
> > For an experiment, I ran into some sort of, perhaps stupid, autoconf
> > (9)-
> > -related doubt.
> >
> > The hardware arrangement looks like this (please excuse the
> > poor ASCII drawing):
> >
> > The 'doubt' is what is the most clean way to attach an audio(4) bus
> > in such an arrangement. Some functions of the audio setup need to
> > configure the CODEC via the I2C bus, some functions need to configure
> > the 'Audio controller', and some need to configure both devices.
>
> Yeah, the problem is that the codec would need to attach to two
> devices - the i2c bus and the audio controller ( or rather, the DMA
> engine ) and it needs to deal with them attaching in different order.
> Is there any audio hardware out there that needs this kind of
> arrangement and isn't some sort of Apple onboard audio?

Indeed, the experiment was factoring out the I2S controller code of snapper(4)
and move it to a i2s(4) driver, and then write individual machine-independent
codec drivers in sys/dev/i2c/ similar to the sgsmix(4) driver; so it's easy
to write drivers for the other I2S codecs (daca, pcm3052, etc.) without making
a mess of the snapper driver.

Currently I have this working with the approach A, so it looks like this:

i2s0 at obio0 offset X: Apple I2S controller
iic1 at ki2c1: I2C bus
texasdsp0 at iic1 addr Y: [...]
codec0 at texasdsp0
codec0: [supported formats]
[...]
i2s0: connecting to codec0
audio0 at i2s0: full duplex

So the question was if this could be done another way that didn't
involve deferred
configuration.

> I have an experimental awacs driver that attaches like this:
> audiodma* at obio?
> cawacs* at audiodma?
> audio* at cawacs?
>
> 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.).

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


> > B) Similar to A), but inverse: make the 'codec' look for the
> > controller
> >    and attach the 'audio' bus to the 'codec'.
> >    However, the most logic thing seems to be for the 'audio' bus to
> >    be attached to the audio controller.
>
> The more time critical methods in the audio driver API need to talk
> to the DMA engine, the mixer stuff is much more relaxed. I'd find it
> more logical to have audio at something as the last piece of the
> chain instead of having it fork.

Yeah, I do not like approach B either.

> > What do you think?
>
> I think for the time being we can't really get around the way awacs
> and snapper find their mixers - use a marker that attaches to i2cbus,
> identifies if possible and grabs the mixer device, then have the
> audio driver ( or the real codec driver which attaches to the DMA
> engine ) look for the marker, All it needs from the marker is a
> reference to the i2cbus and a device address.

Or in this case, a codec driver that exports an interface, so the
controller driver (i2s) does not need to use any I2C functions at all.

Thanks for your reply!
Marco.