From owner-freebsd-questions  Tue Apr 15 02:40:25 1997
Return-Path: <owner-questions>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id CAA29266
          for questions-outgoing; Tue, 15 Apr 1997 02:40:25 -0700 (PDT)
Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA29261
          for <questions@FreeBSD.ORG>; Tue, 15 Apr 1997 02:40:21 -0700 (PDT)
Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id EAA15971; Tue, 15 Apr 1997 04:40:36 -0500 (CDT)
Message-Id: <199704150940.EAA15971@iworks.InterWorks.org>
Date: Tue, 15 Apr 1997 04:40:36 -0500 (CDT)
From: "Daniel M. Eischen" <deischen@iworks.InterWorks.org>
To: dg@root.com
Subject: Re: special memory device
Cc: krygier@kph.uni-mainz.de, questions@FreeBSD.ORG
Sender: owner-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >The problem I have, is that if I create a driver for this chip,
> >how do I ask the PCI support code for 4 consecutive 16MB regions
> >of the PCI bus?  From what I can tell, the PCI code will only let
> >you map an address space as it is defined in the PCI configuration
> >space registers.  For the Tundra Universe chip, the registers
> >that configure the special PCI slave image are not in the PCI         
> >configuration space.  
>
>    The obvious question this raises is: How do you do address space conflict
> resolution if you ignore the assignments made by the PCI BIOS?

Right.  There should probably be a resource list to manage these
addresses.  Drivers would have to call a set of common functions
in order to allocate PCI address space.  The Tundra Universe chip
shares the PCI bus with a DEC 21240 and an Adaptec 7880, so I can't
allocate an address range without ensuring it doesn't conflict.

>    It is possible to map any arbitrary physical address range when not using
> the PCI map routine. In fact if you use a device driver to do this (via the
> device mmap interface, which uses the VM "device pager"), the PCI mapping code
> wouldn't be involved in any case. For examples of this, look at the handling
> of /dev/vga (ttyv0...syscons.c...scmmap()). Very trivial.

Ahh, thanks for the pointer :-)

Dan Eischen
deischen@iworks.InterWorks.org