-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

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):
>
>              +------------+
>              |    bus     |
>              +------------+
>      /---------|         |
>      v                   v
> +------------+        +----------+
> |   Audio    |        |   I2C    |
> | controller |        |controller|
> +------------+        +----------+
>   ||                       | (I2C bus)
>   ||                       v
>   ||                   +-------+
>   \\=== (audio link) ==| CODEC |->audio out
>                        +-------+
>
> 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?

> A) Attach all the devices. Defer the configuration of the 'Audio
>    controller' with config_defer(9) and then look for the 'CODEC',
>    connect to it, and attach the 'audio' bus:
>
>    audio_controller0 at bus0
>    [defers configuration]
>    i2c_controller0 at bus0
>    iic0 at i2c_controller0: I2C bus
>    codec0 at iic0
>    [...]
>    audio_controller0: connecting to codec0
>    audio0 at audio_controller0

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

We also can't simply treat the i2c controller as part of the audio  
hardware since there is no guarantee that there are no other,  
unrelated i2c devices on the same bus ( in fact there are such  
devices at least on the beige G3 and the iBook G4 )

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

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

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR0l5AspnzkX8Yg2nAQITaggAtX3q+yiU4sxpa7pQorskKeAjW+2beKh/
fq4Q2XgJU4lQHfIFJqyzZZB9uqCJ/mPKhGsG8t/vnZpQpgtUCC+jzPUYRY7tPFEM
qjeFDxgFaJXYzUYc/rGn5CmO/MuMR2aLAqeTH+Bm8Uvwb4/kG0cacn2vdrysK4bc
OMqxD4+9a1fiVbrKWWshHJYg10WwQb3aZ4y+O/GW+E6fsqe+Og5Yl6jYm+nuWfnu
wA+50dCX/N2IY61/0JWbHywWCU3JYe9OclJzi4lDoYxkMn7Se0h1wPoMJiDKDUm+
KAoeOK8AMdO0VhHF7JV20hKefQ452geueB8V9pZY22snBuGq3MCM3w==
=QA9y
-----END PGP SIGNATURE-----