Re: new sound driver

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

On Thu, 2006-03-23 at 08:50 +1100, Benjamin Herrenschmidt wrote:

> that would make soundbus totally pmac specific, in which case you should
> call it aoa-bus or something like that.

Yeah, well, I just did it differently now with the dbdma stuff done by
the i2sbus objects.

> Regarding your previous question well... I think the soundbus can create
> the pcm streams. Alsa has 2 levels: PCM objects and PCM substreams. We
> need the former. Substreams are used when the harware has several
> streams that are hw mixed to the same mixers which isn't the case with
> apple layout. When we have multiple i2s busses, they are really
> independant with separate codecs, frame rates & formats etc.. thus
> separate PCM objects.
> 
> I think the sound bus should create the PCMs. Now I don't remember from
> Alsa API but do we need to know the available rates in advance ? In that
> case, we may want to have the bitmask provided by the fabric (from the
> layout array for example).

Right. I was still confused on the notion of PCM streams vs. objects.
Got that sorted out, and yes, it is creating pcm objects.

> I'm also not sure how Alsa handle changes there. For example, if you
> plug a digital input, the entire bus where this input is has to be
> clocked from that, thus limiting dynamically what rates/formats are
> available. I'm not sure Alsa API can cope with that yet.

Well, if we're unlucky the Alsa API must just return -EINVAL to users
trying to use other bitrates, if we're lucky then it copes better ;)

> > Actually, this isn't quite possible. On the newer machines where you
> > have two codecs on the same i2s bus, we need to have the layout fabric
> > create the one pcm stream and have it ask the codecs what it should
> > advertise. Then it needs to advertise the lowest common denominator of
> > the multiple codecs... (Or can alsa handle pcms that change their
> > supported rates/formats?) Then it refers to the soundbus functions for
> > actual data transmission.
> 
> The problem is that codec objects have to be created asynchronously
> since they use asynchronous i2c discovery. Unless you instanciate them
> all but simply mark them "offline" and then mark them "online" later
> when the hardware actually shows up. That is fine except for .. topaz
> where you need to access the hw to know the chip type, thus you can't
> really know everything you need early enough (or maybe you can ...)

What I'm currently thinking of is creating one PCM per codec, and then
if you can't use them at the same time just forbid access to it.
 
> Just sleep on it for now :) We definitely need a "core" module that
> handles all of the gpio mess. ..

Yeah. Haven't even opened that can of worms yet...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]