Merge branch 'late/kirkwood' into late/soc

Merge in the late Kirkwood branch with the OMAP late branch for upstream
submission.

Final contents described in shared tag.

Fixup remove/change conflicts in arch/arm/mach-omap2/devices.c and
drivers/spi/spi-omap2-mcspi.c.

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'omap-devel-late-for-v3.7' of git://git./linux/kernel/git/tmlind/linux-omap into late/soc

These changes take us a step closer to merging the common clock
framework for omap but unfortunately these patches were not
ready for merging earlier. See also the notes below on the
dependencies these patches have, they are based on a merge
of sereral branches already merged.

From Paul Walmsley <paul@pwsan.com>:

OMAP patches intended for the 3.7 merge window:

- Runtime PM conversions for the GPMC and RNG IP blocks
- Preparation patches for the OMAP common clock framework conversion
- clkdev alias additions required by other drivers
- Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4
- OMAP hwmod code and data improvements
- Preparation patches for the IOMMU runtime PM conversion
- Preparation patches for OMAP4 full-chip retention support

Based on a merge of v3.6-rc6, the omap-cleanup-b-for-3.7 tag
(7852ec0536ca39cefffc6301dc77f8ae55592926),the cleanup-fixes-for-v3.7
tag (de6ca33a96a6bf61fcb91d3d399703e19ead9d1e), and the
omap-devel-am33xx-for-v3.7 tag
(11964f53eb4d9ce59a058be9999d9cfcb1ced878), due to dependencies.

* tag 'omap-devel-late-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (281 commits)
  ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70
  ARM: OMAP2+: PMU: Add runtime PM support
  ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD
  ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
  ARM: OMAP3: hwmod data: Add debugss HWMOD data
  ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems
  ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP
  hwrng: OMAP: remove SoC restrictions from driver registration
  ARM: OMAP: split OMAP1, OMAP2+ RNG device registration
  hwrng: OMAP: convert to use runtime PM
  hwrng: OMAP: store per-device data in per-device variables, not file statics
  ARM: OMAP2xxx: hwmod/CM: add RNG integration data
  ARM: OMAP2+: gpmc: minimal driver support
  ARM: OMAP2+: gpmc: Adapt to HWMOD
  ARM: OMAP2/3: hwmod data: add gpmc
  ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
  ARM: OMAP3: hwmod data: add mmu data for iva and isp
  ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
  ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks
  ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp
  ...

ARM: mvebu: fix build breaks from multi-platform conversion

Moving ARCH_MVEBU for multi-platform support caused several breakages in
recently added addr-map and pinctrl support for mvebu. This adds the
necessary selects and include paths to fix the build.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'omap-devel-b-c-2-for-3.7' of git://git./linux/kernel/git/pjw/omap-pending into devel-late

OMAP patches intended for the 3.7 merge window:

- Runtime PM conversions for the GPMC and RNG IP blocks
- Preparation patches for the OMAP common clock framework conversion
- clkdev alias additions required by other drivers
- Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4
- OMAP hwmod code and data improvements
- Preparation patches for the IOMMU runtime PM conversion
- Preparation patches for OMAP4 full-chip retention support

Based on a merge of v3.6-rc6, the omap-cleanup-b-for-3.7 tag
(7852ec0536ca39cefffc6301dc77f8ae55592926),the cleanup-fixes-for-v3.7
tag (de6ca33a96a6bf61fcb91d3d399703e19ead9d1e), and the
omap-devel-am33xx-for-v3.7 tag
(11964f53eb4d9ce59a058be9999d9cfcb1ced878), due to dependencies.

These patches have been tested for meaningful warnings from
checkpatch, sparse, smatch, and cppcheck.  Basic build, boot[1], and
PM test logs are available here:

    http://www.pwsan.com/omap/testlogs/hwmod_prcm_clock_a_3.7/20120923173830/

...

1. Note that the N800 boot fails due to a known issue present in the
   base commit:

    http://www.spinics.net/lists/arm-kernel/msg196034.html

ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70

OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
interrupts to the MPU HWMOD so we can use these for PMU events on these
devices. The PMU interrupts need to be the first interrupts in the array of
interrupts as the ARM PMU driver assumes this.

By using these dedicated interrupts we only need to enable the MPU and DEBUG
sub-systems for PMU to work. This is different to OMAP4430 that did not have
dedicated interrupts and required other power domains in addition to the DEBUG
sub-system to be enabled so we could route the PMU events to the CTI interrupts.
Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: PMU: Add runtime PM support

The original implementation of this patch was done by Ming Lei for PMU on OMAP4
[1]. Since then the PM runtime calls have been moved into the ARM PMU code and
this greatly simplifies the changes.

The another differnce since the original version, is that it is no longer
necessary to call pm_runtime_get/put during the PMU initialisation was we are no
longer accessing the hardware at this stage.

By adding runtime PM support, we can ensure that the appropriate power and clock
domains are kept on while PMU is being used.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD

For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
(CTI) because there are no dedicated interrupts. In order to route the PMU
events via the CTI IRQs, the following modules must be enabled:

        l3_instr, l3_main_3, debugss

Therefore, build the arm-pmu device via these three HWMODs.

However, the CTI support for this platform still needs some work.  Until
that's finished, temporarily disable the PMU on OMAP4430.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: temporarily disabled OMAP4430 PMU support until a
 better CTI interface can be implemented; added patch description note]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD

Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
on OMAP2 devices we only need to use MPU sub-system and so we can simply use
the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
device for OMAP3.

The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
add the PMU interrupt to the MPU HWMOD for these devices.

This change also moves the PMU code out of the mach-omap2/devices.c files into
its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed checkpatch messages; updated to apply; dropped old-style
 initial filename line in header comments]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: Add debugss HWMOD data

To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
data for the debug sub-system for OMAP3, we can build the PMU device using the
debug sub-system HWMOD and control this power domain using runtime PM.

Reviewed-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply; added L4-EMU address space]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems

The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle.  Add a workaround flag in the clockdomain
code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
the code necessary to support it.

If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
clockdomain will be forced active whenever an IP block inside that
clockdomain is in use, even if the clockdomain supports
hardware-supervised idle.  When the kernel indicates that the last
active IP block inside the clockdomain is no longer used, the
clockdomain will be forced idle, or, if that mode is not supported in
the hardware, it will be placed into hardware-supervised idle.

This patch is an equal collaboration with Jon Hunter
<jon-hunter@ti.com>.  Ming Lei <ming.lei@canonical.com>, Will Deacon
<will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman
<khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh
Shilimkar <santosh.shilimkar@ti.com> all made essential contributions
to the understanding of EMU clockdomain power management on OMAP.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Madhav Vij <mvij@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Jon Hunter <jon-hunter@ti.com>

ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP

Some instances of the DMTIMER peripheral on OMAP devices have the ability
to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
attribute to indicate which timers can interrupt the DSP. By using the
omap_dm_timer_request_by_cap() API, driver will now be able to allocate
a DMTIMER that can interrupt the DSP based upon this attribute and not require
the driver to know which instance has this capability.

DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as
follows ...

- OMAP1 (OMAP5912/16xx/17xx) devices - All 8 DMTIMERs
- OMAP2/3/4 devices - DMTIMERs 5-8

Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
generate a PWM output.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

hwrng: OMAP: remove SoC restrictions from driver registration

Remove the SoC restriction code from the OMAP RNG driver.  The
integration code in arch/arm/*omap* should handle this.  The device
shouldn't be created if it doesn't exist on the currently-booted SoC.

This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the driver.  Also, if other OMAP chips have RNGs that can be used
by Linux, there will be no need to modify the driver.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

ARM: OMAP: split OMAP1, OMAP2+ RNG device registration

Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c,
and create a omap_device-backed registration function for OMAP2+ devices
in mach-omap2/devices.c.

As a nice side-benefit, we can also get rid of
arch/arm/plat-omap/devices.c, thanks to some recent changes from Tony.

One change from the previous behavior is that the RNG devices are now
registered unconditionally.  This should allow the RNG drivers to be
loaded as modules, even if the original kernel was not built that way.

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

hwrng: OMAP: convert to use runtime PM

Convert the OMAP onboard hardware RNG driver to use runtime PM.

This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the RNG driver.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

hwrng: OMAP: store per-device data in per-device variables, not file statics

Encapsulate all of the RNG per-device state into a single per-device
structure record, as opposed to a set of per-driver file variables.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

ARM: OMAP2xxx: hwmod/CM: add RNG integration data

Add integration data for the hardware random number generator IP block
on some OMAP SoCs.  This appears to be present on at least OMAP2xxx
and OMAP3xxx SoCs, although it is not so easy to tell.  It may also be
present on other OMAP2+ SoCs.

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

ARM: OMAP2+: gpmc: minimal driver support

Create a minimal driver out of gpmc code.  Responsibilities handled by
earlier gpmc initialization is now achieved in probe.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed some checkpatch messages]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: gpmc: Adapt to HWMOD

Create API for platforms to adapt GPMC to HWMOD

Signed-off-by: Afzal Mohammed <afzal@ti.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2/3: hwmod data: add gpmc

Add gpmc hwmod and associated interconnect data

Signed-off-by: Afzal Mohammed <afzal@ti.com>
[paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp

Add mmu hwmod data for ipu and dsp.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
Acked-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: cleaned up whitespace]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: add mmu data for iva and isp

Add mmu hwmod data for iva and isp.

Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present
 on AM35xx so restricted these hwmods to 34xx/36xx]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected

If included without IOMMU_API being selected it will break
compilation:

arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'

This will be seen when hwmod includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks

Some struct omap_hwmod records belonging to PRCM IP blocks are missing
HWMOD_NO_IDLEST flags; add them.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp

Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp. Also
removed phy_48m as the optional clock since it is now made as the
main clock. By this the driver need not enable/disable phy_48m clk
separately and runtime_get/runtime_put will take care of that.

Cc: Benoît Cousson <b-cousson@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries

ocp2scp_usb_phy was missing the address space data and thus
the sysconfig was not populated either.
The usb_host_hs address space was wrong.

Fix both of them and add the missing sysconfig entry.

Reported-by: Kishon Vijay Abraham <kishon@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: add sad2d hwmod

SAD2D stands for the die to die interface, and is used for communicating
with the optional stacked modem. This hwmod is added in preparation for
the d2d_idle move from pm34xx.c to hwmod data.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx,
 so only add it to the OMAP34xx/OMAP36xx lists]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP: hwmod: revise deassert sequence

For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled

Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.

E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
  IP block isn't fully enabled by hwmod code.
- Usually ipu and dsp processors configure their mmu module first
  and then enable the processors, this involves:
    * Deasserting mmu reset line, and enabling the module.
    * Deasserting cpu0 reset line, and enabling the processor.
  The ones portrayed in this example are controlled through
  rproc_fw_boot in drivers/remoteproc/remoteproc_core.c

While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.

This will allow the driver to:
  a. Deassert the reset line.
  b. Enable the hwmod through runtime PM default callbacks.
  c. Do its usecase.
  d. Disable hwmod through runtime PM.
  e. Assert the reset line.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by adding a
flag bit, HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT.  Rest have a valid
'context_offs' populated in .prcm structure already.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: add flag bit rather than overloading .context_offs;
 update changelog message]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add support for lostcontext_mask

Currently hwmod only provides the offset for the context lose
register, and if we attempt to share the same register between two or
more hwmods, the resulting context loss counts get wrong. Thus, we
need a way to specify which bits are used for the context loss
information for each.  This is accomplished by adding a new field to
the omap4 prcm struct, 'lostcontext_mask', which specifies a bit-mask
to use for filtering the register.

Mark the affected hwmods appropriately.  'l4_abe' hwmod uses the
LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register, as l4_abe doesn't
have its own dedicated register for this purpose. This register is
shared with 'aess' hwmod, thus both hwmods must also specify which
bits of the register are used for them.

This patch only adds the hwmod data, but a future patch should add
code support such that only the specified bits are read and cleared by
the context lose counter update code. If a hwmod doesn't specify
'lostcontext_mask' (default behavior), the whole contents of the
context register should be used without any filtering.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: updated to apply after conversion to use flag bit for
 missing module context-loss register; combined data and code patches;
 dropped code change due to serial driver breakage]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: powerdomain: add support for reading prev logic and mem states

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.

If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: removed dependency on functional power state series for now;
 bumped copyright date]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages

The decision was made a few months ago to allow struct omap_hwmod
records and struct clk records to omit clockdomain information if the
clockdomain is not software-controllable.  See for example commit
868c157df9721675c19729eed2c96bac6c3f1d01 ("ARM: OMAP2+: hwmod: remove
prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain").

So convert an existing pr_warning() to a pr_debug() (regarding missing
clockdomains in clocks), and add a pr_debug() for missing hwmod
clockdomains.  It's still useful to enable these messages for
debugging, since missing clockdomains can cause hard-to-debug problems
with power management; see for example commit
6c4a057bffe9823221eab547e11fac181dc18a2b ("ARM: OMAP4: clock data:
Force a DPLL clkdm/pwrdm ON before a relock").

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*()

We're no longer requiring struct omap_hwmod records to contain a
clockdomain.  So we shouldn't return -EINVAL any more from
_omap4_wait_target_disable() or _omap4_wait_target_ready() if there's
no clockdomain defined, since that just gets passed back to the
caller.  This can result in pointless warnings under the relaxed data
format.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices

This API is meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP: hwmod code: remove unused hwmod function prototypes

Several hwmod function prototypes appear to not have an implementation
because the corresponding functions were removed or renamed.
Those prototypes are unneeded anymore - remove them.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
[paul@pwsan.com: tweaked subject]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Merge branch 'clock_devel_3.7' into hwmod_prcm_clock_a_3.7

Conflicts:
arch/arm/mach-omap2/clkt34xx_dpll3m2.c
arch/arm/mach-omap2/clkt_clksel.c
arch/arm/mach-omap2/clock.c

Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7

From Paul Walmsley <paul@pwsan.com>:

AM33xx hwmod data and miscellaneous clock and hwmod fixes.  AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.

Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7

These fixes are needed to fix non-omap build breakage for
twl-core driver and to fix omap1_defconfig compile when
led driver changes and omap sparse IRQ changes are merged
together. Also fix warnings for omaps not using pinctrl
framework yet.

Merge tag 'omap-cleanup-b-for-3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7

smatch and string-wrapping cleanups for the OMAP subarch code.

These changes fix some of the more meaningful warnings that smatch
returns for the OMAP subarch code, and unwraps strings that are
wrapped at the 80-column boundary, to conform with the current
practice.

Basic build, boot, and PM logs are available here:

http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/

ARM: kirkwood: dockstar: fix header include

The platform data was moved, but this file was introduced in parallel
so didn't get caught in the sweeping changes. Fix it up now.

Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: kirkwood: move new dtbs to common Makefile

This moves a few of the newly introduced dtb targets to the common
dts/Makefile instead of the per-platform file.

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'kirkwood/drivers' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

From Jason Cooper:

New drivers:
 - pinctrl (dove, kirkwood, mvebu)
 - gpio (mvebu)

* 'kirkwood/drivers' of git://git.infradead.org/users/jcooper/linux:
  arm: mvebu: add gpio support in defconfig
  arm: mvebu: add DT information for GPIO banks on Armada 370 and XP
  arm: mvebu: use GPIO support now that a driver is available
  Documentation: add description of DT binding for the gpio-mvebu driver
  gpio: introduce gpio-mvebu driver for Marvell SoCs
  arm: mvebu: select the pinctrl drivers for Armada 370 and Armada XP platforms
  arm: mvebu: split Kconfig options for Armada 370 and XP
  ARM: mvebu: adjust Armada XP evaluation board DTS
  ARM: mvebu: Add pinctrl support to Armada 370 SoC
  ARM: mvebu: Add pinctrl support to Armada XP SoCs
  pinctrl: mvebu: add pinctrl driver for Armada XP
  pinctrl: mvebu: add pinctrl driver for Armada 370
  pinctrl: mvebu: kirkwood pinctrl driver
  pinctrl: mvebu: dove pinctrl driver
  pinctrl: mvebu: pinctrl driver core

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

* 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux:
  arm: mvebu: add address decoding controller to the DT
  arm: mvebu: add basic address decoding support to Armada 370/XP
  arm: plat-orion: make bridge_virt_base non-const to support DT use case
  arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option
  arm: plat-orion: use void __iomem pointers for addr-map functions
  arm: plat-orion: use void __iomem pointers for time functions
  arm: plat-orion: use void __iomem pointers for MPP functions
  arm: plat-orion: use void __iomem pointers for UART registration functions
  arm: mach-mvebu: use IOMEM() for base address definitions
  arm: mach-orion5x: use IOMEM() for base address definitions
  arm: mach-mv78xx0: use IOMEM() for base address definitions
  arm: mach-kirkwood: use IOMEM() for base address definitions
  arm: mach-dove: use IOMEM() for base address definitions
  arm: mach-orion5x: use plus instead of or for address definitions
  arm: mach-mv78xx0: use plus instead of or for address definitions
  arm: mach-kirkwood: use plus instead of or for address definitions
  arm: mach-dove: use plus instead of or for address definitions

This branch had quite a few conflicts, in particular with the PCI static
map rework from Rob Herring, and a few other context conflicts due to
changes in Kconfig, etc.

I fixed up conflicts in:
arch/arm/Kconfig
arch/arm/mach-dove/common.c
arch/arm/mach-dove/include/mach/dove.h
arch/arm/mach-kirkwood/common.c
arch/arm/mach-kirkwood/include/mach/kirkwood.h
arch/arm/mach-mv78xx0/common.c
arch/arm/mach-mv78xx0/include/mach/mv78xx0.h
arch/arm/mach-orion5x/common.c
arch/arm/mach-orion5x/include/mach/orion5x.h

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'kirkwood/cleanup' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

From Jason Cooper:

Misc:
 - trim includes for board-dnskw.c

* 'kirkwood/cleanup' of git://git.infradead.org/users/jcooper/linux:
  ARM: kirkwood: Trim excess #includes in board-dnskw.c

Merge branch 'kirkwood/dt' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

From Jason Cooper:

New bindings:
  - iconnect nand and keys
  - mv_cesa
  - gpio-fan

* 'kirkwood/dt' of git://git.infradead.org/users/jcooper/linux:
  ARM: kirkwood: Use devicetree to define DNS-32[05] fan
  hwmon: Add devicetree bindings to gpio-fan
  Crypto: CESA: Add support for DT based instantiation.
  ARM: Kirkwood: Describe iconnect nand in DT.
  ARM: Kirkwood: Describe iconnect keys in DT.

Merge branch 'kirkwood/defconfig' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

From Jason Cooper:

defconfig:
 - update kirkwood_defconfig via 'make oldconfig'
 - Add all Kirkwood DT boards to the defconfig
 - enable SERIAL_OF_PLATFORM and ORION_WATCHDOG in kirkwood_defconfig

* 'kirkwood/defconfig' of git://git.infradead.org/users/jcooper/linux:
  ARM: Kirkwood: add DT boards to defconfig
  ARM: Kirkwood: update defconfig

Merge branch 'kirkwood/boards' of git://git.infradead.org/users/jcooper/linux into late/kirkwood

* 'kirkwood/boards' of git://git.infradead.org/users/jcooper/linux:
  ARM: Dove: allow PCI to be disabled
  ARM: dove: SolidRun CuBox DT
  ARM: dove: add device tree descriptors
  ARM: dove: add device tree based machine descriptor
  ARM: dove: add crypto engine
  ARM: dove: add clock gating control
  ARM: dove: unify clock setup
  ARM: initial DTS support for km_kirkwood
  arm: add documentation describing Marvell families of SoC
  ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar
  ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar
  ARM: Kirkwood: Iomega ix2-200 DT support

Context conflicts in arch/arm/Kconfig and arch/arm/mach-dove/common.c.

The new device trees added to arch/arm/mach-kirkwood/Makefile.boot are
kept and dealt with in a separate changeset, since moving them out to
the new Makefile in this merge commit doesn't work well.

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'next/multiplatform' into late/kirkwood

By Arnd Bergmann (15) and David Brown (1)
* next/multiplatform:
  ARM: msm: Move core.h contents into common.h
  ARM: spear: move platform_data definitions
  ARM: samsung: move platform_data definitions
  ARM: orion: move platform_data definitions
  ARM: nomadik: move platform_data definitions
  ARM: w90x900: move platform_data definitions
  ARM: vt8500: move platform_data definitions
  ARM: tegra: move sdhci platform_data definition
  ARM: sa1100: move platform_data definitions
  ARM: pxa: move platform_data definitions
  ARM: netx: move platform_data definitions
  ARM: msm: move platform_data definitions
  ARM: imx: move platform_data definitions
  ARM: ep93xx: move platform_data definitions
  ARM: davinci: move platform_data definitions
  ARM: at91: move platform_data definitions

Merge branch 'next/cleanup' into late/kirkwood

By Arnd Bergmann (21) and Wei Yongjun (1)
via Olof Johansson (2) and Haojian Zhuang (1)
* next/cleanup: (22 commits)
  ARM: mmp: using for_each_set_bit to simplify the code
  net: seeq: use __iomem pointers for MMIO
  video: da8xx-fb: use __iomem pointers for MMIO
  scsi: eesox: use __iomem pointers for MMIO
  serial: ks8695: use __iomem pointers for MMIO
  input: rpcmouse: use __iomem pointers for MMIO
  ARM: samsung: use __iomem pointers for MMIO
  ARM: spear13xx: use __iomem pointers for MMIO
  ARM: sa1100: use __iomem pointers for MMIO
  ARM: prima2: use __iomem pointers for MMIO
  ARM: nomadik: use __iomem pointers for MMIO
  ARM: msm: use __iomem pointers for MMIO
  ARM: lpc32xx: use __iomem pointers for MMIO
  ARM: ks8695: use __iomem pointers for MMIO
  ARM: ixp4xx: use __iomem pointers for MMIO
  ARM: iop32x: use __iomem pointers for MMIO
  ARM: iop13xx: use __iomem pointers for MMIO
  ARM: integrator: use __iomem pointers for MMIO
  ARM: imx: use __iomem pointers for MMIO
  ARM: ebsa110: use __iomem pointers for MMIO
  ...

Merge branch 'cleanup/__iomem' into next/cleanup

__iomem annotation cleanup branch from Arnd.

* cleanup/__iomem: (21 commits)
  net: seeq: use __iomem pointers for MMIO
  video: da8xx-fb: use __iomem pointers for MMIO
  scsi: eesox: use __iomem pointers for MMIO
  serial: ks8695: use __iomem pointers for MMIO
  input: rpcmouse: use __iomem pointers for MMIO
  ARM: samsung: use __iomem pointers for MMIO
  ARM: spear13xx: use __iomem pointers for MMIO
  ARM: sa1100: use __iomem pointers for MMIO
  ARM: prima2: use __iomem pointers for MMIO
  ARM: nomadik: use __iomem pointers for MMIO
  ARM: msm: use __iomem pointers for MMIO
  ARM: lpc32xx: use __iomem pointers for MMIO
  ARM: ks8695: use __iomem pointers for MMIO
  ARM: ixp4xx: use __iomem pointers for MMIO
  ARM: iop32x: use __iomem pointers for MMIO
  ARM: iop13xx: use __iomem pointers for MMIO
  ARM: integrator: use __iomem pointers for MMIO
  ARM: imx: use __iomem pointers for MMIO
  ARM: ebsa110: use __iomem pointers for MMIO
  ARM: at91: use __iomem pointers for MMIO
  ...

Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: AM33XX: cm: Add bit-field width values

The new common clk framework includes basic definitions for mux and
divider clocks.  These definitions depend on shift and width values
instead of the pre-computed masks that the OMAP/AM33XX clk framework
has traditionally used when accessing the register to control the
mux or divisor.

To ease this transition the masks are left intact and
the width field is simply added alongside the shift and mask data.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: cm: add bitfield width values

The new common clk framework includes basic definitions for mux and
divider clocks.  These definitions depend on shift and width values
instead of the pre-computed masks that the OMAP clk framework has
traditionally used when accessing the register to control the mux or
divisor.

To ease this transition the masks are left intact and the width field is
simply added alongside the shift and mask data.

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

ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk

While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.

While here also concatenate some strings split across multiple lines
which seem to be needed anyway.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: simplified some compound expressions; reformatted some
 messages]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>

ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage

Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from hwmod and omap_device
code.

Moving to clk_get() also means the respective platforms
need the clkdev tables updated with an entry for all clocks
used by hwmod to have clock name same as the alias.

Based on original changes from Mike Turquette.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
[paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
 restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
 clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
 aliases rng_ick and several emulation clocks]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: omap: clk: add clk_prepare and clk_unprepare

As part of Common Clk Framework (CCF) the clk_enable() operation
was split into a clk_prepare() which could sleep, and a clk_enable()
which should never sleep. Similarly the clk_disable() was
split into clk_disable() and clk_unprepare(). This was
needed to handle complex cases where in a clk gate/ungate
would require a slow and a fast part to be implemented.
None of the clocks below seem to be in the 'complex' clocks
category and are just simple clocks which are enabled/disabled
through simple register writes.
Most of the instances also seem to be called in non-atomic
context which means its safe to move all of those from
using a clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare().

For some others, mainly the ones handled through the hwmod framework
there is a possibility that they get called in either an atomic
or a non-atomic context.

The way these get handled below work only as long as clk_prepare
is implemented as a no-op (which is the case today) since this gets
called very early at boot while most subsystems are unavailable.
Hence these are marked with a *HACK* comment, which says we need
to re-visit these once we start doing something meaningful with
clk_prepare/clk_unprepare like doing voltage scaling or something
that involves i2c.

This is in preparation of OMAP moving to CCF.

Based on initial changes from Mike Turquette.

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

SPI: OMAP: remove unnecessary includes of plat/clock.h

Remove unnecessary includes of plat/clock.h from the OMAP SPI
controller drivers.  These need to be removed to build multi-subarch
ARM kernels which include these drivers.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

ARM: OMAP4: Add timer clock aliases for device-tree

For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's
"timer_sys_ck" we need to specify the timer device name as well as clock alias
to find the right clock.

Currently, the device names for the timers have the format "omap_timer.X" where
X is the timer instance number. When using to device tree, the format of the
device name created by device-tree is different and has the format
"<reg-address>.<device-name>" (this is assuming that the device-tree "reg"
property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to
fail. To fix this add new timer clock alias for using device-tree.

Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: AM33XX: clock data: Add clkdev alias for cpu0

Add AM335x cpu0 clock entry to the corresponding clock data file. This
is useful in getting the correct mpu clock pointer to change the cpu
frequency in cpufreq driver.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
[paul@pwsan.com: changed patch subject]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: clock data: add some aliases for use by CPUFreq only

These clkdev aliases should make it possible to remove the
cpu_is_omap*() calls and the omap_device*() call from
drivers/cpufreq/omap-cpufreq.c during the next merge window.  Those
are interfering with multi-subarch ARM kernels.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>

ARM: OMAP3: clock data: Add the USB TLL clocks device name

The platform device name "usbhs_tll" is added for the functional,
interface and channel clocks of the TLL module.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2420: Cosmetic fix for timer clock aliases

In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases) new clock
aliases were added for OMAP2+ devices. For OMAP2420, I incorrectly set the
clock flag as CK_243X instead of CK_242X. This did not introduce a regression
as the clock flags are not checked for OMAP2 devices. This also explains why
I did not catch this when testing on OMAP2420.

Fix the clock flags for these aliases for correctness.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>

ARM: OMAP3: clock data: remove obsolete comment

The file is currently called 'clock3xxx_data.c', so this comment is
out of date.

Signed-off-by: Michael Jones <michael.jones@matrix-vision.de>
[paul@pwsan.com: wrote changelog]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7

From Paul Walmsley <paul@pwsan.com>:

AM33xx hwmod data and miscellaneous clock and hwmod fixes.  AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.

Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7

These fixes are needed to fix non-omap build breakage for
twl-core driver and to fix omap1_defconfig compile when
led driver changes and omap sparse IRQ changes are merged
together. Also fix warnings for omaps not using pinctrl
framework yet.

ARM: kirkwood: Trim excess #includes in board-dnskw.c

Lots of code has now moved into the devicetree, leaving a collection of
useless header files. Tidy them up.

This applies cleanly atop of my previous patch, "[PATCH V2 2/2] ARM:
kirkwood: Use devicetree to define DNS-32[05] fan", which also removes
gpio-fan.h

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: add gpio support in defconfig

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: add DT information for GPIO banks on Armada 370 and XP

The gpioX aliases are needed so that the driver can use
of_alias_get_id() to get a 0-based number of the GPIO bank, which we
then use to compute the base GPIO of the bank being probed. This is
similar to what gpio-mxs.c is doing.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: use GPIO support now that a driver is available

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Documentation: add description of DT binding for the gpio-mvebu driver

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

gpio: introduce gpio-mvebu driver for Marvell SoCs

This driver aims at replacing the arch/arm/plat-orion/gpio.c driver,
and is designed to be compatible with all Marvell EBU SoCs: Orion,
Kirkwood, Dove, Armada 370/XP and Discovery.

It has been successfully tested on Dove and Armada XP at the moment.

Compared to the plat-orion driver, this new driver has the following
added benefits:

 *) Support for Armada 370 and Armada XP
 *) It is integrated with the mvebu pinctrl driver so that GPIO pins
    are properly muxed, and the GPIO driver knows which GPIO pins are
    output-only or input-only.
 *) Properly placed in drivers/gpio
 *) More extensible mechanism to support platform differences. The
    plat-orion driver uses a simple mask-offset DT property, which
    works fine for Discovery MV78200 but not for Armada XP. The new
    driver uses different compatible strings to identify the different
    variants of the GPIO controllers.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: select the pinctrl drivers for Armada 370 and Armada XP platforms

This patch actually enables pinctrl drivers for Armada 370 and XP.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: split Kconfig options for Armada 370 and XP

Until now, all the code for Armada 370 and XP was common, so we had a
single Kconfig option to support all boards using both SoCs. With the
addition of pinctrl drivers, this situation has changed: those two
SoCs are radically different in terms of pinctrl, so they have two
separate drivers. Since pinctrl drivers are typically select-ed from
the SoC Kconfig option, it makes sense to split the 370/XP option into
two separate options: one for Armada 370 and another for Armada XP.

We keep an hidden option selected by both ARMADA_370 and ARMADA_XP in
order to easily compile common code.

A followup patch actually makes use of this split to select the
appropriate pinctrl drivers.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory Clement <gregory.clement@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

ARM: mvebu: adjust Armada XP evaluation board DTS

The Armada XP evaluation board is based on the MV78460 Armava XP
SoC. Now that we have separate .dtsi files for the three different
SoCs of the Armada XP family, use the appropriate one as include for
the Armada XP evaluation board .dts file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

ARM: mvebu: Add pinctrl support to Armada 370 SoC

This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada 370 SoC.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

ARM: mvebu: Add pinctrl support to Armada XP SoCs

This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada XP SoCs.

Until now, the device tree representation considered the Armada XP as
a single SoC. But in fact, there are three different SoCs in the
Armada XP families, with different number of CPU cores, different
number of Ethernet interfaces... and different number of muxable pins
or functions. We therefore introduce three armada-xp-mv78xx0.dtsi for
the three SoCs of the Armada XP family. The current armada-xp-db.dts
evaluation board uses the MV78460 variant of the SoC.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

pinctrl: mvebu: add pinctrl driver for Armada XP

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

pinctrl: mvebu: add pinctrl driver for Armada 370

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

pinctrl: mvebu: kirkwood pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

pinctrl: mvebu: dove pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Dove SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

pinctrl: mvebu: pinctrl driver core

This patch adds a pinctrl driver core for Marvell SoCs plus DT
binding documentation. This core driver will be used by SoC family
specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Conflicts:

arch/arm/Kconfig

ARM: kirkwood: Use devicetree to define DNS-32[05] fan

Remove more board-specific code by using devicetree to define the fan
attached to both boards.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

hwmon: Add devicetree bindings to gpio-fan

Allow a gpio-fan to be defined in devicetree, see binding documentation
for details.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Crypto: CESA: Add support for DT based instantiation.

Based on work by Michael Walle and Jason Cooper.

Added support for getting the interrupt number and address of SRAM
from DT.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Conflicts:

arch/arm/mach-kirkwood/board-dt.c

ARM: Kirkwood: Describe iconnect nand in DT.

Define the nand and its partitions in DT and remove them from cmdline

Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

ARM: Kirkwood: Describe iconnect keys in DT.

Define the 2 keys found on iconnect in DT. It's also changing the keycodes/
switches to use better ones.

Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Merge branch 'multiplatform/platform-data' into next/multiplatform

* multiplatform/platform-data:
  ARM: spear: move platform_data definitions
  ARM: samsung: move platform_data definitions
  ARM: orion: move platform_data definitions
  ARM: nomadik: move platform_data definitions
  ARM: w90x900: move platform_data definitions
  ARM: vt8500: move platform_data definitions
  ARM: tegra: move sdhci platform_data definition
  ARM: sa1100: move platform_data definitions
  ARM: pxa: move platform_data definitions
  ARM: netx: move platform_data definitions
  ARM: msm: move platform_data definitions
  ARM: imx: move platform_data definitions
  ARM: ep93xx: move platform_data definitions
  ARM: davinci: move platform_data definitions
  ARM: at91: move platform_data definitions

Conflicts due to removed files:
arch/arm/mach-tegra/board-harmony.c
arch/arm/mach-tegra/board-trimslice.c

Conflicts due to code removal:
arch/arm/mach-tegra/board-paz00.c

Context conflicts in:
drivers/mmc/host/sdhci-tegra.c
drivers/net/irda/pxaficp_ir.c

Signed-off-by: Olof Johansson <olof@lixom.net>

ARM: msm: Move core.h contents into common.h

No real need to have a separate core.h from the common.h file.  Fold
these two prototypes into the common header file.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'multiplatform/smp_ops' into next/multiplatform

* multiplatform/smp_ops:
  ARM: consolidate pen_release instead of having per platform definitions
  ARM: smp: Make SMP operations mandatory
  ARM: SoC: convert spear13xx to SMP operations
  ARM: SoC: convert imx6q to SMP operations
  ARM: SoC: convert highbank to SMP operations
  ARM: SoC: convert shmobile SMP to SMP operations
  ARM: SoC: convert ux500 to SMP operations
  ARM: SoC: convert MSM to SMP operations
  ARM: SoC: convert Exynos4 to SMP operations
  ARM: SoC: convert Tegra to SMP operations
  ARM: SoC: convert OMAP4 to SMP operations
  ARM: SoC: convert VExpress/RealView to SMP operations
  ARM: SoC: add per-platform SMP operations

Conflicts due to file moves or removals in:
arch/arm/mach-msm/board-msm8960.c
arch/arm/mach-msm/board-msm8x60.c
arch/arm/mach-tegra/board-harmony.c
arch/arm/mach-tegra/board-trimslice.c

Conflicts due to board file cleanup:
arch/arm/mach-tegra/board-paz00.c

Conflicts due to cpu hotplug addition:
arch/arm/mach-tegra/hotplug.c

Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'board' of git://github.com/hzhuang1/linux into next/cleanup

* 'board' of git://github.com/hzhuang1/linux:
  ARM: mmp: using for_each_set_bit to simplify the code

ARM: Kirkwood: add DT boards to defconfig

Also, enable SERIAL_OF_PLATFORM and ORION_WATCHDOG

Signed-off-by: Jason Cooper <jason@lakedaemon.net>

ARM: Kirkwood: update defconfig

Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: add address decoding controller to the DT

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mvebu: add basic address decoding support to Armada 370/XP

This commit adds basic support for address decoding configuration for
the Armada 370 and Armada XP SoCs, re-using the infrastructure
provided in plat-orion.

For now, only a BootROM window is configured on Armada XP, which is
needed to get the non-boot CPUs started and is therefore a requirement
for SMP support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: make bridge_virt_base non-const to support DT use case

For the Armada 370 and XP SoCs where the DT is used, we need to fill
at runtime the bridge_virt_base field on the
orion_addr_map_cfg. Therefore, remove the 'const' qualifier on this
field.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option

Until now, the PLAT_ORION configuration option was common to all the
Marvell EBU SoCs, and selecting this option had the effect of enabling
the MPP code, GPIO code, address decoding and PCIe code from
plat-orion, as well as providing access to driver-specific header
files from plat-orion/include.

However, the Armada 370 and XP SoCs will not use the MPP and GPIO code
(instead some proper pinctrl and gpio drivers are in preparation), and
generally, we want to move away from plat-orion and instead have
everything in mach-mvebu.

That said, in the mean time, we want to leverage the driver-specific
headers as well as the address decoding code, so we introduce
PLAT_ORION_LEGACY. The older Marvell SoCs need to select
PLAT_ORION_LEGACY, while the newer Marvell SoCs need to select
PLAT_ORION. Of course, when PLAT_ORION_LEGACY is selected, it
automatically selects PLAT_ORION.

Then, with just PLAT_ORION, you have the address decoding code plus
the driver-specific headers. If you add PLAT_ORION_LEGACY to this, you
gain the old MPP, GPIO and PCIe code.

Again, this is only a temporary solution until we make all Marvell EBU
platforms converge into the mach-mvebu directory. This solution avoids
duplicating the existing address decoding code into mach-mvebu.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: use void __iomem pointers for addr-map functions

The functions for address mapping management now take void __iomem
pointers, so we remove the temporary "unsigned long" casts from the
mach-*/common.c files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: use void __iomem pointers for time functions

The functions for time management now take void __iomem pointers, so
we remove the temporary "unsigned long" casts from the mach-*/common.c
files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: use void __iomem pointers for MPP functions

The registration function for MPP now takes void __iomem pointers, so
we remove the temporary "unsigned long" casts from the mach-*/mpp.c
files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: plat-orion: use void __iomem pointers for UART registration functions

The registration functions for UARTs now take void __iomem pointers,
so we remove the temporary "unsigned long" casts from the
mach-*/common.c files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

arm: mach-mvebu: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-mvebu code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>