Let's make it clear that some features need to be tested currently on
omap1. Only omap1 still uses platform_data.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-9-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

There is no longer any need to expose the elements of struct omap_dm_timer
outside the driver. The pwm and remoteproc drivers just use struct
omap_dm_timer as a cookie.

Let's move the elements of struct omap_dm_timer into struct dmtimer that
is private to the driver. To do this, we mostly rename omap_dm_timer to
dmtimer in the driver. We keep omap_dm_timer only for the exposed
functions in the platform_data for the pwm and remoteproc drivers.

Let's also add a note about not using the exposed functions internally as
those will get deprecated eventually in favor of Linux generic frameworks.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-8-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Use pm_runtime_resume_and_get() and check for a possible error returned.

We want to do this as omap_dm_timer_enable() and omap_dm_timer_disable()
are exposed to the pwm and remoteproc drivers, and in the following patch
we turn struct omap_dm_timer into a cookie used by the exposed functions
only.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-7-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

These defines are only used by timer-ti-dm driver.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-6-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Let's unify register access and use dmtimer_read() and dmtimer_write()
also for the timer revision specific registers like we now do for the
shread registers.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-5-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

We can simplify register write access by checking for the register write
posted mode in the write function. This way we can combine the functions
for __omap_dm_timer_write() and omap_dm_timer_write_reg() into a single
function dmtimer_write().

We update the shared register access first, the timer revision specific
register access will be updated in a later patch.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-4-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

We can simplify register read access by checking for the register write
posted mode in the read function. This way we can combine the functions
for __omap_dm_timer_read() and omap_dm_timer_read_reg() into a single
function dmtimer_read().

We update the shared register access first, the timer revision specific
register access will be updated in a later patch.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-3-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

We still have some unused functions left, let's drop them.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220815131250.34603-2-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Add compatible for ti,am654-timer to support the timers. For example, am654
has four timers in the MCU domain and 12 timers in the MAIN domain.

Cc: Keerthy <j-keerthy@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220408101715.43697-4-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The __omap_dm_timer_* inline functions in the header are no longer needed
outside the driver, and the header ifdefs prevent the driver working for
ARCH_K3.

Let's move the inline functions to the driver and drop the ifdefs and
drop the unused functions __omap_dm_timer_override_errata() and
__omap_dm_timer_load_start().

Cc: Keerthy <j-keerthy@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220408101715.43697-2-tony@atomide.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The "pdata" pointer cannot be NULL because it's checked at the start of
the function.  Delete the check.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YoZM65RFDQAfqV6J@kiliSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

As a preparation for future omap1 multiplatform support, stop
using mach/hardware.h and instead include the omap1-io.h
for low-level register access to MOD_CONF_CTRL_1.
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The device is not losing context on CPU_CLUSTER_PM_ERROR. As we are only
saving and restoring context with cpu_pm, there is no need to restore the
context in case of an error.

Note that the unnecessary restoring of context does not cause issues, it's
just not needed.

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210518075306.35532-1-tony@atomide.com

As we are using cpu_pm to save and restore context, we must also save and
restore the timer sysconfig register TIOCP_CFG. This is needed because
we are not calling PM runtime functions at all with cpu_pm.

Fixes: b34677b0 ("clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore")
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Adam Ford <aford173@gmail.com>
Cc: Andreas Kemnade <andreas@kemnade.info>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210415085506.56828-1-tony@atomide.com

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200708165856.15322-1-grandmaster@al2klimov.de

omap_dm_timer_prepare() is setting up the parent 32KHz clock. This
prepare() gets called by request_timer in the client's driver. Because of
this, the timer clock parent that is set with assigned-clock-parent is being
overwritten. So drop this default setting of parent in prepare().
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NSuman Anna <s-anna@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200427172831.16546-1-lokeshvutla@ti.com

dm timer ops set_load() api allows to configure the load value and to
set the auto reload feature. But auto reload feature is independent of
load value and should be part of configuring pwm. This way pwm can be
disabled by disabling auto reload feature using set_pwm() so that the
current pwm cycle will be completed. Else pwm disabling causes the
cycle to be stopped abruptly.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-7-lokeshvutla@ti.com

omap_dm_timer_ops provide support to configure the pwm but there is no
support to get the current status. For configuring pwm it is advised to
check the current hw status instead of relying on pwm framework. So
implement a new timer ops to get the current status of pwm.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgen <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-6-lokeshvutla@ti.com

Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value
in Load register(OMAP_TIMER_LOAD_REG) into Counter register
(OMAP_TIMER_COUNTER_REG).

omap_dm_timer_set_load() writes into trigger register every time load
register is updated. When timer is configured in pwm mode, this causes
disruption in current pwm cycle, which is not expected especially when
pwm is used as PPS signal for synchronized PTP clocks. So do not write
into trigger register on updating the period.
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-5-lokeshvutla@ti.com

omap_dm_timer_enable() restores the entire context(including counter)
based on 2 conditions:
- If get_context_loss_count is populated and context is lost.
- If get_context_loss_count is not populated update unconditionally.

Case2 has a side effect of updating the counter register even though
context is not lost. When timer is configured in pwm mode, this is
causing undesired behaviour in the pwm period.

Instead of using get_context_loss_count call back, implement cpu_pm
notifier with context save and restore support. And delete the
get_context_loss_count callback all together.
Suggested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
[tony@atomide.com: removed pm_runtime calls from cpuidle calls]
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200316111453.15441-1-lokeshvutla@ti.com

Let's add runtime_suspend and resume functions and atomic enabled
flag. This way we can use these when converting to use cpuidle
for saving and restoring device context.

And we need to maintain the driver state in the driver as documented
in "9. Autosuspend, or automatically-delayed suspends" in the
Documentation/power/runtime_pm.rst document related to using driver
private lock and races with runtime_suspend().
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-3-lokeshvutla@ti.com

Use SPDX-License-Identifier instead of a verbose license text.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200305082715.15861-2-lokeshvutla@ti.com

The function omap_dm_timer_of_set_source() was originally added in
commit 31a7448f ("ARM: OMAP: dmtimer: Add clock source from DT"),
and is designed to set a clock source from DT using the clocks property
of a timer node. This design choice is okay for clk provider nodes but
otherwise is a bad design as typically the clocks property is used to
specify the functional clocks for a device, and not its parents.

The timer nodes now all define a timer functional clock after the
conversion to ti-sysc and the new clkctrl layout, and this results
in an attempt to set the same functional clock as its parent when a
consumer driver attempts to acquire any of these timers in the
omap_dm_timer_prepare() function. This was masked and worked around
in commit 983a5a43 ("clocksource: timer-ti-dm: Fix pwm dmtimer
usage of fck reparenting"). Fix all of this by simply dropping the
entire function.

Any DT configuration of clock sources should be achieved using
assigned-clocks and assigned-clock-parents properties provided
by the Common Clock Framework.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Tested-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200213053504.22638-1-s-anna@ti.com

Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value
in Load register(OMAP_TIMER_LOAD_REG) into Counter register
(OMAP_TIMER_COUNTER_REG).

omap_dm_timer_set_load() writes into trigger register every time load
register is updated. When timer is configured in pwm mode, this causes
disruption in current pwm cycle, which is not expected especially when
pwm is used as PPS signal for synchronized PTP clocks. So do not write
into trigger register on updating the period.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200224050753.17784-3-lokeshvutla@ti.com

Clean-up commit 8c82723414d5 ("clocksource/drivers/timer-ti-dm: Switch to
platform_get_irq") caused a regression where we now try to access
uninitialized data for timer:

drivers/clocksource/timer-ti-dm.c: In function 'omap_dm_timer_probe':
drivers/clocksource/timer-ti-dm.c:798:13: warning: 'timer' may be used
uninitialized in this function [-Wmaybe-uninitialized]

On boot we now get:

Unable to handle kernel NULL pointer dereference at virtual address
00000004
...
(omap_dm_timer_probe) from [<c061ac7c>] (platform_drv_probe+0x48/0x98)
(platform_drv_probe) from [<c0618c04>] (really_probe+0x1dc/0x348)
(really_probe) from [<c0618ef4>] (driver_probe_device+0x5c/0x160)

Let's fix the issue by moving platform_get_irq to happen after timer has
been allocated.

Fixes: bc83cadd ("clocksource/drivers/timer-ti-dm: Switch to platform_get_irq")
Cc: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Acked-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200106203700.21009-1-tony@atomide.com

platform_get_resource(pdev, IORESOURCE_IRQ) is not recommended for
requesting IRQ's resources, as they can be not ready yet. Using
platform_get_irq() instead is preferred for getting IRQ even if it
was not retrieved earlier.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191221173027.30716-5-tiny.windzz@gmail.com

Use devm_platform_ioremap_resource() to simplify code, which
wraps 'platform_get_resource' and 'devm_ioremap_resource' in a
single helper.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191221173027.30716-4-tiny.windzz@gmail.com

Variable 'dmtimer_ops' was declared const static instead of static const.

../drivers/clocksource/timer-ti-dm.c:899:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
 const static struct omap_dm_timer_ops dmtimer_ops = {
 ^~~~~
Signed-off-by: NPhilippe Mazenauer <philippe.mazenauer@outlook.de>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
successfully compiled because they are never built as a module by
anyone, i.e, the MODULE_ALIAS() calls are always no-op.

A problem showed up when a patch "moduleparam: Save information about
built-in modules in separate file" was applied. With this new feature,
MODULE_*() will be populated even if the callers are built-in.

To avoid the build errors, the lines referencing to the undefined
macro must be removed.

The complete fix is to remove all MODULE_* and #include <linux/module.h>
like many "make ... explicitly non-modular" commits did.

For now, I am touching only the offending lines.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

Commit 008258d9 ("clocksource/drivers/timer-ti-dm: Make
omap_dm_timer_set_load_start() static") made omap_dm_time_set_load_start
static because its prototype was not defined in a header. Unfortunately,
this causes a build warning on multi_v7_defconfig because this function
is not used anywhere in this translation unit:

drivers/clocksource/timer-ti-dm.c:589:12: error: unused function
'omap_dm_timer_set_load_start' [-Werror,-Wunused-function]

In fact, omap_dm_timer_set_load_start hasn't been used anywhere since
commit f190be7f ("staging: tidspbridge: remove driver") and the
prototype was removed in commit 592ea6bd ("clocksource: timer-ti-dm:
Make unexported functions static"), which is probably where this should
have happened.

Fixes: 592ea6bd ("clocksource: timer-ti-dm: Make unexported functions static")
Fixes: 008258d9 ("clocksource/drivers/timer-ti-dm: Make omap_dm_timer_set_load_start() static")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Fix sparse warning:

drivers/clocksource/timer-ti-dm.c:589:5: warning:
 symbol 'omap_dm_timer_set_load_start' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20190322144302.6704-1-yuehaibing@huawei.com

Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") started producing a warning for pwm-omap-dmtimer:

WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x2f8/0x388
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
Data Access in Supervisor mode during Functional access
...
__pm_runtime_idle
omap_dm_timer_disable
pwm_omap_dmtimer_start
pwm_omap_dmtimer_enable
pwm_apply_state
pwm_vibrator_start
pwm_vibrator_play_work

This is because the timer that pwm-omap-dmtimer is using is now being
probed with ti-sysc interconnect target module instead of omap_device
and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
compatible with what omap_device has been doing.

We could fix this by reverting the timer changes and have the timer
probe again with omap_device. Or we could add more quirk handling to
ti-sysc driver. But as these options don't work nicely as longer term
solutions, let's just make timers probe with ti-sysc without any
quirks.

To do this, all we need to do is remove quirks for timers for ti-sysc,
and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.

We should not use pm_runtime_irq_safe() anyways for drivers as it will
take a permanent use count on the parent device blocking the parent
devices from idling and has been forcing ti-sysc driver to use a
quirk flag.

Note that we will move the timer data to DEBUG section later on in
clean-up patches.

Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-By: NAndreas Kemnade <andreas@kemnade.info>
Tested-By: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") moved some omap4 timers to probe with ti-sysc
interconnect target module. Turns out this broke pwm-omap-dmtimer
where we now try to reparent the clock to itself with the following:

omap_dm_timer_of_set_source: failed to set parent

With ti-sysc, we can now configure the clock sources in the dts
with assigned-clocks and assigned-clock-parents. So we should be able
to remove omap_dm_timer_of_set_source with clean-up patches later on.
But for now, let's just fix it first by checking if parent and fck
are the same and bail out of so.

Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-By: NAndreas Kemnade <andreas@kemnade.info>
Tested-By: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This driver is no longer used as an early platform driver. Remove the
registration macro.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Invalid value silently disables use of the prescaler.
Use -1 explicitely for that purpose and error out on
invalid value.
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Reorder omap_dm_timer_set_source internals to get
source verification more straightforward.
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As dmtimer no longer exports functions, make those previously
exported static (this requires few functions to be moved around
as their prototypes were deleted).
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In the case of device tree boot the device platform data is usually
NULL so hook the platform data obtained from the match.
As part of un-constify the platform_data pointer.
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add the timer ops to the platform data
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move the dmtimer driver out of plat-omap to clocksource.
So that non-omap devices also could use this.

No Code changes done to the driver file only renamed to timer-ti-dm.c.
Also removed the config dependencies for OMAP_DM_TIMER.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
[tony@atomide.com: add select omap_dm_timer for omap16xx]
Signed-off-by: NTony Lindgren <tony@atomide.com>