Fix disabling printk's build error.

Disabling printk's via CONFIG_PRINTK in the menuconfig gives the build error:

arch/arm/common/built-in.o: In function `end_syslog_dump':
~/a-3.0/arch/arm/common/fiq_debugger.c:524: undefined reference to `log_buf_copy'
arch/arm/common/built-in.o: In function `begin_syslog_dump':
~/a-3.0/arch/arm/common/fiq_debugger.c:514: undefined reference to `do_syslog'
arch/arm/common/built-in.o: In function `dump_kernel_log':
~/a-3.0/arch/arm/common/fiq_debugger.c:208: undefined reference to `log_buf_copy'
make: *** [.tmp_vmlinux1] Error 1

This was tested on both the 4AI.1.2 and 4AI.1.3 releases with the same result.

Change-Id: I432408bdd4ee07a261d11ca6710a56164512438b
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
Signed-off-by: x0182794 <volodymyr.mieshkov@ti.com>
ARM: omap2: fiq_debugger: ifdef local_timer_irqs in dump_irqs()

The local_timer_irqs field is surrounded by #ifdef
CONFIG_LOCAL_TIMERS in the irq_cpustat_t structure.  Do the same
for its usage in dump_irqs() so fiq_debugger can compile on
non-SMP systems.

Change-Id: Ie212d39b8c705f6815e00d86569bdb92b0c1e4c1
Signed-off-by: Scott Anderson <saa@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
MMC: Make sure PBIAS config matches VMMC supply.

Depending on the system, VMMC may end up being 3 or 1.8v.  It is
important that the PBIAS cell be configured to match the supply.
Fortunately, the PBIAS cell contains a handy detector which can
determine what the supply is set to after PWRDNZ has been released.
Use this detector to make sure that the cell is properly configured
and does not damage itself.

Change-Id: Id59ab8e4042efe0778a80f1476bcf8aa746e6cd6
Signed-off-by: John Grossman <johngro@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
usb: omap4: add HSIC support

The OMAP4 HS USB host subsystem supports the configurations
with two HSIC interfaces. This patch adds the ability
to use both of them

Change-Id: I95478563e07bba6811fed56abe442e640ccd71e4
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
omap: hwmod: enable clocks before deasserting hardreset

The enable code currently deasserts the hard-reset before
turning on the clocks. These kind of reset lines are limited
only to processor-device like IPs such as DSP or IPU or
IVA, which actually need the clock to be enabled first.

The code that deasserts the hard-reset has therefore been
relocated to execute after the clocks are enabled, to avoid
the hard-deassert traces (failed to hard reset).

Change-Id: Id9c413b315c927295cf4be7f986f6e1a710b9ef8
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>
omap:musb:PHY powering time change to longer

This patch helps to avoid problems in coldboot stage with some
selfpowered hubs, like old belkin. Problem looks like this:

[ 1019.749084] usb 2-1: reset high speed USB device number 107 using musb-hdrc
[ 1034.881805] usb 2-1: device descriptor read/64, error -110
[ 1040.115386] usb 2-1: device descriptor read/64, error -19
[ 1043.303710] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1046.389648] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1049.475555] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1049.483459] usb 2-1: USB disconnect, device number 107
[ 1052.569366] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1055.655242] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

At boot time DEVCTL register occasionaly change it's state from
IRQ host to IRQ device but musb->xceiv->state is still host what cause messages.
Problem caused transient processes caused powering after enabling clocks.

Powering on the phy need more time after enabling the internal phy clocks.
It was done because 300ms give us possibility to avoid problems caused transient
processes after powering that was found in the experimental practice
with a larger number of selfpowered hubs.

Also it should make work with chain of two selfpowered hubs more stable.

Change-Id: Ib0add65ab2be6fc2f0123538fb0b6447fa140f8b
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Andrii Danylov <x0158318@ti.com>
OMAP3+: PM: DVFS: Scale dependent domains to existing OPP

Currently dependent domain is scaled to:
 - dependent voltage that is got from voltage dependency table.
 - frequency that is got from OPP found for dependent voltage.

OPP for dependent voltage is found by _volt_to_opp() function
which looks for OPP with equal or _greater_ voltage.
So if there is no OPP with exact voltage (or this OPP is disabled),
then frequency from OPP with higher voltage will be used.

As a result device will run at not supported combination of frequency and voltage.
This may lead to instabilities.

This patch scales dependent domain to a correct voltage-frequency tuple,
by using both frequency and voltage from the matched OPP.

Change-Id: Ieb14be32ce2f6f2971ca0530dd077bb445a7e2f7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4: SAR: Store OMAP revision on SAR

OMAP revision is a useful piece of info to have available in SAR.
At the moment it is required for POR restore on GP devices while
coming out of OFF state. POR service was added to 4430GP ROM in ES2.2
and is not available before that.

Change-Id: I7cd6a1c45d9cbe5dedd4cef39aaee88a55b117c3
Signed-off-by: Vimarsh Zutshi <vimarsh.zutshi@ti.com>
omap4: hwmod_data: add clocks to dsp processor device

The dsp processor hwmod device (dsp_c0) is defined primarily as
a pseudo-hwmod device with only reset control. This shares the
same functional clock along with the dsp hwmod device that is
mainly used for controlling the MMU. This clock name is added to
this pseudo-hwmod device, as it enables the power domain lookup.
This is required to be able to put any latency constraints on
the dsp using the omap_pm_set_max_dev_wakeup_lat api.

There is no major effect on the clock framework itself due to
this change, as the clock enable & disable will simply be
reference counted and the functionality would be identical as
before.

Change-Id: I83d055806a62c583d914ead2b93371413d0b26a9
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAP4430: USB Host: Implement workaround for Errata i719

The OMAP4 EHCI controller has the following defect (errata ID i719):

Title:
	HS USB: Multiple OFF Mode Transitions Introduce Corruption

Description:
	When the system enters off mode, the save-and-restore (SAR)
        process comes into play. When the save of the USB context
	occurs, an extra pulse of UTMI_root clock coming from USB
	DPLL is entering the IP, and generates a minor corruption.
	This corrupted context is saved and restored later.
	This corruption will impact the next use of the USB module:
	it could be while resuming a suspended device, or it could
	be upon the enumeration of a new device. The exact failure
	is not predictable: disconnection or stalls have been observed.
	TLL and external PHY modes are impacted.

WORKAROUND:
	During ON time, anytime before starting the next save sequence:
	• Set the CM_L3INIT_HSUSBHOST_CLKCTRL[1:0] MODULEMODE bit field
	  to 0x2 (enabled).
	• Wait 1 ms.
	• Set the same bit field back to 0x0 (disabled).

All OMAP4430 devices are impacted.

Change-Id: I63c866504ae3899c73755e6f6b00d388205c20bd
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP: dmtimer: Fix timer handling logic for non loses_context timers

The use of the enabled flag is currently tightly coupled with the
loses_context flag on the timer struct. This change makes the enabled
flag behave more sanely without consideration of the loses_context flag.

Change-Id: I9d33bb4cc3fd7917ad493adde75cf57cb240b106
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
OMAP4: PRM: improve cold reset logic

Cold reset logic currently could return back and invoke the
'BUG()' call which was supposed to be triggered if coldreset
was'nt functioning, even though the cold reset is eventually
triggered in h/w this gives a misconception that the cold
reset was'nt really functioning.

In OMAP4, the reset logic could take close to 100uSec before
the cold reset is percolated down from PRCM. Unfortunately,
we dont seem to have a status bit to check exactly when the
PRCM decides to send out cold reset signal to rest of h/w.

The delay is pretty much long enough for kernel messages to
be populated with the 'BUG()' call from pm44xx.c.

Further, it is mandatory that Power On reset bit is cleared
by s/w before cold reset is invoked. This is currently being
done by bootloader/PPA.

Change-Id: I886c420b6532e594b67da6a12122cac785ed6df6
Signed-off-by: Nishanth Menon <nm@ti.com>
omap: ramconsole: set ramconsole start address as 256MB

Currently RAM console start address is set as 512MB which
is not applicable to system with 512MB RAM. To make it
generic across OMAP platforms, make it 256MB

Change-Id: Ib29c70735ef793b3f7877c873f0e2d14857f6b9a
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
OMAP4: ERRATA: ARM: Fix ARM Errata 742230

Errata 742230: This Errata workaround requires bit 4 to be set in the CP15
diagnostic control register. This patch takes care of this errata fix for GP
devices at CPU init time and at the cpu_resume stage.

Change-Id: I5244bec9544fddc9fff33ca2903f5ec19bcc52a7
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>

Conflicts:
	arch/arm/mach-omap2/Kconfig
OMAP4: ERRATA: ARM: Fix ARM Errata 751472

Errata 751472: This Errata workaround requires bit 11 to be set in the CP15
diagnostic control register. This patch takes care of this errata fix for GP
devices at CPU init time and at the cpu_resume stage.

Change-Id: I3a8d2b825ac59719233275a77c5fbf5175b35bcb
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
OMAP4: ERRATA: ARM: Fix ARM Errata 743622

Errata 743622: This Errata workaround requires bit 6 to be set in the CP15
diagnostic control register. This patch takes care of this errata fix for GP
devices at CPU init time and at the cpu_resume stage.

Change-Id: I6b9cf510ca631f74da4ce2f31c1190a2216aa5bb
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>