Date: Sun, 3 May 1998 16:11:04 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/6495: Need pci_unmap_mem and pci_unmap_port routines Message-ID: <199805032211.QAA13046@narnia.plutotech.com>
next in thread | raw e-mail | index | archive | help
>Number: 6495 >Category: kern >Synopsis: Need pci_unmap_mem and pci_unmap_port routines >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun May 3 15:20:02 PDT 1998 >Last-Modified: >Originator: Justin T. Gibbs >Organization: Pluto Technologies International Inc. >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD of any vintage supporting PCI >Description: The pci_map_* routines are only reflexive when it comes to interrupt registration. Drivers may want to release their memory and port mappings as well. For instance, the BusLogic/Mylex MultiMaster driver for CAM performs a pci_mem_map during it's probe to ensure that the device is functional and to disable any ISA compatibility ports. All resources (at least those for which an API exists to do so) are freed before the probe completes. The code is written this way so that no ordering between the probe and attach routines are relied on although it is assumed that ISA probes will follow PCI probes. When the attach routine is called, the resources are allocated again which results in the registers for the card to be mapped in a second time. If resource accounting was in place, this would cause a failure. Right now it simply causes us to consume a little extra KVA. >How-To-Repeat: See above. >Fix: Probably need a pmap_unmap_device to implement pci_unmap_mem?? >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805032211.QAA13046>