Subject: Re: snd-aoa: new apple sound driver

From: Johannes Berg <[email-masked]>
Date: Thu, 30 Mar 2006 16:13:15 +0200

On Thu, 2006-03-30 at 10:11 +1100, Benjamin Herrenschmidt wrote:

> Yes, but we should probably still mute the amps... especially when using
> a separate analog codec (like tas3004 + topaz setups).

Hah ok, are those on the same i2s bus? Hrm. No actually, I don't think
we *have to* mute the amps since in that case, we really should be
turning off the tas3004 anyway so it doesn't even try to create analog
output from the digital 'noise' it's getting. That shouldn't be too hard
to add in that case. Though, the current framework can't do that.
Bugger. I'll have to think about how to export the correct capabilities
to userspace, onyx is currently playing some tricks to get it right :/

Ok, this isn't hard to handle. Right now, we intersect all possible
formats that are registered in all codecs on a soundbus device. This has
to change to intersect all transport_infos within a codec, and then
combine these over the codecs. Something like:

$$\mbox{allowed} = \bigcup_{c \in \mbox{codecs}} \, \bigcap_{t \in \{\mbox{transfers of c}\}} t$$

(http://johannes.sipsolutions.net/snd-aoa-formula)

Then the codecs are notified whichever format userland chooses, and can
then disable themselves if necessary. That should work fine. Initially,
I assumed just doing a big intersection would be ok, but it can't work
across codecs. Within a codec, it is manageable, look into onyx :)

> I was thinking about an event based mecanism... snd-aoa has an array of
> all inputs & outputs, which codec handles them, and, if relevant,
> handles to connector detect GPIOs and amp mute GPIOs.

Yeah, sounds good. Except that the fabric needs the array.

> Clock refcounting will be done ... some other time :)

:)

> And you need to turn the clock off for that ? All the FCRs are useful
> for you is to turn the clock input on and off, you shouldn't need that
> except when switching to an external clock no ? And even then ... AFAIK,
> Darwin AppleOnBoardAudio isn't playing with those FCRs at all unless
> I've missed something, all it does is to call in PowerI2S via platform
> calls to AppleKeyLargo which is equivalent to the existing pmac feature
> call...

I need to turn off the clock to the cell, not the clock. Something that
I'm currently doing by calling the platform cell-enable function. I
think that's all that is needed to be able to change the data word sizes
and serial format registers. Will look a bit more in darwin, it's
commented in the legacy audio stuff I think.

> How so ? autoloading only works for devices on a bus type known by the
> autoloader.. like macio. Thus other modules won't autoload unless you
> have a bus type that supports the loading stuff for hotplug and
> appropriate scripts... macio has such things, I don't think it will
> handle your soundbus though without some changes, and the modules
> themselves must expose via tables what they match on. I'm not sure I
> fully understand what you are expecting there

Ah heh, I thought the userland would just try to load modules for *any*
device that shows up based on the modalias, i.e. "device shows up
in /sys/devices" => "modprobe `cat /sys/device/<new>/modalias`"

> Maybe you aren;t getting the right addresses for it from OF :) I told
> you there are some dodgy things going on with the device-tree ... I
> think tx is at 0x8000 and rx at 0x8100 inside the MacIO ASIC (thus
> 0x8008000 and 0x8008100). Another possibility is that you are
> programming it wrong or haven't enabled something somewhere in the codec
> to actually emit data :) I'll have a look as soon as I manage to find
> some time. Maybe on the plane this week-end.

If the codec wasn't emitting data, then I should still record silence on
the i2s bus, no? Clocking is done by the i2s cell. But I'm not too sure
about this, I don't know where the problem is. I think the address is ok
though.

> > yeah. It's slightly more complicated unless we assume that the control
> > interface (i2c) is always available, because we'd also get power
> > management through the i2c device stuff.
> 
> It is always available. Just ignore PM callbacks from i2c

Ok. But seeing that the soundbus stuff is generic enough, I may want to
still handle that kind of situation. Or maybe not. Haven't decided yet,
probably depends on how hard handling it really is.

johannes