The bisection implemented in unwind_find_origin() stopped to early. If
there is only a single entry left to check the original code just took
the end point as origin which might be wrong.
This was introduced in commit de66a97901 ("ARM: 7187/1: fix unwinding
for XIP kernels").
Reported-and-tested-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arm_dma_zone_size is used by arm_bootmem_free() which is called by
paging_init(). Thus it needs to be set before calling it.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In the unlikely case that a platform registers a PMU platform_device
when running on a CPU that is unsupported by perf, we will encounter a
NULL dereference when trying to assign the platform_device to the
cpu_pmu structure.
This patch checks that the CPU is supported by perf before assigning
the platform_device.
Reported-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The linker places the unwind tables in readonly sections. So when using
an XIP kernel these are located in ROM and cannot be modified.
For that reason the current approach to convert the relative offsets in
the unwind index to absolute addresses early in the boot process doesn't
work with XIP.
The offsets in the unwind index section are signed 31 bit numbers and
the structs are sorted by this offset. So it first has offsets between
0x40000000 and 0x7fffffff (i.e. the negative offsets) and then offsets
between 0x00000000 and 0x3fffffff. When seperating these two blocks the
numbers are sorted even when interpreting the offsets as unsigned longs.
So determine the first non-negative entry once and track that using the
new origin pointer. The actual bisection can then use a plain unsigned
long comparison. The only thing that makes the new bisection more
complicated is that the offsets are relative to their position in the
index section, so the key to search needs to be adapted accordingly in
each step.
Moreover several consts are added to catch future writes and rename the
member "addr" of struct unwind_idx to "addr_offset" to better match the
new semantic. (This has the additional benefit of breaking eventual
users at compile time to make them aware of the change.)
In my tests the new algorithm was a tad faster than the original and has
the additional upside of not needing the initial conversion and so saves
some boot time and it's possible to unwind even earlier.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 1b9f95f8ad (ARM: prepare for removal of a bunch of <mach/memory.h>
files) introduced CONFIG_PHYS_OFFSET but the Kconfig hex prompt did not
provide a default value.
This has the undesired side effect of breaking a reportedly used
trick for updating defconfigs on the fly for routine buildtesting
across all arch and all platforms, i.e.
cp /path/to/somedefconfig .config ; yes "" | make oldconfig
because the config system will endlessly loop until a valid address is
provided.
However we can't just pick a random default value since it is likely to
be wrong for the majority of the boards as the right answer for this
option is quite varied. So the fact that the config system insists on
having a proper value be entered is actually a good thing.
It turns out that only at91x40_defconfig has this problem because it has
CONFIG_MMU=n. However, in the !MMU case, there is already a CONFIG_DRAM_BASE
value that can be used here. So let's use that as a default in that case
and suppress the redundant CONFIG_PHYS_OFFSET prompt.
Eventually the DRAM_BASE config option could simply be replaced by
PHYS_OFFSET directly, but that's a larger change better suited for later.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix loss of notification with multi-event
perf, x86: Force IBS LVT offset assignment for family 10h
perf, x86: Disable PEBS on SandyBridge chips
trace_events_filter: Use rcu_assign_pointer() when setting ftrace_event_call->filter
perf session: Fix crash with invalid CPU list
perf python: Fix undefined symbol problem
perf/x86: Enable raw event access to Intel offcore events
perf: Don't use -ENOSPC for out of PMU resources
perf: Do not set task_ctx pointer in cpuctx if there are no events in the context
perf/x86: Fix PEBS instruction unwind
oprofile, x86: Fix crash when unloading module (nmi timer mode)
oprofile: Fix crash when unloading module (hr timer mode)
Otherwise timing is inaccurate, resulting in devices which depend on it,
like omap-keypad, broken.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
[tony@atomide.com: removed comment referencing a development branch]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Current partition information maintained in kernel does not match with
u-boot, this leads to corruption of u-boot env when we update uImage
from kernel. Patch fixes it to match with u-boot partition information.
Signed-off-by: Shankarmurthy,Akshay <akshay.s@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
On OMAP-L138 platform, EDMA event queue 0 should be used for audio
transfers so that they are not starved by video data moving on event queue 1.
Commit 48519f0ae0 (ASoC: davinci: let platform
data define edma queue numbers) had a side-effect of changing this behavior
by making the driver actually honor the platform data passed.
Fix this now by passing event queue 0 as the queue to be used for audio
transfers.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Cc: <stable@vger.kernel.org> # v2.6.36.x and above
The function setup_vpif_input_channel_mode() used the VSCLKDIS register
instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0
used a different clock from channel 1.
Clearly a copy-and-paste error.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Cc: stable@kernel.org
Fix the incorrect classification of DSP clock into a
seperate DSP domain on DM646x.
Per the reference guide (http://www.ti.com/lit/ug/spruep9e/spruep9e.pdf)
there is only one "AlwaysON" power domain on DM6467.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Seperate PDSTAT and PDCTL registers are defined for
domain 0 and domain 1 where as the code always reads
the domain 0 PDSTAT register and domain 1 PDCTL register.
Fix this issue. While at it, introduce usage of macros
for register masks to improve readability.
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
There are 5 LSB bits defined in PDSTAT and the code
currently uses a mask of 1 bit to check the status.
Use a proper mask per the hardware specification.
While at it, use a #define for the mask to improve
readability.
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
It's a correction of two macro names, renaming them from IRADC to LRADC.
Signed-off-by: Peter Rusko <rusko.peter@prolan.hu>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Adding the machine_is_* line was forgotten when converting mach-stmp378x to
mach-mxs.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: stable@kernel.org
Initializers of m28evk and stmp378x_devb fixed to be in order
they are called.
reference: http://article.gmane.org/gmane.linux.ports.arm.omap/50721
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The symbol is not exported and doesn't need to be.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This is required for the EXPORT_SYMBOL()s the code uses, previously the
header was being included implicitly by another header.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The extern is only useful on prototypes.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
In the new kernel, we will get the following compile error:
arch/arm/mach-prima2/pm.c:141: error: 'THIS_MODULE' undeclared
here (not in a function)
so include module.h head file explicitly
Signed-off-by: Barry Song <baohua.song@csr.com>
commit 98b0124f0e
"ARM: mach-prima2: move ARM_DMA_ZONE_SIZE to mdesc->dma_zone_size"
causes building error:
arch/arm/mach-prima2/prima2.c:39:19: error: 'SZ_256M' undeclared here
(not in a function)
Signed-off-by: Barry Song <baohua.song@csr.com>
Use the exact value found in omap1_rate_table, otherwise I have been
experiencing issues with correct timekeeping on my Amstrad Delta.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
[tony@atomide.com: removed comment referencing a development branch]
Signed-off-by: Tony Lindgren <tony@atomide.com>
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on Kconfig options for the supported
MHz rates in case of boards which boot with dpll1 not set correctly by
their boot loaders.
This means that before we allow for reprogramming of dpll1 rate, we
should remove all unsafe clock selections from omap1_defconfig,
otherwise it will stop booting on boards with imperfect boot loaders,
as it would always try to change to 216MHz.
Keep only one safe clock rate per each supported xtal frequency, i.e.
60MHZ dpll1 for 12MHz xtal and 182MHz dpll1 for 13MHz xtal.
BTW, this change goes into the direction of removing all OMAP1 clock
rate options, planned for next merge window.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit e9b7086b80 (ARM: OMAP: Fix
reprogramming of dpll1 rate) fixed a regression for systems that
did not rely on bootloader set rates.
However, it also introduced a new problem where the rates selected
in .config would not take affect as omap1_select_table_rate
currently refuses to reprogram DPLL1 if it's already initialized.
This was not a problem earlier, as the reprogramming was done
earlier with ck_dpll1_p->rate uninitialized.
Fix this by forcing the reprogramming on systems booting at rates
below 60MHz. Note that the long term fix is to make the rates
SoC specific later on.
Thanks for Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> for figuring
this one out.
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
* 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm:
ARM: 7182/1: ARM cpu topology: fix warning
ARM: 7181/1: Restrict kprobes probing SWP instructions to ARMv5 and below
ARM: 7180/1: Change kprobes testcase with unpredictable STRD instruction
ARM: 7177/1: GIC: avoid skipping non-existent PPIs in irq_start calculation
ARM: 7176/1: cpu_pm: register GIC PM notifier only once
ARM: 7175/1: add subname parameter to mfp_set_groupg callers
ARM: 7174/1: Fix build error in kprobes test code on Thumb2 kernels
ARM: 7172/1: dma: Drop GFP_COMP for DMA memory allocations
ARM: 7171/1: unwind: add unwind directives to bitops assembly macros
ARM: 7170/2: fix compilation breakage in entry-armv.S
ARM: 7168/1: use cache type functions for arch_get_unmapped_area
ARM: perf: check that we have a platform device when reserving PMU
ARM: 7166/1: Use PMD_SHIFT instead of PGDIR_SHIFT in dma-consistent.c
ARM: 7165/2: PL330: Fix typo in _prepare_ccr()
ARM: 7163/2: PL330: Only register usable channels
ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds
ARM: 7161/1: errata: no automatic store buffer drain
ARM: perf: initialise used_mask for fake PMU during validation
ARM: PMU: remove pmu_init declaration
ARM: PMU: re-export release_pmu symbol to modules
When gpio core dynamically allocate gpio number for a port, it starts
from the end of the total range, 0 ~ ARCH_NR_GPIOS. That said, the
earlier a port gets probed, the bigger gpio number it gets assigned.
To match this, the irq_base for gpio should be assigned from
'MXC_GPIO_IRQ_START + ARCH_NR_GPIOS' decreasingly.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The of_irq_init() expects the callback passed by .data of of_device_id
return 'int' instead of 'void'. This patch fixes it to have
irq_init_cb() return the correct value, and in turn have the secondary
interrupt controller (gpio in this case) initialized properly and also
eliminate the error message 'of_irq_init: children remain, but no
parents' which was overlooked before.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
kernel/sched.c:7354:2: warning: initialization from incompatible pointer type
Align cpu_coregroup_mask prototype interface with sched_domain_mask_f typedef
use int cpu instead of unsigned int cpu
Cc: <stable@vger.kernel.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The SWP instruction is deprecated on ARMv6 and with ARMv7 it will be
UNDEFINED when CONFIG_SWP_EMULATE is selected. In this case, probing a
SWP instruction will cause an oops when the kprobes emulation code
executes an undefined instruction.
As the SWP instruction should be rare or non-existent in kernels for
ARMv6 and later, we can simply avoid these problems by not allowing
probing of these.
Reported-by: Leif Lindholm <leif.lindholm@arm.com>
Tested-by: Leif Lindholm <leif.lindholm@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There is a kprobes testcase for the instruction "strd r2, [r3], r4".
This has unpredictable behaviour as it uses r3 for register writeback
addressing and also stores it to memory.
On a cortex A9, this testcase would fail because the instruction writes
the updated value of r3 to memory, whereas the kprobes emulation code
writes the original value.
Fix this by changing testcase to used r5 instead of r3.
Reported-by: Leif Lindholm <leif.lindholm@arm.com>
Tested-by: Leif Lindholm <leif.lindholm@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since 193ab2a607, various AT91 boards don't
register at91_udc anymore due to depending on a now non-existing symbol.
Fix the symbol name.
Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
The conid is supposed to be t0/t1/t2_clk.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
This updates the Ux500 defconfig with the new drivers for HWSEM
and AB5500 core that were merged in the 3.2 cycle.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This updates the U300 defconfig to support some new drivers like
FSMC, sets it to use the MMC clock gating scheme, and removes
some stale config options.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Make it is safe to assign the return value of this function
to u8/u16 variables.
Signed-off-by: Christian Hitz <christian.hitz@aizo.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
