Hi,

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.

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

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.

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.

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.

(*) and perhaps the TAS3001 too

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.

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. For example
Intrepid and Pangea's should work since they are KeyLargo-like...

Greetings,
Marco.