From owner-freebsd-hardware@FreeBSD.ORG Wed Dec 12 19:42:59 2007 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E7516A474 for ; Wed, 12 Dec 2007 19:42:59 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id BF1D213C45A for ; Wed, 12 Dec 2007 19:42:59 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id Pqrj1Y0080b6N640A0Tv00; Wed, 12 Dec 2007 19:32:05 +0000 Received: from discordia ([24.60.136.97]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id PvY31Y00B26FYqY0800000; Wed, 12 Dec 2007 19:32:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=Jz7nmYbVmYPoSATaeuEA:9 a=0t0jI6mHxWjvTjR4BluJ1SoMMb8A:4 a=zUBsD6tbDSsA:10 a=j7-v9rbbZuSrASvDk7UA:9 a=Pj-ws0I6_5RAOj0-3P2lstjqmkgA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 2D0651634F6; Wed, 12 Dec 2007 14:31:58 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.31.1.6] (unknown [172.31.1.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 55A651634F6; Wed, 12 Dec 2007 14:31:43 -0500 (EST) Message-ID: <476036E9.9010002@FreeBSD.org> Date: Wed, 12 Dec 2007 14:30:49 -0500 From: Coleman Kane Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: John Baldwin References: <4759730F.6090302@FreeBSD.org> <200712121311.06777.jhb@freebsd.org> In-Reply-To: <200712121311.06777.jhb@freebsd.org> X-Enigmail-Version: 0.96a Content-Type: multipart/mixed; boundary="------------010007030104080402060906" Cc: freebsd-hardware@freebsd.org Subject: Re: Overlapping PCI Memory Locations X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@FreeBSD.org List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 19:42:59 -0000 This is a multi-part message in MIME format. --------------010007030104080402060906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit John Baldwin wrote: > On Friday 07 December 2007 11:21:35 am Coleman Kane wrote: > >> Hi, >> >> I've got a problem where two components on my system have overlapping >> PCI memory regions: >> >> atapci0: port >> > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > >> atapci0: [ITHREAD] >> >> pcm0: mem 0xd0608000-0xd060bfff >> > irq 16 at device 20.2 on pci0 > >> pcm0: hdac_mem_alloc: Unable to allocate memory resource >> >> >> >> Because of this, I cannot use the sound hardware on this system. In >> addition, the memory range used by atapci0 is the SATA AHCI space. The >> ata-chipset.c doesn't currently identify the ATI IXP600 SATA controller >> (just the paired PATA controller), so I can actually use my drives >> through the PATA/IDE compatibility registers in the I/O space. However, >> if I modify ata-chipset.c to add support for the IXP600 SATA controller, >> I get weird results using ATA_INL(..) calls, which look like something >> is interfering with the data I *should* be getting from the SATA mem space. >> >> In addition, the pcm0 refuses to attach, as above. >> >> Also, this is a notebook and has one of those crummy notebook BIOSes >> that don't allow fiddling with this sort of stuff in BIOS. Is there any >> facility in the kernel to force these to be remapped (or to perform the >> mappings ourselves and ignore what BIOS tells us)? >> > > No. You can hack the pci driver to zero out the BAR in either device during > boot though as a test. > What would the kernel do if the BAR were to be zeroed out? I applied the attached fixup to sys/dev/pci/pci.c that allows me to specify the desired base address from a loader.conf tunable. Is there a better way? Is there a project to make a better way? -- Coleman Kane --------------010007030104080402060906 Content-Type: text/x-patch; name="pci.c-hp6715b.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci.c-hp6715b.diff" --- sys/dev/pci/pci.c.orig 2007-12-08 23:57:21.000000000 -0500 +++ sys/dev/pci/pci.c 2007-12-09 22:34:05.000000000 -0500 @@ -2235,6 +2235,9 @@ & PCIM_CMD_MEMEN) != 0; } +static unsigned int hp6715b_membase_for_hd_audio = 0; +TUNABLE_INT("hw.pci.hp6715b_membase_for_hd_audio", &hp6715b_membase_for_hd_audio); + /* * Add a resource based on a pci map register. Return 1 if the map * register is a 32bit map register or 2 if it is a 64bit register. @@ -2267,6 +2270,12 @@ ln2size = pci_mapsize(testval); ln2range = pci_maprange(testval); base = pci_mapbase(map); + if((pci_get_devid(dev) == 0x43831002) && (hp6715b_membase_for_hd_audio != 0)) { + device_printf(dev, "Applying PCI membase fixup for HDA Audio on an HP 6715b notebook to: %08x\n", + hp6715b_membase_for_hd_audio); + base = (pci_addr_t)hp6715b_membase_for_hd_audio; + pci_write_config(dev, 0x10, base | 4, 4); + } barlen = ln2range == 64 ? 2 : 1; /* --------------010007030104080402060906--