From owner-freebsd-hackers Sat Jan 24 03:10:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA29655 for hackers-outgoing; Sat, 24 Jan 1998 03:10:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com ([209.133.7.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA29646; Sat, 24 Jan 1998 03:10:11 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id DAA21360; Sat, 24 Jan 1998 03:10:00 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199801241110.DAA21360@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: David Dawes cc: Stefan Esser , hackers@FreeBSD.ORG, rgooch@atnf.csiro.au Subject: Re: ANNOUNCE: Fastvid module available! In-reply-to: Your message of "Sat, 24 Jan 1998 13:50:49 +1100." <19980124135049.46451@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jan 1998 03:10:00 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk There are other issues which just simply lead me to believe that the best possible way to implement fastvid is to provide a system call and as for co-operating with linux developers thats fine with me . So Richard, can you bring us up to speed on what you are up to? Tnks, Amancio > On Thu, Jan 22, 1998 at 09:17:31PM +0100, Stefan Esser wrote: > > >> 4. If the pci code is up to it it would be nice to dump the pci configuration > >> for all the devices and if possible properly identify the devices. > >> The probe code already does some of this so it should not be that > >> difficult if the pci code can return a list of currently installed pci > >> devices along with their respective configuration. > > > >The PCI code already is "up to it". You only have to call a > >"fastvid" function from the VGA attach code. All the PCI map > >registers are available, and you can just make the largest > >memory mapped region "fast". > > > >Multiple regions should be OK, too, if supported by the CPU. > > Only do this for the framebuffer areas, not memory mapped I/O areas. > Those chipsets that have separate memory regions allocated for the > framebuffer and MMIO typically mark the framebuffer area a pre-fetchable, > and the MMIO area as non-pre-fetchable. Some cards (some examples are > some S3 cards and some Mach64-based cards) have a single region, which > is divided up into framebuffer and MMIO. It would be marked as > non-pre-fetchable. To use something like fastvid effectively in that > case, you need to have some knowledge of how that area is organised. > Furthermore, some S3 chipsets have a bug that can result in the PCI > BIOS giving them a memory area aligned to 32MB instead of the required > 64MB. This can also result in a clash between the video card memory > and that of other PCI devices. The XFree86 S3 server detects this and > remaps. If the kernel is going to do fastvid, it should know about this > too. > > While I generally like the idea of the OS taking care of this sort of > thing, it can still be useful to provide a way for something like the > Xserver to check and maybe change such things. > > I don't know if any of you have had a look at what the Linux people > are doing in this area. If you're interested, you can contact > Richard Gooch . > > David