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): How reproducible: Always Steps to Reproduce: 1.Install 2.Try to play sound Actual Results: Not much Expected Results: Sound Additional info: 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 subvendor/subdevice id too.
That bit of GPIO code came from obtuse ESS code, who knows what requirements surround it. 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) Subsystem: 10f7:833d 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 PME(D0-,D1+,D2+,D3hot+,D3cold-) 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