The new FPGA firmware in Balloon3 uses different methods to control it's bus
control lines. In the new version, there are separate registers to set/clear
bus control lines. This patch updates affected places.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Tested on a Colibri Evaluation Board Rev.2.1 with a Colibri PXA310 module.
Signed-off-by: Bjorn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Rename colibri-pxa270-evalboard to colibri-evalboard as this board is used with
all Colibri modules.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
This change -- pushing the MFP configuration back into Module files -- is
necessary because some evalboards can be used with multiple modules, where MFP
differs from module to module. Therefore MFP isn't board-specific, but
module-specific and the module should preconfigure itself for the board.
(And there is also the C preprocesor limitation and conflicting #define-s)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
This driver also contains structures to eventually support PXA320. This is
planned to be added in a later patch.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
iwmmxt is used in XScale, XScale3, Mohawk and PJ4 core. But the instructions
of accessing CP0 and CP1 is changed in PJ4. Append more files to support
iwmmxt in PJ4 core.
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Since CPU_PJ4 is shared between PXA95x and MMP2, select CPU_PJ4 in MMP2
configuration.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
The core of PXA955 is PJ4. Add new PJ4 support. And add new macro
CONFIG_PXA95x.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Define all IRQs in irqs.h. If some IRQs are sharing one IRQ number, define
them together. If some IRQs are sharing same name with different IRQ number,
define different IRQ.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
After introducing pxa930/pxa935 and new silicons, original cpuid rules
of XScale generation 3 can't fit new silicons. Now redefine the rule
of PXA3xx.
Only PXA300/PXA310/PXA320/PXA930/PXA935 are family members of PXA3xx.
PXA930/PXA935 are family members of PXA93x. PXA93x can be considered
as PXA3xx + CP.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
This is important because on PXA3xx, the physical mapping of SMEMC registers
differs from the one on PXA2xx. In order to get PCMCIA working on both PXA2xx
and PXA320, the PCMCIA driver was adjusted accordingly as well.
Also, various places in the kernel had to be patched to use
__raw_read/__raw_write.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
This patch introduces pxa2xx_map_io() and pxa3xx_map_io() to distinguish
between PXA25x/PXA27x and PXA3xx memory mapping.
Also, fixup for platforms broken after introducing pxa{25x,27x}_map_io()
and pxa3xx_map_io() is included.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
The camera registers start and range are encoded into the platform
device, and are actually handled by ioremap()'ed, thus the mapping
in pxa_map_io() is not necessary.
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Add missing header file:
arch/x86/crypto/ghash-clmulni-intel_glue.c:256: error: implicit declaration of function 'IS_ERR'
arch/x86/crypto/ghash-clmulni-intel_glue.c:257: error: implicit declaration of function 'PTR_ERR'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: 6535/1: V6 MPCore v6_dma_inv_range and v6_dma_flush_range RWFO fix
ARM: 6534/1: Make CONFIG_FPE_NWFPE depend on !CONFIG_THUMB2_KERNEL
ARM: 6533/1: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
Change bcmring Maintainer list.
ARM: Update mach-types
ARM: 6528/1: Use CTR for the I-cache line size on ARMv7
ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7
ARM: pxa/palm: fix ifdef around gen_nand driver registration
ARM: pxa: fix pxa2xx-flash section mismatch
ARM: mmp2: remove not used clk_rtc
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sparc: Write to prom console using indirect buffer.
sparc: Delete prom_*getchar().
sparc: Pass buffer pointer all the way down to prom_{get,put}char().
sparc: Do not export prom_nb{get,put}char().
sparc64: Delete prom_setcallback().
sparc64: Unexport prom_service_exists().
sparc: Kill prom devops_{32,64}.c
sparc: Remove prom_pathtoinode()
sparc64: Delete prom_puts() unused.
SPARC/LEON: removed constant timer initialization as if HZ=100, now it reflects the value of HZ
Cache ownership must be acquired by reading/writing data from the
cache line to make cache operation have the desired effect on the
SMP MPCore CPU. However, the ownership is never acquired in the
v6_dma_inv_range function when cleaning the first line and
flushing the last one, in case the address is not aligned
to D_CACHE_LINE_SIZE boundary.
Fix this by reading/writing data if needed, before performing
cache operations.
While at it, fix v6_dma_flush_range to prevent RWFO outside
the buffer.
Cc: stable@kernel.org
Signed-off-by: Valentine Barshak <vbarshak@mvista.com>
Signed-off-by: George G. Davis <gdavis@mvista.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Because the nwfpe support is unlikely to be used on new platforms
and requires CONFIG_OABI_COMPAT, which is not generally used with
ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2
kernel.
At present, nwfpe contains assembly code which isn't Thumb-2
compatible, and for now it doesn't appear useful to port this
code.
All ARMv7-A/R platforms necessarily have VFPv3 hardware floating-
point natively, making emulation unnecessary.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This makes sense, because Thumb-2 code can't execute on plain
ARMv6 processors.
This will avoid accidentally configuring a broken kernel where the
config otherwise would allow multiple architecture versions to
coexist in the same kernel.
Not adding !CPU_V5 etc., because the chance of anyone trying to
put v5 and v7 in the same kernel is low, and I'm not aware of
any mach which can do this. These could be added later if it
matters.
Note that the rules may need to be refined if support for the
ARM1156J(F)-S processor is later added to the kernel, since this
processor supports the rare ARMv6T2 extensions, which add support
for Thumb-2 and a few other ARMv7 features.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There are still quite a number of MFD and GPIO expander drivers that are
using the old irq_chip APIs that haven't had a chance to update during
the .37 cycle, resulting in allyes/modconfig errors on some
configurations.
Mark Brown has done most of the legwork to get these fixed up in .38,
so this should just be a .37 stop-gap that we can drop at the end of the
.38 merge window.
Reported-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The current implementation of the v7_coherent_*_range function assumes
that the D and I cache lines have the same size, which is incorrect
architecturally. This patch adds the icache_line_size macro which reads
the CTR register. The main loop in v7_coherent_*_range is split in two
independent loops or the D and I caches. This also has the performance
advantage that the DSB is moved outside the main loop.
Reported-by: Kevin Sapp <ksapp@quicinc.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The current implementation of the dcache_line_size macro reads the L1
cache size from the CCSIDR register. This, however, is not guaranteed to
be the smallest cache line in the cache hierarchy. The patch changes to
the macro to use the more architecturally correct CTR register.
Reported-by: Kevin Sapp <ksapp@quicinc.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
After Charu's GPIO hwmod patches, GPIO initialization on N800 emits
the following messages for all GPIO banks:
omap_hwmod: gpio1: cannot be enabled (3)
This is due to OMAP24XX_ST_GPIOS_SHIFT being defined as a bitmask.
Fix this and also fix two other macros that had the same problem.
Thanks to Tony Lindgren <tony@atomide.com> for originally reporting
this bug.
Signed-off-by: Paul Walmsley <paul@pwsan.com
Cc: Charulatha Varadarajan <charu@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>