[PATCH] Fix Alsa issues including Oopses with OSS emulation

Benjamin Herrenschmidt benh at kernel.crashing.org
Fri Dec 24 01:03:00 EST 2004

On Thu, 2004-12-23 at 23:25 +1100, Dean Hamstead wrote:
> given the variety of hardware would it be worth splitting up snd-powermac?
> how easily can code be used from darwin?

Code cannot be copied "as-is" but it's definitely a good source of
informations. Also, the various codec chips used on recent machines do
have publically available documentations.

What I would suggest is to split the driver for all the pre-i2s machines
(awacs, screamer & burgundy basically) from the i2s based ones (daca,
tumbler, snapper, plus the g5 new digital stuff).

The actual dbdma code for doing the actual sample transfer & buffer
management should be split in a separate file and shared by all

For the i2s based machines, we need a better mecanism. We need, I think,
to have a file with i2s stuffs (for dealing with setting the i2s sample
format & clocks, which we don't do properly yet), separate files for the
actual codecs (either analog or digital), and a "hub" part that puts
everything together.

The thing here is we need to deal with more than one codec on the same
bus (the g5 has both a tas3004 for analog and some other digital chip
for spdif) and we need to be able to change the clock source (when a
digital input is plugged, the whole clock net is to be sourced from it).

So I would suggest writing a "generic" interface structure (a structure
with function pointers etc...) for the codecs. The "core" code would
then match against the mac-io device of the i2s bus (it will match twice
but the second bus is used only by the modem and can be ignored for now)
or with whatever snapper/tumbler/AOA device node is below. It would
decode the "reg" property in there (slightly different on the G5s) and
instanciate the i2s driver the dbdma engine (PCM) and the appropriate
set of codec's. The codecs can register their own mixer controls
individually, but the "core" stuff need to deal with clock switching.


More information about the Linuxppc-dev mailing list