From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dean Hamstead <dean@bong.com.au>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
"debian-powerpc@lists.debian.org"
<debian-powerpc@lists.debian.org>
Subject: Re: [PATCH] Fix Alsa issues including Oopses with OSS emulation
Date: Thu, 23 Dec 2004 15:03:00 +0100 [thread overview]
Message-ID: <1103810580.19814.18.camel@gaston> (raw)
In-Reply-To: <41CAB92A.4050808@bong.com.au>
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
implementations.
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.
Ben.
next prev parent reply other threads:[~2004-12-23 14:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-22 18:13 [PATCH] Fix Alsa issues including Oopses with OSS emulation Benjamin Herrenschmidt
2004-12-22 18:35 ` Benjamin Herrenschmidt
2004-12-23 6:25 ` Sven Luther
2004-12-23 6:55 ` Benjamin Herrenschmidt
2004-12-23 11:36 ` Sven Luther
2004-12-26 12:05 ` Sven Luther
2004-12-22 23:36 ` Martin-Éric Racine
2004-12-23 0:15 ` Dean Hamstead
2004-12-23 8:00 ` Benjamin Herrenschmidt
2004-12-23 12:25 ` Dean Hamstead
2004-12-23 14:03 ` Benjamin Herrenschmidt [this message]
2004-12-23 6:54 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1103810580.19814.18.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=dean@bong.com.au \
--cc=debian-powerpc@lists.debian.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).