fixes for power key from omap4
mfd: Move omap-usb-host usbhs init before allocing child dev

mfd: Move omap-usb-host usbhs init before allocing child dev

[backported from p-android-omap-3.4]

There could be possible race condition where the host dev's
are alloced and added to platform dev just before usbhs_init.
Just move usbhs_init before adding child dev.

Change-Id: I3c54db97f39c7714427e738560fba8076283e66d
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
omap: usb host: mux: force PHY STP line to low state in idle/off mode

omap: usb host: mux: force PHY STP line to low state in idle/off mode

[backported from p-android-omap-3.4]

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, we enable different clocks to the Host quite late
and its internal state machine may enter in some bad state.
Next patch http://review.omapzoom.org/32086 (OMAP: USB Host: Wake
up L3_init clockdomain ASAP on USB remote wakeup event)(1) fixed
this issue for OMAP4470 but it is not enough for 4430/4460
where restoring from OFF mode takes more time.

In this case next behavior has been observed on ULPI lines
for 4430/4460 (say initial OMAP's state is OFF mode):      (2)
 - a device connected to PHY issues remote wakeup
 - the PHY directly represents this state on D0:D1 lines
 - OMAP sees line state change and starts its 'resume from OFF'
   procedure
 - after ~100 uS after D0:D1 change, OMAP asserts STP line
 - PHY starts is internal resume procedure, deasserts DIR and
   starts to generate clocks to OMAP
 - after ~8ms OMAP deasserts STP line and puts the PHY to the
   low-power state immediately (sends 0x84-0x4A 0x84-0x4A 0x84-0x05
   sequence)
 - the OMAP restoring sequence is still in progress and is only on
   its start phase.

After above sequence the ULPI interface is not functional
anymore for OMAP - no matter PORTSC.FPR nor direct access
through INSNREG05_ULPI register you use.
The root cause seems to be related to i693 errata (USB HOST EHCI - Port
Resume Fails On Second Resume Iteration) that says we have to
switch ULPI_CLK to internal clocksource for short time after *each* PHY
suspend, otherwise internal EHCI counter will not reach
18 and second resume iteration will fail.
The reason of why it affects only 4430/4460 but not 4470 is because
after applying patch [1] 4470 restores from OFF mode fast enough
and so internal EHCI logic does not have a chance to
put the PHY in low power mode. Whereas for 4430/4460
the restore-from-OFF sequence is a little bit longer,
and we have PHY-resume and PHY-suspend [2], and after that
after end of restore-from-OFF we try to wakeup the PHY
again and meet the i693 condition.

The workaround here consists in keeping the STP line
in low state until the EHCI is ready to work with PHY.

For this, the patch uses some MUX magic, forcing the
STP to 'safe mode' and pulldown for idle or OFF state
and muxing it back to STP mode for active state.

This prevents wake-up-the-PHY in the middle of restoring from
off sequence and works fine on all OMAP4 SoCs.

Change-Id: I95d7bf707f76519ee7d81f4437d8564f03b5d602
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
cpufreq: Fix sysfs deadlock with concurrent hotplug/frequency switch

Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_setspeed node eventually deadlocks with:

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G        W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
 (s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4

but task is already holding lock:
 (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(s_active#13);
  lock(s_active#13);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by filemonkey/122:
 #0:  (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
 #1:  (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)

This is because store() in cpufreq.c indirectly calls
kobject_get() via cpufreq_cpu_get() and is the last one to call
kobject_put() via cpufreq_cpu_put(). Sysfs code should not call
kobject_get() or kobject_put() directly (see the comment around
sysfs_schedule_callback() for more information).

Fix this deadlock by introducing two new functions:

	struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
	void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)

which do the same thing as cpufreq_cpu_{get,put}() but don't call
kobject functions.

To easily trigger this deadlock you can insert an msleep() with a
reasonably large value right after the fail label at the bottom
of the store() function in cpufreq.c and then write
scaling_setspeed in one task and offline the cpu in another. The
first task will hang and be detected by the hung task detector.

Change-Id: I7db3608f43ef97d7eb1214598bc39946c82734ee
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
OMAP4: ST: Disabling UART if ldisc not installed.

OMAP4: ST: Disabling UART if ldisc not installed.

In cases when there is no line discipline to be installed UART chip must be
disabled.

Rationale: if ldisc is not installed so it can't be uninstalled.
Thus UART chip still enabled and we have wakelock for it
(see plat_uart_enable() function in both blaze and 44xx-tablet board files).
In that case we can't go in suspend mode.

Motivation: when using busybox ramdisk (e.g. for testing kernel w/o AFS) we
have no ldisc that causes impossibility to go to suspend mode.

Change-Id: I6fac0b9411ed765e8e598328b89a41a50b5fbfea
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>

Conflicts:
	drivers/misc/ti-st/st_kim.c