Commit Graph

12 Commits

Author SHA1 Message Date
David Woodhouse
62c4f0a2d5 Don't include linux/config.h from anywhere else in include/
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-26 12:56:16 +01:00
Russell King
7d12963757 [ARM] Remove unnecessary extra parens in include/asm-arm/memory.h
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-04 16:25:47 +01:00
KAMEZAWA Hiroyuki
0da323505f [ARM] arm's arch_local_page_offset() fix against 2.6.17-rc1
This patch fixes arch_local_page_offset(pfn,nid) in arm.
This new one (added by unify_pfn_to_page patches) is obviously buggy.

This macro calculate page offset in a node.

Note: about LOCAL_MAP_NR()
comment in arm's sub-archs says...

 /*
  * Given a kaddr, LOCAL_MAP_NR finds the owning node of the memory
  * and returns the index corresponding to the appropriate page in the
  * node's mem_map.
  */

but LOCAL_MAP_NR() is designed to be able to take both paddr and kaddr.
In this case, paddr is better.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitu.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-04 16:06:00 +01:00
Lennert Buytenhek
23759dc643 [ARM] 3439/2: xsc3: add I/O coherency support
Patch from Lennert Buytenhek

This patch adds support for the I/O coherent cache available on the
xsc3.  The approach is to provide a simple API to determine whether the
chipset supports coherency by calling arch_is_coherent() and then
setting the appropriate system memory PTE and PMD bits.  In addition,
we call this API on dma_alloc_coherent() and dma_map_single() calls.
A generic version exists that will compile out all the coherency-related
code that is not needed on the majority of ARM systems.

Note that we do not check for coherency in the dma_alloc_writecombine()
function as that still requires a special PTE setting.  We also don't
touch dma_mmap_coherent() as that is a special ARM-only API that is by
definition only used on non-coherent system.

Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-04-02 00:07:39 +01:00
KAMEZAWA Hiroyuki
7eb98a2f3b [PATCH] unify pfn_to_page: arm pfn_to_page
ARM can use generic funcs.
PFN_TO_NID, LOCAL_MAP_NR are defined by sub-archs.

Signed-off-by: KAMEZAWA Hirotuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27 08:44:44 -08:00
Kevin Hilman
37134cd55d [ARM] 3209/1: Configurable DMA-consistent memory region
Patch from Kevin Hilman

This patch increase available DMA-consistent memory allocated by dma_coherent_alloc(). The default remains at 2M (defined in asm/memory.h) and each platform has the ability to override in asm/arch-foo/memory.h.

Signed-off-by: Kevin Hilman <kevin@hilman.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-12 16:12:21 +00:00
Deepak Saxena
9d4ae7276a [ARM] 3070/2: Add __ioremap_pfn() API
Patch from Deepak Saxena

In working on adding 36-bit addressed supersection support to ioremap(),
I came to the conclusion that it would be far simpler to do so by just
splitting __ioremap() into a main external interface and adding an
__ioremap_pfn() function that takes a pfn + offset into the page that
__ioremap() can call. This way existing callers of __ioremap() won't have
to change their code and 36-bit systems will just call __ioremap_pfn()
and we will not have to deal with unsigned long long variables.

Note that __ioremap_pfn() should _NOT_ be called directly by drivers
but is reserved for use by arch_ioremap() implementations that map
32-bit resource regions into the real 36-bit address and then call
this new function.

Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-09 19:23:11 +00:00
Hiroki Kaminaga
31a5539e57 [ARM] 3194/1: add pfn_to_kaddr macro for ARM take2
Patch from Hiroki Kaminaga

This patch defines a new macro: pfn_to_kaddr(pfn).
Same macro is already defined on other arch, such as i386.

Signed-off-by: Hiroki Kaminaga <kaminaga@sm.sony.co.jp>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-12-05 10:55:00 +00:00
Nicolas Pitre
37d07b72ef [ARM] 3061/1: cleanup the XIP link address mess
Patch from Nicolas Pitre

Since vmlinux.lds.S is preprocessed, we can use the defines already
present in asm/memory.h (allowed by patch #3060) for the XIP kernel link
address instead of relying on a duplicated Makefile hardcoded value, and
also get rid of its dependency on awk to handle it at the same time.

While at it let's clean XIP stuff even further and make things clearer
in head.S with a nice code reduction.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29 21:44:56 +01:00
Nicolas Pitre
f09b997999 [ARM] 3060/1: allow constants found in asm/memory.h to be used in asm code
Patch from Nicolas Pitre

This patch allows for assorted type of cleanups by letting assembly code
use the same set of defines for constant values and avoid duplicated
definitions that might not always be in sync, or that might simply be
confusing due to the different names for the same thing.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29 21:44:55 +01:00
Russell King
1b3cb73f73 [ARM] Tighten pfn_valid() test.
Thomas Gleixner reported that mmaping and unmapping each physical
page in turn eventually caused the kernel to oops.  It appears
that pfn_valid() in the discontigmem case was too simplistic for
proper operation.

Tighten the logic so we also check if the PFN is within the range
of the selected memory node.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-15 15:17:59 +01:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00