From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
Everything loads and looks like it's working correctly but no sound.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Try to play sound
Actual Results: Not much
Expected Results: Sound
The ESS Allegro chipset supports interfacing with the external amplifier on any
one of several pins. The kernel driver automatically chooses the one that is
used in most implimentations. I created a kernel patch
(http://www.cs.odu.edu/~olson/linux/maestro3.gpio_pin.patch) that makes the pin
number a module option. With this patch applied and the following in
/etc/modules.conf it works great.
alias sound-slot-0 maestro3
options maestro3 gpio_pin=13
I see no reason that it couldn't use the sub-vendor ID (0x833d10f7) to trigger
using the correct pin number but I don't know that there are not different pin
numbers in use by Panasonic on other devices so I figured a module option was
the least likely to blow anyone who was working up.
Created attachment 60244 [details]
Kernel Patch for Maestro3 driver
This bug is STILL unfixed in 7.3/Null... and the patch is relatively painless
from my point of view... is there a reason its been sitting cold for 3 months?
Reassigning to the beta.
Thanks. This is the first I saw of this bug. Its a sensible looking patch. I'll
push it mainstream
What would be even more useful would be the lspci for the device on the
toughbook and the CF-72, we may be able to autodetect them by the
That bit of GPIO code came from obtuse ESS code, who knows what requirements
Different vendors putting the m3 on their board sometimes do very weird things
with the GPIO pins. Some care is probably warranted in messing about with them.
so having it be a module parameter would make me nervous. vendor A puts the
external amp on the gpio pins that this patch wants to touch, vendor B puts an
AC3 asic, and vendor C puts a custom 4-speaker circuit. A user might think that
having the option while they use vendor A's card would mean that they should
have it for vendor B, too, which certainly might not be the case.
Alan's suggestion of keying this off the subvendor/dev id is the right thing.
That said, if the patch seems to work as-is, its probably not significantly
different from the current code base that certainly hasn't derived from any
rigid standards or documentation.
I made it an option rather than autodetecting because I'm not really familar
enough with hardware in general to know what to key off of and didn't want
to risk nuking other peoples working devices.
The output from lspci -vvn follows
00:0d.0 Class 0401: 125d:1988 (rev 12)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
SubSystem is the important one. Thats been set properly with a vendor ID that
seems correct (0x10f7 is Matushita - aka panasonic). That means the code can
test for that subvendor/device pair and set the value automatically
Added to my base 2.4.20pre5-ac tree with autodetection by svid/ssid