snd-aoa: new apple sound driver

snd-aoa: new apple sound driver

[Johannes Berg]

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

Hi,

I think I accomplished most of the things I wanted to accomplish now :)

snd-aoa is now split into a core module and snd-aoa-fabric-layout,
snd-aoa-codec-onyx. I'm going to write a snd-aoa-codec-tas3004 soon, so
that I can use the new code here on both of my machines.

What's left to do? (in order of importance to me)

Locking. There are no locks at all and it still works! Locking shouldn't
be too hard, most things are implicitly serialised anyway, but there
definitely must be some locking. I'll revisit that, but probably not in
the next two weeks. Other sets of eyes always welcome.

GPIO stuff. Currently, the only GPIO I touch is the amp-mute one to turn
on the internal speakers. This is done in the onyx codec module which
obviously isn't the right place for it. This should be moved into the
layout fabric module which draws on some common gpio code to program the
GPIOs. Then it creates controls alsa for amp-mute etc. instead of
unconditionally turning it on, and also registers the interrupts for
headhpone detection etc.

Clock setting. I'm clueless as to programming keylargo in linux. Thing
is, I need to stop the clock to the i2s cell before reprogramming it's
serial format register, and this requires access to the FCR registers.
But I don't know how to get at them best. Need help here. Clock setting
also includes running the i2s cell in slave mode so we can have digital
input. The infrastructure for slave mode isn't too established yet, but
it should be easy to fit it over what is currently there in
soundbus.h/i2sbus.

Modalias situtation. I played some tricks: i2sbus depends on soundbus
but announces its willingness to be bound to the i2s OF thing that macio
exports on its bus, so i2sbus is loaded automatically. i2sbus creates
some soundbus devices that have a name based on the layout ID if
possible, which should in turn auto-load snd-aoa-fabric-layout which
declares its willingness to be bound to such devices. This doesn't
happen during boot, even though modprobe `cat ...../modalias` works just
fine. No idea, need help from someone versed with hotplugging.
But hey, it's already much much closer than snd-powermac ever was ;)

Recording. There's code to record sound, but it doesn't do anything on
my machine. I have no idea why.

Suspend. I have a plan for it, so before thinking about it you may want
to look at some old revisions of my code where a huge comment about
suspend is buried in soundbus.h (I removed it again because it wasn't
quite right any more, but still has the essence of what I intend to do).

Onyx digital output. Currently, onyx always declares that the digital
output is usable even if it is turned off, leading to a restriction in
the output formats you can play. Note that due to 'clock switching'
above, you can only play 44.1KHz currently anyway. But Onyx should make
that depend on the status of the control, and then lock the control if a
bitrate was chosen that isn't compatible with the digital output.

Make i2sbus compatible with old machines. I wrote i2sbus for new
machines only, it relies a lot on stuff that older machines may not have
in the device tree. So someone who has older machines should look into
it and give me patches.


Now, that said, it's actually working fine for just playing sound on the
internal speakers now :)
The GPIO stuff should be a fairly low-hanging fruit so if someone wants
to take it...

johannes

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

Re: snd-aoa: new apple sound driver

[Benjamin Herrenschmidt]

> GPIO stuff. Currently, the only GPIO I touch is the amp-mute one to turn
> on the internal speakers. This is done in the onyx codec module which
> obviously isn't the right place for it. This should be moved into the
> layout fabric module which draws on some common gpio code to program the
> GPIOs. Then it creates controls alsa for amp-mute etc. instead of
> unconditionally turning it on, and also registers the interrupts for
> headhpone detection etc.

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.

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).

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.

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").

> Clock setting. I'm clueless as to programming keylargo in linux. Thing
> is, I need to stop the clock to the i2s cell before reprogramming it's
> serial format register, and this requires access to the FCR registers.
> But I don't know how to get at them best. Need help here. Clock setting
> also includes running the i2s cell in slave mode so we can have digital
> input. The infrastructure for slave mode isn't too established yet, but
> it should be easy to fit it over what is currently there in
> soundbus.h/i2sbus.

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 ...

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.

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.

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

> Modalias situtation. I played some tricks: i2sbus depends on soundbus
> but announces its willingness to be bound to the i2s OF thing that macio
> exports on its bus, so i2sbus is loaded automatically. i2sbus creates
> some soundbus devices that have a name based on the layout ID if
> possible, which should in turn auto-load snd-aoa-fabric-layout which
> declares its willingness to be bound to such devices. This doesn't
> happen during boot, even though modprobe `cat ...../modalias` works just
> fine. No idea, need help from someone versed with hotplugging.
> But hey, it's already much much closer than snd-powermac ever was ;)

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

> 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. 

> Suspend. I have a plan for it, so before thinking about it you may want
> to look at some old revisions of my code where a huge comment about
> suspend is buried in soundbus.h (I removed it again because it wasn't
> quite right any more, but still has the essence of what I intend to do).

No time to look now, but the idea would be that:

 - 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.

 - 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.
 
> Onyx digital output. Currently, onyx always declares that the digital
> output is usable even if it is turned off, leading to a restriction in
> the output formats you can play. Note that due to 'clock switching'
> above, you can only play 44.1KHz currently anyway. But Onyx should make
> that depend on the status of the control, and then lock the control if a
> bitrate was chosen that isn't compatible with the digital output.

Yup.

> Make i2sbus compatible with old machines. I wrote i2sbus for new
> machines only, it relies a lot on stuff that older machines may not have
> in the device tree. So someone who has older machines should look into
> it and give me patches.

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

> Now, that said, it's actually working fine for just playing sound on the
> internal speakers now :)
> The GPIO stuff should be a fairly low-hanging fruit so if someone wants
> to take it...

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...

Ben.

Re: snd-aoa: new apple sound driver

[Benjamin Herrenschmidt]

BTW.. with the current stuff, if I install the modules and then do

modprobe i2sbus

I get a registration error in dmesg. If I then try to rmmod it, the
machine blows up. Haven't had time to track that down at this point.
Appart from that, it works and I can play morse with myh SPID output :)

Oh, and jackd seems to be unhappy even if I tell it to ignore the
capture channels, it's probably a problem with setting the sample
formats, I haven't looked in detail (yet).

Ben.

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

On Wed, 2006-03-29 at 15:01 +1100, Benjamin Herrenschmidt wrote:
> BTW.. with the current stuff, if I install the modules and then do
> 
> modprobe i2sbus
> 
> I get a registration error in dmesg. 

Hmm. What's the error? Can't reproduce this at all. Also, what machine?
It works fine on my powermac, even when i2sbus is auto-loaded due to
binding to the macio i2s device alias.

> If I then try to rmmod it, the
> machine blows up. Haven't had time to track that down at this point.

That sucks.

> Appart from that, it works and I can play morse with myh SPID output :)

Heh yeah, we did that too :)

> Oh, and jackd seems to be unhappy even if I tell it to ignore the
> capture channels, it's probably a problem with setting the sample
> formats, I haven't looked in detail (yet).

Hmm. I'll try to see what jackd does.

johannes

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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

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

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

Re: snd-aoa: new apple sound driver

[Benjamin Herrenschmidt]

On Wed, 2006-03-29 at 15:00 +0200, Johannes Berg wrote:
> On Wed, 2006-03-29 at 15:01 +1100, Benjamin Herrenschmidt wrote:
> > BTW.. with the current stuff, if I install the modules and then do
> > 
> > modprobe i2sbus
> > 
> > I get a registration error in dmesg. 
> 
> Hmm. What's the error? Can't reproduce this at all. Also, what machine?
> It works fine on my powermac, even when i2sbus is auto-loaded due to
> binding to the macio i2s device alias.

On the laptop.

Mar 29 11:11:51 localhost kernel: [  192.069735] i2sbus: found i2s
controller
Mar 29 11:11:51 localhost kernel: [  192.069752] soundbus: adding device
failed sanity check!
Mar 29 11:11:51 localhost kernel: [  192.069757] i2sbus: device
registration error!

Re: snd-aoa: new apple sound driver

[Benjamin Herrenschmidt]

> Note sure what you mean here...

I'll come back with a better explanation later :) I want first to have a
look at the most recent code and think a bit more :)

> > 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.

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

> > 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.

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.

Then it has an event notification callback that's called in by the codec
and the GPIO interrupts as a result of state changes, clock changes
etc...

>From these, snd-aoa can "do the right thing", do mutes, unmutes, etc..
when needed.

> > 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...

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

> > 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 :)

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 understand better what you are exactly trying to do here and
what FCR bits you want to toggle and when.

In any case, if you look at arch/powerpc/platforms/powermac/feature.c,
You can see how FCRs are manipulated. The macros MACIO_IN/OUT read/write
from FCRs and MACIO_BIC/BIS clear/set bits. LOCK/UNLOCK are used to
protect (it's just a spinlock).

Look specifically at g5_i2s_enable() for K2/shasta based machines. There
is also core99_sound_chip_enable() for Keylargo based machines (32 bits
machines) though the current version does nothing to the i2s bus, it
just toggles a GPIO known to control power to the codec on some
machines. That is, it assumes that i2s is enabled and clocked at boot.
The sleep code in there does switch it off on sleep and back on though
but that's a different thing.
 
> > 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.

Well, again, I have to understand better why here ...You shouldn't need
to touch the FCRs for normal frequency changes unless I missed
something.

> > > 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.

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

> > > 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.

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.

> >  - 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.

It is always available. Just ignore PM callbacks from i2c

> > 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... 

That should be ok.

> > 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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

On Wed, 2006-03-29 at 15:01 +1100, Benjamin Herrenschmidt wrote:

> Oh, and jackd seems to be unhappy even if I tell it to ignore the
> capture channels, it's probably a problem with setting the sample
> formats, I haven't looked in detail (yet).

Yeah, that's exactly it, it is trying to set 48KHz which I don't support
yet because I'd need to do i2s cell manipulations (serial format
register etc)

$ jackd -d alsa -r 44100 -S

starts for me. Not like it actually seems to work though...

johannes

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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

On Thu, 2006-03-30 at 09:53 +1100, Benjamin Herrenschmidt wrote:

> On the laptop.
> 
> Mar 29 11:11:51 localhost kernel: [  192.069735] i2sbus: found i2s
> controller
> Mar 29 11:11:51 localhost kernel: [  192.069752] soundbus: adding device
> failed sanity check!
> Mar 29 11:11:51 localhost kernel: [  192.069757] i2sbus: device
> registration error!

That is, umm, weird. But it shouldn't cause the module to crash either
way so I'll force it and look into it.

johannes

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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

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

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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

Just FYI if anyone's thinking about using this:

> GPIO stuff.

Started, you can now turn on/off the lineout/speakers/headphones (note:
powerbooks have line out, not headphones despite the symbol on them),
but automatic switching isn't done yet.
Only on new machines with PMFs though.

> Clock setting.

Done except for master/slave switching.

johannes

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

Re: snd-aoa: new apple sound driver

[Johannes Berg]

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

On Tue, 2006-03-28 at 14:10 +0200, Johannes Berg wrote:

> I'm going to write a snd-aoa-codec-tas3004 soon, so
> that I can use the new code here on both of my machines.

somewhat done, but I suggest you use it only on powerbook5,6 now where I
confirmed that it works (before I add more error checking, proper
handling of some cases etc.)

johannes

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