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

Hello,

On Dec 6, 2007, at 11:10, Marco Trillo wrote:

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

Yuck. I wish they could settle for one thing instead of shuffling  
everything around with each release.

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

Nice :)

> So I've made it use a callback, so the driver registers callbacks only
> for the devices it cares about.

Why not put them into device properties? So we just call the parser  
and then whoever needs information can look them up without caring  
where it came from. That way we can also provide information for  
models without sound-objects property.

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

Neither the PB3400c nor the beige G3 have sound-objects but both need  
special wiring for their gpios ( it's reversed on the powerbook and  
uses a different pin on the G3 as you probably saw in awacs.c )

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

Very nice :)
I'm not sure if we should automatically switch the input channel when  
something's plugged into line in or microphone - some models have CD  
input and a built-in microphone.

> 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'd say turn it into properties so i2s, awacs and whatnot doesn't  
have to deal with 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

Thanks, I'll look at it.

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

I'm not sure I like the callback approach.

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

What I meant is - is it always the same IRQ line? Or at least on a  
majority of devices so we can guess if there's no other information  
available?

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

iQEVAwUBR1gkqcpnzkX8Yg2nAQI9vgf/YDJXCzSK3Yxb55VNryU4iLdh2AUknnuB
HZ35nTO6RUm1jBPKPWFmS3qAVFsaffF/U51hADSDbDwdR8zkD5kS9sFDzfSngchc
JKhQ7pwIQCK+Kitk8iKVLwGsvkPLPyN8kwa1ROnRZsUFlX9jHEz7QaQhKSJefeis
Ukcue/0LY/TzErjeSgojETuL6HRiVjMW9hdCDZpJ+SJDKKtYQRUdiknInjWu0wer
qicF+qMrcHWPVF7l/me7BuIZeHsxfBceTEm8FkFtvpKbmVEMOAnaT8UxIpa1EwR+
8dxWLlkCMsxYOQ0YYzp6VZCEXW+33pmwxmDd46o4AFNN+fWKIEdQTw==
=FarP
-----END PGP SIGNATURE-----