snd-aoa status update / automatic driver loading

snd-aoa status update / automatic driver loading

[Johannes Berg]

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

Hey,

Currently snd-aoa is known to work on the following machines:
* PowerBook5,8
* PowerBook5,7
* PowerMac8,1
* PowerMac8,2
* 17" October 2005 PowerBook (don't know the number)
* PowerMac11,2
* PowerBook6,8
and my
* PowerBook5,6

People with those machines are encouraged to use and stress-test it, it
also provides much better hardware support than snd-powermac, for
example it can actually reprogram the hardware if you have a 48KHz file
instead of having to digitally downsample it to 44.1KHz like required
with snd-powermac in most cases.

Note that the big missing feature is headphone/line-in/line-out
autodetection at the moment, so if you rely on that don't use snd-aoa
for the moment.

There are apparently some cases where it loses interrupts and then the
sound is garbled, my brother's investigating that at the moment, it
doesn't happen with my powerbook nor with my powermac.

Note that Topaz chips (optical input usually, though I think there's a
version where it does optical output too, probably the tas/topaz
combinations I heard about) are not supported yet as I don't have any
optical hardware except for my PowerMac11,2 and haven't written any code
for the required clock recovering and switching. If you want to see it
supported (and don't want to write the code yourself) your best bet is
probably to send me some hardware that has a controllable optical
output ;) If you want to write the code yourself talk to me first
please.

But the other reason for writing this mail is that I finally found the
last remaining bug that prevented sound module autoloading! :)

Now, when you boot, mac-io is already built-in so provides the i2s
device, which my i2sbus module binds to. Since udev synthesizes events,
i2sbus gets loaded automatically. Now, i2sbus creates uevents on its
own, with the layout number given as the MODALIAS. Hence, the layout
fabric module is loaded because it has an alias for all the layouts it
handles, and it in turn requests all the codec modules that it requires.
Also, this means that 'modprobe i2sbus' will suffice to get the driver
up and running without a reboot, provided that all modules are
installed.

Have fun,
johannes

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

Re: snd-aoa status update / automatic driver loading

[Tony Vroon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Berg wrote:
> Hey,
> 
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8
> * PowerBook5,7
> * PowerMac8,1
> * PowerMac8,2
> * 17" October 2005 PowerBook (don't know the number)

That would be the PowerBook 5,9 (confirmed working, that's what I have).

> * PowerMac11,2
> * PowerBook6,8
> and my
> * PowerBook5,6

> People with those machines are encouraged to use and stress-test it, it
> also provides much better hardware support than snd-powermac, for
> example it can actually reprogram the hardware if you have a 48KHz file
> instead of having to digitally downsample it to 44.1KHz like required
> with snd-powermac in most cases.

When writing documentation, you might want to add that the ALSA-plugin
in XMMS & Audacious requires a period time of 100ms instead of the
default of 50ms, as otherwise the sou*click*nd is n*click*ot ver*click*y
good.
(A look at the current code of that plugin, to see how the volume
control code can be fixed would be highly appreciated)

> There are apparently some cases where it loses interrupts and then the
> sound is garbled, my brother's investigating that at the moment, it
> doesn't happen with my powerbook nor with my powermac.

Not seen this, although I must say it does not resume from sleep as
gracefully as I have seen you describe it.

> But the other reason for writing this mail is that I finally found the
> last remaining bug that prevented sound module autoloading! :)

Much appreciated, thank you :)

> Now, when you boot, mac-io is already built-in so provides the i2s
> device, which my i2sbus module binds to. Since udev synthesizes events,
> i2sbus gets loaded automatically. Now, i2sbus creates uevents on its
> own, with the layout number given as the MODALIAS. Hence, the layout
> fabric module is loaded because it has an alias for all the layouts it
> handles, and it in turn requests all the codec modules that it requires.
> Also, this means that 'modprobe i2sbus' will suffice to get the driver
> up and running without a reboot, provided that all modules are
> installed.
> 
> Have fun,
> johannes

Regards,
Tony V.
(Chainsaw)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEa3Icp5vW4rUFj5oRAuFXAJwMgzHiZLal33irvZt6qtDbo1L+rQCbBb4d
KF5TAISi/CUHYj+ZqJjPpFE=
=ptuO
-----END PGP SIGNATURE-----

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Wed, 2006-05-17 at 19:57 +0100, Tony Vroon wrote:

> When writing documentation, you might want to add that the ALSA-plugin
> in XMMS & Audacious requires a period time of 100ms instead of the
> default of 50ms, as otherwise the sou*click*nd is n*click*ot ver*click*y
> good.
> (A look at the current code of that plugin, to see how the volume
> control code can be fixed would be highly appreciated)

How's that related to snd-aoa? You can currently buffer up to 131072
bytes which at 96KHz and 32 bits is ~171ms. At the regular 44100Hz/16bit
it is ~743ms. But you can easily increase that in i2sbus-pcm.c line
126ff:
        /* these are somewhat arbitrary */
        hw->buffer_bytes_max = 131072;
        hw->period_bytes_min = 256;
        hw->period_bytes_max = 16384;
The thing is just that this memory area is essentially mlock()ed so if I
did indeed allow 16k per period and 32 periods the stream would mlock
512K. What would others say is appropriate?

Ah then again I can see how this might be related to snd-aoa -- we only
update the pcm position on each period so maybe we should increase the
minimum number of periods. Can you try that? Go into i2sbus-pcm.c line
130 and change
        hw->periods_min = 3;
to maybe 6. Or just try binary search for  smallest value that makes it
work (if it ever does, but I think it should, if this is indeed the
issue). Indeed, at 50ms buffer you have just 8820 bytes which can even
be divided by 3 so that probably means that xmms used 3 periods. Maybe
that's a bit tight. Do you see the same issue with snd-powermac? (it
uses the same period setup)

> Not seen this, although I must say it does not resume from sleep as
> gracefully as I have seen you describe it.

What happens? I just fixed tas resume from sleep (by completely
re-initialising the codec) and something similar should be done for the
onyx probably (or do I do that already?) for suspend to disk, but other
than that... Oh I just realised that it'll lose some sound due to
restarting the dma command ring at the beginning. Hmm. I suppose I can
change that easily, will have to do some testing.

Benjamin (Berg), can we do that even with the lost interrupt issue?

Maybe both of these issues can be fixed by using the frame count
register instead to count how many samples were played? Below is a small
patch to print out a lot of frame count numbers, Benjamin, I'd
appreciate if you could look how this interacted with the lost
interrupts.

Note that for this to work we'd of course have to sample the frame count
register right before starting the DMA engine, it increases even while
we're not playing because we don't stop the clocks. We probably should
do that too for powersaving. Humm. Lots to do :) Oh and this probably
means that yes, it works fine even when we do lose interrupts. 

Alternatively we could use the register just to detect if we lost
interrupts, i.e. calculate how many frames we have per period and then
see if the frame count increased approximately by that much (I've seen
+- a few frames probably due to timing, with higher samplerates we'll
probably see a bit more error) and if it increased by much more we could
estimate how many interrupts we lost. What do you think?

johannes

--- snd-aoa.orig/soundbus/i2sbus/i2sbus-pcm.c	2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus-pcm.c	2006-05-19 12:11:22.119474526 +0200
@@ -488,12 +488,17 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
 static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
 {
 	struct pcm_info *pi;
+	u32 fc;
 
 	get_pcm_info(i2sdev, in, &pi, NULL);
 	if (!pi->substream) {
 		printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
 		return;
 	}
+	fc = in_le32(&i2sdev->intfregs->frame_count);
+	printk(KERN_DEBUG "i2sbus: frame count is %d\n", fc);
+	printk(KERN_DEBUG "i2sbus: delta fc = %d\n", fc - i2sdev->fc);
+	i2sdev->fc = fc;
 	pi->current_period = (pi->current_period+1) % (pi->periods);
 	snd_pcm_period_elapsed(pi->substream);
 }
--- snd-aoa.orig/soundbus/i2sbus/i2sbus.h	2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus.h	2006-05-19 12:11:22.119474526 +0200
@@ -50,6 +50,7 @@ struct i2sbus_dev {
 	struct macio_dev *macio;
 	struct i2sbus_control *control;
 	volatile struct i2s_interface_regs __iomem *intfregs;
+	u32 fc;
 
 	int resource_allocated; /* bitmask of resources */
 	struct resource resources[3];


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

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

> Alternatively we could use the register just to detect if we lost
> interrupts, i.e. calculate how many frames we have per period and then
> see if the frame count increased approximately by that much (I've seen
> +- a few frames probably due to timing, with higher samplerates we'll
> probably see a bit more error) and if it increased by much more we could
> estimate how many interrupts we lost. What do you think?

What do you mean by lost interrupts ?

DBDMA sends edge interrupts. Thus, if it emits interrupts A, then B and
C, and for any reason, your kenrel is not able to service interrupts (is
doing something with IRQs disabled) from before B happens to after C
happens, you'll indeed get called only twice (A and C) and "B" will be
sort-of lost.

First thing about that is: what the heck is causing us to have such a
latency !!! that would be useful to figure out. A way to do that would
be maybe to "detect" when C happens that we missed B (see below how to
do that) and print something along with the regs->nip & lr (or even a
backtrace). That might give us an idea of there interrupts are
re-enabled after the long latency which could perhaps lead us to the
cause of the latency.

Now for detecting lost interrupts (and for being immune to them), the
technique is not to just assume IRQ -> 1 period completed, but instead,
when an irq happens, to go read the DBDMA descriptors in memory to see
which ones have actually been completed. Their status field should be
updated as their get comleted. Thus, you keep track of the "previous"
last completed descriptor and you walk from that to recycle them.

Since we can only update the framecounter on a per-period basis, the
driver would benefit from having lots of very small periods. I don't
know if we can provide "hints" to userland about that though. Using the
i2s frame counter means we need some kind of calibration... it might
still be counting if for the reason the DBDMA "misses" something or gets
stopped....

Ben.

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Sun, 2006-05-21 at 09:56 +1000, Benjamin Herrenschmidt wrote:

> What do you mean by lost interrupts ?

Well, when our interrupt handler isn't run for each expected interrupt.

> DBDMA sends edge interrupts. Thus, if it emits interrupts A, then B and
> C, and for any reason, your kenrel is not able to service interrupts (is
> doing something with IRQs disabled) from before B happens to after C
> happens, you'll indeed get called only twice (A and C) and "B" will be
> sort-of lost.

Right. But I have a hard time believing that we had such a high latency,
I expect an interrupt about every 10ms under normal alsa programming.

> First thing about that is: what the heck is causing us to have such a
> latency !!! that would be useful to figure out. A way to do that would
> be maybe to "detect" when C happens that we missed B (see below how to
> do that) and print something along with the regs->nip & lr (or even a
> backtrace). That might give us an idea of there interrupts are
> re-enabled after the long latency which could perhaps lead us to the
> cause of the latency.

Yeah ok, we might be able to figure out what's causing this, but on an
otherwise idle system I assumed actual hardware problems, but it also
never happened on my machine, only on my brother's (same as your pbook).

> Now for detecting lost interrupts (and for being immune to them), the
> technique is not to just assume IRQ -> 1 period completed, but instead,
> when an irq happens, to go read the DBDMA descriptors in memory to see
> which ones have actually been completed. Their status field should be
> updated as their get comleted. Thus, you keep track of the "previous"
> last completed descriptor and you walk from that to recycle them.

Right, that's how snd-powermac does it. It has the nasty side-effect of
polluting the cache a lot though, since dbdma commands are 16 bytes
long. Am I wrong?

> Since we can only update the framecounter on a per-period basis, 

Alsa calls this thing the 'pointer' :) The frame counter we currently
use is the frame counter register of the i2s bus controller, and I don't
see why we shouldn't do that instead of reading back all the dbdma
command status fields.

> the
> driver would benefit from having lots of very small periods. I don't
> know if we can provide "hints" to userland about that though. 

Yes, we can set the minimum period count or maximum period length. Not a
hint though, it then makes it required.

> Using the
> i2s frame counter means we need some kind of calibration... it might
> still be counting if for the reason the DBDMA "misses" something or gets
> stopped....

Since the i2s bus is not shut down it also counts when we are not
transferring data. We currently calibrate on the first interrupt. That's
fine, since having multiple periods means that we don't need to be
absolutely precise here. If we miss one, that's fine, we can make it up
the next time by saying that 2 have elapsed.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

> Right, that's how snd-powermac does it. It has the nasty side-effect of
> polluting the cache a lot though, since dbdma commands are 16 bytes
> long. Am I wrong?

You don't have that much DBDMA commands that it would pollute the cache
_a lot_ :) 

> > Since we can only update the framecounter on a per-period basis, 
> 
> Alsa calls this thing the 'pointer' :) The frame counter we currently
> use is the frame counter register of the i2s bus controller, and I don't
> see why we shouldn't do that instead of reading back all the dbdma
> command status fields.

If you manage to have it properly in sync, that may work too.

> Since the i2s bus is not shut down it also counts when we are not
> transferring data. We currently calibrate on the first interrupt. That's
> fine, since having multiple periods means that we don't need to be
> absolutely precise here. If we miss one, that's fine, we can make it up
> the next time by saying that 2 have elapsed.

Ok.

Ben.

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Wed, 2006-05-24 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> > Right, that's how snd-powermac does it. It has the nasty side-effect of
> > polluting the cache a lot though, since dbdma commands are 16 bytes
> > long. Am I wrong?
> 
> You don't have that much DBDMA commands that it would pollute the cache
> _a lot_ :) 

Ah, yeah, I guess so. Well I do have 32 dbdma commands, them being
spaced up in 16-bytes means 16 cachelines, no? I'm not sure how the
cache is wired up ...

> > Alsa calls this thing the 'pointer' :) The frame counter we currently
> > use is the frame counter register of the i2s bus controller, and I don't
> > see why we shouldn't do that instead of reading back all the dbdma
> > command status fields.
> 
> If you manage to have it properly in sync, that may work too.

Seems to work fine so far, even if bcm43xx kills a few interrupts ;)

johannes

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

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

On Wed, 2006-05-24 at 11:42 +0200, Johannes Berg wrote:
> On Wed, 2006-05-24 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> > > Right, that's how snd-powermac does it. It has the nasty side-effect of
> > > polluting the cache a lot though, since dbdma commands are 16 bytes
> > > long. Am I wrong?
> > 
> > You don't have that much DBDMA commands that it would pollute the cache
> > _a lot_ :) 
> 
> Ah, yeah, I guess so. Well I do have 32 dbdma commands, them being
> spaced up in 16-bytes means 16 cachelines, no? I'm not sure how the
> cache is wired up ...

On a 32 bits CPU yes.

> > > Alsa calls this thing the 'pointer' :) The frame counter we currently
> > > use is the frame counter register of the i2s bus controller, and I don't
> > > see why we shouldn't do that instead of reading back all the dbdma
> > > command status fields.
> > 
> > If you manage to have it properly in sync, that may work too.
> 
> Seems to work fine so far, even if bcm43xx kills a few interrupts ;)

So it's bcm's fault ? Did you do a bit of analysis ? that would be
useful...

Ben.

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-25 at 18:00 +1000, Benjamin Herrenschmidt wrote:

> So it's bcm's fault ? Did you do a bit of analysis ? that would be
> useful...

I kinda assumed the list was lagging again and my brother had already
posted the solution. Yes, bcm does some measuring stuff that keeps
interrupts disabled for lots of milliseconds (25 or something). It's
being fixed.

I still think, however, that we ought to be able to deal with lost
interrupts.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

On Thu, 2006-05-25 at 11:42 +0200, Johannes Berg wrote:
> On Thu, 2006-05-25 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> 
> > So it's bcm's fault ? Did you do a bit of analysis ? that would be
> > useful...
> 
> I kinda assumed the list was lagging again and my brother had already
> posted the solution. Yes, bcm does some measuring stuff that keeps
> interrupts disabled for lots of milliseconds (25 or something). It's
> being fixed.
> 
> I still think, however, that we ought to be able to deal with lost
> interrupts.

Oh sure, but it's also useful to have a way to find who are the bast*rds
who are causing big latencies so we can fix them :)

Ben.

Re: snd-aoa status update / automatic driver loading

[Andreas Schwab]

Johannes Berg <johannes@sipsolutions.net> writes:

> Hey,
>
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8
> * PowerBook5,7
> * PowerMac8,1
> * PowerMac8,2
> * 17" October 2005 PowerBook (don't know the number)
> * PowerMac11,2
> * PowerBook6,8
> and my
> * PowerBook5,6

For PowerBook6,7:

	/* PowerBook6,7 */
	{ .layout_id = 92,
	  .codecs[0] = {
		.name = "tas",
		.connections = tas_connections_nolineout,
	  },
	},

Appears to work fine, apart from the missing features.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Wed, 2006-05-17 at 21:53 +0200, Andreas Schwab wrote:

> 	/* PowerBook6,7 */
> 	{ .layout_id = 92,
> 	  .codecs[0] = {
> 		.name = "tas",
> 		.connections = tas_connections_nolineout,
> 	  },
> 	},

Thanks, I'll add that.

Autodetection will come some time too :)

johannes

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

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

Hi Johannes

Thanks for the update .. :)

I loaded the new drivers, and they work, as it seems. In the end it
will probably need a bit more use of this driver before i can give a
reliable test report ... :)

Below a few first notes ..

On Wed, May 17, 2006 at 12:09:24PM +0200, Johannes Berg wrote:
> Hey,
> 
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8

I use snd-aoa on the latter

> 
> People with those machines are encouraged to use and stress-test it,


I compiled/installed your (old) snd-aoa files at about last (Tuesday)
night , and got these errors when re-booting the machine today:

-------------------------
# zgrep mismatch /var/log/boot.*gz [following op slightly edited for readability]

/var/log/boot.2.gz:Wed May 17 16:14:04 2006: ^[[9;0]^[[14;0]Setting up
ALSA...warning: 'alsactl restore' failed with error message 'alsactl:
set_control:894: warning: name mismatch (Line-out Switch/Headphone
Switch) for control #2

/var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
warning: index mismatch (0/0) for control #2

/var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:894:
warning: name mismatch (Master Playback Volume/Capture Source) for
control #3

/var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
warning: index mismatch (0/0) for control #3
--------------------------

This error seems to be *gone* after updating ('git pull') snd-aoa,
compiling and installing it at about 16:00 UTC today (Wednesday)...

# modinfo snd-aoa
filename:       /lib/modules/2.6.17-rc3-gf358166a-dirty/kernel/sound/aoa/snd-aoa.ko
description:    Apple Onboard Audio Sound Driver
author:         Johannes Berg <johannes@sipsolutions.net>
license:        GPL
vermagic:       2.6.17-rc3-gf358166a-dirty mod_unload gcc-4.1
depends:        snd
srcversion:     C4332AD34674ECE97C7BF91

Notes:

1:

I removed snd-powermac from /etc/modules to prevent the module from
being loaded when booting ... only today .. Sound still works ... :)

2:

Took me some reboots/'alsactl store' to have sound switched on
automatically after logging in to KDE ... not being sure what was
going on .. 


3:

I have a kmix Volume slider now ... this is new on *this* kmix applet
(i.e. the one I have to load via Multimedia --> KMix from the KDE
kicker)

So: Nice ... is this the solution you like, too ? ... ;) .. 

4:

I can hear two sound files at the same time: Didn't work at the first
try. I then installed again /etc/asound.conf, that I copied from my
old ti-IV-Book (Not being sure tho' whether this really is such a good
idea .... : 

-------------------------------
pcm.!default {
	type plug
	slave.pcm asymer
}

pcm.dmixer {
	type dmix
	ipc_key 1977
	ipc_perm 666
#	ipc_key_add_uid true
	slowptr true
	slave {
		pcm "hw:0"
		period_time 0
		period_size 1024
		buffer_size 8192
		rate 44100
	}
}

pcm.dsnooper {
	type dsnoop
	ipc_key 1978
	ipc_perm 666
#	ipc_key_add_uid true
	slave.pcm "hw:0"
}

pcm.asymer {
	type asym
	playback.pcm "dmixer"
	capture.pcm "dsnooper"
}

pcm.jack {
	type jack
	playback_ports {
		0 alsa_pcm:playback_1
		1 alsa_pcm:playback_2
	}
	capture_ports {
		0 alsa_pcm:capture_1
		1 alsa_pcm:capture_2
	}
}

# These are for alsa-oss
pcm.dsp0 pcm.default
ctl.mixer0 "hw:0"
------------------------------

5:

Ooops: Alsaplayer just disappeared while playing somem Internet radio
station:

/var/log/kern.log from about the time of the crash:

May 17 23:34:11 debby1-6 kernel: [15962.091766] i2sbus: stop/suspend

[nothing more, as it seems .. Sorry]

No problem restarting alsa-player after this little crash .. :) 



> Now, when you boot, mac-io is already built-in so provides the i2s
> device, which my i2sbus module binds to. Since udev synthesizes events,
> i2sbus gets loaded automatically. Now, i2sbus creates uevents on its
> own, with the layout number given as the MODALIAS. Hence, the layout
> fabric module is loaded because it has an alias for all the layouts it
> handles, and it in turn requests all the codec modules that it requires.
> Also, this means that 'modprobe i2sbus' will suffice to get the driver
> up and running without a reboot, 

... didn't try this so far, but I'll keep that in mind for
/etc/modules ... :)

The problem I had so far after installing the new snd-aoa drivers was
to first unload them (before reloading) without the need to reboot
... it seems the KDE panel (kicker) is using the drivers, thus
preventing them from being unloadable ... I'll see into that later on
... 

Just in case it helps:


# lsmod | grep -i snd   [again slightly edited]
snd_aoa_codec_onyx     12736  2 
snd_aoa_fabric_layout     7716  2 
snd_aoa                 8076  2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
snd_pcm_oss            45824  0 
snd_mixer_oss          19392  1 snd_pcm_oss
snd_pcm                89060  2 i2sbus,snd_pcm_oss
snd_timer              22468  1 snd_pcm
snd_page_alloc          8744  1 snd_pcm
soundbus                6436  2 snd_aoa_fabric_layout,i2sbus
snd                    60148  12 snd_aoa_codec_onyx,
				 snd_aoa_fabric_layout,snd_aoa,i2sbus,
				 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore               8612  1 snd


[do you see modules that are not needed anymore with the new snd-aoa,
with the hardware I have?]


/etc/modules:
-------------------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

apm_emu
ide-cd
#ide-disk
#ide-generic
sbp2
i2c-powermac
#snd-powermac

#snd-aoa:
soundbus
i2sbus
snd-aoa
snd-aoa-fabric-layout
snd-aoa-codec-onyx
# End snd-aoa

cpufreq_performance
cpufreq_powersave
sr_mod
therm_adt746x

------------------------

Thanks for your work .. :)

And please let me know if you need to know more ..

Best Regards
Wolfgang

-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

On Wed, May 17, 2006 at 11:54:12PM +0200, Wolfgang Pfeiffer wrote:
> 
> 
> # lsmod | grep -i snd   [again slightly edited]
> snd_aoa_codec_onyx     12736  2 
> snd_aoa_fabric_layout     7716  2 
> snd_aoa                 8076  2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
> snd_pcm_oss            45824  0 
> snd_mixer_oss          19392  1 snd_pcm_oss
> snd_pcm                89060  2 i2sbus,snd_pcm_oss
> snd_timer              22468  1 snd_pcm
> snd_page_alloc          8744  1 snd_pcm
> soundbus                6436  2 snd_aoa_fabric_layout,i2sbus
> snd                    60148  12 snd_aoa_codec_onyx,
> 				 snd_aoa_fabric_layout,snd_aoa,i2sbus,
> 				 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
> soundcore               8612  1 snd
> 
> 
> [do you see modules that are not needed anymore with the new snd-aoa,
> with the hardware I have?]

Update:

changed /etc/modules to explicitly load only i2sbus:

--------------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

apm_emu
ide-cd
#ide-disk
#ide-generic
sbp2
i2c-powermac
#snd-powermac

#snd-aoa:
#soundbus
i2sbus
#snd-aoa
#snd-aoa-fabric-layout
#snd-aoa-codec-onyx
# End snd-aoa

cpufreq_performance
cpufreq_powersave
sr_mod
therm_adt746x
-------------------

.. which seems enough to load the rest of the needed snd modules:
After the change above [following op. slightly edited]:

---------------------
# lsmod | grep -i snd
snd_aoa_codec_onyx     12736  2 
snd_aoa_fabric_layout     7716  1 
snd_aoa                 8076  2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
snd_pcm_oss            45824  0 
snd_mixer_oss          19392  1 snd_pcm_oss
snd_pcm                89060  2 i2sbus,snd_pcm_oss
snd_timer              22468  1 snd_pcm
snd_page_alloc          8744  1 snd_pcm
soundbus                6436  2 snd_aoa_fabric_layout,i2sbus

snd                    60148  10 snd_aoa_codec_onyx,
				 snd_aoa_fabric_layout,snd_aoa,i2sbus,
				 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer


soundcore               8612  1 snd

---------------------


> 
> 
> /etc/modules:
> -------------------------
> # /etc/modules: kernel modules to load at boot time.
> #
> # This file contains the names of kernel modules that should be loaded
> # at boot time, one per line. Lines beginning with "#" are ignored.
> 
> apm_emu
> ide-cd
> #ide-disk
> #ide-generic
> sbp2
> i2c-powermac
> #snd-powermac
> 
> #snd-aoa:
> soundbus
> i2sbus
> snd-aoa
> snd-aoa-fabric-layout
> snd-aoa-codec-onyx
> # End snd-aoa
> 
> cpufreq_performance
> cpufreq_powersave
> sr_mod
> therm_adt746x
> 
> ------------------------

HTH

Regards
Wolfgang
-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:

> changed /etc/modules to explicitly load only i2sbus:

Even that should not be necessary.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

On Thu, May 18, 2006 at 12:13:12PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:
> 
> > changed /etc/modules to explicitly load only i2sbus:
> 
> Even that should not be necessary.

True. Just tested it (i.e. booted the machine) with this /etc/modules file:

----------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

apm_emu
ide-cd
#ide-disk
#ide-generic
sbp2
i2c-powermac
#snd-powermac

#snd-aoa:
#soundbus
#i2sbus
#snd-aoa
#snd-aoa-fabric-layout
#snd-aoa-codec-onyx
# End snd-aoa

cpufreq_performance
cpufreq_powersave
sr_mod
therm_adt746x

-----------------

And this is lsmod, after booting with he file above (op. slightly
edited for better readability):

# lsmod | grep snd

snd_aoa_codec_onyx     12736  2 
snd_aoa_fabric_layout     7716  1 
snd_aoa                 8076  2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
snd_pcm_oss            45824  0 
snd_mixer_oss          19392  1 snd_pcm_oss
snd_pcm                89060  2 i2sbus,snd_pcm_oss
snd_timer              22468  1 snd_pcm
snd_page_alloc          8744  1 snd_pcm
soundbus                6436  2 snd_aoa_fabric_layout,i2sbus
snd                    60148  10 snd_aoa_codec_onyx,
				 snd_aoa_fabric_layout,snd_aoa,i2sbus,
				 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore               8612  1 snd


BTW: Is there a way to let 'alsaconf' detect the soundcard on this
PB5,8 ?
So far that's impossible, as it seems. But this could also be
related to mistakes I made in my modules files, or wherever.

That's why I changed a few files today below /etc/modprobe.d/ and
/etc/modutils/ that still had a few instances calling snd-powermac:
I simply replaced 'snd-powermac' with i2sbus resp. (IIRC)
snd-aoa. To no avail so far: alsaconf still does not detect any
soundcard .. 

Status quo:

$ grep -irs i2sbus /etc/         
/etc/modprobe.d/alsa-base:install i2sbus /sbin/modprobe --ignore-install i2sbus $CMDLINE_OPTS && /lib/alsa/modprobe-post-install i2sbus
/etc/modprobe.d/sound:alias snd-card-0 i2sbus
/etc/modutils/alsa-base:post-install i2sbus /lib/alsa/modprobe-post-install i2sbus

Anything wrong up there?

Best Regards
Wolfgang


-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Andreas Schwab]

Wolfgang Pfeiffer <roto@gmx.net> writes:

> BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> PB5,8 ?

AFAIK, alsaconf has only support for probing PCI and ISA sound cards, but
the AOA sound is hidden behind an i2s bus that is hidden behind a mac-io
bus.  The version included in SuSE has hardcoded special cases for Sparc
and PPC.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:

> BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> PB5,8 ?
> So far that's impossible, as it seems. But this could also be
> related to mistakes I made in my modules files, or wherever.

No idea, but I don't see why you'd want alsaconf to figure it out if the
kernel can by itself...

johannes

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

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

On Fri, May 19, 2006 at 02:50:18PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:
> 
> > BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> > PB5,8 ?
> > So far that's impossible, as it seems. But this could also be
> > related to mistakes I made in my modules files, or wherever.
> 
> No idea, but I don't see why you'd want alsaconf to figure it out 

... because it's the job of alsaconf, too, to figure that
out. IINM. And because I thought it might help to mention the issue,
when I was already at it .. :)

But yes, it does not bother me if the kernel itself knows what's going
on .. :)

Best Regards
Wolfgang


-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Fri, 2006-05-19 at 16:40 +0200, Wolfgang Pfeiffer wrote:

> ... because it's the job of alsaconf, too, to figure that
> out. IINM. And because I thought it might help to mention the issue,
> when I was already at it .. :)

:)
I never used alsaconf, and frankly, for PCI cards and anything else
that's sensible I don't see the point since the kernel along with
hotplugging can get it just to work. With ISA, well, yea, maybe. Or does
alsaconf have any other function than detecting the hardware and loading
the right modules?

johannes

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

Re: snd-aoa status update / automatic driver loading

[Dean Hamstead]

perhaps a comprehensive sound test would be in order, akin perhaps to 
the one the winehq chaps are doing right now

Dean

Wolfgang Pfeiffer wrote:
> Hi Johannes
> 
> Thanks for the update .. :)
> 
> I loaded the new drivers, and they work, as it seems. In the end it
> will probably need a bit more use of this driver before i can give a
> reliable test report ... :)
> 
> Below a few first notes ..
> 
> On Wed, May 17, 2006 at 12:09:24PM +0200, Johannes Berg wrote:
>> Hey,
>>
>> Currently snd-aoa is known to work on the following machines:
>> * PowerBook5,8
> 
> I use snd-aoa on the latter
> 
>> People with those machines are encouraged to use and stress-test it,
> 
> 
> I compiled/installed your (old) snd-aoa files at about last (Tuesday)
> night , and got these errors when re-booting the machine today:
> 
> -------------------------
> # zgrep mismatch /var/log/boot.*gz [following op slightly edited for readability]
> 
> /var/log/boot.2.gz:Wed May 17 16:14:04 2006: ^[[9;0]^[[14;0]Setting up
> ALSA...warning: 'alsactl restore' failed with error message 'alsactl:
> set_control:894: warning: name mismatch (Line-out Switch/Headphone
> Switch) for control #2
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
> warning: index mismatch (0/0) for control #2
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:894:
> warning: name mismatch (Master Playback Volume/Capture Source) for
> control #3
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
> warning: index mismatch (0/0) for control #3
> --------------------------
> 
> This error seems to be *gone* after updating ('git pull') snd-aoa,
> compiling and installing it at about 16:00 UTC today (Wednesday)...
> 
> # modinfo snd-aoa
> filename:       /lib/modules/2.6.17-rc3-gf358166a-dirty/kernel/sound/aoa/snd-aoa.ko
> description:    Apple Onboard Audio Sound Driver
> author:         Johannes Berg <johannes@sipsolutions.net>
> license:        GPL
> vermagic:       2.6.17-rc3-gf358166a-dirty mod_unload gcc-4.1
> depends:        snd
> srcversion:     C4332AD34674ECE97C7BF91
> 
> Notes:
> 
> 1:
> 
> I removed snd-powermac from /etc/modules to prevent the module from
> being loaded when booting ... only today .. Sound still works ... :)
> 
> 2:
> 
> Took me some reboots/'alsactl store' to have sound switched on
> automatically after logging in to KDE ... not being sure what was
> going on .. 
> 
> 
> 3:
> 
> I have a kmix Volume slider now ... this is new on *this* kmix applet
> (i.e. the one I have to load via Multimedia --> KMix from the KDE
> kicker)
> 
> So: Nice ... is this the solution you like, too ? ... ;) .. 
> 
> 4:
> 
> I can hear two sound files at the same time: Didn't work at the first
> try. I then installed again /etc/asound.conf, that I copied from my
> old ti-IV-Book (Not being sure tho' whether this really is such a good
> idea .... : 
> 
> -------------------------------
> pcm.!default {
> 	type plug
> 	slave.pcm asymer
> }
> 
> pcm.dmixer {
> 	type dmix
> 	ipc_key 1977
> 	ipc_perm 666
> #	ipc_key_add_uid true
> 	slowptr true
> 	slave {
> 		pcm "hw:0"
> 		period_time 0
> 		period_size 1024
> 		buffer_size 8192
> 		rate 44100
> 	}
> }
> 
> pcm.dsnooper {
> 	type dsnoop
> 	ipc_key 1978
> 	ipc_perm 666
> #	ipc_key_add_uid true
> 	slave.pcm "hw:0"
> }
> 
> pcm.asymer {
> 	type asym
> 	playback.pcm "dmixer"
> 	capture.pcm "dsnooper"
> }
> 
> pcm.jack {
> 	type jack
> 	playback_ports {
> 		0 alsa_pcm:playback_1
> 		1 alsa_pcm:playback_2
> 	}
> 	capture_ports {
> 		0 alsa_pcm:capture_1
> 		1 alsa_pcm:capture_2
> 	}
> }
> 
> # These are for alsa-oss
> pcm.dsp0 pcm.default
> ctl.mixer0 "hw:0"
> ------------------------------
> 
> 5:
> 
> Ooops: Alsaplayer just disappeared while playing somem Internet radio
> station:
> 
> /var/log/kern.log from about the time of the crash:
> 
> May 17 23:34:11 debby1-6 kernel: [15962.091766] i2sbus: stop/suspend
> 
> [nothing more, as it seems .. Sorry]
> 
> No problem restarting alsa-player after this little crash .. :) 
> 
> 
> 
>> Now, when you boot, mac-io is already built-in so provides the i2s
>> device, which my i2sbus module binds to. Since udev synthesizes events,
>> i2sbus gets loaded automatically. Now, i2sbus creates uevents on its
>> own, with the layout number given as the MODALIAS. Hence, the layout
>> fabric module is loaded because it has an alias for all the layouts it
>> handles, and it in turn requests all the codec modules that it requires.
>> Also, this means that 'modprobe i2sbus' will suffice to get the driver
>> up and running without a reboot, 
> 
> ... didn't try this so far, but I'll keep that in mind for
> /etc/modules ... :)
> 
> The problem I had so far after installing the new snd-aoa drivers was
> to first unload them (before reloading) without the need to reboot
> ... it seems the KDE panel (kicker) is using the drivers, thus
> preventing them from being unloadable ... I'll see into that later on
> ... 
> 
> Just in case it helps:
> 
> 
> # lsmod | grep -i snd   [again slightly edited]
> snd_aoa_codec_onyx     12736  2 
> snd_aoa_fabric_layout     7716  2 
> snd_aoa                 8076  2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
> snd_pcm_oss            45824  0 
> snd_mixer_oss          19392  1 snd_pcm_oss
> snd_pcm                89060  2 i2sbus,snd_pcm_oss
> snd_timer              22468  1 snd_pcm
> snd_page_alloc          8744  1 snd_pcm
> soundbus                6436  2 snd_aoa_fabric_layout,i2sbus
> snd                    60148  12 snd_aoa_codec_onyx,
> 				 snd_aoa_fabric_layout,snd_aoa,i2sbus,
> 				 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
> soundcore               8612  1 snd
> 
> 
> [do you see modules that are not needed anymore with the new snd-aoa,
> with the hardware I have?]
> 
> 
> /etc/modules:
> -------------------------
> # /etc/modules: kernel modules to load at boot time.
> #
> # This file contains the names of kernel modules that should be loaded
> # at boot time, one per line. Lines beginning with "#" are ignored.
> 
> apm_emu
> ide-cd
> #ide-disk
> #ide-generic
> sbp2
> i2c-powermac
> #snd-powermac
> 
> #snd-aoa:
> soundbus
> i2sbus
> snd-aoa
> snd-aoa-fabric-layout
> snd-aoa-codec-onyx
> # End snd-aoa
> 
> cpufreq_performance
> cpufreq_powersave
> sr_mod
> therm_adt746x
> 
> ------------------------
> 
> Thanks for your work .. :)
> 
> And please let me know if you need to know more ..
> 
> Best Regards
> Wolfgang
> 

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

On Thu, May 18, 2006 at 08:30:23AM +1000, Dean Hamstead wrote:
> perhaps a comprehensive sound test would be in order, akin perhaps to 
> the one the winehq chaps are doing right now

Not being sure if I got that one ... :)

Regards
Wolfgang

-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Dean Hamstead]

they are running about a 30 min test with a variety of
audio and so forth so test for distortion.

they are hoping people will use oss and alsa, as well
as oss emulation and report back on what worked and what
didnt etc

Dean

Wolfgang Pfeiffer wrote:
> On Thu, May 18, 2006 at 08:30:23AM +1000, Dean Hamstead wrote:
>> perhaps a comprehensive sound test would be in order, akin perhaps to 
>> the one the winehq chaps are doing right now
> 
> Not being sure if I got that one ... :)
> 
> Regards
> Wolfgang
> 

Re: snd-aoa status update / automatic driver loading

[Wolfgang Pfeiffer]

On Wed, May 17, 2006 at 11:54:12PM +0200, Wolfgang Pfeiffer wrote:

> 
> 4:
> 
> I can hear two sound files at the same time: Didn't work at the first
> try. I then installed again /etc/asound.conf, that I copied from my
> old ti-IV-Book (Not being sure tho' whether this really is such a good
> idea .... : 

And the file below wasn't written by me. Not sure tho' where I found it
once   ...

> 
> -------------------------------
> pcm.!default {
> 	type plug
> 	slave.pcm asymer
> }
> 
> pcm.dmixer {
> 	type dmix
> 	ipc_key 1977
> 	ipc_perm 666
> #	ipc_key_add_uid true
> 	slowptr true
> 	slave {
> 		pcm "hw:0"

> [ ... ]

> 	capture_ports {
> 		0 alsa_pcm:capture_1
> 		1 alsa_pcm:capture_2
> 	}
> }
> 
> # These are for alsa-oss
> pcm.dsp0 pcm.default
> ctl.mixer0 "hw:0"
> ------------------------------

Wolfgang

-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

> /var/log/boot.2.gz:Wed May 17 16:14:04 2006: ^[[9;0]^[[14;0]Setting up
> ALSA...warning: 'alsactl restore' failed with error message 'alsactl:
> set_control:894: warning: name mismatch (Line-out Switch/Headphone
> Switch) for control #2
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
> warning: index mismatch (0/0) for control #2
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:894:
> warning: name mismatch (Master Playback Volume/Capture Source) for
> control #3
> 
> /var/log/boot.2.gz:Wed May 17 16:14:05 2006: alsactl: set_control:896:
> warning: index mismatch (0/0) for control #3

That's Alsa being stupid. It stores the values of the control by number
and screws up when the driver is updated and adds/removes controls.
Storing the settings with the new driver should cure that

Re: snd-aoa status update / automatic driver loading

[Eddy Petrişor]

T24gNS8xNy8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAo+Cj4gQ3VycmVudGx5IHNuZC1hb2EgaXMga25vd24gdG8gd29yayBvbiB0aGUg
Zm9sbG93aW5nIG1hY2hpbmVzOgo+ICogUG93ZXJCb29rNSw4Cj4gKiBQb3dlckJvb2s1LDcKPiAq
IFBvd2VyTWFjOCwxCj4gKiBQb3dlck1hYzgsMgo+ICogMTciIE9jdG9iZXIgMjAwNSBQb3dlckJv
b2sgKGRvbid0IGtub3cgdGhlIG51bWJlcikKPiAqIFBvd2VyTWFjMTEsMgo+ICogUG93ZXJCb29r
Niw4Cj4gYW5kIG15Cj4gKiBQb3dlckJvb2s1LDYKCkFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQg
aXMgbmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote:

> Any chance for 5,2 ? What is needed for it? Codec only?

I don't know. If you try loading the modules, the kernel will tell you
something about an unhandled layout id. Alternatively, you can find the
layout-id file in your /proc/device-tree/ and tell me the number in it.
The rest I can figure out.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Paul Collins]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=C5=9For wrote:
>
>> Any chance for 5,2 ? What is needed for it? Codec only?
>
> I don't know. If you try loading the modules, the kernel will tell you
> something about an unhandled layout id. Alternatively, you can find the
> layout-id file in your /proc/device-tree/ and tell me the number in it.
> The rest I can figure out.

I have a PowerBook5,4 here and I'd be happy to test support for it.
The hardware is identified by snd-powermac as "PowerMac Snapper" and
the layout ID appears to be "3".

[briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sou=
nd/layout-id
0000000  \0  \0  \0   3
0000004

--=20
Dag vijandelijk luchtschip de huismeester is dood

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:

> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".

Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
occurrences of '70' to '3'. If it works, let me know and I'll add the
proper entry for it.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Paul Collins]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
>
>> I have a PowerBook5,4 here and I'd be happy to test support for it.
>> The hardware is identified by snd-powermac as "PowerMac Snapper" and
>> the layout ID appears to be "3".
>
> Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
> occurrences of '70' to '3'. If it works, let me know and I'll add the
> proper entry for it.

When I probed i2sbus nothing much seemed to happen, so I added a
printk to see what layout ID was being returned, and I'm getting 51,
not 3 as found in the device tree.  However, when I use 51 instead of
3 in those two places, I still don't get much happening.

Here's the dmesg after "modprobe i2sbus":

May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
May 20 00:35:51 briny kernel: i2sbus: control register contents:
May 20 00:35:51 briny kernel: i2sbus:    fcr0 = 0x0
May 20 00:35:51 briny kernel: i2sbus:    cell_control = 0x0
May 20 00:35:51 briny kernel: i2sbus:    fcr2 = 0x4ef1c25
May 20 00:35:51 briny kernel: i2sbus:    fcr3 = 0x0
May 20 00:35:51 briny kernel: i2sbus:    clock_control = 0x0
May 20 00:35:51 briny kernel: layout id is 51
May 20 00:35:51 briny kernel: i2sbus control destroyed

And lsmod:

Module                  Size  Used by
i2sbus                 21632  0 
soundbus                8132  1 i2sbus
radeon                129896  0 
drm                    82968  1 radeon
snd_usb_audio          90624  0 
snd_usb_lib            19232  1 snd_usb_audio
snd_rawmidi            29280  1 snd_usb_lib
snd_hwdep              11012  1 snd_usb_audio
hci_usb                14164  3 
snd_pcm_oss            50816  0 
snd_pcm               103588  3 i2sbus,snd_usb_audio,snd_pcm_oss
snd_timer              27140  1 snd_pcm
snd_page_alloc         11432  1 snd_pcm
pcmcia                 45776  0 
ehci_hcd               37224  0 
bcm43xx               448916  0 
ieee80211softmac       32384  1 bcm43xx
uninorth_agp           11112  1 
agpgart                38484  2 drm,uninorth_agp
ohci_hcd               24452  0 
ieee80211              36776  2 bcm43xx,ieee80211softmac
ieee80211_crypt         6880  1 ieee80211
yenta_socket           30412  1 
rsrc_nonstatic         13472  1 yenta_socket
pcmcia_core            49592  3 pcmcia,yenta_socket,rsrc_nonstatic

Here are the changes I made.

diff --git a/aoa/fabrics/snd-aoa-fabric-layout.c b/aoa/fabrics/snd-aoa-fabric-layout.c
index 65cda87..180dca4 100644
--- a/aoa/fabrics/snd-aoa-fabric-layout.c
+++ b/aoa/fabrics/snd-aoa-fabric-layout.c
@@ -84,7 +84,7 @@ MODULE_ALIAS("sound-layout-64");
 MODULE_ALIAS("sound-layout-65");
 MODULE_ALIAS("sound-layout-68");
 MODULE_ALIAS("sound-layout-69");
-MODULE_ALIAS("sound-layout-70");
+MODULE_ALIAS("sound-layout-51");
 MODULE_ALIAS("sound-layout-72");
 MODULE_ALIAS("sound-layout-86");
 MODULE_ALIAS("sound-layout-84");
@@ -214,7 +214,7 @@ static struct layout layouts[] = {
 	  },
 	  .busname = "digital in", .pcmid = 1 },
 	/* Early 2005 PowerBook */
-	{ .layout_id = 70,
+	{ .layout_id = 51,
 	  .codecs[0] = {
 		.name = "tas",
 		.connections = tas_connections_nolineout,
diff --git a/soundbus/i2sbus/i2sbus-core.c b/soundbus/i2sbus/i2sbus-core.c
index f6463cb..ff5b52e 100644
--- a/soundbus/i2sbus/i2sbus-core.c
+++ b/soundbus/i2sbus/i2sbus-core.c
@@ -130,7 +130,10 @@ static int i2sbus_add_dev(struct macio_d
 		u32 *layout_id;
 		layout_id = (u32*) get_property(sound, "layout-id", NULL);
 		if (layout_id) {
+			printk(KERN_INFO "layout id is %d\n", *layout_id);
 			snprintf(dev->sound.modalias, 32, "sound-layout-%d", *layout_id);
+		} else {
+			printk(KERN_INFO "no layout id!?\n");
 		}
 	}
 


-- 
Dag vijandelijk luchtschip de huismeester is dood

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:

> Here's the dmesg after "modprobe i2sbus":
> 
> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
> May 20 00:35:51 briny kernel: i2sbus: control register contents:
> May 20 00:35:51 briny kernel: i2sbus:    fcr0 = 0x0
> May 20 00:35:51 briny kernel: i2sbus:    cell_control = 0x0
> May 20 00:35:51 briny kernel: i2sbus:    fcr2 = 0x4ef1c25
> May 20 00:35:51 briny kernel: i2sbus:    fcr3 = 0x0
> May 20 00:35:51 briny kernel: i2sbus:    clock_control = 0x0
> May 20 00:35:51 briny kernel: layout id is 51

Did you have the changed modules installed? Otherwise you'd also have to
manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
so. If you had them installed the MODULE_ALIAS("sound-layout-51");
should have made it load automatically.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Paul Collins]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
>
>> Here's the dmesg after "modprobe i2sbus":
>> 
>> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
>> May 20 00:35:51 briny kernel: i2sbus: control register contents:
>> May 20 00:35:51 briny kernel: i2sbus:    fcr0 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:    cell_control = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:    fcr2 = 0x4ef1c25
>> May 20 00:35:51 briny kernel: i2sbus:    fcr3 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:    clock_control = 0x0
>> May 20 00:35:51 briny kernel: layout id is 51
>
> Did you have the changed modules installed? Otherwise you'd also have to
> manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
> so. If you had them installed the MODULE_ALIAS("sound-layout-51");
> should have made it load automatically.

Yep, I did make install after the build.  And modinfo
/lib/modules/`uname -r`/kernel/sound/aoa/snd-aoa-fabric-layout.ko
shows ones of the aliases as "sound-layout-51".

I did a fresh boot with snd-powermac renamed out of the way, and now I
get even less action: nothing logged in dmesg, and when I unload all
five modules and probe snd-powermac (having renamed it back) I get

May 20 01:08:29 briny kernel: snd: can't request rsrc  0 (Sound Control: 0x80010000:80010fff)

Then when I removed snd-powermac and probed i2sbus I got the same

May 20 01:10:00 briny kernel: i2sbus: mapped i2s control registers
May 20 01:10:00 briny kernel: i2sbus: control register contents:
May 20 01:10:00 briny kernel: i2sbus:    fcr0 = 0x0
May 20 01:10:00 briny kernel: i2sbus:    cell_control = 0x0
May 20 01:10:00 briny kernel: i2sbus:    fcr2 = 0xb7f53c
May 20 01:10:00 briny kernel: i2sbus:    fcr3 = 0x0
May 20 01:10:00 briny kernel: i2sbus:    clock_control = 0x0
May 20 01:10:00 briny kernel: layout id is 51
May 20 01:10:00 briny kernel: i2sbus control destroyed

Probing snd_aoa_fabric_layout and snd_aoa_codec_tas yielded no further
dmesg output and /proc/asounds/cards remains "no soundcards".

-- 
Dag vijandelijk luchtschip de huismeester is dood

Re: snd-aoa status update / automatic driver loading

[Andreas Schwab]

Paul Collins <paul@briny.ondioline.org> writes:

> Johannes Berg <johannes@sipsolutions.net> writes:
>
>> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=BAor wrote:
>>
>>> Any chance for 5,2 ? What is needed for it? Codec only?
>>
>> I don't know. If you try loading the modules, the kernel will tell you
>> something about an unhandled layout id. Alternatively, you can find the
>> layout-id file in your /proc/device-tree/ and tell me the number in it.
>> The rest I can figure out.
>
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
>
> [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/s=
ound/layout-id
> 0000000  \0  \0  \0   3
> 0000004

Apparently the layout-id on your system is 51 (decimal).

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Fri, 2006-05-19 at 16:33 +0200, Andreas Schwab wrote:
> > [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
> > 0000000  \0  \0  \0   3
> > 0000004
> 
> Apparently the layout-id on your system is 51 (decimal).

Eh, right, replace 70 by 51 of course. Thanks Andreas.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Sjoerd Simons]

On Fri, May 19, 2006 at 11:20:29PM +1000, Paul Collins wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri??or wrote:
> >
> >> Any chance for 5,2 ? What is needed for it? Codec only?
> >
> > I don't know. If you try loading the modules, the kernel will tell you
> > something about an unhandled layout id. Alternatively, you can find the
> > layout-id file in your /proc/device-tree/ and tell me the number in it.
> > The rest I can figure out.
> 
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".

I wanted to test on my PowerBook5,2. Uhfortunately i can't find no layout-id
file for the sound device or any other layout-id file for that matter:

$ find /proc/device-tree | grep -i layout 
/proc/device-tree/memory@0/ram-layout-architecture      

Futhermore one loading the i2sbus module it only gives some information in
dmesg once every two tries ? No errors are shown when there is no output.

Probably not very usefull, but when i get output it shows the following:

i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus:    fcr0 = 0x0
i2sbus:    cell_control = 0x0
i2sbus:    fcr2 = 0xa2caec
i2sbus:    fcr3 = 0x0
i2sbus:    clock_control = 0x0
i2sbus control destroyed

  Sjoerd
-- 
Life exists for no known purpose.

Re: snd-aoa status update / automatic driver loading

[Eddy Petrişor]

T24gNS8yMy8wNiwgU2pvZXJkIFNpbW9ucyA8c2pvZXJkQHNwcmluZy5sdW9uLm5ldD4gd3JvdGU6
Cj4gT24gRnJpLCBNYXkgMTksIDIwMDYgYXQgMTE6MjA6MjlQTSArMTAwMCwgUGF1bCBDb2xsaW5z
IHdyb3RlOgo+ID4gSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jp
dGVzOgo+ID4KPiA+ID4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBl
dHJpPz9vciB3cm90ZToKPiA+ID4KPiA+ID4+IEFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQgaXMg
bmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KPiA+ID4KPiA+ID4gSSBkb24ndCBrbm93LiBJZiB5
b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVsZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+ID4g
PiBzb21ldGhpbmcgYWJvdXQgYW4gdW5oYW5kbGVkIGxheW91dCBpZC4gQWx0ZXJuYXRpdmVseSwg
eW91IGNhbiBmaW5kIHRoZQo+ID4gPiBsYXlvdXQtaWQgZmlsZSBpbiB5b3VyIC9wcm9jL2Rldmlj
ZS10cmVlLyBhbmQgdGVsbCBtZSB0aGUgbnVtYmVyIGluIGl0Lgo+ID4gPiBUaGUgcmVzdCBJIGNh
biBmaWd1cmUgb3V0Lgo+Cj4gSSB3YW50ZWQgdG8gdGVzdCBvbiBteSBQb3dlckJvb2s1LDIuIFVo
Zm9ydHVuYXRlbHkgaSBjYW4ndCBmaW5kIG5vIGxheW91dC1pZAo+IGZpbGUgZm9yIHRoZSBzb3Vu
ZCBkZXZpY2Ugb3IgYW55IG90aGVyIGxheW91dC1pZCBmaWxlIGZvciB0aGF0IG1hdHRlcjoKClNh
bWUgbWFjaGluZSBoZXJlOyBJIGhhdmUgY2xvbmVkIHRoZSBhb2EgcmVwbyBhbmQgIm1hZGUiIGl0
LgpJbnNtb2QgZGlkbid0IHdvcmsgb24gYW55IG90aGVyIG1vZHVsZSBidXQgdGhlIHRoZSBzb3Vu
ZGJ1cywgYW5kCnJlc3VsdGVkIGluIGEgbWlzc2luZyBzeW1ib2wuCgpUaGlzIGlzIG9uIGEgMi4x
Ni4xNyBrZXJuZWwKCgotLSAKUmVnYXJkcywKRWRkeVAKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09CiJJbWFnaW5hdGlvbiBpcyBtb3JlIGltcG9ydGFudCB0aGFu
IGtub3dsZWRnZSIgQS5FaW5zdGVpbgo=

Re: snd-aoa status update / automatic driver loading

[Eddy Petrişor]

T24gNS8yNS8wNiwgRWRkeSBQZXRyacWfb3IgPGVkZHkucGV0cmlzb3JAZ21haWwuY29tPiB3cm90
ZToKPiBUaGlzIGlzIG9uIGEgMi4xNi4xNyBrZXJuZWwKCmVyciwgMi42LjE2LjE3CgotLSAKUmVn
YXJkcywKRWRkeVAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
CiJJbWFnaW5hdGlvbiBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGtub3dsZWRnZSIgQS5FaW5zdGVp
bgo=

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-25 at 10:21 +0300, Eddy Petrişor wrote:

> Same machine here; I have cloned the aoa repo and "made" it.
> Insmod didn't work on any other module but the the soundbus, and
> resulted in a missing symbol.

You probably forgot to load snd-pcm.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Eddy Petrişor]

T24gNS8xOC8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBldHJpxZ9vciB3
cm90ZToKPgo+ID4gQW55IGNoYW5jZSBmb3IgNSwyID8gV2hhdCBpcyBuZWVkZWQgZm9yIGl0PyBD
b2RlYyBvbmx5Pwo+Cj4gSSBkb24ndCBrbm93LiBJZiB5b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVs
ZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+IHNvbWV0aGluZyBhYm91dCBhbiB1bmhhbmRs
ZWQgbGF5b3V0IGlkLiBBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIGZpbmQgdGhlCj4gbGF5b3V0LWlk
IGZpbGUgaW4geW91ciAvcHJvYy9kZXZpY2UtdHJlZS8gYW5kIHRlbGwgbWUgdGhlIG51bWJlciBp
biBpdC4KPiBUaGUgcmVzdCBJIGNhbiBmaWd1cmUgb3V0LgoKSSBhbSBub3Qgc3VyZSBpZiB5b3Ug
Y2FuIG1ha2UgX25vd18gc29tZXRoaWduIG91dCBvZiB0aGlzIGluZm8sIGJ1dCBJCmd1ZXNzIHRo
aXMgaXMgd2lsbCBub3QgaHVydDoKCmh0dHA6Ly9saXN0cy5kZWJpYW4ub3JnL2RlYmlhbi1wb3dl
cnBjLzIwMDYvMDQvbXNnMDAwNTkuaHRtbApodHRwOi8vbGlzdHMuZGViaWFuLm9yZy9kZWJpYW4t
cG93ZXJwYy8yMDA2LzA0L21zZzAwMDYzLmh0bWwKCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-25 at 20:44 +0300, Eddy Petrişor wrote:
> On 5/18/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote:
> >
> > > Any chance for 5,2 ? What is needed for it? Codec only?
> >
> > I don't know. If you try loading the modules, the kernel will tell you
> > something about an unhandled layout id. Alternatively, you can find the
> > layout-id file in your /proc/device-tree/ and tell me the number in it.
> > The rest I can figure out.
> 
> I am not sure if you can make _now_ somethign out of this info, but I
> guess this is will not hurt:

Hrm, I keep forgetting that you don't have a layout-id property... I
need to sort some things, been doing so much other stuff that I lost
track. Sorry.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Rene Rebe]

Hi,

thanks for the update. Is record/capture supost to work now?

Yours,

=2D-=20
Ren=E9 Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://exactcode.de | http://t2-project.org | http://rebe.name
            +49 (0)30 / 255 897 45

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Thu, 2006-05-18 at 10:56 +0200, Rene Rebe wrote:

> thanks for the update. Is record/capture supost to work now?

Yes, that was a pretty stupid bug.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Benjamin Berg]

On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote:=20
> Hi all,
>=20
> just a "me too" mail:
>=20
> Le Thu, May 18, 2006 at 12:02:01AM +0200, B=C3=B8rge Holen a =C3=A9crit :
> > I can also remember half way throught a ogg/mp3 playlist when it also=20
> > scrambled the output, this has only happened ONCE.
>=20
> I experience the same on my 8,1 powermac, but more systematically. It
> takes usually more than one hour of continuous listening before it
> happens, and then it happens sort of stochastically. I am not using
> anything else than xmms, so I did not figure out if it is a xmms or a
> driver problem. Stop/Starting the listening stops the scrambling.

This is exactly the problem that I have experienced since a while now.
The problem is that some interrupts get lost. This results in a broken
address calculation and the new data is written to the wrong place.

The attached patch fixes this by checking the 'frame_count'.
What I don't really understand is, that the first time the interrupt
gets executed, the frame_count is 8 _less_ of what I would have expected
My guess is that the dma controller reads the last 32 bytes, and then
the interrupt gets fired.

diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
index 9eadf83..8511234 100644
--- a/soundbus/i2sbus/i2sbus-pcm.c
+++ b/soundbus/i2sbus/i2sbus-pcm.c
@@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
 			return -ENXIO;
 		}
=20
+		/* get the current frame_count - 32 bytes. This is just guessed,
+		   but it seems that the interrupt triggers as soon as the last 32 bytes
+		   are cached or something. */
+		pi->frame_count =3D in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi=
->substream->runtime->sample_bits / 8);
+
 		/* wake up the chip with the next descriptor */
 		out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
 		/* off you go! */
@@ -488,13 +493,29 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
 static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
 {
 	struct pcm_info *pi;
+	u32 fc;
+	u32 delta;
=20
 	get_pcm_info(i2sdev, in, &pi, NULL);
 	if (!pi->substream) {
 		printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx")=
;
 		return;
 	}
-	pi->current_period =3D (pi->current_period+1) % (pi->periods);
+=09
+	fc =3D in_le32(&i2sdev->intfregs->frame_count);
+	/* a counter overflow does not change the calculation. */
+	delta =3D fc - pi->frame_count;
+=09
+	if (delta <=3D pi->substream->runtime->period_size) {
+		pi->current_period =3D pi->current_period + 1;
+		delta =3D 0;
+	} else while (delta >=3D pi->substream->runtime->period_size) {
+		pi->current_period =3D pi->current_period + 1;
+		delta =3D delta - pi->substream->runtime->period_size;
+	}
+=09
+	pi->frame_count =3D fc - delta;
+	pi->current_period =3D pi->current_period % pi->periods;
 	snd_pcm_period_elapsed(pi->substream);
 }
=20
diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
index b054e02..f5d16aa 100644
--- a/soundbus/i2sbus/i2sbus.h
+++ b/soundbus/i2sbus/i2sbus.h
@@ -41,6 +41,7 @@ struct pcm_info {
 	struct snd_pcm_substream *substream;
 	int current_period;
 	int periods;
+	u32 frame_count;
 	struct dbdma_command_mem dbdma_ring;
 	volatile struct dbdma_regs __iomem *dbdma;
 };

Re: snd-aoa status update / automatic driver loading

[Benjamin Herrenschmidt]

On Sat, 2006-05-20 at 16:57 +0200, Benjamin Berg wrote:
> On Thu, 2006-18-05 at 09:41 +0900, Charles Plessy wrote: 
> > Hi all,
> > 
> > just a "me too" mail:
> > 
> > Le Thu, May 18, 2006 at 12:02:01AM +0200, Børge Holen a écrit :
> > > I can also remember half way throught a ogg/mp3 playlist when it also 
> > > scrambled the output, this has only happened ONCE.
> > 
> > I experience the same on my 8,1 powermac, but more systematically. It
> > takes usually more than one hour of continuous listening before it
> > happens, and then it happens sort of stochastically. I am not using
> > anything else than xmms, so I did not figure out if it is a xmms or a
> > driver problem. Stop/Starting the listening stops the scrambling.
> 
> This is exactly the problem that I have experienced since a while now.
> The problem is that some interrupts get lost. This results in a broken
> address calculation and the new data is written to the wrong place.

See my other mail about that. Worth tracking down. As far as the DBDMA
handling is concerned, I think walking the descriptors and harvesting
status bits is a better approach as it also allows you to get error
status if you ever get any. Now, if you can have some reliable frame
counter, that's definitely something to look into passing userland too.

> The attached patch fixes this by checking the 'frame_count'.
> What I don't really understand is, that the first time the interrupt
> gets executed, the frame_count is 8 _less_ of what I would have expected
> My guess is that the dma controller reads the last 32 bytes, and then
> the interrupt gets fired.

The DBDMA definitely has a fifo. By the time you get the IRQ, it may
have started pumping the "next" packet. 32 bytes sounds about right for
the DBDMA fifo... old DBDMAs had 16 bits iirc but I could imagine Apple
improving that.

> diff --git a/soundbus/i2sbus/i2sbus-pcm.c b/soundbus/i2sbus/i2sbus-pcm.c
> index 9eadf83..8511234 100644
> --- a/soundbus/i2sbus/i2sbus-pcm.c
> +++ b/soundbus/i2sbus/i2sbus-pcm.c
> @@ -440,6 +440,11 @@ static int i2sbus_pcm_trigger(struct i2s
>  			return -ENXIO;
>  		}
>  
> +		/* get the current frame_count - 32 bytes. This is just guessed,
> +		   but it seems that the interrupt triggers as soon as the last 32 bytes
> +		   are cached or something. */
> +		pi->frame_count = in_le32(&i2sdev->intfregs->frame_count) - 0x20 / (pi->substream->runtime->sample_bits / 8);
> +
>  		/* wake up the chip with the next descriptor */
>  		out_le32(&pi->dbdma->control, (RUN|WAKE) | ((RUN|WAKE)<<16));
>  		/* off you go! */
> @@ -488,13 +493,29 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
>  static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
>  {
>  	struct pcm_info *pi;
> +	u32 fc;
> +	u32 delta;
>  
>  	get_pcm_info(i2sdev, in, &pi, NULL);
>  	if (!pi->substream) {
>  		printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
>  		return;
>  	}
> -	pi->current_period = (pi->current_period+1) % (pi->periods);
> +	
> +	fc = in_le32(&i2sdev->intfregs->frame_count);
> +	/* a counter overflow does not change the calculation. */
> +	delta = fc - pi->frame_count;
> +	
> +	if (delta <= pi->substream->runtime->period_size) {
> +		pi->current_period = pi->current_period + 1;
> +		delta = 0;
> +	} else while (delta >= pi->substream->runtime->period_size) {
> +		pi->current_period = pi->current_period + 1;
> +		delta = delta - pi->substream->runtime->period_size;
> +	}
> +	
> +	pi->frame_count = fc - delta;
> +	pi->current_period = pi->current_period % pi->periods;
>  	snd_pcm_period_elapsed(pi->substream);
>  }
>  
> diff --git a/soundbus/i2sbus/i2sbus.h b/soundbus/i2sbus/i2sbus.h
> index b054e02..f5d16aa 100644
> --- a/soundbus/i2sbus/i2sbus.h
> +++ b/soundbus/i2sbus/i2sbus.h
> @@ -41,6 +41,7 @@ struct pcm_info {
>  	struct snd_pcm_substream *substream;
>  	int current_period;
>  	int periods;
> +	u32 frame_count;
>  	struct dbdma_command_mem dbdma_ring;
>  	volatile struct dbdma_regs __iomem *dbdma;
>  };
> 
> 

Re: snd-aoa status update / automatic driver loading

[Hollis Blanchard]

On Wed, 17 May 2006 12:09:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8
> * PowerBook5,7
> * PowerMac8,1
> * PowerMac8,2
> * 17" October 2005 PowerBook (don't know the number)
> * PowerMac11,2
> * PowerBook6,8
> and my
> * PowerBook5,6
> 
> People with those machines are encouraged to use and stress-test it,
> it also provides much better hardware support than snd-powermac, for
> example it can actually reprogram the hardware if you have a 48KHz
> file instead of having to digitally downsample it to 44.1KHz like
> required with snd-powermac in most cases.

The "auto-loading" stuff doesn't seem to be working for me on my
PowerMac11,2, with a fresh git clone as of right now. What is the base
module that should load all the others? After a "make install", I still
had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
in the source directory to get a list).

When the driver finally did completely load, I saw this in dmesg:
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd: Unknown layout ID 0x44
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus:    fcr0 = 0x8000056
i2sbus:    cell_control = 0x5b43831a
i2sbus:    fcr2 = 0xe7008000
i2sbus:    fcr3 = 0x72009607
i2sbus:    clock_control = 0x0
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
serial format: 0x41100000
dws: 0x0
all codec info:
        formats = 0x808
        rates = 0x7fe

For the record, there are two "layout-id" properties in my device tree,
as discussed in this patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=4867

Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
headphone jack was enabled; I had to use GNOME's "Volume Control" panel
applet to enable speakers or line out (both of which work).

However, volume control doesn't work at all, for both line-out and
headphone jacks. Should it?

Also, it would be helpful if the git tree were better publicized
somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.
	mkdir snd-aoa
	cd snd-aoa/
	git clone http://johannes.sipsolutions.net/snd-aoa.git/ 
	cd snd-aoa/ 
	make

-Hollis

P.S. Thanks for working on this Johannes!

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:

> The "auto-loading" stuff doesn't seem to be working for me on my
> PowerMac11,2, with a fresh git clone as of right now. What is the base
> module that should load all the others? After a "make install", I still
> had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
> in the source directory to get a list).

Odd. i2sbus should pull in all other required modules, and should itself
load automatically at boot due to having a modalias that matches the
of:... modalias the mac-io bus device for the i2s stuff has.

> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance
> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance

Uh. That one I need to check, there is no tas codec on your machine.

> snd: Unknown layout ID 0x44

That looks like you have snd-powermac loaded too. Or not? I don't think
I have anything that prints "snd:" as the prefix but I might be wrong.

> snd-aoa-fabric-layout: found bus with layout 68 (using)
> snd-aoa: fabric didn't like codec tas
> snd-aoa: fabric didn't like codec tas
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> snd-aoa: fabric didn't like codec onyx
> snd-aoa-codec-onyx: created and attached onyx instance
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: can use this codec
> snd-aoa-codec-onyx: attached to onyx codec via i2c
> snd-aoa-codec-onyx: created and attached onyx instance

Most of this is due to that device-tree bug on those machines.

> For the record, there are two "layout-id" properties in my device tree,
> as discussed in this patch:
> http://patchwork.ozlabs.org/linuxppc/patch?id=4867

Note that the patch is mine :)
But also note that this isn't the reason that there are two layout-id
properties, there really *are* two sound nodes with layout-id property
because there are two i2s busses for the two codecs.

> Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
> headphone jack was enabled; I had to use GNOME's "Volume Control" panel
> applet to enable speakers or line out (both of which work).
> 
> However, volume control doesn't work at all, for both line-out and
> headphone jacks. Should it?

Yes, it should. I think the bug is that the tas module thinks it can
attach a codec here. Can you try *not* loading that module and see if it
works better then? I'll try to see if I can make the tas module not
attach on those machines, but as long as you don't load it manually all
should be fine.

> Also, it would be helpful if the git tree were better publicized
> somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.

Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/ and
will add a few more details later.

johannes

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

Re: snd-aoa status update / automatic driver loading

[Hollis Blanchard]

On Tue, 23 May 2006 14:27:52 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> --44731b52_16deb9ec_c30
> 
> gpg: Signature made Tue 23 May 2006 07:27:49 AM CDT using RSA key ID
> 227A1158 gpg: Can't check signature: public key not found
> 
> --44731b52_16deb9ec_c30
> 
> On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:
> 
> > The "auto-loading" stuff doesn't seem to be working for me on my
> > PowerMac11,2, with a fresh git clone as of right now. What is the
> > base module that should load all the others? After a "make
> > install", I still had to modprobe almost everything by hand
> > (`find ./snd-aoa -name \*.ko` in the source directory to get a
> > list).
> 
> Odd. i2sbus should pull in all other required modules, and should
> itself load automatically at boot due to having a modalias that
> matches the of:... modalias the mac-io bus device for the i2s stuff
> has.

Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
module. That seems to be working now. Again, from PowerMac11,2:
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus:    fcr0 = 0x8000056
i2sbus:    cell_control = 0x5b43b71a
i2sbus:    fcr2 = 0xe7008000
i2sbus:    fcr3 = 0x7200d607
i2sbus:    clock_control = 0x0
i2sbus: found i2s controller
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
serial format: 0x41100000
dws: 0x0
...
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx

> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
> 
> Uh. That one I need to check, there is no tas codec on your machine.

This is probably just because I loaded all the modules I could find.

> > snd: Unknown layout ID 0x44
> 
> That looks like you have snd-powermac loaded too. Or not? I don't
> think I have anything that prints "snd:" as the prefix but I might be
> wrong.

Yes, it looks like snd-powermac was loading as well, thanks to
modules.conf. I've removed that now.

> > For the record, there are two "layout-id" properties in my device
> > tree, as discussed in this patch:
> > http://patchwork.ozlabs.org/linuxppc/patch?id=3D4867
> 
> Note that the patch is mine :)

I noted that. Since most of the archived mails aren't overly helpful, I
was trying to be complete.

> > Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only
> > the headphone jack was enabled; I had to use GNOME's "Volume
> > Control" panel applet to enable speakers or line out (both of which
> > work).
> >=20
> > However, volume control doesn't work at all, for both line-out and
> > headphone jacks. Should it?
> 
> Yes, it should. I think the bug is that the tas module thinks it can
> attach a codec here. Can you try *not* loading that module and see if
> it works better then? I'll try to see if I can make the tas module not
> attach on those machines, but as long as you don't load it manually
> all should be fine.

Volume control does indeed work when the tas module isn't loaded.

> > Also, it would be helpful if the git tree were better publicized
> > somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig
> > through =
> a LOT of mails to find the source.
> 
> Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/
> and will add a few more details later.

Could you also add a sample modules.conf? For example, users should be
told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
alias snd-card-0 i2sbus
remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
|| : ; }; /sbin/modprobe -r --ignore-remove snd-powermac

Thanks again!

-Hollis

Re: snd-aoa status update / automatic driver loading

[Hollis Blanchard]

On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:
> 
> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
> alias snd-card-0 i2sbus
> remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
> || : ; }; /sbin/modprobe -r --ignore-remove snd-powermac

Oops, obviously that last "snd-powermac" shouldn't be there; I just
edited what FC5 had put there and I missed a spot. Maybe this will be
better:
alias snd-card-0 i2sbus
remove i2sbus { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove i2sbus

Also, the file is called modprobe.conf... :)

-Hollis

Re: snd-aoa status update / automatic driver loading

[Johannes Berg]

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

On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:

> Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
> module. 

Heh, yeah, sorry. Thing is, if you'd have just installed the modules and
rebooted, it would have worked :)

> That seems to be working now. Again, from PowerMac11,2:

Yeah looks fine, except I just fixed a very stupid bug in the i2sbus
module. Please don't try to remove it after loading, until you upgrade
to the current version.


> This is probably just because I loaded all the modules I could find.

I tried changing the tas module to detect if the codec *really is
present*, but failed. There's some code in there, but I'll solicit some
help with that later.

> Volume control does indeed work when the tas module isn't loaded.

Interesting, but good to know. I'd have thought that the fabric would
not take the codec into use. Will see if I can fix that.

> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac.

Good point. Everything else should not be necessary though, since the
i2sbus module should automatically load due to having a macio modalias.

johannes

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