Date: Mon, 4 May 1998 16:20:01 -0700 (PDT) From: Stefan Esser <se@FreeBSD.ORG> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/6495: Need pci_unmap_mem and pci_unmap_port routines Message-ID: <199805042320.QAA00467@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/6495; it has been noted by GNATS. From: Stefan Esser <se@FreeBSD.ORG> To: gibbs@narnia.plutotech.com, FreeBSD-gnats-submit@freebsd.org Cc: Stefan Esser <se@freebsd.org> Subject: Re: kern/6495: Need pci_unmap_mem and pci_unmap_port routines Date: Tue, 5 May 1998 00:18:47 +0200 On 1998-05-03 16:11 -0600, "Justin T. Gibbs" <gibbs@narnia.plutotech.com> wrote: > >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. The pci_map_mem function just registers a VM mapping, but does not allocate any memory or other system resources (well, it does take 4 bytes per page that is mapped). But I agree, the addition of resource accounting requires the unmap functions to exist ... The port map function actually is a NOP, currently, since all ports are directly accessed through processor instructions that use physical addresses. For that reason, a trivial implementation of the unmap functions is to provide dummy functions that do nothing (or just remove the accounting information). I'm not sure whether a repeated call of "pmap_mapdev()" is permitted and will just return the same virtual address on each invocation. (But David Greenman or John Dyson will know, for sure :) Your comment abput "a little extra KVA" seems to suggest, that a new page table entry is allocated each time, though. The interrupt unmap function does only exist in -stable. I was waiting for changes to the bus-independent device management code (which I expected to replace the current ISA bus specific attach code), but since there has been no sign of such code actually being commited, I might as well implement the interrupt unmap function independently in the new PCI code in -current. > Probably need a pmap_unmap_device to implement pci_unmap_mem?? Yes, that sounds like the function that might do the hard work. But if pmap_mapdev() can be called repeatedly and will return the same information, each time, then the NOP implementation of the unmap functions might be sufficient. We should have the unmap functions for both memory and port ranges in order to support other architecturs, though. Regards, STefan 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?199805042320.QAA00467>