From gibbs@narnia.plutotech.com  Sun May  3 15:14:52 1998
Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08747
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 3 May 1998 15:14:50 -0700 (PDT)
          (envelope-from gibbs@narnia.plutotech.com)
Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id QAA13046; Sun, 3 May 1998 16:11:04 -0600 (MDT)
Message-Id: <199805032211.QAA13046@narnia.plutotech.com>
Date: Sun, 3 May 1998 16:11:04 -0600 (MDT)
From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Reply-To: gibbs@narnia.plutotech.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Need pci_unmap_mem and pci_unmap_port routines
X-Send-Pr-Version: 3.2

>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:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun May  3 15:20:02 PDT 1998
>Closed-Date:    Wed Oct 4 20:08:14 PDT 2000
>Last-Modified:  Wed Oct 04 20:09:56 PDT 2000
>Originator:     Justin T. Gibbs
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Pluto Technologies International Inc.
>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??

>Release-Note:
>Audit-Trail:

From: Nate Williams <nate@mt.sri.com>
To: gibbs@narnia.plutotech.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/6495: Need pci_unmap_mem and pci_unmap_port routines
Date: Sun, 3 May 1998 16:55:59 -0600

 > >Number:         6495
 > >Description:
 > 
 > 	The pci_map_* routines are only reflexive when it comes to
 > 	interrupt registration.
 
 Actually, this isn't the case.  The interrupt 'unregistration' is
 certainly not reflexive. :(
 
 
 Nate

From: "Justin T. Gibbs" <gibbs@plutotech.com>
To: Nate Williams <nate@mt.sri.com>
Cc: gibbs@plutotech.com, FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/6495: Need pci_unmap_mem and pci_unmap_port routines 
Date: Sun, 03 May 1998 16:55:17 -0600

 >> >Number:         6495
 >> >Description:
 >> 
 >> 	The pci_map_* routines are only reflexive when it comes to
 >> 	interrupt registration.
 >
 >Actually, this isn't the case.  The interrupt 'unregistration' is
 >certainly not reflexive. :(
 
 Sorry.  I only did a grep.  I didn't look closely enough to see that
 the interface was not implemented yet.
 
 --
 Justin
 
 

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
State-Changed-From-To: open->closed 
State-Changed-By: gibbs 
State-Changed-When: Wed Oct 4 20:08:14 PDT 2000 
State-Changed-Why:  
Obviated by new bus. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6495 
>Unformatted:
