please review alsaconf patch

[Martin Habets]

I created the patch below to make alsaconf work with the DBRI and
CS4231 chips. But I'm not sure if this will work for the AMD7930
chip. The patch tries to find a "SUNW,AMD7930*" directory in this
case, but I don't know if that exists. Can somebody with an AMD7930
sound chip confirm/deny this?

Other feedback (like better approaches) is welcome too. I'll submit
it to Takashi once the AMD7930 issue is resolved.

--
Martin

--- alsaconf.orig 2005-10-25 16:00:11.000000000 +0100
+++ alsaconf 2005-10-25 17:17:51.000000000 +0100
@@ -696,6 +696,27 @@
echo "PowerMac $i" >> $FOUND
done
fi
+
+ #
+ # Sparc
+ #
+ if grep -q Sparc $PROCFS/cpuinfo; then
+ test -r $PROCFS/openprom || /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1
+ /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ while read i; do
+ i=${i##*/}
+ i=${i%%.o}
+ i=${i%%.ko}
+ sdev=`echo ${i#snd-sun-} | tr "[a-z]" "[A-Z]"`
+
+ if test -r $PROCFS/openprom; then
+ find $PROCFS/openprom -follow -type d -name "SUNW,${sdev}*" \
+ -exec echo "$sdev $i" \; 2>/dev/null >> $FOUND
+ else
+ echo "$sdev $i" >> $FOUND
+ fi
+ done
+ fi
}

#

--
To UNSUBSCRIBE, email to debian-spa...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Roland Stigge]

Roland Stigge wrote:
> Is this problem related to the above

Forget this line.

[Roland Stigge]

Hi Martin,

you wrote:
> I created the patch below to make alsaconf work with the DBRI and
> CS4231 chips. But I'm not sure if this will work for the AMD7930
> chip. The patch tries to find a "SUNW,AMD7930*" directory in this
> case, but I don't know if that exists. Can somebody with an AMD7930
> sound chip confirm/deny this?
>
> Other feedback (like better approaches) is welcome too. I'll submit
> it to Takashi once the AMD7930 issue is resolved.

I tried with my CS4231 and that didn't work. Loading the module
snd-sun-cs4231 manually works fine.

Maybe the following debug output is of interest:

# /sbin/modprobe -a -l | grep 'snd-sun-'
/lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-cs4231.ko
/lib/modules/2.6.12-1-sparc64/kernel/sound/sparc/snd-sun-amd7930.ko

/proc/openprom# find /proc/openprom -follow -type d -name "SUNW,*"
/proc/openprom/packages/SUNW,builtin-drivers
/proc/openprom/SUNW,UltraSPARC-III@40,0
/proc/openprom/pci@40,4600000/SUNW,qlc@4
/proc/openprom/upa@40,4480000/SUNW,afb@1c,0

(On A SunBlade 1000.)

So there's no 'SUNW,CS4231*' which results in the whole patch giving no
output.

Is this problem related to the above

bye,
Roland

[Martin Habets]

Roland,

Thanks for the info. I guess you must have an "audio" device on the
ebus then, and I failed to check for that in my original patch.
Could you try the patch attached in stead of the original one, please?

This patch may also work for the AMD7930, and I would be gratefull if
someone with an AMD7930 could test it.

Thanks,
Martin

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

--- alsaconf.orig 2005-10-25 16:00:11.000000000 +0100

+++ alsaconf 2005-10-31 13:02:07.000000000 +0000
@@ -696,6 +696,40 @@

echo "PowerMac $i" >> $FOUND
done
fi
+
+ #
+ # Sparc
+ #
+ if grep -q Sparc $PROCFS/cpuinfo; then
+ test -r $PROCFS/openprom || /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1

+ # Check for an "audio" device
+ audio=
+ compat=

+ if test -r $PROCFS/openprom; then

+ audio=`find $PROCFS/openprom -follow -type d -name "audio" -print`
+ fi
+ if test -n "$audio"; then
+ compat=`cat $audio/compatible`
+ compat=${compat#SUNW,}
+ fi
+ # Go through all cards we have

+ /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ while read i; do
+ i=${i##*/}
+ i=${i%%.o}
+ i=${i%%.ko}
+ sdev=`echo ${i#snd-sun-} | tr "[a-z]" "[A-Z]"`
+

+ if test "$sdev" = "$compat"; then

+ echo "$sdev $i" >> $FOUND

+ elif test -r $PROCFS/openprom; then

+ find $PROCFS/openprom -follow -type d -name "SUNW,${sdev}*" \
+ -exec echo "$sdev $i" \; 2>/dev/null >> $FOUND
+ else
+ echo "$sdev $i" >> $FOUND
+ fi
+ done
+ fi
}

#

[Frans Pop]

On Monday 31 October 2005 14:11, Martin Habets wrote:
> + /sbin/modprobe -a -l | grep 'snd-sun-' | \

Hmmm. Is "-a -l" correct for modprobe? -l is supposed to list modules, -a
to insert (load) them...
I doubt that the intention here is to try to actually load all modules
available on the system, so why "-a"? Or am I missing something?

From the manpage, -l takes a wildcard, thus why not just use
modprobe -l snd-sun-*
?

Also from the manpage it looks like both the -a and the -l options are
deprecated and using something like
find /lib/modules/$(uname -r)/kernel/ -name "snd-sun-*"
is suggested instead.

Cheers,
FJP

[Roland Stigge]

Hi,

Martin Habets wrote:
> Thanks for the info. I guess you must have an "audio" device on the
> ebus then, and I failed to check for that in my original patch.
> Could you try the patch attached in stead of the original one, please?

Unfortunately, it didn't work out-of-the-box. With a bit of polishing I
could at least make it run (see attached incremental patch to your changes).

Some comments to the respective changes:

(1) $PROCFS was not defined, so I set it manually. I didn't know where
you intended it to come from so I just set it in the beginning of the
patch to /proc.

(2) I guess you meant mounting openpromfs in case /proc/openprom exists?
Therefore && instead of ||.

(3) Under /proc/openprom/pci@40,4700000/ebus@5, I have a directory
called "audio@1,200000". Therefore, I needed to search for "audio*"
instead of "audio".

(4) The file "compatible" contains: "'SUNW,CS4231'" (with single
quotes). I needed to remove them.

Now, alsaconf detects the device fine. (Also consider FJP's comments on
using modprobe.)

However, there are some issues left with my CS4231: On bootup, the
modules are not loaded automatically (even hotplug doesn't care about
them). So I need to put "snd-sun-cs4231" into /etc/modules. Further,
when I want to play something (e.g., with xmms), I often (unpredictably)
get (white?) noise. Retrying helps every 3rd or 4th time. Maybe
alignment or endianess issues. But these are different issues and not
related to alsaconf I think. If noone else has experienced this yet, I
will need to dive into the driver myself later.

Thanks for now.

bye,
Roland

[Martin Habets]

To be honest, I just copied that line from the powermac code.
Wrong move it seems. I'll replace it with find as suggested.

Thanks,
Martin

[Martin Habets]

On Tue, Nov 01, 2005 at 01:45:56PM +0100, Roland Stigge wrote:
> Hi,
>
> Martin Habets wrote:
> > Thanks for the info. I guess you must have an "audio" device on the
> > ebus then, and I failed to check for that in my original patch.
> > Could you try the patch attached in stead of the original one, please?
>
> Unfortunately, it didn't work out-of-the-box. With a bit of polishing I
> could at least make it run (see attached incremental patch to your changes).
>
> Some comments to the respective changes:
>
> (1) $PROCFS was not defined, so I set it manually. I didn't know where
> you intended it to come from so I just set it in the beginning of the
> patch to /proc.

It is set at line 30 of the script. Maybe you are using an old version of
alsconf?

> (2) I guess you meant mounting openpromfs in case /proc/openprom exists?
> Therefore && instead of ||.

I meant to mount it if it has not been mounted yet. Fixed the code for this.

> (3) Under /proc/openprom/pci@40,4700000/ebus@5, I have a directory
> called "audio@1,200000". Therefore, I needed to search for "audio*"
> instead of "audio".
>
> (4) The file "compatible" contains: "'SUNW,CS4231'" (with single
> quotes). I needed to remove them.
>
> Now, alsaconf detects the device fine. (Also consider FJP's comments on
> using modprobe.)

Thanks for testing and for the fixes.

> However, there are some issues left with my CS4231: On bootup, the
> modules are not loaded automatically (even hotplug doesn't care about
> them). So I need to put "snd-sun-cs4231" into /etc/modules. Further,
> when I want to play something (e.g., with xmms), I often (unpredictably)
> get (white?) noise. Retrying helps every 3rd or 4th time. Maybe
> alignment or endianess issues. But these are different issues and not
> related to alsaconf I think. If noone else has experienced this yet, I
> will need to dive into the driver myself later.

What kernel version are you on? A number of patches have been submitted
on the sparclinux list in the last 2 months, the last one on october 29th.
If you have those, it is best to follow up with Georg Chini on this.

Thanks,
Martin
---------------------------------------------------------------------------
--- alsaconf.orig 2005-10-31 13:02:07.000000000 +0000
+++ alsaconf 2005-11-02 08:16:08.000000000 +0000
@@ -688,7 +688,8 @@
# PowerMac
#
if grep -q MacRISC $PROCFS/cpuinfo; then
- /sbin/modprobe -a -l | grep 'snd-powermac' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-powermac' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -701,19 +702,22 @@
# Sparc
#

if grep -q Sparc $PROCFS/cpuinfo; then

- test -r $PROCFS/openprom || /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1
+ test -r $PROCFS/openprom/name || /bin/mount -t openpromfs none $PROCFS/openprom >/dev/null 2>&1

# Check for an "audio" device

audio=
compat=

if test -r $PROCFS/openprom; then

- audio=`find $PROCFS/openprom -follow -type d -name "audio" -print`
+ audio=`find $PROCFS/openprom -follow -type d -name "audio*" -print`
fi

if test -n "$audio"; then

compat=`cat $audio/compatible`
+ compat=${compat#\'}
+ compat=${compat%\'}
compat=${compat#SUNW,}
fi

# Go through all cards we have

- /sbin/modprobe -a -l | grep 'snd-sun-' | \
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -name 'snd-sun-*' -print | \
while read i; do
i=${i##*/}
i=${i%%.o}
@@ -1339,7 +1343,8 @@

if [ -s "$FOUND" ]; then
while read dev card ; do
- /sbin/modprobe -a -l | grep -q -E $card'\.(o|ko)' || continue
+ MODDIR=/lib/modules/`uname -r`
+ find $MODDIR -type f | grep -q -E $card'\.(o|ko)' || continue
cardname=`find_device_name $dev | cut -c 1-64`
if [ -z "$cardname" ]; then
cardname="$card"

[Roland Stigge]

Martin Habets wrote:
>>(1) $PROCFS was not defined, so I set it manually. I didn't know where
>>you intended it to come from so I just set it in the beginning of the
>>patch to /proc.
>
> It is set at line 30 of the script. Maybe you are using an old version of
> alsconf?

The one from unstable, and indeed the experimental version sets $PROCFS.
But that shouldn't make a difference for the other points. I need to
stick with unstable; for my taste, it's unstable enough. ;)

>>(2) I guess you meant mounting openpromfs in case /proc/openprom exists?
>>Therefore && instead of ||.
>
> I meant to mount it if it has not been mounted yet. Fixed the code for this.

Wouldn't it even better if we leave the system in the state we found it?
I.e. unmounting in the end if mounting in the beginning.

bye,
Roland

[Martin Habets]

On Wed, Nov 02, 2005 at 09:54:59PM +0100, Roland Stigge wrote:
> Martin Habets wrote:
> >>(1) $PROCFS was not defined, so I set it manually. I didn't know where
> >>you intended it to come from so I just set it in the beginning of the
> >>patch to /proc.
> >
> > It is set at line 30 of the script. Maybe you are using an old version of
> > alsconf?
>
> The one from unstable, and indeed the experimental version sets $PROCFS.
> But that shouldn't make a difference for the other points. I need to
> stick with unstable; for my taste, it's unstable enough. ;)

Ok, that explains. I created the patch against ALSA 1.0.10rc1, as it will
go into ALSA CVS. From there it will be picked up by all distro's.
So it will be a while before this hits debian stable :)

> >>(2) I guess you meant mounting openpromfs in case /proc/openprom exists?
> >>Therefore && instead of ||.
> >
> > I meant to mount it if it has not been mounted yet. Fixed the code for this.
>
> Wouldn't it even better if we leave the system in the state we found it?
> I.e. unmounting in the end if mounting in the beginning.

Yes that would be better, but I consider that a bit overkill.

--
Martin