snd-aoa: new apple sound driver

[Johannes Berg]

On Wed, 2006-03-29 at 10:40 +1100, Benjamin Herrenschmidt wrote:

> The GPIO stuff is a bit can-of-worms-ish ... we need at least 2
> different implementations for machines using "old style" direct GPIO
> access and machines using platform functions. So we may need a gpio
> "driver" with 2 instances there.

Yeah, was thinking like that too.

> I think we need to hook that with the input/output net... basically we
> just say things like mute/unmute(id) and the gpio "layer" sort of
> matches the input/output "id" with whatever gpios it has at hand. That's
> also why I think your input/output IDs should have separate entries for
> combo connectors vs. analog line out (at least you used not to, I
> haven't looked at the latest code).

Note sure what you mean here...

> Then, the core would get events from interrupts (or clock switches from
> the codecs) via a yet-to-be-defined call and would react by calling the
> various mute/unmutes accordingly for available inputs and outputs on the
> bus where the event occured.

Ah but you see, the codec actually "mutes" the digital output when it
isn't usable, and the codec also mutes the analog output when we
transfer compressed data. We don't amp-mute in that case, but just from
the codec, so no analog audio is even leaving the codec.

> For things like headphone/speaker automute, I think we need a kind of
> tristate.. either that, or we need a bit mask of mute conditions. When
> any of them is set, it's muted. That way, the "user" mute control sticks
> regardless of the automute action or temporary mute to analog outputs
> because, for example, the digital input lost its clock and we are
> switching (we need to mute to avoid "clics").

Yeah. I have to think a bit about an in-snd-aoa api for all this.

> Hrm... So my feature calls are doing too much at once... (they both do
> the clocks and the cell enable). I don't do clock refcounting like Apple
> does tho, thus the main clock sources are always enabled. So I think all
> you have to do is toggle the I2Sn_CLK_ENABLE bits ...

Hmm. How do I get at those bits? Clock refcounting would be nice too,
along with proper power save management...

> Can you verify if all machines that have digital inputs (thus all
> machines for which you may need to do that kind of clock switching) also
> have working platform functions for doing so ? If they do, then it's
> really just a matter of calling those. If not, then we can either
> ioremap the FCR's in the driver and play with them (evil solution +
> possibly locking problems) or add a feature call.

The former isn't feasible since I need to do clock switching even on
analog-only machines to support more sample rates than the 44.1 KHz that
the firmware sets for the boing sound :)

> In the later case, you add a feature call in pmac_feature.h and the
> appropriate entry in the table in feature.c and then you can toggle bits
> as you wish with appropriate locking (look at eixsting code in there). I
> can give you more details on irc if you need.

Ok. I definitely need more details I think.

> But it would be nice if it could all be done with platform functions
> instead.

Hardly possible though, see above.

> > Modalias situtation. I played some tricks: i2sbus depends on soundbus

> Yeah :) There might be some issue with the macio automatching from
> userland, not sure yet, could just be missing bits in hotplug scripts.

macio automatching is working, i2sbus loads, but the latter modules
don't. I guess there's a userland issue in that it doesn't pick up new
devices that are added to /sys while it is loading another module.

> > Recording. There's code to record sound, but it doesn't do anything on
> > my machine. I have no idea why.
> 
> What machine ? The quad ? maybe you need some gpio manipulation or maybe
> you just didn't get something right in onyx ... I'll try later. 

Yeah the quad. I was thinking that no matter what, I should at least be
recording silence, but my userland app (arecord) doesn't get *any* data
at all. It's like the dbdma controller isn't doing anything.

>  - macio_device gets the suspend resume event. That is, the i2s busses
> basically. That code should forward to all attaches sub-busses which
> then dispatch to codecs.

right.

>  - ordering of things should be: mute all, stop alsa, stop codecs
> (enable whatever internal power management mode they may have), stop
> clocks, disable i2s cells.

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.

> I'll play with adapting the whole stuff to older machines, I have plenty
> of those :) We also need to implement a davbus module, so make sure you
> don't have too much i2s-related assumptions in your core.. No timeframe
> for that though, I'm fairly busy with other things at the moment

I don't think there are any i2s assumptions. Well, except that on any
given soundbus_dev, you have at most one input and one output stream... 

> It's also a complicated thing because of the need to deal with old
> machines and the need to coordinate properly & serialize... things like
> interrupts or events from the codec should, if possible, use alsa hidden
> controls or whatever other ways to properly serialize, if possible, be
> run at task level (from a work queue) and things like that (due to the
> need for delays etc...

Good points.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060329/1a2b851e/attachment.pgp>