Looks like some boards are calling gpio_request from init_irq.
This will make the request_irq fail, as GPIO will be initialized
as postcore_initcall.
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This should be only selected in CONFIG_ARCH_OMAP2PLUS_TYPICAL
to make it easy to disable.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Using true/false instead of 1/0 to update the free variable.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Function omap_mcbsp_probe allocates struct omap_mcbsp *mcbsp but it is not
freed in omap_mcbsp_remove. Fix this, remove unneeded structure cleanups
and clk_disable calls since they are not needed here.

This is not problem currently but becomes if the mcbsp driver is ever
modularized.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Value of "isr_reg" pointer is depend on configuration and GPIO method.
Potentially it may have NULL value and it is dereferenced later
in code. Warning and exit from function are added in this case.
Signed-off-by: NEvgeny Kuznetsov <EXT-Eugeny.Kuznetsov@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In some cases we can get error function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 4d17aeb1 ("OMAP: I2C: split
device registration and convert OMAP2+ to omap_device") broke I2C on
OMAP1.  The following messages appear at boot:

i2c_omap i2c_omap.1: failure requesting irq 0
i2c_omap: probe of i2c_omap.1 failed with error -22

Investigation revealed that a chunk of code is missing from the
original plat-omap/i2c.c file which configured the IRQ and base address
for the I2C block on OMAP1.  Upon adding this back, the OMAP1 I2C block
seems to initialize correctly.

Thanks to Cory Maccarrone <darkstar6262@gmail.com> for reporting the bug,
and apologies for the breakage.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Tested-by: NCory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
• Operational mode     LCR_REG[7] = 0x0
• Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
• Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0]  = 0xBF

Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Define MDR1 register serial definitions used in serial and
bluetooth drivers.
Change magic number to ones defined in serial_reg for omap1/2
serial driver.
Remove redefined MDR1 register definitions in omap-serial driver.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Craneboard is a hardware development platform based on the
Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a
low cost reference design.

This patch adds basic board file. Detailed support will follow in
subsequent patches.

  [1] http://www.ti.com/arm
  [2] http://www.mistralsolutions.com/products/craneboard.phpSigned-off-by: NSrinath <srinath@mistralsolutions.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patches removes a config option that was used to select a FIQ
handler to be build for Amstrad Delta, as required by the on-board serio
interface driver. Not having any problem reports received since it was
introduced in 2.6.35, the FIQ handler can now be built and initialized by
default, thus reqiring no extra config option.
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

It's easier to understand what that number means and
also avoids problems if we ever have to change it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

They are extremely similar anyway, let's get rid
of one file.

While at that, also remove the empty zoom_config
variable.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The changes are:
  - Use 'for' loop instead 'while' loop.
  - No need to initialize ret to 0, we're assigning it right after.
  - No need to check for onenandcs < GPMC_CS_NUM here, it will always be true.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

omap_board_config_size is implicitly initialized to 0 in
plat-omap/common.c, get_config() won't dereference omap_board_config,
so we can remove the empty igep2_config array.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.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>

Delete a redundant local variable.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use IOMEM() macro to get rid of the following sparse warning:

arch/arm/mach-omap1/board-ams-delta.c:319:36: warning: incorrect type in initializer (different address spaces)
arch/arm/mach-omap1/board-ams-delta.c:319:36:    expected void [noderef] <asn:2>*membase
arch/arm/mach-omap1/board-ams-delta.c:319:36:    got void *<noident>
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Delete unused variable from probe().
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Make some variables static to get rid of the following warnings:

arch/arm/mach-omap1/mailbox.c:136:18: warning: symbol 'mbox_dsp_info' was not declared. Should it be static?
arch/arm/mach-omap1/mailbox.c:142:18: warning: symbol 'omap1_mboxes' was not declared. Should it be static?
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Make some functions static to get rid of the following sparse warnings:

arch/arm/mach-omap1/mcbsp.c:177:12: warning: symbol 'omap1_mcbsp_init' was not declared. Should it be static?
arch/arm/mach-omap1/mux.c:346:22: warning: symbol 'omap1_cfg_reg' was not declared. Should it be static?
arch/arm/plat-omap/dma.c:177:5: warning: symbol 'omap_dma_in_1510_mode' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:273:12: warning: symbol 'omap1_sram_init' was not declared. Should it be static?
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add missing includes to get rid of the following sparse warnings:

arch/arm/mach-omap1/devices.c:225:13: warning: symbol 'omap1_camera_init' was not declared. Should it be static?
arch/arm/mach-omap1/flash.c:15:6: warning: symbol 'omap1_set_vpp' was not declared. Should it be static?
arch/arm/mach-omap1/serial.c:190:6: warning: symbol 'omap_serial_wake_trigger' was not declared. Should it be static?
arch/arm/mach-omap1/time.c:252:18: warning: symbol 'omap_timer' was not declared. Should it be static?
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.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>

Adding KERN_WARNING in the middle of strings now produces those tokens
in the output, rather than accepting the level as was once the case.
Fix this in the one reported case.  There might be more...
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We now:
 * check for a v3 controller before setting 8-bit bus width
 * offer a callback for platform code to switch to 8-bit mode, which
   allows non-v3 controllers to support it
 * rely on mmc->caps |= MMC_CAP_8_BIT_DATA; in platform code to specify
   that the board designers have indeed brought out all the pins for
   8-bit to the slot.

We were previously relying only on whether the *controller* supported
8-bit, which doesn't tell us anything about the pin configuration in
the board design.

This fixes the MMC card regression reported by Maxim Levitsky here:
   http://thread.gmane.org/gmane.linux.kernel.mmc/4336
by no longer assuming that 8-bit works by default.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Tested-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The .stack section doesn't contain any contents, and doesn't require
initialization either.  Rather than marking the output section with
'NOLOAD' but still having it exist in the object files, mark it with
%nobits which avoids the assembler marking the section with 'CONTENTS'.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>