Subject: macppc audio (was Re: autoconf(9) tree in an odd hardware arrangement )
To: Marco Trillo <firstname.lastname@example.org>
From: Michael Lorenz <email@example.com>
Date: 12/03/2007 09:25:47
-----BEGIN PGP SIGNED MESSAGE-----
On Dec 3, 2007, at 06:25, Marco Trillo wrote:
> On Nov 25, 2007 11:51 PM, Michael Lorenz <firstname.lastname@example.org> wrote:
>>> On 11/25/07, Michael Lorenz <email@example.com> wrote:
>>>>>> The intention was to factor out all the DBDMA goo that's more or
>>>>>> 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
>>>>> 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
> 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----