Date: Fri, 1 Jul 2005 11:33:07 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-multimedia@freebsd.org, Muzaffar Ariff <mus.bsd@gmail.com> Subject: Re: ESS Maestro3 no sound Message-ID: <20050701023307.GF17609@rndsoft.co.kr> In-Reply-To: <42C2B94F.2010708@samsco.org> References: <8eb2b81050628200659d338ab@mail.gmail.com> <20050629043027.GB8832@rndsoft.co.kr> <42C2B94F.2010708@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Jun 29, 2005 at 09:07:59AM -0600, Scott Long wrote:
[...]
>
> 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.
>
Thanks for detailed explanation. :-)
Here is patch. Muzaffar, does the patch change your situation?
Btw, I encountered dreasful message "play interrupt timeout, channel dead"
again. Unloading the driver and then reloading the driver fixed it.
Since I see "pci_link2: Unable to choose an IRQ" during driver load
I can't sure it's fault of maestro3(4) driver.
> Scott
PS. Due to mail server issues I sent again.
--
Regards,
Pyun YongHyeon
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="maestro3.resource.diff"
--- maestro3.c.orig Mon May 23 15:27:07 2005
+++ maestro3.c Thu Jun 30 14:55:02 2005
@@ -1203,19 +1203,21 @@
}
}
+ pci_enable_busmaster(dev);
data = pci_read_config(dev, PCIR_COMMAND, 2);
- data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN);
+ data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN);
pci_write_config(dev, PCIR_COMMAND, data, 2);
sc->regid = PCIR_BAR(0);
- sc->regtype = SYS_RES_MEMORY;
+ data = pci_read_config(dev, PCIR_COMMAND, 2);
+ device_printf(dev,"PCIR_COMMAND = 0x%x\n", data);
+ sc->regtype = SYS_RES_IOPORT;
+ if ((data & PCIM_CMD_PORTEN) == 0) {
+ sc->regtype = SYS_RES_MEMORY;
+ device_printf(dev,"using memory mapped I/O\n");
+ }
sc->reg = bus_alloc_resource_any(dev, sc->regtype, &sc->regid,
RF_ACTIVE);
- if (!sc->reg) {
- sc->regtype = SYS_RES_IOPORT;
- sc->reg = bus_alloc_resource_any(dev, sc->regtype, &sc->regid,
- RF_ACTIVE);
- }
if (!sc->reg) {
device_printf(dev, "unable to allocate register space\n");
goto bad;
--FL5UXtIhxfXey3p5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050701023307.GF17609>