Bug 66397 - No sound on Panasonic CF-72 Laptop
Summary: No sound on Panasonic CF-72 Laptop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-06-09 23:48 UTC by Michael Olson
Modified: 2007-04-18 16:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-10 18:12:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kernel Patch for Maestro3 driver (2.87 KB, patch)
2002-06-09 23:52 UTC, Michael Olson
no flags Details | Diff

Description Michael Olson 2002-06-09 23:48:45 UTC
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:

Steps to Reproduce:
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.

Comment 1 Michael Olson 2002-06-09 23:52:32 UTC
Created attachment 60244 [details]
Kernel Patch for Maestro3 driver

Comment 2 Tom "spot" Callaway 2002-09-03 20:25:37 UTC
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.

Comment 3 Alan Cox 2002-09-03 20:33:31 UTC
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

Comment 4 Brown, Zach 2002-09-03 20:40:30 UTC
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.

Comment 5 Michael Olson 2002-09-03 23:18:54 UTC
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 
                Status: D0 PME-Enable- DSel=0 DScale=0 PME- 

Comment 6 Alan Cox 2002-09-04 10:46:53 UTC
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

Comment 7 Alan Cox 2002-09-05 13:28:28 UTC
Added to my base 2.4.20pre5-ac tree with autodetection by svid/ssid

Note You need to log in before you can comment on or make changes to this bug.