ARM: OMAP2+: nand: fix build error when CONFIG_MTD_ONENAND_OMAP2=n

commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled.  By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:

/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error: redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2

Fix this by removing the duplicate dummy entry from the C file.

Cc: Enric Balletbò i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Linux-omap rebuilt: Final rebuild for branches for v3.5 merge window

$ git checkout -b tmp-rebuild-1336763529 linus
$ git merge -m "Merge fixes testing-misc tmp-merge testing-board cbus" fixes testing-misc tmp-merge testing-board cbus
$ git merge -s ours master
$ git checkout master
$ git merge tmp-rebuild-1336763529

To view the changes since the last rebuild, please do
$ git diff 7cf543bce32d07db1c2a3be6f964c361287209fc..3c1900faf483cd7f80e78bcdbb47f24953c4b367 arch/arm/*omap*/

Merge fixes testing-misc tmp-merge 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-fixes-for-cleanup-for-v3.5' into tmp-merge

Turns out the earlier omap-cleanup-sparse-for-v3.5
up introduced one compile issue and a new warning.

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

ARM: OMAP: OTG integration: fix compiler warning

Tony reported the following compile warning after commit
eeb3711b89d68e147e05e7b43a49ecc5009dc157 ("ARM: OMAP2+: clean up some
cppcheck warnings"):

arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
arch/arm/plat-omap/usb.c:40: warning: unused variable 'status'

This happens if CONFIG_ARCH_OMAP_OTG is set but
CONFIG_USB_GADGET_OMAP, CONFIG_USB_OHCI_HCD,
CONFIG_USB_OHCI_HCD_MODULE, and CONFIG_USB_OTG are all unset.

Fix by localizing the status variable to the blocks that use it.

Compile-tested only, with omap2plus_defconfig and omap2plus_defconfig
with CONFIG_USB_OHCI_HCD and CONFIG_USB_OTG enabled.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds

Janusz Krzysztofik reported the following build break on OMAP1 builds that
don't include CONFIG_ARCH_OMAP16XX:

  LD      .tmp_vmlinux1
arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init':
lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable'
make: *** [.tmp_vmlinux1] Error 1

This was caused by commit d3645d39ad0ed9f09535065676ea0ba114f93cdf
("ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus").
Fix by declaring an empty ocpi_enable() on non-16XX builds, which
should work until the OCPI code is moved out to drivers/.

Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

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

Clean up for omap DSS board init in preparation for adding DT support.

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

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-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.

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-renames-for-v3.5' into tmp-merge

Simplify some SoC config options before things get too unreadable.

Note that this depends on a fix in omap-fixes-non-critical-for-v3.5,
so it's based on that.

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 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.

GPMC: add ECC control definitions

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Tony Lindgren <tony@atomide.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 branch 'cleanup-soc' into cleanup

Conflicts:
arch/arm/mach-omap2/Makefile

Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test

$ git checkout -b tmp-rebuild-1336609929 linus
$ git merge -m "Merge fixes tmp-merge testing-misc testing-board cbus" fixes tmp-merge testing-misc testing-board cbus
$ git merge -s ours master
$ git checkout master
$ git merge tmp-rebuild-1336609929

To view the changes since the last rebuild, please do
$ git diff 5e136da4f5d9aa5388097afad1f6a0e6fd8572c6..838c1b88c6e798c8248ec89c7eae7b1c1c4c5b2b arch/arm/*omap*/

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.

Merge branch 'for-l-o-3.5' of git://gitorious.org/linux-omap-dss2/linux into cleanup-dss

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>

OMAPDSS: DSI: implement generic DSI pin config

In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
0, // pin num for clock lane +
1, // pin num for clock lane -
2, // pin num for data1 lane +
3, // pin num for data1 lane -
...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.

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

OMAPDSS: Taal: move reset gpio handling to taal driver

The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.

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

OMAPDSS: TFP410: rename dvi files to tfp410

Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.

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

OMAPDSS: TFP410: rename dvi -> tfp410

The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
panel driver". This patch renames the code to use tfp410 name for the
driver.

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

OMAP: board-files: remove custom PD GPIO handling for DVI output

Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.

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

OMAPDSS: panel-dvi: add PD gpio handling

The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.

This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.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>