From owner-freebsd-current Thu Jul 18 0:48:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF7AA37B426 for ; Thu, 18 Jul 2002 00:48:24 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id F00C543E5E for ; Thu, 18 Jul 2002 00:48:22 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g6I7m91f023584; Thu, 18 Jul 2002 01:48:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 18 Jul 2002 01:46:37 -0600 (MDT) Message-Id: <20020718.014637.23108139.imp@bsdimp.com> To: Ronald.vanderPol@rvdp.org Cc: frode@nordahl.net, current@FreeBSD.ORG Subject: Re: When will PCI_ENABLE_IO_MODES be default? From: "M. Warner Losh" In-Reply-To: <20020718073741.GA16952@rvdp.org> References: <49500.80.212.246.133.1026946735.squirrel@epost.powertech.no> <20020717.233313.105053781.imp@bsdimp.com> <20020718073741.GA16952@rvdp.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020718073741.GA16952@rvdp.org> Ronald van der Pol writes: : On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote: : : > It is a tiny piece of a larger puzzle that will be fixed as we do : > proper resource allocation now that the BIOS specifications have been : > changed by MS to move that into the OS. : : Can you elaborate on that or give some pointers? Short answer: ACPI. :-) Longer Answer: For some time now MS has had the notion of a Plug and Play OS at the BIOS level. Most BIOSes had the ability to say "This OS is a Plug and Play OS" and would refrain from assigning resources to the pci cards that might be a pita for the PnP OS to deal with down the road. In a Plug and Play OS, it deals with resource issues compeletely and totally (except for devices required to boot the system, iirc). In a non PnP OS, like FreeBSD, the OS expects the BIOS to have assigned all the resources and activated all the cards. For years, this worked great. ACPI can be viewed as an even more extensive attempt to get the OS to assign all the resources to the cards. Now with ACPI in more and more BIOSes, they are shipping w/o the ability to turn off PnP OS. They assume that the OS will be at least PnP, if not fully use the ACPI paradigm[*] to do its resource thing. FreeBSD has to cope with this better in general. PCI_ENABLE_IO_MODES is a kludge that only kinda makes things better. NetBSD does a better job at this by enumerating things at boot time and assigning resources when the big picture is being looked at. FreeBSD should do this as well. We will have to deal with assigning things that could need more resources later, like cardbus and cPCI bridges, "big" chunks of space that they can later dole out as needed. pci bridges make this problem more interesting because some of them will only decode certain address ranges (which is the cause of another kludge in the pci code). You can do a web search for the pc99 design guide (and newer ones). They go into some of this. The ACPI standards docs also go into this as well, although the 1.0 verion didn't do it very well (imho). There are a number of other places to look for information too. The mindshare books might be good. I'm not aware of one place the ties all of these "customs" together into a coherent hole :-(. Warner [*] These are wesil words for "The OS does all the resource assignment." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message