Hi,

On 12/3/07, Michael Lorenz <macallan@netbsd.org> wrote:
> > 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?

That is probably the best approach. In fact some newer models
abandoned the sound-objects property... so we have models which use
only the sound-objects, models which use both sound-objects and some
gpio nodes, and models which don't have sound-objects and use only
gpio nodes. What a mess :-)

I have a first version of the parser which uses the sound-objects
property to get a list of available objects and detect the active
devices. The parser itself is general and should work with any device,
but the problem is that the driver (awacs or i2s, or even the codec)
has to have support for the devices to mute/unmute them (or configure
their volumes).
So I've made it use a callback, so the driver registers callbacks only
for the devices it cares about.

At the moment I've tested it with the awacs driver in a screamer-based
G4 (which is also a plain screamer with only an internal speaker and a
headphones port). The good thing about the sound-objects property is
that it eliminates the need to hardcode different GPIO wirings for
different machines.

awacs0 at obio0 offset 0x14000: Apple Screamer
awacs0: using 'sound-objects' property
awacs0: object[0]: direction:output, type:<ispk>, mask:0x2, match:0x0,
enabled:false
awacs0: object[1]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
enabled:false
awacs0: detect[0]: type:sense, mask:0x2, match:0x2
awacs0: detect[1]: type:sense, mask:0x4, match:0x4
awacs0: detect[2]: type:sense, mask:0x1, match:0x0
awacs0: interrupting at (cirq, oirq, iirq) = (24, 9, 10)
awacs0: object[0]: direction:output, type:<ispk>, mask:0x2, match:0x0,
enabled:false
awacs0: object[1]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
enabled:true

I booted it with the headphones plugged, so it prints 'enabled:true'
on the 'hdpn' device. If I unplug the headphones it enables the
speaker:

awacs0: object[0]: direction:output, type:<ispk>, mask:0x2, match:0x0,
enabled:true
awacs0: object[1]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
enabled:false

Currently it only supports output devices, but it should be easy to
support input devices too.

Now I have to find a good way to implement the fallback series in the
'i2s' driver.
The parser is in an external library so both awacs and i2s can use it.

I have uploaded the current version and an awacs driver which uses it
if available:
 http://www.telefonica.net/web2/marco2z/aoa.c
 http://www.telefonica.net/web2/marco2z/aoa.h
 http://www.telefonica.net/web2/marco2z/awacs.c


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

I hope the parser is extensible enough. If the driver has support for
a device, it just needs to register a callback with
aoa_register_callback() with the device type to be informed of the
device state.

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

In models which have 'gpio' nodes, the sound-objects references the
node via its name (extint-gpioXX) and the node contains an
'interrupts' property.

However, in this case there are no gpio nodes. Oddly enough, the
sound-objects still references the gpio via a name, which is
'extint-gpio12' (but it also provides the address, which other
machines with gpio nodes don't do).

Other machines also use different extint-gpios (for example my
snapper-equipped eMac uses 'extint-gpio15' for output detection and
'extint-gpio4' for input detection).

Thanks for the reply,

Greetings!
Marco.