There's no longer any need for the board specific
map_io.
Signed-off-by: NTony Lindgren <tony@atomide.com>

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>

Register access can be made more generic by calculating register address
offsets runtime from common register definitions and by using reg_size and
reg_step variables that are passed via platform data. Common register
definitions are possible since McBSP registers are ordered similarly between
OMAP versions.

Remove also references to OMAP2+ specific config_type variable from generic
McBSP code since other variables and feature flags are better to carry needed
information from platform 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>

Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod
conversion so it can be moved to mach-omap1/mcbsp.c.
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 variables got unused after McBSP was converted to use resource
structures.
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>

Add omap_device pointer to the ARM-specific arch data in the
platform_device.  This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit f41caddb (omap2+: Use
Kconfig symbol in Makefile instead of obj-y) cleaned up the
omap2+ Makefile. However this did not account for the inline
functions that are now needed for board_flash_init and
board_nand_init.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

During the idle/suspend path, we expect the console lock to be held so
that no console output is done during/after the UARTs are idled.

However, when using the no_console_suspend argument on the
command-line, the console driver does not take the console lock.  This
allows the possibility of console activity after UARTs have been
disabled.

To fix, update the current is_suspending() to also check the
console_suspend_enabled flag.
Reported-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.

Use the arch-specific data field of the platform_device (pdev_archdata)
to add an omap_device pointer after the platform_device has been created.
Signed-off-by: NKevin Hilman <khilman@ti.com>

Public omap_device functions need to take platform_device pointers,
conversion to omap_device pointers is done internal to the omap_device
layer.
Signed-off-by: NKevin Hilman <khilman@ti.com>

The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: NKevin Hilman <khilman@ti.com>

All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: NKevin Hilman <khilman@ti.com>

During normal system operation warning messages similar to this
are appearing quite often:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035

This doesn't seem to be reporting a problem, nor is it very useful for
non-developers, so reduce it to debug level.
Acked-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name().  Using the dev_*
versions uses the standard device naming from the driver core.

Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

struct omap_device *od is only set with find_omap_device_by_dev but not used
otherwise so remove them and references to omap device API.
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>

Now that all of the users of the OMAP_CHIP bitfield code have been converted
to use lists, the OMAP_CHIP code, data, and declarations can be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.

Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions.  Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.

Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a
related patch that also applied to this patch - thanks Gražvydas.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions.  This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are specific to a single SoC.

The appropriate order to call these functions - which is enforced
by the code - is:

1. pwrdm_register_platform_funcs()
2. pwrdm_register_pwrdms() (can be called multiple times)
3. pwrdm_complete_init()

Convert the OMAP2, 3, and 4 powerdomain init code to use these new
functions.

While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At Tony's request, remove the omap_chip bitmasks from the clockdomain
and clockdomain dependency definitions.  Instead, initialize
clockdomains based on one or more lists that are applicable to a
particular SoC family, variant, and silicon revision.

Tony Lindgren <tony@atomide.com> found a bug in a previous version of this
patch - thanks Tony.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions.  This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are specific to a single SoC.

The appropriate order to call these functions - which is enforced
by the code - is:

1. clkdm_register_platform_funcs()
2. clkdm_register_clkdms() (can be called multiple times)
3. clkdm_register_autodeps() (optional; deprecated)
4. clkdm_complete_init()

Convert the OMAP2, 3, and 4 clockdomain init code to use these new
functions.

While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.

Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>