Subject: macppc audio (was Re: autoconf(9) tree in an odd hardware arrangement )
To: Marco Trillo <marcotrillo@gmail.com>
From: Michael Lorenz <macallan@netbsd.org>
List: tech-kern
Date: 12/03/2007 09:25:47
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Dec 3, 2007, at 06:25, Marco Trillo wrote:

> On Nov 25, 2007 11:51 PM, Michael Lorenz <macallan@netbsd.org> 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.
>>> 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.
>
> To make things worse, I discovered that some I2S-based models, in
> particular the 'daca'-based ones (which seem to be the first models
> that used I2S) don't have any `gpio' nodes at all.

Yeah, Apple OF and consistency - guess we should have expected that.

> So I think that in order to find the GPIO control to detect the
> headphone presence the only way is to parse the `sound-objects' node,
> which contains the relative address and the sense-match bits. Other
> alternative is to hardcode the address (and the sense bits), which is
> what the Darwin driver does, but the `sound-objects' property is
> probably the way to go, especially since some screamer-based models
> also have it.

Or use all of that as a series of fallbacks? My G4 has a screamer and  
the sound-objects property but since it's a plain old screamer  
without any bells & whistles the awacs driver does The Right Thing(tm).
Probably look at sound-objects first since we may need other  
information from there as well, if we don't find the gpio there look  
for nodes and if that fails use hardcoded values?

> So I'll try to write a parser for the sound-objects. I have collected
> device trees of the models which have the property so it'll be easy to
> test that it works before including it in any driver.

I have an 800MHz iBook G4 and a Gigabit Ethernet G4 in case you need  
more datapoints. The sound-objects parser would be interesting for  
some awacs models as well since screamer has additional inputs over  
plain awacs which may or may not be connected to anything ( like  
audio from the internal modem or PCMCIA, currently they're ignored  
since I don't have any hardware that actually uses them. My PB3400c  
has PCMCIA but no such properties and a plain awacs, no idea if audio  
from PCMCIA goes anywhere, I have no card that uses it )

> Another problem I've found with such models is that neither the device
> tree nor the `sound-objects' proprety mention any interrupt for
> detecting the port change. I looked at the Darwin driver but it's
> weird since it uses polling... however it does mention in a comment
> that it should use an interrupt, so I suspect that it does generate an
> interrupt.
> What do you think?

Hmm, maybe it's always the same interrupt so we can guess ( and print  
a warning ) if there's no other information available?

> [PS: Perhaps I should have changed the subject, since this is not  
> related to the autoconf question now]

Done :)

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

iQEVAwUBR1QR7MpnzkX8Yg2nAQIqyAf+NQMWtO76DzSUmci53DQ34Wnir0ltvKFx
P+gOHkO4DKJdG/btLhFBggVcGshi1WAT2ykKnKyuxNWF1s/KvsHytEbbs977qXaT
NO7/qKxKza7XBh53jzeHxVl4cp0JrUBw9d7/zT6n1kieEFum89xQ6Pc2FD9gDNfh
UF+Ks4ysGLxJtomsh3HWLBVj/SAT7YEQ6rd1RmJfAznu1jYJTn3nFD2CB+rY/xab
QUC1u0sU0HdB+Sd/2Z/CBCxh/EGhUnC6i6oiFdDwbaq7ON4tFahqWtAbEkd8aPc9
TEOx1FWv/pw8faJpl0mqx1uVg+SI+i0m63zFWpgpk18e9STEs5TOHQ==
=5+gF
-----END PGP SIGNATURE-----