The individually named clocks are all static to the code
and thus can be compressed into a single array and then
the array can be referenced. This removes the need for
a seperate array of pointers to clocks.
Fix a minor problem of re-initialising the pointers in
s3c6400_set_clksrc() as this is also called by the cpufreq
code. Move these initialisations to the code that does the
registration.
Based on Harald Welte's original clock changes patch.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Remove the four fields from clksrc_clk.clk which are always the same
and init them when the clock is registered. This helps remove the amount
of repeated code.
This is a re-work of Harald Welte's clock changes for the latest kernel.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Move the <plat/clock.h> header to plat-samsung where it can be used by all
the platforms, and readies it for the next round of clock updates where
the clock code will be amalgamated.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Remove some of the __initdata tags which are currently inappropriate for
platform_device and some of the platform data. These can be returned once
support for copying platform devices and data is added.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
This patch fix mini2440 crash on boot due to improper __initdata
qualifier on mini2440_led1_pdata.
Signed-off-by: Uri Yosef <uri.yosef@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
This wires up the mode pins support on the SDK7786. The pins are
standard SH7786 pins, and all are fixed in software. Needed for the
clock framework, PCIe, and so forth.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Presently the secondary CPU entry point is only aimed at 29bit phys mode,
causing it to point to a stray virtual address in 32bit mode. Fix it up
after consulting with our shiny new __in_29bit_mode().
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
flush_cache_all() gets called in to when we do some early ioremapping.
Unfortunately on SDK7786 the interrupt controller itself requires
ioremapping, leading to a bit of a chicken and egg scenario. For now,
don't bother with IPI crosscalls if there aren't any other CPUs online.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This updates the existing boards that specify the register width through
platform data to use the resource flags instead. This eliminates platform
data completely in most cases, and permits further improvement in the
heartbeat driver as well as shrinking the overall private data size.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This permits the resource access size to be handed off through the
resource flags, which saves platforms from having to establish
platform data only to specify the register width.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Move the defintion and lock helper routines for the cpu hotplug driver
lock from pseries to powerpc code to avoid build breaks for platforms
other than pseries that use cpu hotplug.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Acked-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The newly added fixup for buggy dcbX insn's has
a bug that always trigger a kernel TLB walk so a user space
dcbX insn will cause a Kernel Machine Check if it hits DTLB error.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We noticed that recent kernels didn't boot on our 1GHz Canyonlands 460EX
boards anymore. As it seems, patch 8d165db1 [powerpc: Improve
decrementer accuracy] introduced this problem. The routine div_sc()
overflows with shift = 32 resulting in this incorrect setup:
time_init: decrementer frequency = 1000.000012 MHz
time_init: processor frequency = 1000.000012 MHz
clocksource: timebase mult[400000] shift[22] registered
clockevent: decrementer mult[33] shift[32] cpu[0]
This patch now introduces a local div_dc64() version of this function
so that this overflow doesn't happen anymore.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Detlev Zundel <dzu@denx.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
get_viotape_info() declares a vio_waitevent on the stack, which
contains a completion, but never initialises the completion.
I have no idea how this ever worked, and on recent kernels it causes
an oops in handle_tape_event() when we access the non-initialised
completion.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Make sure compiler won't do weird things with limits. E.g. fetching
them twice may return 2 different values after writable limits are
implemented.
I.e. either use rlimit helpers added in
3e10e716ab
or ACCESS_ONCE if not applicable.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
pcibus_to_node can return -1 if we cannot determine which node a pci bus
is on. If passed -1, cpumask_of_node will negatively index the lookup array
and pull in random data:
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
00000000,00000003,00000000,00000000
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
64-65
Change cpumask_of_node to check for -1 and return cpu_all_mask in this
case:
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
ffffffff,ffffffff,ffffffff,ffffffff
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
0-127
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit 57b150cce8 (irq: only update affinity if
->set_affinity() is sucessfull) broke xics irq affinity.
We need to use the cpumask passed in, instead of accessing ->affinity directly.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
It seems there is a thinko in the TLB invalidation code that makes the
tlbie in the loop executed just once. The intended check was probably
'gt', not 'lt'.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Various kernel asm modifies SRR0/SRR1 just before executing
a rfi. If such code crosses a page boundary you risk a TLB miss
which will clobber SRR0/SRR1. Avoid this by always pinning
kernel instruction TLB space.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Since the fixed voltage regulator grew support for GPIO based
enables and GPIO 0 is valid on some systems we need to specify
that there is no valid GPIO enable control.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
This patch adds support for the lis3lv02d motion sensor connected via
i2c on the Ecovec board. Tested with evtest.
Signed-off-by: NISHIMOTO Hiroki <nishimoto.hiroki@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The last commit introduced the following breakage
arch/sh/include/asm/mmu.h: In function 'pmb_remap':
arch/sh/include/asm/mmu.h:79: error: expected ';' before '}' token
and...
arch/sh/include/asm/mmu.h:78: error: 'EINVAL' undeclared (first use in this function)
arch/sh/include/asm/mmu.h:78: error: (Each undeclared identifier is reported only once
arch/sh/include/asm/mmu.h:78: error: for each function it appears in.)
arch/sh/include/asm/mmu.h: In function 'pmb_init':
arch/sh/include/asm/mmu.h:87: error: 'ENODEV' undeclared (first use in this function)
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This stubs in some preliminary board support for the RTE SDK7786.
This is quite stunted at the moment, and primarily builds on top of the
system FPGA. FPGA IRQs are handled via CPU IRL masking for simplicity,
with initial peripheral support restricted to the debug ethernet.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
It doesn't account for phys_base like it should, fix by using
page_to_pfn().
While we're here, make virt_to_page() use pfn_to_page() as well, so we
consistently use the asm/memory-model.h abstractions instead of
open-coding memory model assumptions.
Tested-by: Kristoffer Glembo <kristoffer@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This one is much faster than the spinlock based fallback rwsem code,
with certain artifical benchmarks having shown 300%+ improvement on
threaded page faults etc.
Again, note the 32767-thread limit here. So this really does need that
whole "make rwsem_count_t be 64-bit and fix the BIAS values to match"
extension on top of it, but that is conceptually a totally independent
issue.
NOT TESTED! The original patch that this all was based on were tested by
KAMEZAWA Hiroyuki, but maybe I screwed up something when I created the
cleaned-up series, so caveat emptor..
Also note that it _may_ be a good idea to mark some more registers
clobbered on x86-64 in the inline asms instead of saving/restoring them.
They are inline functions, but they are only used in places where there
are not a lot of live registers _anyway_, so doing for example the
clobbers of %r8-%r11 in the asm wouldn't make the fast-path code any
worse, and would make the slow-path code smaller.
(Not that the slow-path really matters to that degree. Saving a few
unnecessary registers is the _least_ of our problems when we hit the slow
path. The instruction/cycle counting really only matters in the fast
path).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <alpine.LFD.2.00.1001121810410.17145@localhost.localdomain>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The fast version of the rwsems (the code that uses xadd) has
traditionally only worked on x86-32, and as a result it mixes different
kinds of types wildly - they just all happen to be 32-bit. We have
"long", we have "__s32", and we have "int".
To make it work on x86-64, the types suddenly matter a lot more. It can
be either a 32-bit or 64-bit signed type, and both work (with the caveat
that a 32-bit counter will only have 15 bits of effective write
counters, so it's limited to 32767 users). But whatever type you
choose, it needs to be used consistently.
This makes a new 'rwsem_counter_t', that is a 32-bit signed type. For a
64-bit type, you'd need to also update the BIAS values.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <alpine.LFD.2.00.1001121755220.17145@localhost.localdomain>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Since the structure field nr_map is optional, we need to check whether the
chip number map is provided to avoid unexpected NULL pointer exception.
Signed-off-by: Ramax Lo <ramaxlo@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Commit ac4c2a3bbe broke the build
of all powerpc boot wrappers.
It attempts to add an include of autoconf.h but used the wrong
path for it. It also adds -D__KERNEL__ to our boot wrapper, both
things that we pretty much didn't do on purpose so far.
We want our boot wrapper to remain independent enough of the kernel
for various reasons, one of them being that you can "wrap" an existing
kernel at distro install time which allows to ship one kernel image
and a set of boot wrappers for different platforms, the wrappers
don't have to be built out of the same kernel build tree.
It's also incorrect to do what the patch does in our boot environment
since we may not have a proper alignment exception handler which means
we may not be able to fixup the few cases where an unaligned access will
need SW emulation (depends on the core variant, could be when crossing
page or segment boundaries for example).
This patch fixes it by putting the old code back in and using the
new "fancy" variant only when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
is set, which happens not to be set on powerpc since we don't include
autoconf.h. It also reverts the changes to our boot wrapper Makefile.
This means that x86 should, afaik, keep the optimisations since its
boot wrapper does include autoconf.h and define __KERNEL__ (though I
doubt they make that much different outside of slow embedded processors).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sys_recvmmsg is reachable via sys_socketcall. So unwire it again since
there is no point in having two entry points for it.
Also put it to the ignore list so we don't get reminded anymore in order
to wire it up.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This one will trap, generates shorter code and emits better debug data
than the generic version.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Finally move it to the place where it belongs to and make get rid of
it for !CONFIG_SMP.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
smp_processor_id() is supposed to work before setup_arch() gets called.
Before that smp_processor_id() may return just an arbitrary value that
is contained in the uninitialized boot lowcore.
So provide the arch function which will override the weak function in
init/main.c.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The TIF_USEDFPU bit is always 0 for s390 and it is not tested anywhere.
Remove the bit. At the same time remove the calls to clear_used_math()
as well. The PF_USED_MATH bit is never set for s390 either.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The code in do_signal sets the TIF_SINGLE_STEP bit and calls
tracehook_signal_handler after the signal frame has been set up.
This causes two SIGTRAP signals to be delivered to the tracer.
Stop setting the TIF_SINGLE_STEP bit in do_signal to get the
correct number of SIGTRAPs.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Clear the TIF_SINGLE_STEP bit in copy_thread. The new process did not get
a PER event of its own. It is wrong deliver a SIGTRAP that was meant for
the parent process.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
If the current task enables / disables PER tracing for itself the
PER control registers need to be loaded in FixPerRegisters.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>