From owner-freebsd-scsi Sun Aug 15 13:48:34 1999
Delivered-To: freebsd-scsi@freebsd.org
Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130])
by hub.freebsd.org (Postfix) with ESMTP id 722D814D11
for <scsi@FreeBSD.org>; Sun, 15 Aug 1999 13:48:31 -0700 (PDT)
(envelope-from gibbs@narnia.plutotech.com)
Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id OAA47448; Sun, 15 Aug 1999 14:35:08 -0600 (MDT)
Date: Sun, 15 Aug 1999 14:35:08 -0600 (MDT)
From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Message-Id: <199908152035.OAA47448@narnia.plutotech.com>
To: Keith Mitchell <kmitch@weenix.guru.org>
Cc: scsi@FreeBSD.org
Subject: Re: CAM (driver devel) question
X-Newsgroups: pluto.freebsd.scsi
In-Reply-To: <19990811201425.A89846@weenix.guru.org> <199908120100.TAA51068@panzer.kdm.org> <19990811223315.A93634@weenix.guru.org>
User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386))
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org
In article <19990811223315.A93634@weenix.guru.org> you wrote:
> On Wed, Aug 11, 1999 at 07:00:44PM -0600, Kenneth D. Merry wrote:
>> Not all of the drivers support S/G. And you're right, it isn't used in any
>> of the upper level code at the moment.
>
> All of the drivers I looked at (aic7xxx, dpt, buslogic) all supported
> scatter/gather. But it looked like they only supported scatter/gather if
> they were passed a scatter/gather buffer from the upper layer (and since it
> doesn't look like the upper layer sends down a scatter gather list then
> I am guessing that scatter/gather never occurs).
>
> It looks like from the drivers they take whatever buffer they get passed
> from the upper layer and pass it down to the card (if its a physical address
> or maps it into DMAable memory via bus_dmamap_load() if its a virtual
> address). So my initial conclusion was the drivers were architected so
> that when the upper layer supported S/G they would too without modification.
> but I wanted to be sure before I coded everything.
When you perform a bus_dmamap_load(), you are returned a 'generic' S/G
list corresponding to the virtual buffer address/size provided. The
list conforms to all of the constraints listed in the DMA tag for the
map. This is how 99.9% of all S/G will occur for your driver. Some
applications may require operations on discontiguous chunks of 'bus addressed'
buffers. In this case, the application will provide an S/G list that
needs no further interpretation by the driver. I would not expect users
of FreeBSD as a 'standard UNIX' to ever exercise this API, but it certainly
has many uses in embedded environments.
As for your other question about transaction descriptors that are DMA'ed
to the card, these are usually handled by allocating DMA safe memory
up front. Most of the drivers do this already. At some point in the
future, we will likely add some additional calls to the bus dma API
that allow you to explicitly sync DMA safe memory after you touch it.
For most architectures this would be a no-op, but for those architectures
that don't have bus snooping, these calls would flush the data cache.
--
Justin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message