From owner-freebsd-hackers  Thu Dec  7 12:52:52 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA19202
          for hackers-outgoing; Thu, 7 Dec 1995 12:52:52 -0800 (PST)
Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA19187
          for <hackers@FreeBSD.ORG>; Thu, 7 Dec 1995 12:52:49 -0800 (PST)
Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id OAA22145; Thu, 7 Dec 1995 14:52:43 -0600 (CST)
Date: Thu, 7 Dec 1995 14:52:43 -0600 (CST)
From: Mark Tinguely <tinguely@plains.nodak.edu>
Message-Id: <199512072052.OAA22145@plains.nodak.edu>
To: terry@lambert.org
Subject: Re: Matrox Meteor & pal...
Cc: hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

>  Out of curiousity, what would really be invovled in running a driver in
>  its own linear address space so that this wasn't a problem?
>  
>  Or must it be physically contiguous?

the card uses DMAs to physical memory, and needs physically contiguous memory
for each field. we interlace the field into one buffer to make a faster
user application use. so packed mode could use two seperate smaller contiguous
buffers and planer YUV could be split into 3 YUV (interlaced but seperate
Y, U, and V buffers) or 6 (non-interlace Y, U, V buffers) contiguous buffers.

In the massive frame capture mode we could go with an array of smaller
contiguous chunks.

I don't think breaking these up is wise because when you look at grabbing at
a high frame rate you want to keep driver and user processing to a minimum.
Besides, there is no guarrentee we can get the smaller chunks contiguous
after several minutes of allocations/free.

--mark.