Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be registered only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be built once at init time and never be modified
at runtime.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use
bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505,
etc.).  Superset flags, such as CK_3XXX or CK_AM35XX, are now defined
as disjunctions of individual SoC variant flags.  This simplifies the
definition and use of these flags.  struct omap_clk record definitions
can now simply specify the bitmask of actual SoCs that the records are
valid for.  The clock init code can simply set a single CPU type mask
bit for the SoC that is currently in use, and test against that,
rather than needing to set some combination of flags.

Similarly, clarify the use of struct clksel_rate.flags.  The bit
allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has
been defined as a disjunction of the 34xx and 36xx rate flags.  The
advantages are the same as the above.

Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only
apply to the SoCs that they name, e.g., OMAP34xx chips.  The previous
practice caused significantly different SoCs, such as OMAP36xx, to be
included in CK_34XX.  In my opinion, this is much more intuitive.

Similarly, clarify the use of struct clksel_rate.flags, such that
RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2
- it does not apply to OMAP36xx.

...

At some point, it probably makes sense to collapse the CK_* and
RATE_IN_* flags together into a single bitfield, and possibly use the
existing CHIP_IS_OMAP* flags for platform detection.

...

This all seems to work fine on OMAP34xx and OMAP36xx Beagle.  Not sure
if it works on Sitara or the TI816X, unfortunately I don't have any
here to test with.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Move the padconf save code from pm34xx.c to the System Control Module
code in mach-omap2/control.c.  This is part of the general push to
move direct register access from middle-layer core code to low-level
core code, so the middle-layer code can be abstracted to work on
multiple platforms and cleaned up.

In the medium-to-long term, this code should be called by the mux
layer code, not the PM idle code.  This is because, according to the
TRM, saving the padconf only needs to be done when the padconf
changes[1].
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H]
   Section 4.11.4 "Device Off-Mode Sequences"

The OMAP powerdomain code and data is all OMAP2+-specific.  This seems
unlikely to change any time soon.  Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h.  The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and data directly.

As part of this process, remove the references to powerdomain data
from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
Change the DSPBridge code to point to the new location for the
powerdomain headers.  The DSPBridge code should not be including the
powerdomain headers; these should be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>

The OMAP clockdomain code and data is all OMAP2+-specific.  This seems
unlikely to change any time soon.  Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h.  The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and data directly.

DSPBridge also uses the clockdomain headers for some reason, so,
modify it also. The DSPBridge code should not be including the
clockdomain headers; these should be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Reverse some of the effects of commit
84c0c39a ("ARM: OMAP4: PM: Make OMAP3
Clock-domain framework compatible for OMAP4").  On OMAP2/3, the
CM_CLKSTCTRL register is at a constant offset from the powerdomain's
CM instance.

Also, remove some of the direct CM register access from the
clockdomain code, moving it to the OMAP2/3 CM code instead.  The
intention here is to simplify the clockdomain code.  (The long-term
goal is to move all direct CM register access across the OMAP core
code to the appropriate cm*.c file.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Add PRCM partition, CM instance register address offset, and clockdomain
register address offset to each OMAP4 struct clockdomain record.  Add OMAP4
clockdomain code to use this new data to access registers properly.

While here, clean up some nearby clockdomain code to allocate auto variables
in my recollection of Linus's preferred style.

The autogeneration scripts have been updated.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

OMAP4 powerdomain control registers are split between the PRM hardware
module and the PRCM_MPU local PRCM.  Add this PRCM partition
information to each OMAP4 powerdomain record, and convert the OMAP4
powerdomain function implementations to use the OMAP4 PRM instance
functions.

Also fixes a potential null pointer dereference of pwrdm->name.

The autogeneration scripts have been updated.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Now that OMAP4-specific PRCM functions have been added, distinguish the
existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_".

This patch should not result in any functional change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

In some ways, the OMAP4 PRCM register layout is quite different than
the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
register layout point of view, all CM instances were located in the CM
subsystem, and all PRM instances were located in the PRM subsystem.
OMAP4 changes this.  Now, for example, some CM instances, such as
WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
"local PRCM" exists for the MPU - this PRCM combines registers that
would normally appear in both CM and PRM instances, but uses its own
register layout which matches neither the OMAP2/3 PRCM layout nor the
OMAP4 PRCM layout.

To try to deal with this, introduce some new functions, omap4_cminst*
and omap4_prminst*.  The former is to be used when writing to a CM
instance register (no matter what subsystem or hardware module it
exists in), and the latter, similarly, with PRM instance registers.
To determine which "PRCM partition" to write to, the functions take a
PRCM instance ID argument.  Subsequent patches add these partition IDs
to the OMAP4 powerdomain and clockdomain definitions.

As far as I can see, there's really no good way to handle these types
of register access inconsistencies.  This patch seemed like the least
bad approach.

Moving forward, the long-term goal is to remove all direct PRCM
register access from the PM code.  PRCM register access should go
through layers such as the powerdomain and clockdomain code that can
hide the details of how to interact with the specific hardware
variant.

While here, rename cm4xxx.c to cm44xx.c to match the naming convention
of the other OMAP4 PRCM files.

Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

The OMAP3 PRM module is in the WKUP powerdomain, which is always
powered when the chip is powered, so it shouldn't be necessary to save
and restore those PRM registers.  Remove the PRM register save/restore
code, which should save several microseconds during off-mode
entry/exit, since PRM register accesses are relatively slow.

While doing so, move the CM register save/restore code into
CM-specific code.  The CM module has been distinct from the PRM module
since 2430.

This patch includes some minor changes to pm34xx.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.

This process also requires the #includes in each of these files to be
changed to reference the new file name.  As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.

Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Static data should be declared in .c files, not .h files.  It should be
possible to #include .h files at any point without creating multiple
copies of the same data.

We converted the clock data to .c files some time ago.  This patch does
the same for the clockdomain data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Static data should be declared in .c files, not .h files.  It should be
possible to #include .h files at any point without creating multiple
copies of the same data.

We converted the clock data to .c files some time ago.  This patch does
the same for the powerdomain data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

powerdomains.h header today has only static definitions.  Adding any
function declarations into it and including it in multiple source file
is expected to cause issues.  Hence move all the static definitions
from powerdomains.h file into powerdomains_data.c file.

Also, create a new powerdomain section of the mach-omap2/Makefile, and
rearrange the prcm-common part of the Makefile, now that the
powerdomain code is in its own Makefile section.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: rearrange Makefile changes, tweaked commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Trivial cleanup and documentation changes on the hwmod code and data:

- add some hwmod documentation to indicate flags that should be moved
  outside the static hwmod data in a future patch

- remove some unused fields in the struct omap_hwmod_ocp_if and
  struct omap_hwmod structures
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Change the per-hwmod mutex to a spinlock.  (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.)  Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR.  The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.

This patch also effectively reverts commit
84824022 - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions.  Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.

Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block.  This
works for most IP blocks on the chip, but unfortunately not all.  For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block.  Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.

Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.

As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Paul Hunt <hunt@ti.com>
Cc: Stanley Liu <stanley_liu@ti.com>

Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ).  Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.

There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>

Some OMAP IP blocks, such as the watchdog timers, cannot be completely
shut down via the standard hwmod shutdown mechanism.  This patch
enables the hwmod data files to supply a pointer to a custom
pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
function pointer.  If the struct omap_hwmod_class.pre_shutdown
function pointer is non-null, the function will be executed before the
existing hwmod shutdown code runs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Split omap2_init_common_hw() into two functions.  The first,
omap2_init_common_infrastructure(), initializes the hwmod code and
data, the OMAP PM code, and the clock code and data.  The second,
omap2_init_common_devices(), handles any other early device
initialization that, for whatever reason, has not been or cannot be
moved to initcalls or early platform devices.

This patch is required for the hwmod postsetup patch, which allows
board files to change the state that hwmods should be placed into at
the conclusion of the hwmod _setup() function.  For example, for a
board whose creators wish to ensure watchdog coverage across the
entire kernel boot process, code to change the watchdog's postsetup
state will be added in the board-*.c file between the
omap2_init_common_infrastructure() and omap2_init_common_devices() function
calls.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.

The macros are now defined at a centralized place, for
easier maintenance.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Nishanth Menon<nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

No need to call this early from init_irq. Also recent changes
initialize GPIO now later, so calling gpio_request from init_irq
will make it fail.

While at it, also remove the unnecessary EXPORT_SYMBOL.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Convert DMA library into DMA platform driver and make use of
platform data provided by hwmod data base for OMAP2+ onwards.

For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.

Thanks to Tony Lindgren <tony@atomide.com> for fixing various
omap1 issues and testing the same on OSK5912 board.
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Implement errata handling to use flags instead of cpu_is_* and
cpu_class_* in the code.

The errata flags are initialized at init time and during runtime we are
using the errata variable (via the IS_DMA_ERRATA macro) to execute the
required errata workaround.

Reused errata handling patch from: Peter Ujfalusi
<peter.ujfalusi@nokia.com>
https://patchwork.kernel.org/patch/231191/

Changes to above patch:
1. Changes are done for converting all the existing errata work arounds
to use this feature.
2. Detailed description for each errata is added.
3. Fixed bug in SET_DMA_ERRATA macro
4. Bit shifting in macro definitions are replaced with BIT() macro
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Prepare DMA library to get converted into DMA driver using platform
device model and hwmod infrastucture(for omap2+, resource structures
for omap1)

The low level read/write macros are replaced with static inline
functions and register offsets are handled through static register
offset tables mapped through  enumeration constants.

These low level read/write functions along with static register offset
tables will be moved to respective mach-omap dma files in the later
patches of this series.

There are no functionality changes with these changes except change in
logic for handling 16bit registers of OMAP1.
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The convention for omap device naming is omap_XXX.

Rename the device and driver name in order to stick
to this naming convention.

Change device name in clock nodes as well.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ben Dooks <ben-i2c@fluff.org>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The naming convention for omap_device is omap_XXX.

Rename the device and driver name in order to stick
to this naming convention.
Remove the hs prefix that is implicit for every OMAP uarts.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NGovindraj Raja <govindraj.raja@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit f2ce6231 (OMAP: WDT: Split OMAP1 and OMAP2PLUS device
registration) removed omap_init_wdt and related structures from
plat-omap/devices.c. However a subsequent commit or merge
seems to have reintroduced these by accident. The caller of
omap_init_wdt was also removed by that commit, and this did
not get restored. So we have the following build warning now:

  CC      arch/arm/plat-omap/devices.o
arch/arm/plat-omap/devices.c:252: warning: 'omap_init_wdt' defined but not used

Fix this by removing this dead code.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add minimal support for Nokia RM-680 board.

Tested with omap2plus_defconfig.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
[tony@atomide.com: updated to remove omap_gpio_init
Signed-off-by: NTony Lindgren <tony@atomide.com>

It seems dsp-link will do this, and tidspbridge too at some point, but
right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU.

Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Yogesh Marathe <yogesh_marathe@ti.com>
Signed-off-by: NFelipe Contreras <felipe.contreras@nokia.com>

Some IOMMUs cannot use the whole 0x0 - 0xFFFFFFFF range.
With this new API the valid range can be set.
Signed-off-by: NFernando Guzman Lugo <x0095840@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>

__iounmap function is wrong for OMAP architecture,
instead use iounmap which will call to the correct function.
Signed-off-by: NFernando Guzman Lugo <x0095840@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>

This patch adds superpages support to fixed ad address
inside iommu_kmap function.
Signed-off-by: NFernando Guzman Lugo <x0095840@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>

If some fixed da address is wanted to be mapped and the page
is freed but it is used as gap, the mapping will fail.
This patch is fixing that and olny keeps the gap for
not fixed address.
Signed-off-by: NFernando Guzman Lugo <x0095840@ti.com>
Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>

Otherwise multi-omap1 support for omap1 won't work as the cpu_class_is_omap1()
won't work until the SoC is detected.

Note that eventually these will go away, please use ioremap + read/write instead.
Signed-off-by: NTony Lindgren <tony@atomide.com>