Subject: Re: virt_to_page/pci_map_page vs. pci_map_single
From: James Bottomley <James.Bottomley@steeleye.com>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: Jamie Wellnitz <Jamie.Wellnitz@emulex.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <yq0znfcjwh1.fsf@trained-monkey.org>
References: <1067885332.2076.13.camel@mulgrave> 
	<yq0znfcjwh1.fsf@trained-monkey.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 04 Nov 2003 10:43:39 -0600
Message-Id: <1067964220.1792.106.camel@mulgrave>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1292
Lines: 28

On Tue, 2003-11-04 at 03:48, Jes Sorensen wrote:
> The question is whether that should be allowed in the first place. Some
> IOMMU's will have to map it page-by-page anyway. However if it is to
> remain a valid use then I don't see why pci_map_page() shouldn't be
> able to handle it under the same conditions by passing it a
> size > PAGE_SIZE.

I really don't see what's to be gained by doing this.  map_page is for
mapping one page or a fragment of it.  It's designed for small zero copy
stuff, like networking.  To get it to map more than one page, really we
should pass in an array of struct pages.

If the data you have to map is > 1 Page, then the scatter gather
interface (dma_map_sg()) is a better way to handle it.  dma_map_single()
is for the special case of data generated in kernel, which is virtually
and physically contiguous (i.e. generated by kmalloc or get_free_pages,
so no highmem issues either), which we haven't passed through the SG
machinery.  It's special cased out in all the drivers that handle SG
transactions.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/