From owner-svn-src-head@FreeBSD.ORG Sun Aug 22 21:26:36 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0A510656A4; Sun, 22 Aug 2010 21:26:36 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8438FC17; Sun, 22 Aug 2010 21:26:36 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id o7MLQaPS016671; Sun, 22 Aug 2010 21:26:36 GMT (envelope-from yongari@svn.freebsd.org) Received: (from yongari@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id o7MLQavY016669; Sun, 22 Aug 2010 21:26:36 GMT (envelope-from yongari@svn.freebsd.org) Message-Id: <201008222126.o7MLQavY016669@svn.freebsd.org> From: Pyun YongHyeon Date: Sun, 22 Aug 2010 21:26:36 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r211648 - head/sys/pci X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 21:26:36 -0000 Author: yongari Date: Sun Aug 22 21:26:35 2010 New Revision: 211648 URL: http://svn.freebsd.org/changeset/base/211648 Log: It seems some newer RTL8139 controllers provides only memory space register mapping. I'm not sure whether it comes from the fact that controllers live behind certain PCI brdge(PLX PCI 6152 33BC) and the bridge has some issues in handling I/O space register mapping. Unfortunately it's not possible to narrow down to an exact controller that shows this issue because RealTek used the same PCI device/revision id again. In theory, it's possible to check parent PCI bridge device and change rl(4) to use memory space register mapping if the parent PCI bridge is PLX PCI 6152. But I didn't try to do that and we wouldn't get much benefit with added complexity. Blindly switching to use memory space register mapping for rl(4) may make most old controllers not to work. At least, I don't want to take potential risk from such change. So use I/O space register mapping by default but give users chance to override it via a tunable. The tunable to use memory space register mapping would be given by adding the following line to /boot/loader.conf file. dev.rl.%d.prefer_iomap="0" This change makes P811B quad-port work with this tunable. Tested by: Nikola Kalpazanov ( n.kalpazanov <> gmail dot com ) MFC after: 1 week Modified: head/sys/pci/if_rl.c Modified: head/sys/pci/if_rl.c ============================================================================== --- head/sys/pci/if_rl.c Sun Aug 22 21:25:21 2010 (r211647) +++ head/sys/pci/if_rl.c Sun Aug 22 21:26:35 2010 (r211648) @@ -125,16 +125,6 @@ MODULE_DEPEND(rl, miibus, 1, 1, 1); /* "device miibus" required. See GENERIC if you get errors here. */ #include "miibus_if.h" -/* - * Default to using PIO access for this driver. On SMP systems, - * there appear to be problems with memory mapped mode: it looks like - * doing too many memory mapped access back to back in rapid succession - * can hang the bus. I'm inclined to blame this on crummy design/construction - * on the part of RealTek. Memory mapped mode does appear to work on - * uniprocessor systems though. - */ -#define RL_USEIOSPACE - #include /* @@ -225,14 +215,6 @@ static void rl_watchdog(struct rl_softc static void rl_setwol(struct rl_softc *); static void rl_clrwol(struct rl_softc *); -#ifdef RL_USEIOSPACE -#define RL_RES SYS_RES_IOPORT -#define RL_RID RL_PCI_LOIO -#else -#define RL_RES SYS_RES_MEMORY -#define RL_RID RL_PCI_LOMEM -#endif - static device_method_t rl_methods[] = { /* Device interface */ DEVMETHOD(device_probe, rl_probe), @@ -806,7 +788,7 @@ rl_attach(device_t dev) struct sysctl_ctx_list *ctx; struct sysctl_oid_list *children; int error = 0, hwrev, i, pmc, rid; - int unit; + int prefer_iomap, unit; uint16_t rl_did = 0; char tn[32]; @@ -828,10 +810,31 @@ rl_attach(device_t dev) pci_enable_busmaster(dev); - /* Map control/status registers. */ - rid = RL_RID; - sc->rl_res = bus_alloc_resource_any(dev, RL_RES, &rid, RF_ACTIVE); + /* + * Map control/status registers. + * Default to using PIO access for this driver. On SMP systems, + * there appear to be problems with memory mapped mode: it looks + * like doing too many memory mapped access back to back in rapid + * succession can hang the bus. I'm inclined to blame this on + * crummy design/construction on the part of RealTek. Memory + * mapped mode does appear to work on uniprocessor systems though. + */ + prefer_iomap = 1; + snprintf(tn, sizeof(tn), "dev.rl.%d.prefer_iomap", unit); + TUNABLE_INT_FETCH(tn, &prefer_iomap); + if (prefer_iomap) { + sc->rl_res_id = PCIR_BAR(0); + sc->rl_res_type = SYS_RES_IOPORT; + sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, + &sc->rl_res_id, RF_ACTIVE); + } + if (prefer_iomap == 0 || sc->rl_res == NULL) { + sc->rl_res_id = PCIR_BAR(1); + sc->rl_res_type = SYS_RES_MEMORY; + sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, + &sc->rl_res_id, RF_ACTIVE); + } if (sc->rl_res == NULL) { device_printf(dev, "couldn't map ports/memory\n"); error = ENXIO; @@ -1029,7 +1032,8 @@ rl_detach(device_t dev) if (sc->rl_irq[0]) bus_release_resource(dev, SYS_RES_IRQ, 0, sc->rl_irq[0]); if (sc->rl_res) - bus_release_resource(dev, RL_RES, RL_RID, sc->rl_res); + bus_release_resource(dev, sc->rl_res_type, sc->rl_res_id, + sc->rl_res); if (ifp) if_free(ifp);