IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This does the same as the previous commit, but for the S bit, which also
needs to match the initial value which the assembly code used for the
same reasons. Again, we add a check for SMP to ensure that the page
tables are correctly setup for SMP.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix a long standing bug where, for ARMv6+, we don't fully ensure that
the C code sets the same cache policy as the assembly code. This was
introduced partially by commit 11179d8ca2 ([ARM] 4497/1: Only allow
safe cache configurations on ARMv6 and later) and also by adding SMP
support.
This patch sets the default cache policy based on the flags used by the
assembly code, and then ensures that when a cache policy command line
argument is used, we verify that on ARMv6, it matches the initial setup.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
cr_no_alignment is really only used by the alignment code. Since we no
longer change the setting of cr_alignment after boot, we can localise
this to alignment.c
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
alignment.c will not be built unless CPU_CP15 is set:
config CPU_CP15
bool
config CPU_CP15_MMU
bool
select CPU_CP15
config ALIGNMENT_TRAP
bool
depends on CPU_CP15_MMU
So there's no point having conditionals on CPU_CP15 within this code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
memblock is now fully integrated into the kernel and is the prefered
method for tracking memory. Rather than reinvent the wheel with
meminfo, migrate to using memblock directly instead of meminfo as
an intermediate.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Due to a design incompatibility between the PCIe Marvell controller
and the Cortex-A9, stressing PCIe devices with a lot of traffic
quickly causes a deadlock.
One part of the workaround for this is to have all PCIe regions mapped
as strongly-ordered (MT_UNCACHED) instead of the default
MT_DEVICE. While the arch_ioremap_caller() mechanism allows
sub-architecture code to override ioremap(), used to map PCIe memory
regions, there isn't such a mechanism to override the behavior of
pci_ioremap_io().
This commit adds the arch_pci_ioremap_mem_type variable, initialized
to MT_DEVICE by default, and that sub-architecture code can
override. We have chosen to expose a single variable rather than
offering the possibility of overriding the entire pci_ioremap_io(),
because implementing pci_ioremap_io() requires calling functions
(get_mem_type()) that are private to the arch/arm/mm/ code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When configure kprobe events of ftrace with "stacktrace" option enabled
in arm, there is no stacktrace was recorded after the kprobe event was
triggered. The root cause is no save_stack_trace_regs() function implemented.
Implement the save_stack_trace_regs() function in arm, then ftrace will
call this architecture-related function to record the stacktrace into
ring buffer.
After this fix, stacktrace can be recorded, for example:
# mount -t debugfs nodev /sys/kernel/debug
# echo "p:netrx net_rx_action" >> /sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobes/netrx/enable
# echo 1 > /sys/kernel/debug/tracing/options/stacktrace
# echo 1 > /sys/kernel/debug/tracing/tracing_on
# ping 127.0.0.1 -c 1
# echo 0 > /sys/kernel/debug/tracing/tracing_on
# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 12/12 #P:1
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
<------ missing some entries ---------------->
ping-1200 [000] dNs1 667.603250: netrx: (net_rx_action+0x0/0x1f8)
ping-1200 [000] dNs1 667.604738: <stack trace>
=> net_rx_action
=> do_softirq
=> local_bh_enable
=> ip_finish_output
=> ip_output
=> ip_local_out
=> ip_send_skb
=> ip_push_pending_frames
=> raw_sendmsg
=> inet_sendmsg
=> sock_sendmsg
=> SyS_sendto
=> ret_fast_syscall
Signed-off-by: Lin Yongting <linyongting@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Support for ARM710 CPUs was removed in v3.5. Now remove the last code
depending on its Kconfig macro.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We will reach fixup handler when one thread(say cpu0) caused an undefined exception, while another thread(say cpu1) is unmmaping the page.
Fixup handler returns to the next userspace instruction which has caused the undef execption, rather than going to the same instruction.
ARM ARM says that after undefined exception, the PC will be pointing
to the next instruction. ie +4 offset in case of ARM and +2 in case of Thumb
And there is no correction offset passed to vector_stub in case of
undef exception.
File: arch/arm/kernel/entry-armv.S +1085
vector_stub und, UND_MODE
During an undefined exception, in normal scenario(ie when ldrt
instruction does not cause an abort) after resorting the context in
VFP hardware, the PC is modified as show below before jumping to
ret_from_exception which is in r9.
File: arch/arm/vfp/vfphw.S +169
@ The context stored in the VFP hardware is up to date with this thread
vfp_hw_state_valid:
tst r1, #FPEXC_EX
bne process_exception @ might as well handle the pending
@ exception before retrying branch
@ out before setting an FPEXC that
@ stops us reading stuff
VFPFMXR FPEXC, r1 @ Restore FPEXC last
sub r2, r2, #4 @ Retry current instruction - if Thumb
str r2, [sp, #S_PC] @ mode it's two 16-bit instructions,
@ else it's one 32-bit instruction, so
@ always subtract 4 from the following
@ instruction address.
But if ldrt results in an abort, we reach the fixup handler and return
to ret_from_execption without correcting the pc.
This patch modifes the fixup handler to re-execute the same instruction which caused undefined execption.
Signed-off-by: Vinayak Menon <vinayakm.list@gmail.com>
Signed-off-by: Arun KS <getarunks@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
asm-generic offers an atomic-add based rwsem implementation, which
can avoid the need for heavier, spinlock-based synchronisation on the
fast path.
This patch makes use of the optimised implementation for ARM CPUs.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As we have now removed all instances of the L2C-310 having its cache
size "modified" via platform/SoC code, discourage new cases showing
up by printing a warning.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We no longer need or require the .set_debug method; we handle everything
it used to do via the .write_sec method instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
L2X0_AUX_CTRL_MASK is not useful for PL310s. It would be better if
people thought about their value for this rather than cargo-cult
programming.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It is beneficial to have the L2 cache up and running earlier in the
system boot. Not only will this allow for simpler code when we come to
enable some features, but it also means that we get a more accurate
bogomips value for the udelay() loop. Calibrating the loop with the
L2 cache off, and then running with the L2 cache on is not the best
idea.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ux500 can't change the auxiliary control register, so there's no point
passing values to try and modify it to the l2x0 init functions.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ux500 can't write to any of the secure registers on the L2C controllers,
so provide a dummy handler which ignores all writes.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead. We can remove the .init_machine as it becomes
the same as the generic version.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead. This also allows us to eliminate the
.init_machine function as this becomes the same as the generic version.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add better commentry about the L2 cache requirements on these platforms.
Unfortunately, the auxiliary control register is not pre-set to indicate
the correct cache parameters, so we have to manually program these.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead. Along with this change, we can delete l2x0.c
from prima2.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for L2 cache controller (PL310) on AM437x SoC.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Get rid of init call to initialize L2 cache. Instead use the init_early
machine hook. This helps in using the initialization routine across
SoCs without the need of ugly cpu_is_*() checks.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
L2 cache initialization for OMAP4 redundantly sets the cache policy to
Round-Robin. This is not needed since thats the PL310 default anyway.
Removing this reduces the number of platform specific aux control
settings.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Avoid reading directly from the L2 registers in platform code. The L2
code will have already saved the register values itself into the
l2x0_saved_regs structure, so platform code should just move these
values to where they're required.
This is safe because the L2x0 will have been initialised by an early
initcall, whereas the OMAP4 PM code is initialised late.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since we now always enable NS access to the unlock registers, this can
be removed from OMAP4. Remove the NS access bit for the interrupt
registers from OMAP4 as well - nothing in the kernel accesses that yet,
and we can add it in core code when we have the need.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Now that OMAP2 uses the write_sec method, we don't need to enable the L2
cache in OMAP2 specific code; this can be done via the normal mechanisms
in the L2C code. Remove the OMAP2 specific code.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With the write_sec method, we no longer need to override the default
L2C disable method, and we no longer need the L2C set_debug method.
Both of these can be handled via the write_sec method.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead. This also allows us to eliminate the
.init_machine function as it is identical to the generic version.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The cache size should already be present in the L2 cache auxiliary
control register: it is part of the integration process to configure
the hardware IP. Most platforms get this right, yet still many
cargo-cult program, and assume that they always need specifying to
the L2 cache code. Remove them so we can find out which really need
this.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the explicit call to l2x0_of_init(), converting to the generic
infrastructure instead. Since the .init_irq method only calls
irqchip_init(), we can remove that too as the generic code will take
care of that.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
