snd-aoa: new apple sound driver
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
Quoted 8 lines
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").
Quoted 8 lines
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.
Quoted 9 lines
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 ...../modaliasworks 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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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
Quoted 4 lines
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.
Quoted 4 lines · Benjamin Herrenschmidt
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.
Quoted 6 lines
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...
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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_ENABLEbits ...
Hmm. How do I get at those bits? Clock refcounting would be nice too, along with proper power save management...
Quoted 6 lines
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 :)
Quoted 4 lines
In the later case, you add a feature call in
pmac_feature.hand the appropriate entry in the table infeature.cand 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.
Quoted 2 lines
But it would be nice if it could all be done with platform functions instead.
Hardly possible though, see above.
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
-
macio_devicegets 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.
Quoted 3 lines
- 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.
Quoted 4 lines
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...
Quoted 6 lines
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
Quoted 2 lines
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 :)
Quoted 9 lines
Quoted 4 lines
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).
Quoted 8 lines
Quoted 6 lines
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...
Quoted 1 line
From these, snd-aoa can "do the right thing", do mutes, unmutes, etc..
when needed.
Quoted 7 lines
Quoted 4 lines
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_ENABLEbits ...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 :)
Quoted 10 lines
Quoted 6 lines
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.
Quoted 11 lines
Quoted 4 lines
In the later case, you add a feature call in
pmac_feature.hand the appropriate entry in the table infeature.cand 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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
-
macio_devicegets 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.
Quoted 7 lines
Quoted 3 lines
- 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
Quoted 7 lines
Quoted 4 lines
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.
Quoted 10 lines
Quoted 6 lines
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
Quoted 2 lines · Benjamin Herrenschmidt
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 :)
Quoted 3 lines
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.
Quoted 1 line
Clock refcounting will be done ... some other time :)
:)
Quoted 7 lines
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.
Quoted 7 lines
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"
Quoted 7 lines
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
0x8000and rx at0x8100inside the MacIO ASIC (thus0x8008000and0x8008100). 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.
Quoted 5 lines
Quoted 3 lines
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
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.
Quoted 5 lines · Benjamin Herrenschmidt
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.
Quoted 2 lines
If I then try to rmmod it, the
machine blows up. Haven't had time to track that down at this point.
That sucks.
Quoted 1 line
Appart from that, it works and I can play morse with myh SPID output :)
Heh yeah, we did that too :)
Quoted 3 lines
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
Quoted 10 lines · Johannes Berg
Quoted 5 lines · Benjamin Herrenschmidt
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!
Quoted 8 lines · Benjamin Herrenschmidt
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: deviceregistration 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
Quoted 3 lines · Benjamin Herrenschmidt
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
Just FYI if anyone's thinking about using this:
Quoted 1 line
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.
Quoted 1 line
Clock setting.
Done except for master/slave switching.
johannes
Quoted 2 lines · Johannes Berg
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