Re: volunteer to fix ALSA for every PPC subarch found! :-)
- To: Martin-Éric Racine <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: volunteer to fix ALSA for every PPC subarch found! :-)
- From: Benjamin Herrenschmidt <email@example.com>
- Date: Tue, 09 Aug 2005 10:47:13 +0200
- Message-id: <1123577234.30257.169.camel@gaston>
- In-reply-to: <Pine.LNX.firstname.lastname@example.org>
- References: <Pine.LNX.email@example.com> <1123491697.30257.140.camel@gaston> <Pine.LNX.firstname.lastname@example.org>
> > I can provide almost all the necessary informations. I have specs for
> > most chips, and those I don't have spec for have Darwin drivers that
> > should tell us all we need to know.
> > There are several issues though, as I wrote earlier. More than just
> > "fixups", we need some real re-architecture of the driver. We need to
> > properly separate the transport layer (can be davbus or i2s) from the
> > codecs, deal with multiple codecs (G5s have that typically) and multiple
> > transport busses (some machines have codecs on the 2 i2s interfaces), we
> > need to properly reprogram the i2s clocks, we need to do clock switching
> > when fed with a digital input signal, etc...
> > Also, on pretty much all recent machines, the only info that you have
> > about the sound hardware is an "ID" value in the device-tree. Apple code
> > matches that value with some XML structure in the driver property list
> > that indicates what set of codecs etc... to use.
> > I don't have time to actually do the work, but I'm willing to help.
> Adding the above info as a comment to the ALSA BTS bug I opened would already be
> a tremendous start. :)
Please do it for me, I can't be bothered opening yet another account to
some random BTS ...