From: "H. Peter Anvin" <hpa@zytor.com>
To: Alessandro Rubini <rubini@gnudd.com>
Cc: mingo@elte.hu, akpm@linux-foundation.org,
jbarnes@virtuousgeek.org, fujita.tomonori@lab.ntt.co.jp,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, x86@kernel.org, giancarlo.asnaghi@st.com,
alan@linux.intel.com
Subject: Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS
Date: Thu, 12 Apr 2012 13:18:20 -0700 [thread overview]
Message-ID: <4F87388C.300@zytor.com> (raw)
In-Reply-To: <20120412201533.GA26533@mail.gnudd.com>
On 04/12/2012 01:15 PM, Alessandro Rubini wrote:
>
> The current approach is using swiotlb and it works pretty well, though
> with a limit of 4MB of swiotlb area. I've been considering use of the
> DMA zone to this aim: internally I have some half-working thing that
> resuses the ISA DMA zone for our own aims, raising the DMA limit to
> 512MB.
>
> Do you think the approach may make sense? I use this basic
> thing in Kconfig, to rely on GFP_DMA for the rest:
>
> config MAX_DMA_PADDR
> int
> default 536870912 if MAX_DMA_PADDR_512M
> default 16777216
>
> config MAX_DMA_PADDR_512M
> bool
>
> (actually, we'd benefit from being able to use hex in defaults)
>
> Is this worth exploring, to possibly submit a patch in this direction?
>
Not as a compile-time patch.
-hpa
next prev parent reply other threads:[~2012-04-12 20:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 7:28 [PATCH V4 0/3] *** SUBJECT HERE *** Alessandro Rubini
2012-03-13 7:30 ` [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS Alessandro Rubini
2012-03-14 6:56 ` Ingo Molnar
2012-04-11 10:19 ` Alessandro Rubini
2012-04-12 18:01 ` H. Peter Anvin
2012-04-12 20:15 ` Alessandro Rubini
2012-04-12 20:18 ` H. Peter Anvin [this message]
2012-04-12 20:32 ` Alessandro Rubini
2012-04-12 20:47 ` H. Peter Anvin
2012-04-14 11:38 ` Ingo Molnar
2012-03-13 7:30 ` [PATCH V4 2/3] x86: introduce CONFIG_X86_DMA_REMAP Alessandro Rubini
2012-03-13 7:30 ` [PATCH V4 3/3] x86/PCI: initial support for sta2x11 I/O hub Alessandro Rubini
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=4F87388C.300@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=giancarlo.asnaghi@st.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=rubini@gnudd.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.