Subject: Re: virt_to_page/pci_map_page vs. pci_map_single
From: James Bottomley <James.Bottomley@steeleye.com>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: Jes Sorensen <jes@trained-monkey.org>,
       Jamie Wellnitz <Jamie.Wellnitz@emulex.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <20031104093556.A24704@home.com>
References: <1067885332.2076.13.camel@mulgrave>
	<yq0znfcjwh1.fsf@trained-monkey.org>  <20031104093556.A24704@home.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 04 Nov 2003 10:47:25 -0600
Message-Id: <1067964447.1792.116.camel@mulgrave>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1203
Lines: 26

On Tue, 2003-11-04 at 10:35, Matt Porter wrote:
> This raises a question for me regarding these rules in 2.4 versus
> 2.6.  While fixing a bug in PPC's 2.4 pci_map_page/pci_map_sg
> implementations I noticed that a scatterlist created by the IDE
> subsystem will pass nents by page struct reference with a
> size > PAGE_SIZE.  Is this a 2.4ism resulting from allowing both
> address and page reference scatterlist entries?  This isn't
> explicitly mentioned in the DMA docs AFAICT.  I'm wondering
> if this is the same expected behavior in 2.6 as well.  If
> pci_map_page() is limited to size <= PAGE_SIZE then I would
> expect pci_map_sg() to be limited as well (and vice versa).

Not really.  By design, the SG interface can handle entries that are
physically contiguous.

If you have a limit on the length of your SG elements (because of the
device hardware, say), you can express this to the block layer with the
blk_queue_max_segment_size() API.

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/