A single character (line break) should be put into a sequence at the end.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The function is empty, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For OMAP4, volt_data is set in omap44xx_voltagedomains_init.
If the SoC is neither OMAP443X or OMAP446X, we end up with a
NULL in volt_data which causes a kernel oops.
This is the case when booting OMAP4470.
Signed-off-by: NNicolae Rosia <Nicolae_Rosia@mentor.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In the case where has_uart4 is false, en_uart4_mask and grpsel_uart4_mask
are not initialized and so any garbage value is being logically or'd into
the write of PM_WKEN and OMAP3430_PM_MPUGRPSEL.  Fix this by initializing
these masks to zero.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM437x makes use of the omap_l3_noc driver so explicitly select
OMAP_INTERCONNECT in the Kconfig for SOC_AM43XX to ensure it gets enabled
for AM43XX only builds.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the printk cleanups merged into v4.9-rc1, we now get the omap
revision printed on multiple lines. Let's fix that and also remove the
extra empty space at the end of the features. And let's update things
to use scnprintf as suggested by Ivaylo Dimitrov
<ivo.g.dimitrov.75@gmail.com>.
Reported-by: NAdam Ford <aford173@gmail.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Reviewed-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

commit d47529b2
"gpio: don't include module.h in shared driver header"
removed <linux/module.h> from the <linux/gpio/driver.h> header.

It seems arch/arm/mach-omap2/board-rx51-peripherals.c
is using __initdata_or_module from <linux/module.h> through
<linux/gpio.h> to <linux/gpio/driver.h>, so break this dependency
so that we get a clean compile.

Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Tony Lindgren <tony@atomide.com>
Fixes: d47529b2 ("gpio: don't include module.h in shared driver header")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Install the callbacks via the state machine.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: rt@linutronix.de
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/20160906170457.32393-4-bigeasy@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.

Using the macro makes the code more readable by helping abstract away some
of the Kconfig built-in and module enable details.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Below call chain causes system crash when OMAP device is
removed by calling of_platform_depopulate()/device_del():

device_del()
- blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
 			     BUS_NOTIFY_DEL_DEVICE, dev);
  - _omap_device_notifier_call()
    - omap_device_delete()
      - od->pdev->archdata.od = NULL;
	kfree(od->hwmods);
	kfree(od);
  - bus_remove_device()
    - device_release_driver()
      - __device_release_driver()
	- pm_runtime_get_sync()
	   - _od_runtime_resume()
	     - omap_hwmod_enable() <- OOPS od's delted already

Backtrace:
Unable to handle kernel NULL pointer dereference at virtual address 0000000d
pgd = eb100000
[0000000d] *pgd=ad6e1831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty #68
Hardware name: Generic DRA74X (Flattened Device Tree)
task: eb1ee800 ti: ec962000 task.ti: ec962000
PC is at omap_device_enable+0x10/0x90
LR is at _od_runtime_resume+0x10/0x24
[...]
[<c00299dc>] (omap_device_enable) from [<c0029a6c>] (_od_runtime_resume+0x10/0x24)
[<c0029a6c>] (_od_runtime_resume) from [<c04ad404>] (__rpm_callback+0x20/0x34)
[<c04ad404>] (__rpm_callback) from [<c04ad438>] (rpm_callback+0x20/0x80)
[<c04ad438>] (rpm_callback) from [<c04aee28>] (rpm_resume+0x48c/0x964)
[<c04aee28>] (rpm_resume) from [<c04af360>] (__pm_runtime_resume+0x60/0x88)
[<c04af360>] (__pm_runtime_resume) from [<c04a4974>] (__device_release_driver+0x30/0x100)
[<c04a4974>] (__device_release_driver) from [<c04a4a60>] (device_release_driver+0x1c/0x28)
[<c04a4a60>] (device_release_driver) from [<c04a38c0>] (bus_remove_device+0xec/0x144)
[<c04a38c0>] (bus_remove_device) from [<c04a0764>] (device_del+0x10c/0x210)
[<c04a0764>] (device_del) from [<c04a67b0>] (platform_device_del+0x18/0x84)
[<c04a67b0>] (platform_device_del) from [<c04a6828>] (platform_device_unregister+0xc/0x20)
[<c04a6828>] (platform_device_unregister) from [<c05adcfc>] (of_platform_device_destroy+0x8c/0x90)
[<c05adcfc>] (of_platform_device_destroy) from [<c04a02f0>] (device_for_each_child+0x4c/0x78)
[<c04a02f0>] (device_for_each_child) from [<c05adc5c>] (of_platform_depopulate+0x30/0x44)
[<c05adc5c>] (of_platform_depopulate) from [<bf123920>] (cpsw_remove+0x68/0xf4 [ti_cpsw])
[<bf123920>] (cpsw_remove [ti_cpsw]) from [<c04a68d8>] (platform_drv_remove+0x24/0x3c)
[<c04a68d8>] (platform_drv_remove) from [<c04a49c8>] (__device_release_driver+0x84/0x100)
[<c04a49c8>] (__device_release_driver) from [<c04a4b20>] (driver_detach+0xac/0xb0)
[<c04a4b20>] (driver_detach) from [<c04a3be8>] (bus_remove_driver+0x60/0xd4)
[<c04a3be8>] (bus_remove_driver) from [<c00d9870>] (SyS_delete_module+0x184/0x20c)
[<c00d9870>] (SyS_delete_module) from [<c0010540>] (ret_fast_syscall+0x0/0x1c)
Code: e3500000 e92d4070 1590630c 01a06000 (e5d6300d)

Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device
deletion which is sent when DD has finished processing of device
deletion.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now that we have moved the check for valid clkctrl_offs to the caller of
am33xx_cm_wait_module_ready/idle and omap4_cminst_wait_module_ready/idle
let's remove the now redundant check for clkctrl_offs from these functions.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Previously the low-level CM call internal to the
_omap4_wait_target_ready/disable calls was responsible for checking for
a valid clkctrl_offs. Now we must also consider the value of the
prcm.omap4.flags because if HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET is set in
the flags then clkctrl_offs of 0 is valid.

Let's add this check into the _omap4_wait_target_ready/disable where we
have access to both the clkctrl_offs and the flags values and simply
return 0 without calling the low level CM call at all, which would have
returned 0 anyway if the clktrl_offs was zero.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The RTC hwmod on AM335x family of SoCs is unique in that the
clkctrl_offs in the PRCM is 0. We rely on a clkctrl_offs of zero as
indicating no clkctrl is present so we must flag this hwmod with
HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET to indicate the 0 clkctrl_offs is in
fact valid in this case.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Nearly all modules on OMAP4 and newer platforms have clkctrl offsets
that are non-zero except for the RTC on am335x. Because we rely on a
clkctrl_offset of zero to indicate no clkctrl_offset being present,
lets add a HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET flag to use to indicate
hwmods that have a valid clkctrl_offset of 0.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's drop the last two remaining omap3 legacy boot board files.
Let's only use the device tree based booting known to work for
these two boards.

We still have two omap3 boards booting in legacy mode in addition
to device tree based booting. All the other ten or so omap2+ SoCs
have been booting using device tree mode only for years now. This
has allowed us to get rid of quite a bit of arch/arm/mach-omap2
related platform init code in favor of dts and driver changes.

Pretty much the only remaining known users for omap3 legacy boot
board files are Kevin's and Russell's boot test systems, and N900
kernel tree maintained by Pali and Ivaylo. And all of them are
also supporting the device tree based booting. The legacy booting
mode has been kept around mostly to verify against regressions.

As there is still a slim chance of possible other uses of the
mainline kernel for these boards, let's just drop the board
files for v4.8, and let's not touch the related platform init
code until around v4.9 time if no issues are found. This makes
it trivial for us to add back the board files with a simple revert.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's drop the last two remaining omap3 legacy boot board files.
Let's only use the device tree based booting known to work for
these two boards.

We still have two omap3 boards booting in legacy mode in addition
to device tree based booting. All the other ten or so omap2+ SoCs
have been booting using device tree mode only for years now. This
has allowed us to get rid of quite a bit of arch/arm/mach-omap2
related platform init code in favor of dts and driver changes.

Pretty much the only remaining known users for omap3 legacy boot
board files are Kevin's and Russell's boot test systems, and N900
kernel tree maintained by Pali and Ivaylo. And all of them are
also supporting the device tree based booting. The legacy booting
mode has been kept around mostly to verify against regressions.

As there is still a slim chance of possible other uses of the
mainline kernel for these boards, let's just drop the board
files for v4.8, and let's not touch the related platform init
code until around v4.9 time if no issues are found. This makes
it trivial for us to add back the board files with a simple revert.
Acked-By: NSebastian Reichel <sre@kernel.org>
Acked-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If the module has no clkctrl register defined, module_wait_ready should
not try to access this. This can potentially cause an illegal register
access, and result in bad idle reporting also.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The previous implementation was racy in many locations, where the current
status of the clockdomain was read out, some operations were executed,
and the previous status info was used afterwards to decide next state
for the clockdomain. Instead, fix the implementation of the allow_idle /
deny_idle APIs to properly have usecounting support. This allows clean
handling internally within the clockdomain core, and simplifies the
usage also within hwmod.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the introduction of hwmod module clocks, the name of the hwmod
main clk may not be available before hwmod setup, as hwmod setup
may lookup the main clock dynamically based on the hwmod name.
Thus, change the order of hwmod setup and main clock handling for
the timer code, to make sure the main clock is going to be
available.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the transition to hwmod module clocks, all hwmods will have
their main clocks named <hwmod_name>_mod_ck. Use this info to
fetch main_clk, and use it if found.

Also, if a main_clk is found based on the hwmod name, disable
the direct PRCM modulemode access from hwmod.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This avoids the need to add most of the clock aliases under
drivers/clk/ti/clk-xyz.c files.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

I found one more make randconfig build error with the recent
SMP kexec changes. We need the mpuss now always available early.

Fixes: 0573b957 ("ARM: OMAP4+: Prevent CPU1 related hang
with kexec")
Signed-off-by: NTony Lindgren <tony@atomide.com>

Drop dmtimer usage for pulse timer in favor of hrtimer. That allows
removing PWM dmitimer platform data usage.
Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the upcoming removal of legacy boot, lets add support to one of the
last N900 drivers remaining without it. As the driver still uses omap
dmtimer, add auxdata as well.
Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Convert driver to use PWM framework instead of calling dmtimer functions
directly for PWM timer. Remove paragraph about writing to the Free Software
Foundation's mailing address while at it.
Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Looks like I only partially fixed up things if CONFIG_SMP
is not set for the recent kexec changes. We don't have
boot_secondary available without SMP as reported by Arnd.

Fixes: 0573b957 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Kexec needs omap4_cpu_kill, otherwise kexec will produce on SMP:

kexec_load failed: Invalid argument
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to reset CPU1 properly for kexec when booting different
kernel versions. Otherwise CPU1 will attempt to boot the the
previous kernel's start_secondary(). Note that the restctrl
register is different from the low-power mode wakeup register
CPU1_WAKEUP_NS_PA_ADDR. We need to configure both.

Let's fix the issue by defining SoC specific data to initialize
things in a more generic way. And let's also standardize omap-smp.c
to use soc_is instead of cpu_is while at it.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Kexec booted kernels on omap4 will hang early during the boot if the
booted kernel is different version from the previous kernel.

This is because the previous kernel may have configured low-power mode
using CPU1_WAKEUP_NS_PA_ADDR. In that case it points to the previous
kernel's omap4_secondary_startup(), and CPU1 can be in low power mode
from the previous kernel. When the new kernel configures the CPU1
clockdomain, CPU1 can wake from low power state prematurely during
omap44xx_clockdomains_init() running random code.

Let's fix the issue by configuring CPU1_WAKEUP_NS_PA_ADDR before we
call omap44xx_clockdomains_init(). Note that this is very early during
the init, and we will do proper CPU1 reset during SMP init a bit later
on in omap4_smp_prepare_cpus(). And we need to do this when SMP is
not enabled as the previous kernel may have had it enabled.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Prepare things for making kexec work on SMP omap variants by initializing
SARM RAM base early. This allows us to configure CPU1 for kexec in case
the previous kernel has put CPU1 in low power mode.

Note that this should not prevent moving other SAR RAM code to live
under drivers. However for kexec, we will need this very early.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As per the TRM: http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf
offset 0x4 is reserved for PRM_PER. Hence removing the wrongly
defined address offset.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The ti81xx_rtc_hwmod is not exported, or declared outside the file
arch/arm/mach-omap2/omap_hwmod_81xx_data.c so make it static to
avoid the following warning:

arch/arm/mach-omap2/omap_hwmod_81xx_data.c:246:19: warning: symbol 'ti81xx_rtc_hwmod' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of
am43xx. Fix the RSTST register offset value.

This can lead to setting of wrong power state values for PER domain.

Fixes: 1c7e224d ("ARM: OMAP2+: hwmod: AM335x: runtime register update")
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

A few platforms are currently missing clocksource_probe() completely
in their time_init functionality. On OMAP3430 for example, this is
causing cpuidle to be pretty much dead, as the counter32k is not
going to be registered and instead a gptimer is used as a clocksource.
This will tick in periodic mode, preventing any deeper idle states.

While here, also drop one unnecessary check for populated DT before
existing clocksource_probe() call.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), with the exception of MPU power domain, all
other power domains do not have memories capable of retention since
they all operate in either "ON" or "OFF" mode. For these power states,
the retention state for memories are basically ignored by PRCM and does
not require to be programmed.

[1] http://www.ti.com/lit/pdf/spruhz6Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), with the exception of MPU power domain (and
CPUx sub power domains), all other power domains can either operate
in "ON" mode OR in some cases, "OFF" mode. For these power states,
the logic retention state is basically ignored by PRCM and does not
require to be programmed.

[1] http://www.ti.com/lit/pdf/spruhz6Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), L4Per and L3init power domains now operate in
always "ON" mode due to asymmetric aging limitations. Update the same

[1] http://www.ti.com/lit/pdf/spruhz6Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The addresses for DSS are provided in the DT data, so they can be
removed from the hwmod.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

QSPI address space information is passed from device tree. Therefore
remove legacy way of passing address space via hwmod data.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>