| Age | Commit message (Collapse) | Author |
|---|
|
The IRQ_* macros need to be made visible via the mach/irqs.h file but
without the additional macros defined in the board-*.h files.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
_sdata and __bss_stop are common symbols defined by many architectures
and made available to the kernel via asm-generic/sections.h. Kmemleak
uses these symbols when scanning the data sections.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
This patch adds a comment to the proc-v7.S file for the setting of the
PRRR and NMRR registers. It also sets the PRRR[13:12] bits to 0
(corresponding to the reserved TEX[0]CB encoding 110) to be consistent
with the documentation.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The SWP instruction has been deprecated starting with the ARMv6
architecture. On ARMv7 processors with the multiprocessor extensions
(like Cortex-A9), this instruction is disabled by default but it can be
enabled by setting bit 10 in the System Control register. Note that
setting this bit is safe even if the ARMv7 processor has the SWP
instruction enabled by default.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
If a process is interrupted during an If-Then block and a signal is
invoked, the ITSTATE bits must be cleared otherwise the handler would
not run correctly.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Joseph S. Myers <joseph@codesourcery.com>
|
|
There are additional bits to set for the ARMv7 SMP extensions in the
TTBR registers. The IRGN bits order is counter-intuitive but it allows
software built for the ARMv7 base architecture to run on an
implementation with the MP extensions.
Signed-off-by: Tony Thompson <Anthony.Thompson@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
ARMv7 SMP hardware can handle the TLB maintenance operations
broadcasting in hardware so that the software can avoid the costly IPIs.
This patch adds the necessary checks (the MMFR3 CPUID register) to avoid
the broadcasting if already supported by the hardware.
(this patch is based on the work done by Tony Thompson @ ARM)
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
If CONFIG_LEDS is enabled, it makes more sense to toggle one LED per CPU
in SMP systems rather than a single LED for all the CPUs.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Signed-off-by: Colin Tuckley <Colin.Tuckley@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
This patch adds a Kconfig option for specifying whether Linux will only
be run in secure mode on the RealView PB1176 platform. Enabling it will
make the secure flash memory block (64MB @ 0x3c000000) available to
Linux.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
This is a RealView platform supporting core tiles with ARM11MPCore,
Cortex-A8 or Cortex-A9 (multicore) processors. It has support for MMC,
CompactFlash, PCI-E.
Signed-off-by: Colin Tuckley <colin.tuckley@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Previous size thresholds were guessed from various user space benchmarks
using a kernel with and without the alternative uaccess option. This
is however not as precise as a kernel based test to measure the real
speed of each method.
This adds a simple test bench to show the time needed for each method.
With this, the optimal size treshold for the alternative implementation
can be determined with more confidence. It appears that the optimal
threshold for both copy_to_user and clear_user is around 64 bytes. This
is not a surprise knowing that the memcpy and memset implementations
need at least 64 bytes to achieve maximum throughput.
One might suggest that such test be used to determine the optimal
threshold at run time instead, but results are near enough to 64 on
tested targets concerned by this alternative copy_to_user implementation,
so adding some overhead associated with a variable threshold is probably
not worth it for now.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
Because the alternate copy_to_user implementation has a higher setup cost
than the standard implementation, the size of the memory area to copy
is tested and the standard implementation invoked instead when that size
is too small. Still, that test is made after the processor has preserved
a bunch of registers on the stack which have to be reloaded right away
needlessly in that case, causing a measurable performance regression
compared to plain usage of the standard implementation only.
To make the size test overhead negligible, let's factorize it out of
the alternate copy_to_user function where it is clear to the compiler
that no stack frame is needed. Thanks to CONFIG_ARM_UNWIND allowing
for frame pointers to be disabled and tail call optimization to kick in,
the overhead in the small copy case becomes only 3 assembly instructions.
A similar trick is applied to clear_user as well.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
This implements {copy_to,clear}_user() by faulting in the userland
pages and then using the regular kernel mem{cpy,set}() to copy the
data (while holding the page table lock). This is a win if the regular
mem{cpy,set}() implementations are faster than the user copy functions,
which is the case e.g. on Feroceon, where 8-word STMs (which memcpy()
uses under the right conditions) give significantly higher memory write
throughput than a sequence of individual 32bit stores.
Here are numbers for page sized buffers on some Feroceon cores:
- copy_to_user on Orion5x goes from 51 MB/s to 83 MB/s
- clear_user on Orion5x goes from 89MB/s to 314MB/s
- copy_to_user on Kirkwood goes from 240 MB/s to 356 MB/s
- clear_user on Kirkwood goes from 367 MB/s to 1108 MB/s
- copy_to_user on Disco-Duo goes from 248 MB/s to 398 MB/s
- clear_user on Disco-Duo goes from 328 MB/s to 1741 MB/s
Because the setup cost is non negligible, this is worthwhile only if
the amount of data to copy is large enough. The operation falls back
to the standard implementation when the amount of data is below a certain
threshold. This threshold was determined empirically, however some targets
could benefit from a lower runtime determined value for optimal results
eventually.
In the copy_from_user() case, this technique does not provide any
worthwhile performance gain due to the fact that any kind of read access
allocates the cache and subsequent 32bit loads are just as fast as the
equivalent 8-word LDM.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Martin Michlmayr <tbm@cyrius.com>
|
|
This allows for optional alternative implementations of __copy_to_user
and __clear_user, with a possible runtime fallback to the standard
version when the alternative provides no gain over that standard
version. This is done by making the standard __copy_to_user into a weak
alias for the symbol __copy_to_user_std. Same thing for __clear_user.
Those two functions are particularly good candidates to have alternative
implementations for, since they rely on the STRT instruction which has
lower performances than STM instructions on some CPU cores such as
the ARM1176 and Marvell Feroceon.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
CSUM copy to/from user assembler was missing allocatable and
executable attributes for .fixup
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] update mach-types
[ARM] Add cmpxchg support for ARMv6+ systems (v5)
[ARM] barriers: improve xchg, bitops and atomic SMP barriers
Gemini: Fix SRAM/ROM location after memory swap
MAINTAINER: Add F: entries for Gemini and FA526
[ARM] disable NX support for OABI-supporting kernels
[ARM] add coherent DMA mask for mv643xx_eth
[ARM] pxa/palm: fix PalmLD/T5/TX AC97 MFP
[ARM] pxa: add parameter to clksrc_read() for pxa168/910
[ARM] pxa: fix the incorrectly defined drive strength macros for pxa{168,910}
[ARM] Orion: Remove explicit name for platform device resources
[ARM] Kirkwood: Correct MPP for SATA activity/presence LEDs of QNAP TS-119/TS-219.
[ARM] pxa/ezx: fix pin configuration for low power mode
[ARM] pxa/spitz: provide spitz_ohci_exit() that unregisters USB_HOST GPIO
[ARM] pxa: enable GPIO receivers after configuring pins
[ARM] pxa: allow gpio_reset drive high during normal work
[ARM] pxa: save/restore PGSR on suspend/resume.
|
|
Proper pin configuration for MMC.
Signed-off-by: Sergey Lapin <slapin@ossfans.org>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add board information about on-board I2C eeprom AT24C512N at 0x50.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Update the dma clocks so that the magic numbers are named.
All the dma clocks have an enable bit to turn them on/off as
needed. Currently these bits are in the code as "magic"
numbers. This changes all of them to named defines to
improve code readability.
Also, the EP93XX_SYSCON_CLOCK_CONTROL register is improperly
named. In the EP93xx User's Guide this register is called
PwrCnt (Power Control). All of the uses of this register
are associated with the clock support so this patch also
modifies the names to match the User's Guide.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Fix trivial spelling error in arch/arm/mach-ep93xx/core.c
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Cleanup the ohci-ep93xx driver.
1) Use the usb.h dbg() macro instead of pr_debug() so that
the source filename is prefixed to the message and it is
terminated with a linefeed.
2) Add error handling for the clk_get() call.
3) Update clkdev support so that the usb clock is matched by
the dev_id instead of the con_id.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 into devel
Conflicts:
arch/arm/Makefile
|
|
Some DMA_32BIT_MASK usage snuck in with the MMC platform support.
Convert these to the new preferred DMA_BIT_MASK(32).
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
shared or not
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13302
On x86 and x86-64, it is possible that page tables are shared beween
shared mappings backed by hugetlbfs. As part of this,
page_table_shareable() checks a pair of vma->vm_flags and they must match
if they are to be shared. All VMA flags are taken into account, including
VM_LOCKED.
The problem is that VM_LOCKED is cleared on fork(). When a process with a
shared memory segment forks() to exec() a helper, there will be shared
VMAs with different flags. The impact is that the shared segment is
sometimes considered shareable and other times not, depending on what
process is checking.
What happens is that the segment page tables are being shared but the
count is inaccurate depending on the ordering of events. As the page
tables are freed with put_page(), bad pmd's are found when some of the
children exit. The hugepage counters also get corrupted and the Total and
Free count will no longer match even when all the hugepage-backed regions
are freed. This requires a reboot of the machine to "fix".
This patch addresses the problem by comparing all flags except VM_LOCKED
when deciding if pagetables should be shared or not for hugetlbfs-backed
mapping.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: <starlight@binnacle.cx>
Cc: Eric B Munson <ebmunson@us.ibm.com>
Cc: Adam Litke <agl@us.ibm.com>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The flat loader uses an architecture's flat_stack_align() to align the
stack but assumes word-alignment is enough for the data sections.
However, on the Xtensa S6000 we have registers up to 128bit width
which can be used from userspace and therefor need userspace stack and
data-section alignment of at least this size.
This patch drops flat_stack_align() and uses the same alignment that
is required for slab caches, ARCH_SLAB_MINALIGN, or wordsize if it's
not defined by the architecture.
It also fixes m32r which was obviously kaput, aligning an
uninitialized stack entry instead of the stack pointer.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Oskar Schirmer <os@emlix.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Bryan Wu <cooloney@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Johannes Weiner <jw@emlix.com>
Acked-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci into devel
|
|
|
|
|
|
Conflicts:
arch/arm/mach-omap2/serial.c
|
|
Conflicts:
arch/arm/mach-omap2/Makefile
|
|
DaVinci EMAC driver is now upstream. Enable it in default defconfig.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses. This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).
Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.
The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Package on-chip SRAM. It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.
In some cases (dm6467) the physical addresses used for EDMA are
not the same as the ones used by the ARM ... so record that info
separately in the SOC data, for chips (unlike the OMAP-L137)
where SRAM may be used with EDMA.
Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
may be unused/available on some system. They are ignored here.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Remove remnants of dm6446-specific SRAM allocator, as preparation for
a more generic replacement.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Different SoC have different numbers of pinmux registers and other
resources that overlap with each other. To clean up the code and
eliminate defines that overlap with each other, move the PINMUX
defines to the SoC specific files.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The Timer64p timer has 8 compare registers that can
be used to generate interrupts when the timer value
matches the compare reg's value. They do not disturb
the timer itself. This can be useful when there is
only one timer available for both clock events and
clocksource.
When enabled, the clocksource remains a continuous
32-bit counter but the clock event will no longer
support periodic interrupts. Instead only oneshot
timers will be supported and implemented by setting
the compare register to the current timer value plus
the period that the clock event subsystem is requesting.
Compare registers support is enabled automatically
when the following conditions are met:
1) The same timer is being used for clock events
and clocksource.
2) The timer is the bottom half (32 bits) of the
64-bit timer (hardware limitation).
3) The the compare register offset and irq are
not zero.
Since the timer is always running, there is a hardware
race in timer32_config() between reading the current
timer value, and adding the period to the current
timer value and writing the compare register.
Testing on a da830 evm board with the timer clocked
at 24 MHz and the processor clocked at 300 MHz,
showed the number of counter ticks to do this ranged
from 20-53 (~1-2.2 usecs) but usually around 41 ticks.
This includes some artifacts from collecting the
information. So, the minimum period should be
at least 5 usecs to be safe.
There is also an non-critical lower limit that
the period should be since there is no point in
setting an event that is much shorter than the
time it takes to set the event, and get & handle
the timer interrupt for that event. There can
also be all sorts of delays from activities
occuring elsewhere in the system (including
hardware activitis like cache & TLB management).
These are virtually impossible to quantify so a
minimum period of 50 usecs was chosen. That will
certianly be enough to avoid the actual hardware
race but hopefully not large enough to cause
unreasonably course-grained timers.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Integrate the Common Platform Interrupt Controller (cp_intc)
support into the low-level irq handling for davinci and similar
platforms. Do it such that support for cp_intc and the original
aintc can coexist in the same kernel binary.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Factor out the code to extract that mac address from
i2c eeprom.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The dm644x and dm646x board files have i2c eeprom read and
write routines but they are not used so remove them.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Since most of the emac platform_data is really SoC specific
and not board specific, move it to the SoC-specific files.
Put a pointer to the platform_data in the soc_info structure
so the board-specific code can set some of the platform_data
if it needs to.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
Currently, there is one set of platform_device and platform_data
structures for all DaVinci SoCs. The differences in the data
between the various SoCs is handled by davinci_serial_init()
by checking the SoC type. However, as new SoCs appear, this
routine will become more & more cluttered.
To clean up the routine and make it easier to add support for new
SoCs, move the platform_device and platform_data structures into the
SoC-specific code and use the SoC infrastructure to provide access
to the data.
In the process, fix a bug where the wrong irq is used for uart2
of the dm646x.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
The current gpio code needs to know the number of
gpio irqs there are and what the bank irq number is.
To determine those values, it checks the SoC type.
It also assumes that the base address and the number
of irqs the interrupt controller uses is fixed.
To clean up the SoC checks and make it support
different base addresses and interrupt controllers,
have the SoC-specific code set those values in
the soc_info structure and have the gpio code
reference them there.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
|
This patch adds the defconfig for OMAP4430 SDP platform.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
This patch updates the Makefile and Kconfig entries for OMAP4. The OMAP4430 SDP
board file supports only minimal set of drivers.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
