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

Hello,

On Dec 8, 2007, at 12:47, Marco Trillo wrote:

> On 12/8/07, Michael Lorenz <macallan@netbsd.org> wrote:
>>> I don't know i2s well enough to have a strong opinion here - my gut
>>> feeling is that the gpios depend more on i2s than anything else
>>> though. Also, I'm not so sure anymore that putting the DMA stuff
>>> into a separate driver is such a good idea - too many layers. Maybe
>>> just have i2s and awacs pull the DMA code in as a dependency?
>> ...
>>> I think the codecs know best which gpios they need and where to
>>> look for them. Then again, unifying i2s and awacs doesn't look all
>>> that straight forward anymore.
>>
>> Hmm, that doesn't sound right.
>> So, I'm no longer sure that unifying i2s and awacs will work right, I
>> think factoring out the DMA code and pulling it in as dependency is
>> the least painful way here. That said, I hereby drop my reservations
>> about putting the gpio stuff into i2s, I think you're right about
>> having all that in one place. I would still like the sound-objects
>> parser to be mostly abstract so it can be used by both i2s and awacs.
>
> I like this approach too. Maybe all of the dma-related variables  
> can be
> grouped into a structure so at least the DMA interrupt handler can  
> be the
> same for both awacs & i2s (and possible future drivers, like the  
> 'burgundy'),
> without intermediate layers. The rest of the functions will  
> probably need
> a bit of indirection.

Sounds good to me.

> I have already the sound-objects stuff working with the i2s driver.  
> This also
> paves the way to have nice input device selection, since the sound- 
> object stuff
> makes little diference between the two. In fact the 'extint-gpio4'  
> detect that
> shows in the dmesg below corresponds to the line in port.
>
> i2s0 at obio0 offset 0x10000: Apple I2S module
> i2s0: interrupting at irq 1
> i2s0: interrupting at irq 2
> i2s0: using 'sound-objects' property
> i2s0: found GPIO detect <extint-gpio15> at PA 0x80000067
> i2s0: interrupting at irq 61
> i2s0: found GPIO detect <extint-gpio4> at PA 0x8000005c
> i2s0: interrupting at irq 50
> i2s0: object[0]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
> enabled:false
> i2s0: object[1]: direction:output, type:<ispk>, mask:0x2, match:0x0,
> enabled:false
> i2s0: detect[0]: type:gpio, mask:0x2, match:0x0, devices:0x2
> i2s0: detect[1]: type:gpio, mask:0x2, match:0x2, devices:0x800
> [...]
> i2s0: connecting to codec0
> i2s0: resetting codec
> i2s0: object[0]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
> enabled:false
> i2s0: object[1]: direction:output, type:<ispk>, mask:0x2, match:0x0,
> enabled:true
> audio0 at i2s0: full duplex
>
> Then if I plug headphones:
> i2s0: object[0]: direction:output, type:<hdpn>, mask:0x2, match:0x2,
> enabled:true
> i2s0: object[1]: direction:output, type:<ispk>, mask:0x2, match:0x0,
> enabled:false
>
> The i2s driver now builds the 'output select' mixer dynamically by
> showing only the
> devices that are really present (in most cases headphones plus
> speaker, but there
> are apparently machines which also have a lineout).

Yeah, that's mainly what awacs would use it for - figure out what  
additional input is in use for what. The gpio-related information it  
provides may still be useful but as far as I can see the machines  
that need to be special-cased here don't have sound-objects.

> About input devices, I think the same function that parses the
> 'output' property can parse the 'input' property -- it just needs  
> to set ao->ao_direction to AO_INPUT
> instead of AO_OUTPUT and it should just work.

*nod*

> The problem with input devices is matching for example 'line' or
> 'microphone' to what the codec understands. For example the TAS300x  
> has 'input A' and
> 'input B', and input B can be set to mono mode using only one of  
> the channels -- left or right.
> The daca has also two inputs, aux1 and aux2...
>
> But this should be solved simply by implementing this in the codec  
> driver so i2s doesn't
> need to worry about this: it simply calls the codec method.

Yeah, I think the codec driver is the right place for that - it knows  
what the hardware can support so mapping that to whatever we get from  
sound-objects should be trivial in most cases.

> Talking about awacs and loopthrough I remembered the TAS3004(*) can
> also support a loopthrough-like function by configuring the 'mixer  
> gain' register. It
> can also mix the normal output with the input. So I think I'll  
> provide a mixer item
> to set the loop-through volume, similar to what awacs provides.

I think snapper already uses the mixer gain register as some sort of  
master volume control.

> About the G5 and the FCRs... it seems that newer machines, including
> some of the late G4s, include platform functions in the mac-io node  
> to perform the functions
> that are now done manually by the i2s driver. For example a  
> 'platform-do-clock-enable' property that
> has a bytecode to set the appropriate bit in the FCR register.

Calling OF methods is expensive but might be a useful fallback if we  
don't know how to handle the FCR for some reason.

> What I don't know if the current FCR stuff in the i2s driver will  
> work as it is on the G5. It may work if the mac-io of the G5s is  
> compatible with the KeyLargo.

My guess is it will be different, at least on newer G5s.

> For example Intrepid and Pangea's should work since they are  
> KeyLargo-like...

Eh, I have an Intrepid in my iBook but the mac-io identifies itself  
as KeyLargo. Same with the G4 - says it's a KeyLargo without any  
further information.

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

iQEVAwUBR1rkZ8pnzkX8Yg2nAQIBJAgAmVIUtnXYiU2fmLMc+dKda4OAdHEdbvSv
cpu+ge5ceSNKUVZ0rAP7ECY/JflzSvCBqtEx4M0NFsH5tRUYHApgTIRx29dhbJ9h
N3sIlTZxByVKCXf8AnKbwR5j9F2mraqn7Uz7tAA5vPsheoP5xK40SU/VCaDpkUdt
tblVMYmka8344PY/k4Jjhd47uzem4RHzDl0UNLi2tW6jxGOHKT6unUPdoxDRjW0I
pcFs/Cs14ElHqoQF9KwExkNIJ40qIes4cE5k4sLL041EGbud7PKDhlAjL3MWVa4l
5S6NiZPzI/bGUZRcmZP0uj8U6FX09UrKsJEwgHznUuiYKrGbpT9S0A==
=O+xS
-----END PGP SIGNATURE-----