From owner-freebsd-current@FreeBSD.ORG Sat May 31 20:46:57 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 612DC37B401 for ; Sat, 31 May 2003 20:46:57 -0700 (PDT) Received: from gold.he.net (gold.he.net [216.218.149.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA1B643F85 for ; Sat, 31 May 2003 20:46:56 -0700 (PDT) (envelope-from daver@gomerbud.com) Received: from tombstone.localnet.gomerbud.com (adsl-64-161-56-54.dsl.snlo01.pacbell.net [64.161.56.54]) by gold.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id UAA14095; Sat, 31 May 2003 20:46:48 -0700 Received: by tombstone.localnet.gomerbud.com (Postfix, from userid 1001) id D1CFE395; Sat, 31 May 2003 20:46:54 -0700 (PDT) Date: Sat, 31 May 2003 20:46:54 -0700 From: "David P. Reese Jr." To: Dag-Erling Smorgrav Message-ID: <20030601034654.GA643@tombstone.localnet.gomerbud.com> References: <20030531210600.GA670@tombstone.localnet.gomerbud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: "David P. Reese Jr." cc: current@freebsd.org Subject: Re: viapropm doesnt like sys/dev/pci.c rev 1.214 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2003 03:46:57 -0000 On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: > "David P. Reese Jr." writes: > > In rev 1.214 of sys/dev/pci/pci.c, we have started checking if a > > pci_set_command_bit() was successful with a subsequent PCI_READ_CONFIG > > and comparing the results. For some odd reason, this doesnt work when > > my viapropm tries to attach. > > viapropm is seriously broken for other reasons and needs professional > help. It will be hard for me to provide that professional help because the chipset docs require an NDA. > > pci_set_command_bit(dev, child, bit); > > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); > > if (command & bit) > > return (0); > > It should allow the register to "settle" between write and read, which > may take some time (see chipset docs for timing details). DELAY(1000) > should be OK in an attach function. Well, using the following patch: Index: pci.c =================================================================== RCS file: /home/daver/cvs-freebsd/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 16 Apr 2003 03:15:08 -0000 1.214 +++ pci.c 1 Jun 2003 02:45:11 -0000 @@ -606,6 +606,9 @@ break; } pci_set_command_bit(dev, child, bit); +#define PCI_CFG_DELAY 10000000 + device_printf(dev, "delaying for %i microseconds\n", PCI_CFG_DELAY); + DELAY(PCI_CFG_DELAY); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command & bit) return (0); I get: viapropm0: SMBus I/O base at 0x5000 viapropm0: port 0x5000-0x500f at device 7.4 on pci0 pci0: delaying for 10000000 microseconds viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 This seems to imply that we don't have a timing problem. Instead it looks like the chip doesn't want reflect it's status in it's command register. Can someone with access to the docs give me a clue? -- David P. Reese Jr. daver@gomerbud.com -------------------------------------------------------------------------- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3)