| Age | Commit message (Collapse) | Author |
|---|
|
This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add include of <linux/bitops.h> to io.h to solve compilations errors in
files such as drivers/w1/w1_io.c caused by the ixp4xx version of io.h
using the BIT() macro without including <linux/bitops.h> first.
Signed-off-by: Rod Whitby <rod@whitby.id.au>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Don't lose __iomem in casts. Use __force to cast __iomem addresses to
integers. Use __force to cast u32 to __le32 and vice versa.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
define global BIT macro
move all local BIT defines to the new globally define macro.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Conflicts:
include/asm-arm/arch-ixp4xx/io.h
|
|
__ioremap() took a set of page table flags (specifically the cacheable
and bufferable bits) to control the mapping type. However, with
the advent of ARMv6, this is far too limited.
Replace the page table flags with a memory type index, so that the
desired attributes can be selected from the mem_type table.
Finally, to prevent silent miscompilation due to the differing
arguments, rename the __ioremap() and __ioremap_pfn() functions.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add Intel KIXRP435 Reference Platform based on IXP43x processor.
Fixed after review : access to cp15 removed in identification functions,
used access to global processor_id instead
Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
Signed-off-by: Ruslan Sushko <rsushko@ru.mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Fix compilation fail for ixp4xx platforms for the case when CONFIG_IXP4XX_INDIRECT_PCI is set. That is due to the check_signature() is appeared in include/linux/io.h.
Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
On all targets that sucker boils down to memcpy_fromio(sbk->data, from, len).
The function name is highly misguiding (it _never_ does any checksums), the
last argument is just a noise and simply expanding the call to memcpy_fromio()
gives shorter and more readable source. For a lot of reasons it has almost
no remaining users, so it's better to just outright kill it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
Patch from Deepak Saxena
This patch allows for the addition of IXP4xx systems that do not make
use of the PCI interface by moving the CONFIG_PCI symbol selection to
be platform-specific instead of for all of IXP4xx. If at least one machine
with PCI support is built, the PCI code will be compiled in, but when
building !PCI, this will drastically shrink the kernel size.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The "align" argument in ARMs __ioremap is unused and provides a
misleading expectation that it might do something. It doesn't.
Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
pointer passed to integral function argument
Patch from John Bowler
Fix for a compiler warning, this wasn't apparent in 2.6.12, I
believe the compiler options have been changed (somewhere) so
that passing a (void*) to a (u32) argument is now warned.
This accounts for the majority of the warnings in my builds of
the 2.6.14 kernel for NSLU2.
The patch changes pointer parameters declared as u32 to be
declared as either, for read parameters:
const volatile void __iomem *
and for write parameters:
volatile void __iomem *
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Compiler warning fix; the inline callers of these APIs were changed
to have const vaddr parameters.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Patch from David Vrabel
Correct the ioread* and iowrite* functions. In particular, add an offset to the cookie in ioport_map so we can map I/O port ranges starting from 0 (0 is for reporting errors).
Signed-off-by: David Vrabel <dvrabel@arcom.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Patch from Deepak Saxena
This patch implements the iomap API for Intel IXP4xx NPU systems.
We need to implement our own version of the API functions b/c of the
PCI hostbridge does not provide the capability to map PCI I/O space
into the CPU's physical memory space. In addition, if a system has
more than 64M of PCI memory mapped BARs, PCI memory must also be
accessed indirectly. This patch changes the assignment of PCI I/O
resources to fall into to 0x0000:0xffff range so that we can trap
I/O areas in our ioread/iowrite macros.
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
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!
|
