If kprobes installs a breakpoint on a "stmdb sp!, {...}" instruction,
and then single-step it by simulation from the exception context, it will
corrupt the saved regs on the stack from the previous context.
To avoid this, let's add an optional parameter to the svc_entry macro
allowing for a hole to be created on the stack before saving the
interrupted context, and use it in the undef_svc handler when kprobes
is enabled.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This is a full implementation of Kprobes including Jprobes and
Kretprobes support.
This ARM implementation does not follow the usual kprobes double-
exception model. The traditional model is where the initial kprobes
breakpoint calls kprobe_handler(), which returns from exception to
execute the instruction in its original context, then immediately
re-enters after a second breakpoint (or single-stepping exception)
into post_kprobe_handler(), each time the probe is hit.. The ARM
implementation only executes one kprobes exception per hit, so no
post_kprobe_handler() phase. All side-effects from the kprobe'd
instruction are resolved before returning from the initial exception.
As a result, all instructions are _always_ effectively boosted
regardless of the type of instruction, and even regardless of whether
or not there is a post-handler for the probe.
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Quentin Barnes <qbarnes@gmail.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This is the code implementing instruction single-stepping for kprobes
on ARM.
To get around the limitation of no Next-PC and no hardware single-
stepping, all kprobe'd instructions are split into three camps:
simulation, emulation, and rejected. "Simulated" instructions are
those instructions which behavior is reproduced by straight C code.
"Emulated" instructions are ones that are copied, slightly altered
and executed directly in the instruction slot to reproduce their
behavior. "Rejected" instructions are ones that could be simulated,
but work hasn't been put into simulating them. These instructions
should be very rare, if not unencountered, in the kernel. If ever
needed, code could be added to simulate them.
One might wonder why this and the ptrace singlestep facility are not
sharing some code. Both approaches are fundamentally different because
the ptrace code regains control after the stepped instruction by installing
a breakpoint after the instruction itself, and possibly at the location
where the instruction might be branching to, instead of simulating or
emulating the target instruction.
The ptrace approach isn't suitable for kprobes because the breakpoints
would have to be moved back, and the icache flushed, everytime the
probe is hit to let normal code execution resume, which would have a
significant performance impact. It is also racy on SMP since another
CPU could, with the right timing, sail through the probe point without
being caught. Because ptrace single-stepping always result in a
different process to be scheduled, the concern for performance is much
less significant.
On the other hand, the kprobes approach isn't (currently) suitable for
ptrace because it has no provision for proper user space memory
protection and translation, and even if that was implemented, the gain
wouldn't be worth the added complexity in the ptrace path compared to
the current approach.
So, until kprobes does support user space, both kprobes and ptrace are
best kept independent and separate.
Signed-off-by: Quentin Barnes <qbarnes@gmail.com>
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
registers are retained during standby mode, thus it's not necessary
to save/restore and checksum
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When PXA27x wakes up, tick_resume_oneshot() tries to set a timer
interrupt to occur immediately. Since PXA27x requires at least
MIN_OSCR_DELTA, this causes us to flag an error.
tick_program_event() then increments the next event time by
min_delta_ns. However, by the time we get back to programming
the next event, the OSCR has incremented such that we fail again.
We repeatedly retry, but the OSCR is too fast for us - we never
catch up, so we never break out of the loop - resulting in us
never apparantly resuming.
Fix this by doubling min_delta_ns.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The PXA manuals indicate that when in standby or sleep modes, clocks to
peripherals are shut off by the processor itself. Eg:
PXA270 standby: "In standby mode, all clocks are disabled except those
for the power manager and the RTC."
PXA270 sleep: "In sleep mode, all clocks are disabled to the processor
and to all peripherals except the RTC."
PXA255 sleep: "In Sleep Mode, all processor and peripheral clocks are
disabled, except the RTC."
Therefore, it should be safe to leave the clock enable register alone
prior to entering low power modes for these SoCs.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Wakeup sources on PXA3 are enabled at two levels. First, the MFP
configuration has to be set to enable which edges a specific pin
will trigger a wakeup. The pin also has to be routed to a functional
unit. Lastly, the functional unit must be enabled as a wakeup source
in the appropriate AD*ER registers (AD2D0ER for standby resume.)
This doesn't fit well with the IRQ wake scheme - we currently do a
best effort conversion from IRQ numbers to functional unit wake enable
bits. For instance, there's several USB client related enable bits but
there's no corresponding IRQs to determine which you'd want. Conversely,
there's a single enable bit covering several functional units.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook the MFP code into the power management code so that the MFPs can
be reconfigured when suspending and resuming. However, note the FIXME
- low power mode MFP configuration may depend on the system state being
entered.
Also note that we have to clear any detected edge events prior to
entering a low power mode - otherwise we immediately wake up.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There are two reasons for making the MFP configuration to be processor
independent, i.e. removing the relationship of configuration bits with
actual MFPR register settings:
1. power management sometimes requires the MFP to be configured
differently when in run mode or in low power mode
2. for future integration of pxa{25x,27x} GPIO configurations
The modifications include:
1. introducing of processor independent MFP configuration bits, as
defined in [include/asm-arm/arch-pxa/mfp.h]:
bit 0.. 9 - MFP Pin Number (1024 Pins Maximum)
bit 10..12 - Alternate Function Selection
bit 13..15 - Drive Strength
bit 16..18 - Low Power Mode State
bit 19..20 - Low Power Mode Edge Detection
bit 21..22 - Run Mode Pull State
and so on,
2. moving the processor dependent code from mfp.h into mfp-pxa3xx.h
3. cleaning up of the MFPR bit definitions
4. mapping of processor independent MFP configuration into processor
specific MFPR register settings is now totally encapsulated within
pxa3xx_mfp_config()
5. using of "unsigned long" instead of invented type of "mfp_cfg_t"
according to Documentation/CodingStyle Chapter 5, usage of this
in platform code will be slowly removed in later patches
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
pxa3xx_mfp_set_xxx() functions are originally provided for overwriting
MFP configurations performed by pxa3xx_mfp_config(), the usage of such
a dirtry trick is not recommended, since there is currently no user of
these functions, they are safely removed
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PXA3 has a different memory controller from PXA2 platforms. Avoid
clashing definitions by moving the PXA2 definitions to pxa2xx-regs.h
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The mapping for physical address 0x48000000 is not sufficient
to allow access to the dynamic memory controller configuration
registers on PXA3. These registers need to be accessed to
reconfigure the SDRAM when waking from a low power mode.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch is to add the third mmc controller support _only_
for pxa310.
On zylonite, the third controller support one slot.
Signed-off-by: Bridge Wu <bridge.wu@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch is to add the second mmc controller support for pxa3xx.
It's valid for pxa3[0|1|2]0.
On zylonite, the second controller has no slot.
Signed-off-by: Bridge Wu <bridge.wu@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patchis to add the first mmc controller support for pxa3xx.
It's valid for pxa3[0|1|2]0.
On zylonite, the first controller supports two slots, this patch
only support the first one right now.
Signed-off-by: Bridge Wu <bridge.wu@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Considering that generic.c is getting more and more bloated by device
information, moving that part out side will be much cleaner.
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch is to move pxamci DMA specific code to corresponding
platform layer because using DRCMRRXMMC/DRCMRTXMMC in pxamci.c makes
the driver code dedicated to platform which is not extensible.
It is applicable to all pxa platforms.
Signed-off-by: Bridge Wu <bridge.wu@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There have been patches hanging around for ages to add support for
cpufreq to PXA255 processors. It's about time we applied one.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Initialise the SSP driver at arch_initcall() time, so it's available
for other drivers to use it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Only register the "cpld_irq" sysclass for mainstone/lubbock if we're
running on one of those platforms.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1. make pxa2xx_spi.c use ssp_request() and ssp_free() to get the common
information of the designated SSP port.
2. remove those IRQ/memory request code, ssp_request() has done that for
the driver
3. the SPI platform device is thus made psuedo, no resource (memory/IRQ)
has to be defined, all will be retreived by ssp_request()
4. introduce ssp_get_clk_div() to handle controller difference in clock
divisor setting
5. use clk_xxx() API for clock enable/disable, and clk_get_rate() to
handle the different SSP clock frequency between different processors
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1. change SSP register definitions from absolute virtual addresses to
offsets
2. use __raw_writel()/__raw_readl() for functions of ssp_xxxx()
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1. define "struct ssp_device" for SSP information, which is requested
and released by function ssp_request()/ssp_free()
2. modify the ssp_init() and ssp_exit() to use the interface
Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
OSCR is supposed to monotonically increment; however restoring it
to a time prior to OSMR0 may result in it being wound backwards.
Instead, if OSMR0 is within the minimum expiry time, wind OSMR0
forwards.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Apparantly, the generic time subsystem can accurately emulate periodic
mode via the one-shot support code, so we don't need our own periodic
emulation code anymore. Just ensure that we build support for one shot
into the generic time subsystem.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linux has framebuffer backlight support infrastructure which should
be used to expose backlight attributes. Mainstone should use it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Only register the MMC, framebuffer, I2C and FICP devices when the
platform supplies the necessary platform data structures for the
devices.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since the PIC is attached to UART1, it doesn't need a kernel device driver
of its own; but powering off is something that the kernel should do, so
this patch forcefully configures the UART1 for 19200 baud and sends the
character that tells the PIC to cut the power.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Cc: Byron Bradley <byron.bbradley@gmail.com>
Acked-by: Nicolas Pitre <nico@marvell.com>
This patch adds support for the Orion/MV88F5182 based QNAP
TS-109/TS-209 NAS device. The driver for the S-35390A RTC
chip on this board has been submitted to LKML separately.
Signed-off-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Oyvind Repvik <repvik@kynisk.com>
Tested-by: Tim Ellis <timtimred@foonas.org>
Tested-by: Herbert Valerio Riedel <hvr@gnu.org>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
The Orion I2C controller is the same one used in the Discovery
family (MV643XX). This patch include the common platform_device
stuff according to the existing i2c_mv64xxx.c conventions.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
The D-Link DNS-323 uses a M41T80 RTC chip, so enable this driver in
the Orion defconfig.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Cc: Herbert Valerio Riedel <hvr@gnu.org>
Acked-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Basic selections for Orion machines
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Signed-off-by: Nicolas Pitre <nico@cam.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
With this patch USB, SATA (via sata_mv), Ethernet, RTC, LEDs and NOR Flash
work.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
add MV88F5181 support bits required by D-link DNS-323 patch
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Only serial, NOR, NAND, PCI and Ethernet is activated at the moment.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Reviewed-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
serial, NOR, PCI and Ethernet is activated at the moment.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Reviewed-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Orion Ethernet port is the same port used in the Discovery
family (MV643XX). This patch include the common platform_device
stuff according to the existing mv643xx_eth conventions.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds support for Orion edge sensitive GPIO IRQs.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
CC: Thomas Gleixner <tglx@linutronix.de>
This is a pre-requisite for implementing proper hardware accelerated
GPIO LED flashing, and since we want proper locking, it's sensible to provide
the orion specific orion_gpio_set_blink() implementation within
mach-orion/gpio.c. The functions orion_gpio_set_blink() and gpio_set_value()
implicitly turn off each others state.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
Acked-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Orion has fully programable address map. There's a separate address
map for each of the device _master_ interfaces, e.g. CPU, PCI, PCIE, USB,
Gigabit Ethernet, DMA/XOR engines, etc.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for PCI and PCI-E controllers in the
Orion, Orion-NAS and Orion2.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Marvell Orion is a family of ARM SoCs with a DDR/DDR2 memory
controller, 10/100/1000 ethernet MAC, and USB 2.0 interfaces,
and, depending on the specific model, PCI-E interface, PCI-X
interface, SATA controllers, crypto unit, SPI interface, SDIO
interface, device bus, NAND controller, DMA engine and/or XOR
engine.
This contains the basic structure and architecture register definitions.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
This enables the usage of some old Feroceon cores
for which the CPU ID is equal to the ARM926 ID.
Relevant for Feroceon-1850 and old Feroceon-2850.
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache replacement policy on the Feroceon core doesn't guarantee
that reading through a linear chunk of memory flushes the entire cache.
This is however what the default method for ARMv5TE cores does.
Although the Feroceon is an ARMv5TE core, it implements the same
cache handling instructions as the ARMv5TEJ cores, and must use it for
proper cache flush.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The default ARMv4 method consisting of reading through some memory
area isn't compatible with the cache replacement policy of some
ARMv5TEJ compatible cache implementations. It is also a bit wasteful
when a dedicated instruction can do the needed work optimally.
It is hard to tell if all ARMv5TEJ cores will support the used CP15
instruction, but at least all those implementations Linux currently
knows about (ARM926 and ARM1026) do support it.
Tested on an OMAP1610 H2 target.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Tested-by: George G. Davis <gdavis@mvista.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Feroceon is a family of independent ARMv5TE compliant CPU core
implementations, supporting a variable depth pipeline and out-of-order
execution. The Feroceon is configurable with VFP support, and the
later models in the series are superscalar with up to two instructions
per clock cycle.
This patch adds the initial low-level cache/TLB handling for this core.
Signed-off-by: Assaf Hoffman <hoffman@marvell.com>
Reviewed-by: Tzachi Perelstein <tzachi@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for the Atmel AT91CAP9A-DK Evaluation Kit board.
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for Atmel's AT91CAP9 Customizable Microcontroller family.
<http://www.atmel.com/products/AT91CAP/Default.asp>
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Currently the udc pullup is enabled by default on boot. If the device
is connected to a host at this time, the host starts the negotiation
before the udc/gadget driver is ready to handle it.
Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add NEW_LEDs support for the following boards:
- Cogent CSB337
- Atmel AT91RM9200-DK
- Atmel AT91RM9200-EK
- Atmel AT91SAM9263-EK
Mostly based on patch from David Brownell.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Due to errata regarding the handling of SPI CS0 on the AT91RM9200, the
atmel_spi driver drives CS0 from the SPI controller and not as a GPIO
pin.
We therefore need to configure CS0 for use by the controller
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Support for the 3 GPIO-connected buttons on the CSB300 board.
Based on wakeup testing code from David Brownell.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move the LED initialization code out of the various *_devices.c files,
and into leds.c.
Also add support for NEW_LEDs.
Patch from David Brownell.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Modify the UART initialization to allow the board-initialization code
to specify which pins are connected, and which pins should therefore
be initialized.
The current at91_init_serial() will continue to work as-is, but is
marked as "deprecated" and will be removed once the board-specific
files has been updated to use the new interface.
As in the AVR32 code, we assume that the TX and RX pins will always be
initialized.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Map the complete memory region (SZ_256M) as is done on the other AT91
processors.
The SMC_SMARTMEDIA bit should be set in the EBI controller to enable
the hardware NAND logic.
(Patch from Sascha Erlacher)
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Core support of the Atmel SSC library for all Atmel AT91 processors.
Based on David Brownell's initial patch for the AT91RM9200.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Replace hard-coded DMA mask (0xffffffff) with DMA_BIT_MASK(32) as
defined in dma-mapping.h.
Set "dma_mask" field for the UART platform_devices.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add platform_device and initialization for the RTT (Real Time Timer)
and WDT (Watchdog) integrated in the Atmel AT91SAM9 processors.
For SAM9263, register both RTT peripherals.
[From: David Brownell <dbrownell@users.sourceforge.net>]
Provide platform_resources for RTT peripherals
[From: David Brownell <dbrownell@users.sourceforge.net>]
Add support for RTC peripheral on AT91SAM9RL (same RTC peripherals as
AT91RM9200)
[From: David Brownell <dbrownell@users.sourceforge.net>]
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for the Image Sensor Interface (ISI) peripheral integrated
in the Atmel AT91SAM9263 processor.
Patch from MaLiK
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for STN LCD displays on Atmel AT91SAM9261-based boards.
Patch from Nicolas Ferre.
Signed-off-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On the at92sam9263ek board, tell the MACB driver the IRQ used
by its PHY. This patch is taken from Andrew Victor's 2.6.23-at91
patchset; it matches board schematics. (But it's currently a NOP
since the MACB driver doesn't yet use PHY irqs.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This makes HZ configurable on AT91, following the model used on OMAP.
It defaults to a power of two on AT91rm9200 chips, avoiding rounding
errors which come from dividing a 32 KiHz clock to generate scheduler
irqs; and uses 100 on AT91sam926x chips, using MCK/16 (multi-MHZ).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Remy Bhmer <linux@bohmer.net>
Acked-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Slight tweaking of the default interrupt priorities (AIC) for the
integrated peripherals on the AT91RM9200, AT91SAM9260, AT91SAM9261 and
AT91SAM9263 processors.
Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
AT91RM9200 needlessly verifies machine-type numbers of
supported / known platforms and overwrites it for unknown
ones. Remove it.
Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add STN LCD support on the Atmel AT91SAM9261-EK board.
Uses a black and white screen from Hitachi: SP06Q002.
Signed-off-by: Nicolas Ferre <nicolas.ferre@rfo.atmel.com>
Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds a debug interface (if CONFIG_DEBUG_FS is selected) to
display the basic configuration and current state of the GPIO pins on
the Atmel AT91 processors.
Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch is required, in conjunction with the patch submitted to
linux-mtd [1], to access the flash memory device in the GLAN Tank.
Without the patches, the boot log shows
physmap platform flash device: 00080000 at f0000000
...
physmap-flash physmap-flash.0: map_probe failed
whereas with the patches, the boot log shows
physmap platform flash device: 00080000 at f0000000
Found: ST M29W400DB
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
number of JEDEC chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
...
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset 0x70000
No RedBoot partition table detected in physmap-flash.0
The change made by this patch is required because the ST M29W400DB
flash memory chip in the GLAN Tank is used in 16 bit bus mode (~BYTE
pin is high when the board is powered on).
[1] http://lists.infradead.org/pipermail/linux-mtd/2008-January/020291.html
Signed-off-by: Gordon Farquharson <gordonfarquharson@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Lucas Woods <woodzy@gmail.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In early 2.6 days stack utilization instrumentation was made
configurable. Seems that arm misses the DEBUG_STACK_USAGE option.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The CONFIG variable MTD_OBSOLETE_CHIPS was deleted in commit
ba7cc09c9c.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
mach-integrator/pci_v3.c: no need to reference 'irq' arg, its constant
mach-omap1/pm.c: remove extra whitespace
arch/arm/mach-sa1100/ssp.c: remove braces around single C stmt
arch/arm/plat-omap/mcbsp.c:
- remove pointless casts from void*
- make longer lines more readable
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch enables the use of the Advanced SIMD (NEON) extension on
ARMv7. The NEON technology is a 64/128-bit hybrid SIMD architecture
for accelerating the performance of multimedia and signal processing
applications. The extension shares the registers with the VFP unit and
enabling/disabling and saving/restoring follow the same rules. In
addition, there are instructions that do not have the appropriate CP
number encoded, the checks being made in the call_fpe function.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds the support for VFPv3 (the kernel currently supports
VFPv2). The main difference is 32 double registers (compared to 16).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch allows the VFP support code to run correctly on CPUs
compatible with the common VFP subarchitecture specification (Appendix
B in the ARM ARM v7-A and v7-R edition). It implements support for VFP
subarchitecture 2 while being backwards compatible with
subarchitecture 1.
On VFP subarchitecture 1, the arithmetic exceptions are asynchronous
(or imprecise as described in the old ARM ARM) unless the FPSCR.IXE
bit is 1. The exceptional instructions can be read from FPINST and
FPINST2 registers. With VFP subarchitecture 2, the arithmetic
exceptions can also be synchronous and marked by the FPEXC.DEX bit
(the FPEXC.EX bit is cleared). CPUs implementing the synchronous
arithmetic exceptions don't have the FPINST and FPINST2 registers and
accessing them would trigger and undefined exception.
Note that FPEXC.EX bit has an additional meaning on subarchitecture 1
- if it isn't set, there is no additional information in FPINST and
FPINST2 that needs to be saved at context switch or when lazy-loading
the VFP state of a different thread.
The patch also removes the clearing of the cumulative exception flags in
FPSCR when additional exceptions were raised. It is up to the user
application to clear these bits.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for the Qualcomm MSM7200A eval board.
Common devices are defined in common.c, to avoid excessive
cut'n'pasting them into other board files.
Signed-off-by: Brian Swetland <swetland@google.com>
