ESS Maestro3 no sound

[Scott Long]

Pyun YongHyeon wrote:
> On Wed, Jun 29, 2005 at 11:06:09AM +0800, Muzaffar Ariff wrote:
>  > Hi, 
>  > 
>  > I've been trying to configure my maestro3 on a dell latitude (C600)
>  > but can't seem to get it right. Here's what I've done:
>  > 
>  > 1. Identified my sound card by loading the sound driver module:
>  >     #kldload snd_driver
>  > 
>  > 2. Cat /dev/sndstat to see what sound driver it is:
>  >     FreeBSD Audio Driver (newpcm)
>  >     Installed devices:
>  >     pcm0: <ESS Technology Maestro3> at io 0xd800 irq 5 kld snd_maestro3  
>  >     (4p/1r/0v channels duplex default)
>  > 
>  > 3. So then I load the driver directly to /boot/loader.conf:
>  >     snd_maestro3_load="YES"
>  > 
>  > 4. The I reboot the system and used xmms to play my mp3. It runs and
>  > can play the file but no sound! Pump up the volume but nothing
>  > happens. The weird thing is the sound works on Windows. I've search
>  > the startup messages /var/run/dmesg.boot and found the following:
>  > 
>  > pci0: <bridge, PCI-unknown> at device 7.3 (no driver attached)
>  > pcm0: <ESS Technology Maestro3> port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ffffff irq
>  >  5 at device 8.0 on pci0
>  > pcm0: failed: rid 0x10 is ioport, requested 3
>  > pcm0: [GIANT-LOCKED]
>  > pcm0: <SigmaTel STAC9721/23 AC97 Codec>
>  > 
>  > Now could there be something wrong with the pci0 or the pcm0? Any
>  > pointers on how to fix this?
>  > 
> 
> While converting maestro3(4) to MPSAFE one I noticed the same thing.
> Unloading/reloading the driver fixed it. I guess there are cases that
> the hardware were not initialized correctly. But it was hard to
> reproduce it on my system and I just met just two times so far.
> Due to lack of publicly available documentaion from ESS it's also
> difficult to know what is the reason. :-(
> Btw, does the issue vanish away when you cold start your system?
> 
> You may get better chance if the driver is linked into kernel.
> 

It looks like yet more decay in the driver.  When I wrote it, I was lazy
and didn't want to figure out which chip versions preferred IOPORT
mapping and which ones preferred MEMIO, so I just had it try MEMIO first
(since that is a better choice) and then fail back to IOPORT.  The
resource manager seemed to tolerate this back then, but apparently it
doesn't now.  My guess is that the first call to bus_alloc_resource
returns success but actually fails, and in the process it leaks the
resource out of the resource manager.  Then when you unload and load
again, the resource is unavailable (since it was leaked) so the first
call to fails, prompting it to go to the second call which succeeds
fully.  This would mean that there are now a number of bugs in the
resource manager which need to be fixed.

Based on what I've seen over the years, it might be safe to assume that
BAR0 on both the meastro3 and allegro1 is IOPORT and that BAR1 on the
maestro3 is MEMIO.  Thus, the easiest change might be to just remove
the first bus_alloc_resource call and force the driver to always use
IOPORT.  I'd still like to use this as a test case for fixing the deeper
bugs in the resource manager, though.

Scott