From: Ian Campbell <Ian.Campbell@eu•citrix.com>
To: Becky Bruce <beckyb@kernel•crashing.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab•ntt.co.jp>,
"linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>,
Jeremy Fitzhardinge <jeremy@goop•org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>
Subject: Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Date: Thu, 21 May 2009 20:01:37 +0100 [thread overview]
Message-ID: <1242932497.25553.230.camel@localhost.localdomain> (raw)
In-Reply-To: <E6DAA792-9923-4B76-9759-6955AABE3EAB@kernel.crashing.org>
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
> We have both in every case but one,
> which is in swiotlb_map_page where we call address_needs_mapping()
> without calling range_needs_mapping.
The reason it calls address_needs_mapping without range_needs_mapping is
that in the swiotlb_force=1 case it would trigger every time. If
address_needs_mapping and range_needs_mapping are merged as proposed and
they do not subsume the swiotlb_force check (and I don't think they
would) then I think this will work fine.
> It's not actually clear to me that we need that check, though. Can
> someone explain what case that was designed to catch?
If map_single fails and returns NULL then we try to use
io_tlb_overflow_buffer, if that is somehow not DMA-able (for the
particular device) then the check will trigger. I would have thought we
could arrange that the overflow buffer is always OK and really if
map_page is failing we must be close the edge already.
Ian.
next prev parent reply other threads:[~2009-05-21 19:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-14 22:42 [PATCH V2 1/3] powerpc: Use sg->dma_length in sg_dma_len() macro on 32-bit Becky Bruce
2009-05-14 22:42 ` [PATCH V2 2/3] powerpc: Add support for swiotlb " Becky Bruce
2009-05-14 22:42 ` [PATCH V2 3/3] powerpc: Add 86xx support for SWIOTLB Becky Bruce
2009-05-15 4:49 ` [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit Kumar Gala
2009-05-18 4:49 ` Benjamin Herrenschmidt
2009-05-18 13:25 ` Kumar Gala
2009-05-18 21:49 ` Benjamin Herrenschmidt
2009-05-19 13:04 ` Kumar Gala
2009-05-19 20:06 ` Becky Bruce
2009-05-28 4:42 ` Kumar Gala
2009-05-28 6:11 ` Benjamin Herrenschmidt
2009-05-28 13:06 ` Kumar Gala
2009-05-19 5:27 ` FUJITA Tomonori
2009-05-19 20:57 ` Becky Bruce
2009-05-21 17:43 ` Jeremy Fitzhardinge
2009-05-21 18:27 ` Becky Bruce
2009-05-21 19:01 ` Ian Campbell [this message]
2009-05-22 10:51 ` FUJITA Tomonori
2009-05-21 20:18 ` Jeremy Fitzhardinge
2009-05-21 22:08 ` Ian Campbell
2009-05-22 10:51 ` FUJITA Tomonori
2009-05-27 19:05 ` Becky Bruce
2009-05-22 11:11 ` Ian Campbell
2009-05-22 23:55 ` Jeremy Fitzhardinge
2009-05-23 22:59 ` Leon Woestenberg
2009-05-26 12:51 ` Ian Campbell
2009-05-27 19:11 ` Becky Bruce
2009-05-27 19:05 ` Becky Bruce
2009-05-27 20:29 ` Ian Campbell
2009-05-27 22:11 ` Becky Bruce
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=1242932497.25553.230.camel@localhost.localdomain \
--to=ian.campbell@eu$(echo .)citrix.com \
--cc=beckyb@kernel$(echo .)crashing.org \
--cc=fujita.tomonori@lab$(echo .)ntt.co.jp \
--cc=jeremy@goop$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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