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

Hello,

On Nov 25, 2007, at 12:43, Marco Trillo wrote:

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

Yuck. Not surprising though, Apple OF has never been very consistent  
on anything :/

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

Yeah, we'd probably need something to parse that sound-objects  
prioperty in order to find out which output is in use.

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

Yeah, and to make things worse they-re sometimes relative to gpio,  
sometimes to mac-io

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

I only have an iBook G4 with a snapper, all my other macs have some  
sort of awacs.

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

*nod*

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

It's either duplicating (some) code or annoying special cases all  
over the place. Yay Apple.

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

That sounds like the i2s handling really should be part of the codec  
even if it's shared by a couple drivers.

have fun
Michael

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

iQEVAwUBR0n8YspnzkX8Yg2nAQJQ9AgAm8eiLkKZO3KsefSdHDi/9QHGXtsaHJ4w
bJMFrAzXOGwjyDrb4VFyXzbkdPOOo+g/3PN6bkoix5tCvRhRYUocffjVZeayBSkY
Lnsygt1gOToNLcHCiofG3vbnoFSE7jGD9NHawTmOxtwb41EG6Z8OLtjDD1Lu0n9G
wYOmkWQmqUgV0dKzW286lCxpA/lGco6Qp71dgTkzsSpsn+M/qrHYfAoNWUgmumUG
xdfbEwlqw//VWmJKqNpd/aHl4cU6bTxLlMbKhw7GnbSghfnLQTzIhW+CthshFLWg
53yzKyeinoG8ozmdn//XsBa6W0S7hKo4B+RshPsa3GC7HHcPlsAozg==
=ugyb
-----END PGP SIGNATURE-----