From: David Daney <ddaney@caviumnetworks.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
konrad.wilk@oracle.com, mingo@elte.hu, andre.goddard@gmail.com,
konrad.wilk@oracle.com
Subject: Re: [PATCH 7/9] swiotlb: Make bounce buffer bounds non-static.
Date: Mon, 27 Sep 2010 10:39:14 -0700 [thread overview]
Message-ID: <4CA0D6C2.7030901@caviumnetworks.com> (raw)
In-Reply-To: <20100927141616S.fujita.tomonori@lab.ntt.co.jp>
On 09/26/2010 10:20 PM, FUJITA Tomonori wrote:
> On Thu, 23 Sep 2010 15:47:31 -0700
> David Daney<ddaney@caviumnetworks.com> wrote:
>
>> Octeon PCI mapping has to be established to cover the bounce buffers,
>> so it has to have access to the bounds.
>
> Why can't you use swiotlb_init_with_tbl() instead?
>
Yes, as pointed out be several people, that would be better.
The swiotlb_init_with_tbl() didn't exist in earlier kernel versions and
this simplification was missed when I forward ported the patch set.
By using this function, I think the entire patch set will be MIPS
specific, making it unnecessary to touch the generic swiotlb code.
Thanks,
David Daney
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
konrad.wilk@oracle.com, mingo@elte.hu,
andre.goddard@gmail.comkonrad.wilk@oracle.com
Subject: Re: [PATCH 7/9] swiotlb: Make bounce buffer bounds non-static.
Date: Mon, 27 Sep 2010 10:39:14 -0700 [thread overview]
Message-ID: <4CA0D6C2.7030901@caviumnetworks.com> (raw)
Message-ID: <20100927173914.VbONjINJiS7KOcII0TT0AT6kV9tsAWJa6SZb8VQwMvs@z> (raw)
In-Reply-To: <20100927141616S.fujita.tomonori@lab.ntt.co.jp>
On 09/26/2010 10:20 PM, FUJITA Tomonori wrote:
> On Thu, 23 Sep 2010 15:47:31 -0700
> David Daney<ddaney@caviumnetworks.com> wrote:
>
>> Octeon PCI mapping has to be established to cover the bounce buffers,
>> so it has to have access to the bounds.
>
> Why can't you use swiotlb_init_with_tbl() instead?
>
Yes, as pointed out be several people, that would be better.
The swiotlb_init_with_tbl() didn't exist in earlier kernel versions and
this simplification was missed when I forward ported the patch set.
By using this function, I think the entire patch set will be MIPS
specific, making it unnecessary to touch the generic swiotlb code.
Thanks,
David Daney
next prev parent reply other threads:[~2010-09-27 17:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 22:38 [PATCH 0/9] MIPS: Use dma-mapping-common.h and use swiotlb for Octeon David Daney
2010-09-23 22:38 ` [PATCH 1/9] MIPS: Octeon: Set dma_masks for octeon_mgmt device David Daney
2010-09-23 22:38 ` [PATCH 2/9] MIPS: Allow MAX_DMA32_PFN to be overridden David Daney
2010-09-23 22:38 ` [PATCH 3/9] MIPS: Octeon: Adjust top of DMA32 zone David Daney
2010-09-23 22:38 ` [PATCH 4/9] MIPS: Octeon: Select ZONE_DMA32 David Daney
2010-09-23 22:38 ` [PATCH 5/9] MIPS: Convert DMA to use dma-mapping-common.h David Daney
2010-09-24 1:03 ` [PATCH] MIPS: Remove plat_map_dma_mem_page() David Daney
2010-09-27 5:30 ` [PATCH 5/9] MIPS: Convert DMA to use dma-mapping-common.h FUJITA Tomonori
2010-09-27 17:35 ` David Daney
2010-09-28 0:12 ` FUJITA Tomonori
2010-09-23 22:38 ` [PATCH 8/9] MIPS: Add a platform hook for swiotlb setup David Daney
2010-09-24 16:08 ` Sergei Shtylyov
2010-09-24 16:13 ` David Daney
2010-09-24 16:32 ` Ralf Baechle
2010-09-23 22:38 ` [PATCH 9/9] MIPS: Octeon: Rewrite DMA mapping functions David Daney
2010-09-24 1:06 ` [PATCH] MIPS: Octeon: Remove plat_map_dma_mem_page() David Daney
2010-09-23 22:47 ` [PATCH 6/9] swiotlb: Declare swiotlb_init_with_default_size() David Daney
2010-09-27 16:53 ` Konrad Rzeszutek Wilk
2010-09-23 22:47 ` [PATCH 7/9] swiotlb: Make bounce buffer bounds non-static David Daney
2010-09-27 5:20 ` FUJITA Tomonori
2010-09-27 17:39 ` David Daney [this message]
2010-09-27 17:39 ` David Daney
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=4CA0D6C2.7030901@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=akpm@linux-foundation.org \
--cc=andre.goddard@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mingo@elte.hu \
--cc=ralf@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.