Convert the omap2plus platforms to be using CONFIG_MULTI_IRQ_HANDLER.
Each machine is modified to provide either omap2_intc_handle_irq(),
omap3_intc_handle_irq() or gic_handle_irq().

This allows for a major cleanup, removing the MULTI_OMAP setup
from the interrupt path.

Tested on both Panda and IGEPv2 (single kernel image)
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Provide the OMAP2/3 IRQ code with low level handlers that can be used
by platforms using CONFIG_MULTI_IRQ_HANDLER. Though the handlers are
written in C, the compiled code looks very similar to its assembly
counterpart (at least with my gcc 4.4.1).
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Include linux/export.h to fix below build warning:

  CC      arch/arm/plat-omap/omap_device.o
arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class
arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There is no use for omap-alsa.h and board-palmz71.c doesn't need it either.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.

Change the functions to return an int, with negative value meaning an
error.

OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated to fix a warning with recent dmtimer changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 4d17aeb1 ("OMAP: I2C: split
device registration and convert OMAP2+ to omap_device") makes
omap2_i2c_add_bus() return a pointer to an omap_device instead on
success instead of 0.

This breaks the omap_register_i2c_bus() ABI and results in the igep0020
board code detecting an I2C bus registration error when there is none.

Fix the problem by using PTR_RET() instead of PTR_ERR() in
omap2_i2c_add_bus().
Reported-by: NAlexander Kinzer <a.kinzer@plusoptix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
[tony@atomide.com: updated to return pdev instead of od]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Include linux/module.h to fix below build error:

  CC      arch/arm/plat-omap/dmtimer.o
arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:184: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:215: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:215: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:215: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:228: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:228: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:228: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:234: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:234: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:234: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:240: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:240: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:240: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:248: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:248: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:248: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:294: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:294: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:294: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:302: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:302: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:302: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:316: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:316: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:316: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:344: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:344: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:344: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:361: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:361: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:361: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:380: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:380: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:380: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:406: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:406: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:406: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:443: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:443: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:443: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:468: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:468: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:468: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:494: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:494: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:494: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:517: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:517: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:517: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:534: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:534: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:534: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:549: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:549: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:549: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:561: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:561: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:561: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:572: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:572: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:572: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:587: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:587: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:587: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:604: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:604: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:604: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:746: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:746: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:746: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
arch/arm/plat-omap/dmtimer.c:746: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:747: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:747: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:747: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
arch/arm/plat-omap/dmtimer.c:747: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:748: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:748: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:748: warning: type defaults to 'int' in declaration of 'MODULE_ALIAS'
arch/arm/plat-omap/dmtimer.c:748: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:749: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:749: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:749: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
arch/arm/plat-omap/dmtimer.c:749: warning: function declaration isn't a prototype
make[1]: *** [arch/arm/plat-omap/dmtimer.o] Error 1
make: *** [arch/arm/plat-omap] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These files will fail to compile if we dont clean them up in advance
and have them include the appropriate headers they need.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

These files all make use of one of the EXPORT_SYMBOL variants
or the THIS_MODULE macro.  So they will need <linux/export.h>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This allows removing omap hacks for map_io allowing generic
map_io.

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

Given that we want the default to not have any <mach/memory.h> and given
that there are now fewer cases where it is still provided than the cases
where it is not at this point, this makes sense to invert the logic and
just identify the exception cases.

The word "need" instead of "have" was chosen to construct the config
symbol so not to suggest that having a mach/memory.h file is actually
a feature that one should aim for.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.

Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517.  The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup.  To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed.  (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)

Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it.  This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:

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

Convert this test to a feature test with a chip-by-chip whitelist.

Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause.  Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.  Thanks to Russell King <linux@arm.linux.org.uk> for
comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.

For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver will not
work without that information.

Add a documentation to capture the specifics OMAP bindings needed for
device-tree support.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.

The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Remove all these duplicated structures since a default one is now
available.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.

Next patches will clean the duplicated structures.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like "gpu" instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Signed-off-by: NNishanth Menon <nm@ti.com>
[b-cousson@ti.com: Adapt it to the new pdev pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Support for IDE drivers should not be automatic, since most platforms
cannot actually support any IDE low-level drivers. This partly
reverts 2064c946 "ARM: always select HAVE_IDE" to set this symbol
only when either a PC-style bus (PCI, ISA, PCMCIA) is enabled or
a platform is used that is known to have an existing driver in
drivers/ide.

New platforms should not need this option and just use CONFIG_ATA
with drivers/ata/.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The omap_dm_timer_remove function gets discarded when
CONFIG_HOTPLUG is not set, so we must not reference it
unconditionally.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src
implementation between generic McBSP and OMAP2 specific McBSP code. These
functions are used to select source for CLKR and FSR signals on OMAP2+.

Start generalizing the code by implementing an optional mux_signal function
pointer in platform data that will implement the actual muxing and which is
called now from omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src.
These functions are to be removed later and cleanup the API so that
mux_signal gets its arguments directly from client code.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This generalizes the omap2_mcbsp_set_clks_src implementation between generic
McBSP and OMAP2 specific McBSP code. Currently this function is used to
select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+.

Implement generalization by having an optional set_clk_src function pointer
in platform data that is used to select parent for a given clock. Idea is to
pass higher level source clock name (later coming from client driver) that
platform specific code will map to platform specific clock name.

API cleanup between McBSP and client code comes later.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These address definitions are OMAP1 specific can be in single source file.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

hardware.h is not needed here and let the definition for struct clk to come
via linux/clk.h.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Sidetone resource is already registered for a device so there is no need
for cpu_is_omap34xx() and McBSP port number tests in the driver. We can
cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3
conditional compilations and then using sidetone resource and st_data
variable for runtime tests.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Active sidetone requires that McBSP interface clock doesn't idle and there
is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3
in OMAP34xx share their interface clock with McBSP sidetone module and
that interface clock must be active when the sidetone is operating.

Sidetone has its own autoidle bit which should keep the interface clock
active but it is broken. Putting the McBSP core to no-idle mode when the
sidetone is active is no good either since it results to higher power
consumption when using the threshold based DMA transfers.

For making the McBSP code more generic, move this sidetone clock management
with fixme comments to mach-omap2/mcbsp.c and pass pointer to it via
platform data.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Cc: Paul Wamsley <paul@pwsan.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Rationale here is to remove one global variable and to make possible to have
variable size McBSP register maps inside SoC.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test
around buffer threshold based transfer and DMA operating mode control. Use
instead the buffer_size in platform data to determine when these sysfs
controls are exposed and when to access related McBSP registers. Rationale
for this is to make code generic and to allow to use it on OMAP4 that also
supports threshold based transfers.

Currently buffer_size variable is set only for OMAP3 SoCs but it is easy
to extend to OMAP4 and any later OMAP version.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

McBSP transmit and receive configuration control registers must be set up
for OMAP2430 and later. Replace is_omap tests in generic code with a new
feature flag has_ccr in platform data so that there is no need to change
code for any upcoming OMAP version.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is
set even it should be available for CONFIG_ARCH_OMAP4 only builds also.

Fix this by making wakeup control generic so that it is executed whenever
new feature flag has_wakeup in platform data is set. Currently flag is set
for McBSP config types 3 and 4.

Remove also old comments about idle mode settings and HW bug workarounds
that were not updated during hwmod conversion.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>