From: Jes Sorensen <jes@trained-monkey.org>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Jamie Wellnitz <Jamie.Wellnitz@emulex.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: virt_to_page/pci_map_page vs. pci_map_single
Date: 06 Nov 2003 03:28:54 -0500 [thread overview]
Message-ID: <yq0islxx5mh.fsf@trained-monkey.org> (raw)
In-Reply-To: <1067964220.1792.106.camel@mulgrave>
>>>>> "James" == James Bottomley <James.Bottomley@steeleye.com> writes:
James> 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.
James> I really don't see what's to be gained by doing this. map_page
James> is for mapping one page or a fragment of it. It's designed for
James> small zero copy stuff, like networking. To get it to map more
James> than one page, really we should pass in an array of struct
James> pages.
I am totally in favor of that. I think it's a really bad idea on
relying on the pci_map infrstructure to do the page chopping for
multi-page mappings since the IOMMUs will normally have to chop it up
anyway. The driver authors needs to be aware of this.
The above was more meant as an example of how pci_map_page() can be
hacked to do the same thing as pci_map_single if we really wanted to
rely on that behavior.
Cheers,
Jes
next prev parent reply other threads:[~2003-11-06 8:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-03 18:48 virt_to_page/pci_map_page vs. pci_map_single James Bottomley
2003-11-03 22:03 ` Jamie Wellnitz
2003-11-04 9:48 ` Jes Sorensen
2003-11-04 16:35 ` Matt Porter
2003-11-04 16:47 ` James Bottomley
2003-11-04 17:11 ` Matt Porter
2003-11-04 16:43 ` James Bottomley
2003-11-05 16:23 ` Anton Blanchard
2003-11-06 8:28 ` Jes Sorensen [this message]
[not found] <NuZH.1a5.7@gated-at.bofh.it>
[not found] ` <NI6s.1MM.3@gated-at.bofh.it>
[not found] ` <NMtC.7Vs.21@gated-at.bofh.it>
[not found] ` <NNSy.1Cd.1@gated-at.bofh.it>
[not found] ` <NV3O.5w7.19@gated-at.bofh.it>
[not found] ` <NWCA.7Qv.19@gated-at.bofh.it>
2003-11-04 8:41 ` Ihar 'Philips' Filipau
-- strict thread matches above, loose matches on Subject: below --
2003-11-02 18:12 Jamie Wellnitz
2003-11-03 8:10 ` Jes Sorensen
2003-11-03 12:52 ` Jamie Wellnitz
2003-11-03 14:17 ` Jes Sorensen
2003-11-03 22:02 ` David Mosberger
2003-11-04 0:41 ` David S. Miller
2003-11-04 9:44 ` Jes Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq0islxx5mh.fsf@trained-monkey.org \
--to=jes@trained-monkey.org \
--cc=James.Bottomley@steeleye.com \
--cc=Jamie.Wellnitz@emulex.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox