From: Alessandro Rubini <rubini@gnudd.com>
To: hpa@zytor.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 22:32:20 +0200 [thread overview]
Message-ID: <20120412203220.GA27629@mail.gnudd.com> (raw)
In-Reply-To: <4F87388C.300@zytor.com>
>> 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.
Why not? CONFIG_ISA is a compile-time choice. I thought that if you
compile for non-ISA systems you may reuse the zone mechanism with a
different split.
But if not a compile-time thing, would you accept it at run time?
I feel it's not a beautiful approach, because it must clearly be
masked by #ifndef CONFIG_ISA or such. Worse, you must know the zone
split at the beginning, before you scan the PCI bus and find your
devices.
thanks
/alessandro
next prev parent reply other threads:[~2012-04-12 20:32 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
2012-04-12 20:32 ` Alessandro Rubini [this message]
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=20120412203220.GA27629@mail.gnudd.com \
--to=rubini@gnudd.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=giancarlo.asnaghi@st.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.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.