Merge fixes tmp-merge testing-misc testing-board cbus

ARM:OMAP4 add Phytec phyCORE-OMAP4 board

This adds support for the Phytec OMAP4430 board called phyCORE-OMAP4 PCM049.

Signed-off-by: Jan Weitzel <j.weitzel@phytec.de>
[tony@atomide.com: updated for timer and twl cleanup, and to select the board by default]
Signed-off-by: Tony Lindgren <tony@atomide.com>

Initial B&N Nook Color (encore) support

Bare-bones board file, comes with serial console, gpio keys,
MMC/SDCard and USB (peripheral) support.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
[tony@atomide.com: updated for irq and timer cleanup and to select the board by default]
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-dt-for-v3.5' into tmp-merge

Minor DT updates based on the dt-missed-3.4 branch

Conflicts:
arch/arm/mach-omap2/board-generic.c

Merge tag 'omap-devel-soc-for-v3.5' into tmp-merge

Yet more clean up for making adding support for new SoCs easier.

Note that as these depend on omap-cleanup-for-v3.5 and conflict
with omap-fixes-non-critical-for-v3.5 these are based on a
merge of the two.

arm/dts: omap4-panda: Add LEDs support

Add the debug LEDs nodes for an OMAP4 PandaBoard.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

arm/dts: omap4-sdp: Add LEDs support

Add the debug LEDs nodes for an OMAP4 SDP/Blaze.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

arm/dts: twl4030: Add twl4030-gpio node

Add the twl-gpio node inside twl4030 definition.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-cleanup-timer-for-v3.5' into tmp-merge

Timer changes to make it easier to support various SoCs

Conflicts:
arch/arm/mach-omap1/common.h

Merge tag 'omap-cleanup-devices-for-v3.5' into tmp-merge

Changes to split plat-omap/devices.c into mach-omap1 and mach-omap2
except for the RNG driver that will be done later on.

As this depends on omap-devel-hwmod-data-for-v3.5 and causes merge
conflict with omap-fixes-non-critical-for-v3.5, this branch is based
on merge of the two.

ARM: OMAP1: Pass dma request lines in platform data to MMC driver

Pass dma request lines in platform data to MMC driver.

Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: Move omap_mmc_add() to mach-omap1

Now that omap2420 is using hwmod for MMC, this code is omap1
only used on omap1.

Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-devel-hwmod-data-for-v3.5' into tmp-merge

Data changes related to omap hwmod

Merge tag 'omap-board-for-v3.5' into tmp-merge

Board specific changes for omap.

Note that these are based on omap-pm-regulator-for-v3.5 as
both branches are adding twl regulators.

Merge tag 'omap-devel-prcm-for-v3.5' into tmp-merge

Updates for PRCM (Power, Reset, Clock Management).

Note that this depends on omap-devel-hwmod-for-v3.5.

Merge tag 'omap-cleanup-for-v3.5' into tmp-merge

Clean up to make it easier to add support for new SoCs.

Note that these have a merge dependency to omap-devel-hwmod-for-v3.5
branch for the Makefile changes.

Merge tag 'omap-fixes-non-critical-for-v3.5' into tmp-merge

Omap fixes that were considered too intrusive or not critical for the -rc cycle

ARM: OMAP2: Use hwmod to initialize mmc for 2420

This allows us to pass dma request lines in platform data to
MMC driver the same way as we already do for omap2430 and later.

Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: Move omap_dsp_reserve_sdram_memblock() to mach-omap2

This hardware exists only on 2430 and later omaps, so there's no
need to have it in plat-omap/devices.c.

Note that we don't have any users for exported omap_dsp_get_mempool_base(),
so we can make it static.

Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: Move omap_init_uwire to mach-omap1

This hardware exists on omap1 only and there's no need to keep it
in plat-omap/devices.c. No functional changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: Move omap_init_audio() to keep the devices in alphabetical order

The comments in omap1_init_devices() ask to keep the devices in
alphabetical order. Only omap_init_audio() is not following this,
so let's move it. No functional changes.

Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge branch 'fixes-non-critical' into cleanup-devices

OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies

These supplies going to be needed for the twl6040 driver.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies

These supplies going to be needed for the twl6040 driver.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration

V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the V2V1 as supply_regulator for VCXIO, VDAC.
Add twl6040 (1-004b) as consumer for V1V8, and V2V1.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[tony@atomide.com: updated for the pm regulator changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: Mark Beagleboard-xM MMC bus as 4-bit

On Beagleboard-xM (all revisions) only MMC1_DAT0-MMC1_DAT3 are wired up.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Add MSUB support for the LogicPD OMAP3530 DevKits

Add support for the OMAP3 MUSB OTG controller to the LogicPD
OMAP3530 SOM-LV[1] and Torpedo[2] DevKits

[1] - www.logicpd.com/products/system-on-modules/omap35x-som-lv/
[2] - www.logicpd.com/products/system-on-modules/omap35x-torpedo-som/

Signed-off-by: Ashwin Bihari <ashwin.bihari@logicpd.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: rx51: Platform support for lis3lv02d accelerometer

Platform support for lis3lv02d accelerometer

Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: craneboard: register emac device

This adds the required am35xx_emac_init() call to the craneboard init
function.

Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP4: board-omap4panda: Register platform device for HDMI audio codec

Add platform device registratation for HDMI audio codec. This is to
be able to transmit audio through the HDMI output featured in Pandaboard
and PandaboardES boards.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP4: board-4430sdp: Register platform device for HDMI audio codec

Add platform device registratation for HDMI audio codec. This is to
be able to transmit audio through the HDMI output featured in SDP4430
and Blaze boards.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: devices: Register platform devices for HDMI audio

Add platform registration for the devices HDMI audio support. The
omap-hdmi-audio-dai platform device is to be used by the ASoC HDMI
CPU DAI driver. The omap-hdmi-audio platform device is to be used
by the ASoC HDMI machine driver that links together the ASOC CPU DAI,
ASoC plaform and ASoC codec drivers.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP3: igep0020: Add support for Micron NAND Flash storage memory

IGEP-based boards can have two different flash memories, a OneNAND or
a NAND device. The boot configuration pins (sys_boot) are used to
specify which memory is available.

Also, this patch removes unnecesary code for registering the OneNAND.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
[tony@atomide.com: fixed up a minor checkpatch warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: nand: Make board_onenand_init() visible to board code

board_onenand_init() and board_nand_init() initialization functions are
used to initialize OneNAND and NAND memories respectively. But only
board_nand_init() was visible to be used from board code. This patch makes
possible to initialize a OneNAND flash memory within platform code.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP3: cm-t35: add support for power off

Enable the power off feature of the TPS65930 on-board PMIC.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: WiLink platform data for the PandaBoard

The "uim" deamon requires sysfs entries that are filled in using
this platform data.

Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2PLUS: Enable HIGHMEM

HIGMEM support in kernel is quite mature now and we have boards
like ZOOM, PANDA, SDP where 1 GB memories are installed. With
HIGHMEM disabled not all of the 1GB of RAM (only ~700MB) can be
accessed. Hence, enable HIGMEM to make use of the entire memory.

On the boards which doesn't have more than 768 MB memory, all
the memory is directly mapped in "lowmem" and highmem isn't
exercised. Hence, there should be no impact by enabling HIGHMEM
for boards that do not need it.

Tested on OMAP4460 Panda-ES.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: omap2plus_defconfig: Enable ehci-omap and sms95xx support

Boards like beagle and panda use ehci based smsc95xx lan chips
one has to manually enable these supports to get nfs working
on these boards. So keep these support enable by default.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: am33xx: Make am33xx as a separate class

Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).

So,  after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.

Please refer to the link below, for mailing-list discussion on this -

http://www.spinics.net/lists/linux-omap/msg69439.html

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: Kconfig: convert SOC_OMAPAM33XX to SOC_AM33XX

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX

No functional change.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated for the driver config change also]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: Kconfig: convert SOC_OMAPTI81XX to SOC_TI81XX

No need to have an OMAP prefix on these SoCs that are in the family
but arent' really called OMAP.

Simple rename: CONFIG_SOC_OMAPTI81XX --> CONFIG_SOC_TI81XX

No functional change.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge branch 'cleanup' into devel-soc

ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally

The supply is connected to the DSS DO-D5 pins and is thus needed for
both serial and parallel display interfaces on the igep0030 as well as
the igep0020.

If the igep0030 module isn't connected to a display, no DSI or DPI
display will be specified in board code, and the DSS driver won't enable
to VPLL2 regulator anyway.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: INTC: fix Kconfig option for TI81XX

The INTC core is using a Kconfig option for TI816x which doesn't
exist.  Convert it to use TI81XX.

Cc: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: remove incorrect irq_chip ack field

Each irq_chip for the main interrupt controller has offsets set for irq
masking registers, which added to respective base results in a pointer
to appropriate hardware register. However this is not correct for
INTC_CONTROL as there is only one INTC_CONTROL register. This does not
cause problems because generic ack code is never called, but remove
this assignment to avoid confusion.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP4: Adding ID for OMAP4460 ES1.1

Signed-off-by: Chris Lalancette <clalancette@gmail.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP4: panda: add statics to remove warnings

Add statics to board-omap4-panda.c's internal functions and data
structures to remove sparse warnings:

arch/arm/mach-omap2/board-omap4panda.c:234:29: warning: symbol
'omap_panda_wlan_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:441:24: warning: symbol
'omap4_panda_dvi_device' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:451:12: warning: symbol
'omap4_panda_dvi_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:512:13: warning: symbol
'omap4_panda_display_init' was not declared. Should it be static?

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: Incorrect Register Offsets in OMAP Mailbox

Looks like the register offsets are incorrect in the OMAP mailbox code
(arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The
discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K.

Acked-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Henry Chan <enli.chan@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: fix trivial warnings for dspbridge

arch/arm/plat-omap/devices.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/plat-omap/devices.c:170: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_init':
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t'
arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'phys_addr_t'

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-devel-hwmod-for-v3.5' into tmp-merge

Add most of remaining hwmods for omap4

Merge tag 'omap-pm-regulator-for-v3.5' into tmp-merge

Add support for vdd1 and vdd2 regulators and make voltage code to use them

Merge tag 'omap-cleanup-cpuidle-for-v3.5' into tmp-merge

CPUidle cleanup

Merge tag 'omap-cleanup-hwmod-for-v3.5' into tmp-merge

Clean up of hwmod to shrink down the IP block interconnections

Merge tag 'omap-cleanup-sparse-for-v3.5' into tmp-merge

Sparse and cppcheck warning fixes

ARM: OMAP: Make OMAP clocksource source selection using kernel param

Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -

1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.

The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
So, in order to use option 2, deeper idle state MUST be disabled.

Option 3 will still work but it is no better than 32K sync-timer
based clocksource.

We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.

Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.

And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.

So, the solution is,

Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.

Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: Replace space with underscore in the name field of system timers

Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong override configuration.

The only affected kernel parameter configuration for OMAP family
is "clocksource=", used to override kernel clocksource.

So this patch changes "gp timer" => "gp_timer", for clockevent,
clocksource and timer irq_handler.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: Add checks for possible error condition in timer_init

On OMAP1, omap_32k_timer_init() function always returns "true",
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.

This patch adds check for return value from function
omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init()
in case of failure/error from omap_init_clocksource_32k().

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-devel-c-for-3.5' of git://git./linux/kernel/git/pjw/omap-pending into devel-hwmod-data

Some OMAP IP block data additions for 3.5, along with a
fix for a longstanding watchdog timer integration problem.

GPMC: add ECC control definitions

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: igep0020: fix smsc911x dummy regulator id

id 0 is already used and causes errors at boot:

WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x9c/0xac()
sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.0'

Fix it by using the next available one (id=1).

This was caused by 5b3689f4 (ARM: OMAP2+: smsc911x: Add fixed
board regulators) that did not account for some regulators
already being used.

Signed-off-by: Enrico Butera <ebutera@users.berlios.de>
[tony@atomide.com: updated comments for regression causing commit]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP4: hsmmc: check for null pointer

platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer. while at it move the duplicated functions
to omap4-common.c

Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.

Unable to handle kernel NULL pointer dereference at virtual address 0000008c
pgd = c0004000
[0000008c] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0    Not tainted  (3.4.0-rc1-05971-ga4dfa82 #4)
PC is at omap_4430sdp_init+0x184/0x410
LR is at device_add+0x1a0/0x664

Signed-off-by: Balaji T K <balajitk@ti.com>
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: fix compilation issue in board-sx1.c

SX1 board requirese i2c, so select it in Kconfig, otherwise I have the
following build error:

arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_write_byte':
arch/arm/mach-omap1/board-sx1.c:58:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c:58:7: warning: assignment makes pointer from integer without a cast [enabled by default]
arch/arm/mach-omap1/board-sx1.c:67:2: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c:68:2: error: implicit declaration of function 'i2c_put_adapter' [-Werror=implicit-function-declaration]
arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_read_byte':
arch/arm/mach-omap1/board-sx1.c:82:7: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-omap1/board-sx1.o] Error 1
make: *** [arch/arm/mach-omap1] Error 2
make: *** Waiting for unfinished jobs....

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP4: devices: Do not create mcpdm device if the dtb has been provided

If dtb is provided the needed device will be created dynamically.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP4: devices: Do not create dmic device if the dtb has been provided

If dtb is provided the needed device will be created dynamically.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: WDTIMER integration: fix !PM boot crash, disarm timer after hwmod reset

Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.

Currently, we have a special case for WDT in that its postsetup_state
is always set to disabled.  This is done so that the WDT is disabled
and the timer is disarmed at boot in case there is no WDT driver.
This also means that when runtime PM is disabled, if a WDT driver *is*
built in the kernel, the kernel will crash on the first access to the
WDT hardware.

We can't simply leave the WDT module enabled, because the timer is
armed by default after reset. That means that if there is no WDT
driver initialzed or loaded before the timer expires, the kernel will
reboot.

To fix this, a custom reset method is added to the watchdog class of
omap_hwmod.  This method will *always* disarm the timer after hwmod
reset.  The WDT timer then will only be rearmed when/if the driver is
loaded for the WDT.  With the timer disarmed by default, we no longer
need a special-case for the postsetup_state of WDT during init, so it
is removed.

Any platforms wishing to ensure the watchdog remains armed across the
entire boot boot can simply disable the reset-on-init feature of the
watchdog hwmod using omap_hwmod_no_setup_reset().

Tested on 3530/Overo, 4430/Panda.

NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as
documented in the TRM (and what happens on OMAP3.)  I noticed this
because testing the HWMOD_INIT_NO_RESET feature with no driver loaded,
I expected a reboot part way through the boot, but did not see a
reboot.  Adding some debug to read the counter, I verified that right
after OCP softreset, the counter is not firing.  After writing the
magic start sequence, the timer starts counting.  This means that the
timer disarm sequence added here does not seem to be needed for 4430,
but is technically the correct way to ensure the timer is disarmed, so
it is left in for OMAP4.

Special thanks to Paul Walmsley for helping brainstorm ideas to fix
this problem.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: updated the omap2_wd_timer_reset() function in the
 wake of commit 3c55c1baffa5f719eb2ae9729088bc867f972f53 ("ARM:
 OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset
 wait for reset status""); added kerneldoc; rolled in warning fix from Kevin]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database

Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod_data: Name the common irq for McBSP ports

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and OMAP3.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: I2C: add flag for context restore

Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Wamsley <paul@pwsan.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod_data: Rename the common irq for McBSP ports

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data
will be using the same name.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2xxx: hwmod data: add HDQ/1-wire hwmod

Add the HDQ1W hwmod for all OMAP2xxx devices.

Assume that OMAP2xxx chips have the same HDQ idle handling bug
as OMAP3:

   http://www.spinics.net/lists/linux-omap/msg63576.html

and set the OCPIF_SWSUP_IDLE flag accordingly on the HDQ's OCP interface.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: add HDQ/1-wire hwmod

Add the HDQ1W hwmod for OMAP34xx, OMAP36xx, and AM3505/3517 devices.
According to the respective TRMs, it doesn't appear to be available for the
816x/814x or the AM335x.

The OCPIF_SWSUP_IDLE flag is added to work around an apparent hardware
bug: the hardware is not taking the CM_FCLKEN*_CORE.EN_HDQ bit into
account when considering whether to go idle:

    http://www.spinics.net/lists/linux-omap/msg63576.html

This causes HDQ transfers to fail or become corrupt.  Thanks to
NeilBrown for his help diagnosing and testing fixes for this problem.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NeilBrown <neilb@suse.de>

ARM: OMAP2+: hwmod data: add HDQ/1-wire hwmod shared data

Much of the HDQ1W integration data is common between multiple generations
of OMAP SoCs, so rather than make several copies, we add it once into
files which are compiled for multiple SoCs.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NeilBrown <neilb@suse.de>

ARM: OMAP2+: HDQ1W: add custom reset function

Implement a custom reset function for the HDQ1W IP block.  This is
because the HDQ1W IP block, like I2C, has an internal clock gating bit
that needs to be toggled after setting the SOFTRESET bit to allow the
reset to propagate.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Avinash.H.M <avinashhm@ti.com>
Tested-by: NeilBrown <neilb@suse.de>

ARM: OMAP2420: hwmod data: Add MMC hwmod data for 2420

Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[paul@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup;
 changed mmc hwmod name/class to "msdi" as documented in the 2420 TRM Rev X;
 added sysconfig register information; added 16 bit register width flag;
 added MSDI custom reset code]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore

Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx

Currently cpu_is_omap3517() actually detects any device in the AM35x
family (3517 and no-SGX version 3505.)  To make it more clear what is
being detected, convert the names from 3517 to AM35xx.

This adds a new soc_is_am35xx() which duplicates the cpu_is_omap3517().
In order to avoid cross-tree dependencies with clock-tree changes,
cpu_is_omap3517() is left until the clock changes are merged,
at which point cpu_is_omap3517() will be completely removed.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
[tony@atomide.com: change to use soc_is_omap instead]
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505

There are several checks for AM35x devices done using

      if (cpu_is_omap3517() || cpu_is_omap3505())

However, since the 3505 is just a 3517 without an SGX, the 3505 check
is redundant because cpu_is_omap3517() will always be true whenever
cpu_is_omap3505() is true.  From <plat/cpu.h>:

 #define cpu_is_omap3505() (cpu_is_omap3517() && !omap3_has_sgx())

Therefore, remove the redunant 3505 checks.  This helps move towards
removal of SoC detection that depends on specific IP detection.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Merge tag 'omap-devel-b-for-3.5' of git://git./linux/kernel/git/pjw/omap-pending into devel-prcm

Some OMAP PRCM updates for 3.5.  Includes some clock, clockdomain,
powerdomain, PRM, and CM changes.

Merge branch 'cleanup-soc' into cleanup

Conflicts:
arch/arm/mach-omap2/Makefile

Merge branch 'devel-hwmod' into cleanup

Merge branch 'for_3.5/omap_misc_cleanup' of git://gitorious.org/omap-sw-develoment/linux-omap-dev into cleanup-soc

ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.

The system dma module has capabiities register indicating
the support for descriptor loading, constant fill, etc.
Use this instead of OMAP revision check to identify the features
supported runtime.

This avoids patching the code for feature SOCs which has
those capabilities.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: OMAP4: Reduce the static IO mapping

EMIF, GMPC and DMM driver can ioremap() the address
space as part of driver intialisation and there is
no need to have static IO mapping for them.

Hence remove the un-used static IP space and let
the respective drivers manage it as part if driver
init.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: All OMAP2PLUS machines use omap2 directory so just add one entry

All OMAP2PLUS arch based machines makes use of mach-omap2 directory.
So just add one entry so that there is no need to patch this file
for any OMAP2+ devices.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.

cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code
cpu checks accordingly so that there is no need to patch
the file for any future OMAP2+ devices.

In long run, all these attributes should come from hwmod dev_attr based
on DMA IP version.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: OMAP4: Remove un-used WakeupGen register defines.

Current OMAP code doesn't use any of the OMAP_WKG_ENB_SECURE_*
registers.

So remove those defines.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: OMAP2+: Clean up wrapping multiple objects in Makefile

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds.

Since OMAP4 code base now makes use of OMAP4 specific PRCM functions,
cm2xxx_3xxx.c need not be compiled for OMAP4 only builds.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>

Merge branches 'clock_am35xx_cleanup_3.5', 'prm_cm_devel_a_3.5', 'clock_devel_a_3.5' and 'pwrdm_clkdm_cleanup_3.5' into prcm_devel_a_3.5

arm: omap3: clockdomain data: Remove superfluous commas from gfx_sgx_3xxx_wkdeps[]

Clean up clockdomains3xxx_data.c a bit by removing the superfluous
commas in gfx_sgx_3xxx_wkdeps[].

Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API

With patch 'ARM: OMAP2+: powerdomain: Wait for powerdomain transition
in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes
duplicate of pwrdm_state_switch().

Get rid off duplicate pwrdm_clkdm_state_switch() and update the
users of it with pwrdm_state_switch()

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: clock data: add clockdomain for HDQ functional clock

Add the correct clockdomain for the HDQ functional clock.  This is needed
for the clock and hwmod PM code to work correctly.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>

ARM: OMAP3+: dpll: Configure autoidle mode only if it's supported

The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.

With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: dmtimer: cleanup iclk usage

We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4+: Add prm and cm base init function.

Instead of statically defining seperate arrays for every OMAP4+ archs,
have a generic init function to populate the arrays. This avoids the
need for creating new array for every arch added in the future that
reuses the prm and cm registers read/write code.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header

Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: Fix CM register bit masks

The register bits for MPU_CLK_SRC and IVA2_CLK_SRC in CM_CLKSEL1_PLL
register are 3 bits wide.  Fix the MASK definition accordingly.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP: clock: convert AM3517/3505 detection/flags to AM35xx

To improve the clarity of the code, replace the CK_3517 flag used in
the clock data with CK_AM35XX.  The CK_3505 flag can also be
removed, since it is now unused.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: clock data: treat all AM35x devices the same

The init for 3505/3517 specific clocks depends on the ordering of
cpu_is checks, is error prone and confusing (there are 2 separate
checks for cpu_is_omap3505()).

Remove the 3505-specific checking since CK_3505 flag is not used, and
treat all AM35x clocks the same.

This means that the SGX clock (the only AM35x clkdev not currently
flagged for 3505) will now be registered on 3505, but that is
harmless.  That can be cleaned up when the clkdev nodes are removed in
favor of them being registered by hwmod.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: clock data: replace 3503/3517 flag with AM35x flag for UART4

The AM35x UART4 is common to all AM35x devices, so use CK_AM35XX instead
of (CK_3505 | CK_3517), which is equivalent.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>