The regulator support in the l4f00242t03 is very non-idiomatic.  Rather
than requesting the regulators based on the device name and the supply
names used by the device the driver requires boards to pass system
specific supply names around through platform data.  The driver also
conditionally requests the regulators based on this platform data, adding
unneeded conditional code to the driver.

Fix this by removing the platform data and converting to the standard
idiom, also updating all in tree users of the driver.  As no datasheet
appears to be available for the LCD I'm guessing the names for the
supplies based on the existing users and I've no ability to do anything
more than compile test.

The use of regulator_set_voltage() in the driver is also problematic,
since fixed voltages are required the expectation would be that the
voltages would be fixed in the constraints set by the machines rather than
manually configured by the driver, but is less problematic.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is generally a better idea to make intentionally empty files
contain the human-readable /* empty */ comment, also it makes
the files play nice with "make distclean".
Reported-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

A missing mach/gpio.h prevents building gpiolib on versatile express.

  CC      drivers/gpio/gpiolib.o
In file included from /.../linux/include/linux/gpio.h:18:0,
                 from /.../linux/drivers/gpio/gpiolib.c:10:
/.../linux/arch/arm/include/asm/gpio.h:5:23: fatal error: mach/gpio.h: No such file or directory
compilation terminated.
make[3]: *** [drivers/gpio/gpiolib.o] Error 1
make[2]: *** [drivers/gpio] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Most of the OMAP1 implementation flags are set statically, with the
exception that omap7xx has its data bus wired up differently.

Cc: patches@linaro.org
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This is how the driver can find the flags for its implementation
functionality in its platform_data

Cc: patches@linaro.org
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Mark each OMAP I2C bus with the hwmod's knowledge of which I2C
IP version is in the chip we're running on.

Cc: patches@linaro.org
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>

All OMAP1 are using "IP revision 1" in terms of register
layout.  We set this information in omap1_i2c_add_bus() so
we don't have to use cpu_is_xxx() any more in the omap i2c
driver.

Cc: patches@linaro.org
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NKevin Hilman <khilman@ti.com>

When device data indicates that multiple block reads are not supported
on a given HSMMC controller instance, log a message to the console, and
pass the appropriate MMC capability flag to the MMC core.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

On some targets, MCI_IRQ_MASK1 is not routed to the MSM in which
case only "cmd_irq" must be used even for PIO. With this change,
all the targets will use only "cmd_irq" for both CMD and PIO.
Signed-off-by: NSahitya Tummala <stummala@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This allows boards with non-standard sdio cards to fill the CIS/CCCR data.
It is particularly important for old msm72k boards using wl1251.
Also drop the obsolete embedded_sdio_data structure from the header
as it was intended to surve a similiar purpose but was not implemented.
Signed-off-by: NAlexander Tarasikov <alexander.tarasikov@gmail.com>
Acked-by: NSahitya Tummala <stummala@codeaurora.org>
[davidb: minor formatting cleanup]
Signed-off-by: NDavid Brown <davidb@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This allows specific (non-multiplexed) IRQ handlers to be used.

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Paul Mundt <lethal@linux-sh.org>
Acked-by: NMagnus Damm <magnus.damm@gmail.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NChris Ball <cjb@laptop.org>

Homogenize namespace to atmci.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix below build warning and properly set bt_reset pin.

  CC      arch/arm/mach-pxa/cm-x300.o
arch/arm/mach-pxa/cm-x300.c: In function 'cm_x300_init_wi2wi':
arch/arm/mach-pxa/cm-x300.c:779: warning: unused variable 'wlan_en'
arch/arm/mach-pxa/cm-x300.c:795: warning: 'bt_reset' may be used uninitialized in this function
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: <stable@kernel.org>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

GuruPlugD was initially named to be SHEEVAD, and it's causing naming
confusion in the mach-types database. Make it consistent by renaming
to GPLUGD.
Reported-and-Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NTanmay Upadhyay <tanmay.upadhyay@einfochips.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Noticed when setting SSP0 in clk_set_rate, _CLK_SET_RATE attempts to
reset the clock divider for the SSP0 parent clock, in this case
IO0FRAC. Bits 24-29 of HW_CLKCTRL_FRAC0 are cleared correctly, but
when the new frac value is written the value isn't shifted up to write
the correct bit-field.  This results in IO0FRAC being set to 0 and
CPUFRAC being corrupted.

This should occur when writing IO1FRAC, EMIFRAC in HW_CLKCTRL_FRAC0
and GPMIFRAC, HSADCFRAC in HW_CLKCTRL_FRAC1.

Tested on custom i.MX28 board with SSP0 SPI driver.
Signed-off-by: NMatt Burtch <matt@grid-net.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

To configure pads during the initialisation a set of special constants
is used, e.g.
#define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP)

The problem is that no pull-up/down is getting activated unless both
PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module
enable) set. This is clearly stated in the i.MX25 datasheet and is
confirmed by the measurements on hardware. This leads to some rather
hard to understand bugs such as misdetecting an absent ethernet PHY (a
real bug i had), unstable data transfer etc. This might affect mx25,
mx35, mx50, mx51 and mx53 SoCs.

It's reasonable to expect that if the pullup value is specified, the
intention was to have it actually active, so we implicitly add the
needed bits.

Cc: stable@kernel.org
Signed-off-by: NPaul Fertser <fercerpav@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

If TEXT_OFFSET is too large (e.g. like on MSM) the resulting immediate
argument gets wider than 8 bits.

Noticed by David Brown <davidb@codeaurora.org>
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

now we move l2x0 resume to Linux from bootloader since l2x0 already has
resume support in core.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>

Cc: Rob Herring <robherring2@gmail.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>

The problem is related to the early enabling of interrupts and the
per cpu timer setup before the cpu is marked online. This doesn't
need to be done in order to call calibrate_delay().

calibrate_delay() monitors jiffies, which are updated from the CPU
which is waiting for the new CPU to set the online bit.

So simply calibrate_delay() can be called on the new CPU just from
the interrupt disabled region and move the local timer setup after
stored the cpu data and before enabling interrupts.

This solves both the cpu_online vs. cpu_active problem and the
affinity setting of the per cpu timers.
Signed-off-by: NThomas Gleinxer <tglx@linutronix.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch remove the hardcoded link between local timers and PPIs,
and convert the PPI users (TWD, MCT and MSM timers) to the new
*_percpu_irq interface. Also some collateral cleanup
(local_timer_ack() is gone, and the interrupt handler is strictly
private to each driver).

PPIs are now useable for more than just the local timers.

Additional testing by David Brown (msm8250 and msm8660) and
Shawn Guo (imx6q).

Cc: David Brown <davidb@codeaurora.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

PPI handling is a bit of an odd beast. It uses its own low level
handling code and is hardwired to the local timers (hence lacking
a registration interface).

Instead, switch the low handling to the normal SPI handling code.
PPIs are handled by the handle_percpu_devid_irq flow.

This also allows the removal of some duplicated code.

Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

This allows mapping external memory such as SRAM for use.

This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If two requests have been submitted and one of them is running, if you
call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time
between the spin_lock_irqsave() and the _state() check in which the
running transaction may finish.  In that case, we don't receive the
interrupt (because they are disabled), but _start() sees that the DMA
is stopped, so it starts it.  The problem is that it sends the
transaction that has just finished again, because pl330_update()
hasn't mark it as done yet.

This patch fixes this race condition by not calling _start() if the
DMA is already executing transactions.  When interrupts are reenabled,
pl330_update() will call _start().

Reference: <1317892206-3600-1-git-send-email-javi.merino@arm.com>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Acked-by: NJassi Brar <jassi.brar@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This change adds support for the sh7372 A4R power domain.

The sh7372 A4R hardware power domain contains the
SH CPU Core and a set of I/O devices including
multimedia accelerators and I2C controllers.

One special case about A4R is the INTCS interrupt
controller that needs to be saved and restored to
keep working as expected. Also the LCDC hardware
blocks are in a different hardware power domain
but have their IRQs routed only through INTCS. So
as long as LCDCs are active we cannot power down
INTCS because that would risk losing interrupts.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This change adds support for the sh7372 A3SP power domain.

The sh7372 A3SP hardware power domain contains a
wide range of I/O devices. The list of I/O devices
include SCIF serial ports, DMA Engine hardware,
SD and MMC controller hardware, USB controllers
and I2C master controllers.

This patch adds the A3SP low level code which
powers the hardware power domain on and off. It
also ties in platform devices to the pm domain
support code.

It is worth noting that the serial console is
hooked up to SCIFA0 on most sh7372 boards, and
the SCIFA0 port is included in the A3SP hardware
power domain. For this reason we cannot output
debug messages from the low level power control
code in the case of A3SP.

QoS support is needed in drivers before we can
enable the A3SP power control on the fly.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

v2:
- register_syscore_ops(&s3c24xx_irq_syscore_ops) does not need to be
  conditionally compiled out, it is already optimized out on !CONFIG_PM
- fix also s3c2412 and s3c2416 affected by the same build issue

v1:
s3c2440.c fails to build if !CONFIG_PM because in such case
s3c2410_pm_syscore_ops is not defined. Same error should happen also
in s3c2410.c and s3c2442.c
Signed-off-by: NDomenico Andreoli <cavokz@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Offsets of the irq controller registers were calculated
correctly only for first GPIO bank. This patch fixes
calculation of the register offsets for all GPIO banks.
Reported-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Rather than clipping the number of CPUs using the compile-time NR_CPUS
constant, use the runtime nr_cpu_ids value instead.  This allows the
nr_cpus command line option to work as expected.

Cc: <stable@kernel.org>
Reported-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Upon adding new board LL debug support, if the resultant code
addition would not cause PC relative offset of "hexbuf" from
"adr r2, hexbuf" (+2) instruction to be representable in a
shifted 8-bit value (hence indirectly putting higher aligment
requirement on larger offsets), following error occurs,

arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:138: Error: invalid constant (428) after fixup

Fix it by bringing "hexbuf" closer so that "adr"
can have the offset.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We don't have cpu_is_omapxxxx SoC detection initialized until
SoC detection is initialized from init_early.

Note that with the common map_io we should no longer need
cpu_is_omapxxxx for ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This allows us to remove omap hacks for map_io.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.

If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.

Note that further removal of the code can now be done,
but that can be done seprately by the driver maintainers.
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This allows removing omap hacks for map_io allowing generic
map_io.

Note that in the future we can't do cpu_is_omapxxxx detection
until in init_early. This means that board-innovator.c now
assumes 15xx only, and board-generic.c assumes 16xx only.
This is best fixed later on by passing the SoC type from
device tree.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Change bd5f12a2 (ARM: 7042/3: mach-ep93xx: break out GPIO driver specifics)
accidentally removed the ep93xx <mach/gpio.h> instead of making it an empty
file. This causes compilation to fail:

In file included from include/linux/gpio.h:18:0,
                  from drivers/gpio/gpiolib.c:10:
linux/arch/arm/include/asm/gpio.h:5:23: fatal error: mach/gpio.h: No such file or directory
compilation terminated.
make[2]: *** [drivers/gpio/gpiolib.o] Error 1

Fix this by adding the file back.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The pm-imx27.c references a number of things requiring the explicit
inclusion of mach/hardware.h.  Otherwise, when indirect inclusion
to mach/hardware.h gets cleaned up, we will see the following
compile error.

  CC      arch/arm/mach-imx/pm-imx27.o
arch/arm/mach-imx/pm-imx27.c: In function ‘mx27_suspend_enter’:
arch/arm/mach-imx/pm-imx27.c:22:3: error: implicit declaration of function ‘IOMEM’
arch/arm/mach-imx/pm-imx27.c:22:3: error: implicit declaration of function ‘IMX_IO_P2V’
arch/arm/mach-imx/pm-imx27.c: In function ‘mx27_pm_init’:
arch/arm/mach-imx/pm-imx27.c:42:2: error: implicit declaration of function ‘cpu_is_mx27’
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>