From owner-freebsd-hackers  Mon Apr 21 04:58:58 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id EAA08626
          for hackers-outgoing; Mon, 21 Apr 1997 04:58:58 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08615
          for <hackers@freebsd.org>; Mon, 21 Apr 1997 04:58:54 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id EAA00447; Mon, 21 Apr 1997 04:58:16 -0700 (PDT)
Message-Id: <199704211158.EAA00447@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Peter Dufault <dufault@hda.com>
cc: msmith@atrad.adelaide.edu.au (Michael Smith), hackers@freebsd.org
Subject: Re: video capture driver interface to file system? 
In-reply-to: Your message of "Mon, 21 Apr 1997 06:35:30 EDT."
             <199704211035.GAA24306@hda.hda.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Apr 1997 04:58:16 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>From The Desk Of Peter Dufault :
> > I was actually believing that it would cover the uiomove() time as
> > well, which looked to be the worst offender.  Some more study tells
> > me this was wrong, so yes, I'd have to agree that a user-space
> > application is probably going to perform nearly as well.
> 
> I'm assuming DMA directly into the user buffer via physio for a
> raw transfer.  I use "raw transfer" always to mean directly to user
> buffers.  I guess I need to use "cooked" or "psuedo-raw" transfers
> to describe transfers that uiomove indirectly through kernel buffers.
> 
> From Amancio's brief description I assume the device is capable of
> DMAing to anywhere in PCI memory.  The only cool optimization
> I can think of is to use non-ascending transfers to DMA directly
> to a SCSI controller's data FIFO ... but we'll talk about that when
> we're trying to do 40MB/second to a disk array.  (I've done exactly
> that in an HDTV research application four years back, though it
> was only 20MB/sec).

Now thats more like it 8)


Yes the Bt848 is capable of DMAing to any place in memory or to any 
PCI target device. For instance, we can capture video to system
memory or we can dma straight into the video display's frame buffer
without any cpu intervention. I use the latter to watch TV in my system.
On a good monitor it matches the quality of a reqular TV.

Not sure how much clear I can make it. So here is a sample code
from the driver.


This is from the code which instructs the Bt848 where to dma the
info to:

	if (bktr->video.addr) {
		target_buffer = (u_long) bktr->video.addr;
		pitch = bktr->video.width;
	}
	else {
		target_buffer = (u_long) vtophys(bktr->bigbuf);
		pitch = cols*pixel_width;
	}

So if the user specified the physical address of the video display's
frame buffer we use it otherwise we happily capture to system memory.

>From the Bt848 point of view , it does not know if its dmaing to 
host memory or to the card's display frame buffer.

The Bt848 has 70 32bit words to hold a video line.

The dma control procedure is controlled by a "RISC" program in the 
host memory. The RISC instructions tells the dma processor what to
do with a video line: skip pixels , write to a given destination , 
or wait for start of frame, etc... to dma a line one uses a write instruction 
with the number of bytes to transfer and  the address of the target.



	Cheers,
	Amancio