| Age | Commit message (Collapse) | Author |
|---|
|
Newer gcc versions offer an architecture-independent option to check
the stack size and warn if it reaches a certain limit. This option
already existed for s390 by using -mwarn-dynamicstack. Since one
stack check option is enough remove the s390 specific stack check
but keep the option that warns about dynamic stack usage because
that is not covered by the generic option.
Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Adds support for the hardware watchdog found in Ingenic's jz4740
System-on-Chip.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci into devel-stable
|
|
Update p1022 sata compatible to "fsl,p1022-sata", "fsl,pq-sata-v2".
p1022ds sata controller is v2 version comparing previous FSL sata
controller, for example, mpc8536.
Signed-off-by: Lei Xu <B33228@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a
core serializing instruction such as "cpuid" should be executed on _each_ core
before the new instruction is made visible.
Failure to do so can lead to unspecified behavior (Intel XMC erratas include
General Protection Fault in the list), so we should avoid this at all cost.
This problem can affect modified code executed by interrupt handlers after
interrupt are re-enabled at the end of stop_machine, because no core serializing
instruction is executed between the code modification and the moment interrupts
are reenabled.
Because stop_machine_text_poke performs the text modification from the first CPU
decrementing stop_machine_first, modified code executed in thread context is
also affected by this problem. To explain why, we have to split the CPUs in two
categories: the CPU that initiates the text modification (calls text_poke_smp)
and all the others. The scheduler, executed on all other CPUs after
stop_machine, issues an "iret" core serializing instruction, and therefore
handles core serialization for all these CPUs. However, the text modification
initiator can continue its execution on the same thread and access the modified
text without any scheduler call. Given that the CPU that initiates the code
modification is not guaranteed to be the one actually performing the code
modification, it falls into the XMC errata.
Q: Isn't this executed from an IPI handler, which will return with IRET (a
serializing instruction) anyway?
A: No, now stop_machine uses per-cpu workqueue, so that handler will be
executed from worker threads. There is no iret anymore.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
LKML-Reference: <20110303160137.GB1590@Krystal>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: <stable@kernel.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
Commit da3ed89e7ce272ebcc918487e2a28736ca0dd6bb added
'fsl,qoriq-gpio' compatiable searching in the old way
using for_each_compatible_node(). But the driver have
previously been changed to use a struct of_device_id
compatible list passed to for_each_matching_node().
Add 'fsl,qoriq-gpio' compatiable to the existing
compatible list instead of adding another
for_each_compatible_node() loop.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
The MUSB driver doesn't see its platform device on DM644x EVM board anymore
since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci
to its own platform_driver) because the new probe is called as subsys_initcall()
now, and the device is registered later than that by the board code. Move the
registration to davinci_evm_init() -- it's safe to do so because the MUSB core
device still gets initialized as fs_initcall() -- which is late enough for the
I2C GPIO expander (which controls VBUS) to be initialized.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
This patch adds definitions for spi devices on the tnetv107x evm platform.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
This patch adds SSP configuration and pin muxing info for tnetv107x
evm boards.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
This patch adds an SSP platform device definition for the tnetv107x soc family.
The clock lookup entry has also been updated to match.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
|
|
The MPC852 based mgsuvd board from Keymile was initially ported,
but later on not developed further. This patch removes the respective
files to decrease merging conflicts and unneeded maintenance.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher<hs@denx.de>
Cc: Vitaly Bordug <vitb@kernel.crashing.org>
Cc: Marcelo Tosatti <marcelo@kvack.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
The mgcoge board from keymile is now base for some other
similar boards. Therefore the board specific name mgcoge
was renamed to a generic name km82xx. Additionally some
enhancements were made:
- rework partition table in dts file
- add cpm2_pio_c gpio controller in dts file
- update defconfig
- add pin description for SCC1
- add pin description and configuration for USB
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher <hs@denx.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Heiko Schocher <hs@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Beside the MPC 8360 based board kmeter1 other km83xx boards
from keymile will follow. Therefore the board specific naming
kmeter1 for functions and files were replaced with km83xx.
Additionally some updates were made:
- update defconfig for 2.6.38
- rework flash partitioning in dts file
- add gpio controller for qe_pio_c in dts
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Heiko Schocher <hs@denx.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Heiko Schocher <hs@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
This erratum can occur if a single-precision floating-point,
double-precision floating-point or vector floating-point instruction on a
mispredicted branch path signals one of the floating-point data interrupts
which are enabled by the SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits). This
interrupt must be recorded in a one-cycle window when the misprediction is
resolved. If this extremely rare event should occur, the result could be:
The SPE Data Exception from the mispredicted path may be reported
erroneously if a single-precision floating-point, double-precision
floating-point or vector floating-point instruction is the second
instruction on the correct branch path.
According to errata description, some efp instructions which are not
supposed to trigger SPE exceptions can trigger the exceptions in this case.
However, as we haven't emulated these instructions here, a signal will
send to userspace, and userspace application would exit.
This patch re-issue the efp instruction that we haven't emulated,
so that hardware can properly execute it again if this case happen.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
FSL PCIe controller v2.1:
- New MSI inbound window
- Same Inbound windows address as PCIe controller v1.x
Added new pit_t member(pmit) to struct ccsr_pci for MSI inbound window
FSL PCIe controller v2.2 and v2.3:
- Different addresses for PCIe inbound window 3,2,1
- Exposed PCIe inbound window 0
- New PCIe interrupt status register
Added new config and interrupt Status register to struct ccsr_pci & updated
pit_t array size to reflect the 4 inbound windows.
Device tree is used to maintain backward compatibility i.e. update inbound
window 1 index depending upon "compatible" field witin PCIE node.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
If the spin table is located in the linear mapping (which can happen if
we have 4G or more of memory) we need to access the spin table via a
cacheable coherent mapping like we do on ppc32 (and do explicit cache
flush).
See the following commit for the ppc32 version of this issue:
commit d1d47ec6e62ab08d2ebb925fd9203abfad3adfbf
Author: Peter Tyser <ptyser@xes-inc.com>
Date: Fri Dec 18 16:50:37 2009 -0600
powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
This patch includes the implementation of the clock gating
for System MMU. Initially, all System MMUs are not asserted
the system clock. Asserting the system clock to a System MMU
is enabled only when s5p_sysmmu_enable() is called. Likewise,
it is disabled only when s5p_sysmmu_disable() is called.
Therefore, clock gating on System MMUs are still invisible to
the outside of the System MMU driver.
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch includes the following enhancements for System MMU:
- Enhanced readability
- Removal of unused data structures or their members
- Simplified function definitions
- Corrections of some logical errors
- Full compliance with Linux coding style
- Simpler way of registering callback functions of System MMU faults
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch adds support for gpio interrupts on Samsung EXYNOS4 platform.
Common s5p-gpioint.c code is used for handling gpio interrupts. Each gpio
line that needs gpio interrupt support must be later registered with
s5p_register_gpio_interrupt() function.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch removes all global data from common s5p gpio interrupt
handler code. This enables to reuse this code on EXYNOS4 platform.
Instead of global data (IRQ_GPIOINT interrupt number,
S5P_GPIOINT_GROUP_MAXNR groups count), a s5p_register_gpioint_bank()
function is introduced. It is aimed to be called from gpiolib init.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch performs a global cleanup in s5p gpio interrupt support code.
The code is prepared for upcoming support for gpio interrupts on EXYNOS4
platform, which has 2 gpio banks (regions) instead of one (like on
S5PC110 and S5PC100).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch adds missing GPYx gpio banks on Samsung EXYNOS4 platform.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
The cpufreq init function is referenced from the driver structure and
we don't appear to have annotations which allow us to mark that it'll
never be called after system init, causing the linker consistency
infrastructure to complain. Just remove the __init annotation to avoid
noise from the build.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch is to support keypad device to the SMDKV310 board.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
The keypad IF on EXYNOS4 uses 100MHz from PERIR functional
block for clocks, this patch updates the same.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch updates the keypad IF base address in the memory map
for EXYNOS4.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
This patch adds the samsung_keypad_cfg_gpio() for EXYNOS4.
Now, this helpers are only for keypad operating in PORT-0.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
|
|
The EDGE Port module of some ColdFire parts using the intc-simr interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The EDGE Port module of some ColdFire parts using the intc-2 interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The reality is that you do not need the abiltity to configure the
clock divider for ColdFire CPUs. It is a fixed ratio on any given
ColdFire family member. It is not the same for all ColdFire parts,
but it is always the same in a model range. So hard define the divider
for each supported ColdFire CPU type and remove the Kconfig option.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5407/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/532x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5307/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/527x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:39:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:55:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5272/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:67:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:68:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:69:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5249/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/523x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
rch/m68knommu/platform/520x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5206e/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast CC kernel/panic.o
arch/m68knommu/platform/5206e/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206e/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Fix these compiler warnings:
arch/m68knommu/platform/5206/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Signed-off-by: Alexander Kurz <linux@kbdbabel.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The intc-simr interrupt controller on some ColdFire CPUs has a set range of
interrupts its supports (64 through 128 or 192 depending on model). We
shouldn't be setting this handler for every possible interrupt from 0 to
255. Set more appropriate limits, and this means we can drop the interrupt
number check in the mask and unmask routines.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Use a proper irq_startup() routine to intialize the interrupt priority
and level register in the ColdFire intc-2 controller code. We shouldn't
be checking if the priority/level has been set on every unmask operation.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The intc-2 interrupt controller on some ColdFire CPUs has a set range of
interrupts its supports (64 through 128 or 192 depending on model). We
shouldn't be setting this handler for every possible interrupt from 0 to
255. Set more appropriate limits, and this means we can drop the interrupt
number check in the mask and unmask routines.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The FireBee is a ColdFire 5475 based board. Add a configuration option
to support it, and the basic platform flash layout code.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Most ColdFire CPUs have an internal peripheral set that can be mapped at
a user selectable address. Different ColdFire parts either use an MBAR
register of an IPSBAR register to map the peripheral region. Most boards
use the Freescale default mappings - but not all.
Make the setting of the MBAR or IPSBAR register configurable. And only make
the selection available on the appropriate ColdFire CPU types.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Different ColdFire CPUs have different ways of defining where their
internal peripheral registers sit in their address space. Some use an
MBAR register, some use and IPSBAR register, some have a fixed mapping.
Now that most of the peripheral address definitions have been cleaned up
we can clean up the setting of the MBAR and IPSBAR defines to limit them
to just where they are needed (and where they actually exist).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
In some of the RAM size autodetection code on ColdFire CPU startup
we reference DRAM registers relative to the MBAR register. Not all of
the supported ColdFire CPUs have an MBAR, and currently this works
because we fake an MBAR address on those registers. In an effort to
clean this up, and eventually remove the fake MBAR setting make the
DRAM register address definitions actually contain the MBAR (or IPSBAR
as appropriate) value as required.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Not all ColdFire CPUs that use the old style timer hardware module use
an MBAR set peripheral region. Move the TIMER base address defines to the
per-CPU header files where we can set it correctly based on how the
peripherals are mapped - instead of using a fake MBAR for some platforms.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The base addresses of the ColdFire DMA unit registers belong with
all the other address definitions in the per-cpu headers. The current
definitions assume they are relative to an MBAR register. Not all
ColdFire CPUs have an MBAR register. A clean address define can only
be acheived in the per-cpu headers along with all the other chips
peripheral base addresses.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
