Milo is an old boot loader, which is no longer relevant for these
platforms.  References to it are misleading.  Move the code out
of poke_milo(), and remove references to milo in comments.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We don't need this small function as well as scu_get_core_count()
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

scu_get_core_count() never returns zero cores, so we don't need to
check and correct if ncores is zero.

Tegra was missing the check against NR_CPUS, leading to a potential
bitfield overflow if this becomes the case.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Ensure that the number of CPUs is sanity checked before setting
the number of possible CPUs.  This avoids any chance of overflowing
the cpu_possible bitmap.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Wait for CPUs to indicate that they've stopped, after sending the
stop IPI, rather than blindly continuing on and hoping that they've
stopped in time.  Print a warning if we fail to stop the other CPUs.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use r0,r3-r6 rather than r0,r3,r4,r6,r7, which makes it easier to
understand which registers can be modified.  Also document which
registers hold values which must be preserved.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The IPI and local timer interrupts weren't being properly accounted
for in /proc/stat.  Collect them from the irq_stat structure, and
return their sum.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This separates out the individual IPI interrupt counts from the
total IPI count, which allows better visibility of what IPIs are
being used for.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As per x86, align the initial column according to how many IRQs we
have.  Also, provide an english explaination for the 'LOC:' and
'IPI:' lines.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move the ipi_count into irq_stat, which allows the ipi_data structure
to be entirely removed.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Provide __inc_irq_stat() and __get_irq_stat() to increment and
read the irq stat counters.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

send_ipi_message() does nothing except call smp_cross_call().  As
this is a static function, nothing external to this file calls it,
so we can easily clean up this now unnecessary indirection.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As we've now removed the spinlock and bitmask, we have nothing left
which requires interrupts to be disabled when sending an IPI.  All
current IPI-sending implementations use the GIC, which also does not
require interrupts disabled when calling gic_raise_softirq().

Remove the now unnecessary IRQ disable.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Avoid using bitmasks and locks in the percpu area for IPIs, and instead
use individual software generated interrupts to identify the reason for
the IPI.  This avoids the problems of having spinlocks in the percpu
area.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows us to use smp_cross_call() to trigger a number of different
software generated interrupts, rather than combining them all on one
SGI.  Recover the SGI number via do_IPI.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

smp_cross_call_done() was removed long ago (see 78d236c2 - remove useless
smp_cross_call_done()).  Remove those which have been subsequently
merged.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

for the epson frambuffer support it's CONFIG_FB_S1D13XXX
not CONFIG_FB_S1D135XX
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

as based on http://www.picotux.com/pt200/picotux200.pdf
these board does not have such I/O
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

to be a few more concistant with the other boards

as ek is for evaluation kit and dk for development kit
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Convert the following AT91RM9200-based boards to the new-style UART
initialization:
  - Ajeco 1ARM Single Board Computer
  - Sperry-Sun KAFA board
  - picotux 200

Remove the deprecated at91_init_serial
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

About all options present in each file are activated
in the single file.
Signed-off-by: NEric Benard <eric@eukrea.com>
Tested-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

This patch fixes following warning messages when CONFIG_PM selected.

In file included from arch/arm/mach-s5pv210/mach-smdkv210.c:34:
arch/arm/plat-samsung/include/plat/pm.h:104: warning: 'struct sys_device'
declared inside parameter list
arch/arm/plat-samsung/include/plat/pm.h:104: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/plat-samsung/include/plat/pm.h:105: warning: 'struct sys_device'
declared inside parameter list

In file included from arch/arm/mach-s5pv210/mach-smdkc110.c:31:
arch/arm/plat-samsung/include/plat/pm.h:104: warning: 'struct sys_device'
declared inside parameter list
arch/arm/plat-samsung/include/plat/pm.h:104: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/plat-samsung/include/plat/pm.h:105: warning: 'struct sys_device'
declared inside parameter list
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NSangbeom Kim <sbkim73@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The UART3 submask should be 0x7 (SUBSRCPND[26:24]).
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NSangbeom Kim <sbkim73@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

IRQ_S3C2443_UART3 is being used as the base when it should actually
be IRQ_S3C2443_RX3 on S3C2443 and S3C2416 for the UART3.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NSangbeom Kim <sbkim73@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Don't rewrite clock config in UCON preconfigured by
bootloader. No need to set 10th bit in UCON because
[11:10] 2'b00 means source clock is PCLK too.
If set, console does not work if bootloader
has preconfigured [11:10] with 2'b00.
If not set, console works with any bootloader
config value (2'bxx).
More information about clock setup in UCON is available
in "S3C6410X RISC Microprocessor User's Manual,
Revision 1.20" p. 31-13 (Chapter 31.6.2
UART CONTROL REGISTER).
Signed-off-by: NDarius Augulis <augulis.darius@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch fixes wrong s3c_gpio_cfgpull with s3c_gpio_setpull.

Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Replace in s3c_gpio_cfgpull with s3c_gpio_setpull.
Signed-off-by: NVasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The console semaphore must be held while the OMAP UART devices are
disabled, lest a console write cause an ARM abort (and a kernel crash)
when the underlying console device is inaccessible.  These crashes
only occur when the console is on one of the OMAP internal serial
ports.

While this problem has been latent in the PM idle loop for some time,
the crash was not triggerable with an unmodified kernel until commit
6f251e9d ("OMAP: UART: omap_device
conversions, remove implicit 8520 assumptions").  After this patch, a
console write often occurs after the console UART has been disabled in
the idle loop, crashing the system.  Several users have encountered
this bug:

    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html

    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html

The same commit also introduced new code that disabled the UARTs
during init, in omap_serial_init_port().  The kernel will also crash
in this code when earlyconsole and extra debugging is enabled:

    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html

The minimal fix for the -rc series is to hold the console semaphore
while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
since the console may not be located on an OMAP UART, as is the case
with the GPMC UART on Zoom3.  While it is technically possible to
determine which devices the console or earlyconsole is actually
running on, it is not a trivial problem to solve, and the code to do
so is not really appropriate for the -rc series.

The right long-term fix is to ensure that no code outside of the OMAP
serial driver can disable an OMAP UART.  As I understand it, code to
implement this is under development by TI.

This patch is a collaboration between Paul Walmsley <paul@pwsan.com>
and Tony Lindgren <tony@atomide.com>.  Thanks to Ming Lei
<tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their
feedback on earlier versions of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Pramod <pramod.gurav@ti.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Govindraj.R <govindraj.raja@ti.com>

Add additional check to omap_uart_resume_idle() so that only
enabled (specifically, idle-enabled) UARTs are allowed to resume.
This matches the existing check in prepare idle.

Without this patch, the system will hang if a board is
configured to register only some uarts instead of all of
them and PM is enabled.

Cc: Govindraj R. <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
[tony@atomide.com: updated description]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The find_next_bit, find_first_bit, find_next_zero_bit
and find_first_zero_bit functions were not properly
clamping to the maxbit argument at the bit level. They
were instead only checking maxbit at the byte level.
To fix this, add a compare and a conditional move
instruction to the end of the common bit-within-the-
byte code used by all the functions and be sure not to
clobber the maxbit argument before it is used.

Cc: <stable@kernel.org>
Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NJames Jones <jajones@nvidia.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The PLLC2 clock was utilizing the same sort of enable/disable without
regard to usecount approach that the FSIDIV clock was when being used as
a PLL pass-through. This forces the enable/disable through the clock
framework, which now prevents the clock from being ripped out or modified
underneath users that have an existing handle on it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current AP4 FSI didn't use set_rate for ak4642,
and used dummy rate when init.
And FSI driver was modified to always call set_rate.

The user which are using FSI set_rate is only AP4 now.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current AP4 FSI set_rate function used bogus clock process
which didn't care enable/disable and clk->usecound.
To solve this issue, this patch also modify FSI driver to call
set_rate with enough options.
This patch modify it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current FSIDIV clock framework had bogus disable.
This patch remove it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

init_mm used at kernel/sched.c:idle_task_exit() has spin_lock
(init_mm.context.id_lock) that is not initialized when spin_lock/unlock
is called at an ARM machine. Note that mm_struct.context.id_lock is
usually initialized except for the instance of init_mm at
linux/arch/arm/mm/context.c

Not initializing this spinlock incurs "BUG: pinlock bad magic"
warning when spinlock debug is enabled. We have observed such
instances when testing PM in S5PC210 machines.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>