Factor out the register defines for a number of other peripherals
common to the iop32x and iop33x.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Revamp the iop3xx board support: move the support code for each iop
board type into its own file, start using platform serial and platform
physmap flash devices, switch to a per-board time tick rate, and get
rid of the ARCH_EP80219 and STEPD config options by doing the relevant
checks at run time.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Squeeze three instructions out of the iop32x irq demuxer, and nine
out of the iop33x irq demuxer by using the hardware vector generator.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Get rid of the unused IOP3??_IRQ_OFS irq offset define, start IRQ
numbering from zero.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add CP6 enable/disable sequences to the timekeeping code and the IRQ
code. As a result, we can't depend on CP6 access being enabled when
we enter get_irqnr_and_base anymore, so switch the latter over to
using memory-mapped accesses for now.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add macros to enable and disable access to CP6. On the iop3xx, enabling
CP6 access unfortunately also enables access to that coprocessor from
unprivileged code, so we need these macros to enable and disable access
to the coprocessor whenever we need to access it.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Switch the iop32x and iop33x code over to the common time implementation,
and remove the (nearly identical) iop32x and iop33x time implementations.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Merge and rewrite the iop32x/iop33x time code to do lost jiffy
tracking properly, and put the result in plat-iop/time.c.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Switch the iop32x and iop33x code over to the common PCI implementation,
and remove the (nearly identical) iop32x and iop33x PCI implementations.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move the i2c bits shared between iop32x and iop33x to plat-iop/i2c.c
and include/asm-arm/hardware/iop3xx.h.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Introduce the arch/arm/plat-iop directory, for code shared between the
iop32x and iop33x, and move the common memory map setup bits there.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Split the iop3xx mach type into iop32x and iop33x -- split the config
symbols, and move the code in the mach-iop3xx directory to the mach-iop32x
and mach-iop33x directories.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rename CONFIG_ARCH_IOP321 to CONFIG_ARCH_IOP32X and
CONFIG_ARCH_IOP331 to CONFIG_ARCH_IOP33X.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Prevent userland from mapping in physical address regions >= 4G by
checking for that in valid_mmap_phys_addr_range().
Unfortunately, we cannot override valid_mmap_phys_addr_range() without
also overriding valid_phys_addr_range(), so copy drivers/char/mem.c's
version of valid_phys_addr_range() over to arch/arm/mm/mmap.c as well.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Now that we have raw_* variants of local_irq_$FOO(), switch the atomic
helpers over to use those raw_* variants. This is necessary when using
lockdep on pre-ARMv6 hardware, as lockdep uses atomic_t counters in the
trace_hardirqs_off() path.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Allow each CPU type in the S3C24XX range to
select the DMA channel mapping it supports.
We change the DMA registration to use an
virtual channel number that the DMA system
will allocate to a hardware channel at
request time.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Create header with uClinux flat format binary support macros for ARM
platforms. Derived from the m68knommu flat.h.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Daniel Jacobowitz
The ARM kernel has several uses of asm("foo%?"). %? is a GCC internal
modifier used to output conditional execution predicates. However, no
version of GCC supports conditionalizing asm statements. GCC 4.2 will
correctly expand %? to the empty string in user asms. Earlier versions may
reuse the condition from the previous instruction. In 'if (foo) asm
("bar%?");' this is somewhat likely to be right... but not reliable.
So, the only safe thing to do is to remove the uses of %?. I believe
the tlbflush.h occurances were supposed to be removed before, based
on the comment about %? not working at the top of that file.
Old versions of GCC could omit branches around user asms if the asm didn't
mark the condition codes as clobbered. This problem hasn't been seen on any
recent (3.x or 4.x) GCC, but it could theoretically happen. So, where
%? was removed a cc clobber was added.
Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
