Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jan 1998 21:17:31 +0100
From:      Stefan Esser <se@FreeBSD.ORG>
To:        Amancio Hasty <hasty@rah.star-gate.com>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: ANNOUNCE: Fastvid module available!
Message-ID:  <19980122211731.37323@mi.uni-koeln.de>
In-Reply-To: <199801210936.BAA03932@rah.star-gate.com>; from Amancio Hasty on Wed, Jan 21, 1998 at 01:36:40AM -0800
References:  <199801090700.AA299089244@pollux.hrz.uni-bielefeld.de> <199801210936.BAA03932@rah.star-gate.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 1998-01-21 01:36 -0800, Amancio Hasty <hasty@rah.star-gate.com> wrote:
> A couple of things I had to hack fastvid a little in order to get it
> to compile on -current.

> 1. I would like to see a user land program set the values, for example:
> ./fastvid 0x9800000 00x4000000 

I do not like this at all as a command for the "dumb" user.
It's fine for testing and benchmarking, though ...

> 2. Ability to set multiple ranges useful in my case because I have
>    Diamond Monster 3d and a Matrox Millenium.

If multiple ranges are available for that purpose: why not.

> 3. Dump the registers

For debugging purposes: OK.

> 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.

We should perhaps provide a processor type dependent function
"cpu_cacheable(void *base, size_t bytes, int cachemode)", which 
tries to setup the memory region for mode, normally (CM_CACHE+
CM_WRITECOMB+...), you get the picture, on a PPro, P-II, AMD K6, 
Cyrix 6x86 ...

The default emulation of that function is to just return, and
owners of CPUs that support video memory regions should write
and test the CPU specific implementation on their systems.

Well, me ? I only got a i486 class system and can't help much :)

But if you just want me to put a hook into the PCI code, which 
makes the VGA attach call "cpu_cacheable()", that's not much of 
a problem ...

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980122211731.37323>