From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262395AbTKDQoU (ORCPT ); Tue, 4 Nov 2003 11:44:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262397AbTKDQoU (ORCPT ); Tue, 4 Nov 2003 11:44:20 -0500 Received: from nat9.steeleye.com ([65.114.3.137]:46855 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S262395AbTKDQoT (ORCPT ); Tue, 4 Nov 2003 11:44:19 -0500 Subject: Re: virt_to_page/pci_map_page vs. pci_map_single From: James Bottomley To: Jes Sorensen Cc: Jamie Wellnitz , Linux Kernel In-Reply-To: References: <1067885332.2076.13.camel@mulgrave> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-9) 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 X-Mailing-List: linux-kernel@vger.kernel.org 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