OMAP4: EMIF: Added timings for 466MHz elpida lpddr2 memory

OMAP4470 support 466MHz DDR2 memory. This patch add timings from
datasheet for EDB8164B3PF.

Change-Id: Ief7520719a2d7ec3dc9c93a3ecbfcef7cf64507c
Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
OMAP4: EMIF: Add 4Gb memory Configuration data

Elpida EDB8164B3PF is going to be used on OMAP boards.
Unlike the previous memory this one has two pieces of 4Gb,
so a new configuration stucture should be added.

Change-Id: I98cf8fd2689c21ef7b076aceaf4ed6f7a1b6b0b1
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4470: Memory timings fix for LPDDR2 466 MHz

Fixed memory timings for LPDDR2 466MHz according to
hardware recommendations.

Change-Id: I07e821c8fafc1b559b61a443083fc9c1acddc87a
Signed-off-by: Mykola Oleksiienko <x0174904@ti.com>
OMAP4470 LPDDR interface configuration update for 466MHz

Some instability with OMAP4470 when running the DDR at 466MHz is
discovered. This instability is resolved with updated LPDDR settings:

- DLL delay should be set to 461ps:
  DDR_PHY_CTRL_1_SHDW[11:4] = 0x37

- Read latency should be set to 0xB:
  DDR_PHY_CTRL_1_SHDW[3:0] = 0xB

- Slew Rate should be set to “FASTEST” and Impedance Control to “Drv12”:
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_SR] = 0
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_I] = 7
  where x=[1-2]

Change-Id: Ifa47a7ccae437225db5838039e528c04250a911d
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
OMAP4: EMIF: code cleanup and clarification

Removed unused fields of emif_regs structure and
functions that initialize or change them.

Also changed few names of emif_regs members
to match register names.

This made the code easier to understand and read
as well as made it a little bit faster

Change-Id: I0485a01b7f03e922b5a2e69bfb03c2ed941fcf3b
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>

Conflicts:
	arch/arm/mach-omap2/emif.c
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>
 timer: optimize apply_slack()

__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but cheaper.
find_last_bit was showing up high on the list when I was profiling for stalls
on icache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: edoko <r_data@naver.com>
If a clocksource has a (wrong) high rating, but can't be used as a
timebase for oneshot tick mode, it is unconditionally selected even
when the system is already in oneshot tick mode. This causes full
system failure.

Verify the clocksource selection against the oneshot mode.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Quallenauge <Hamsi2k@freenet.de>
MMC CSD info can specify very large, ridiculous timeouts, big enough to
overflow timeout_ns. This can result in the card timing out on every
operation because the wrapped timeout value is far too small.

Fix the overflow by capping the result at UINT_MAX.  Cards specifying
longer timeouts are almost certainly insane, and host controllers
generally cannot support timeouts that long in any case.

Signed-off-by: Torne (Richard Coles) <torne@google.com>
Signed-off-by: Quallenauge <Hamsi2k@freenet.de>
mmc: fix a deadlock between system suspend and MMC block IO

Performing MMC block IO with simultaneous STR can lead to a deadlock: the
mmc_pm_notify() function claims the host and then calls bus .remove()
method, which lands in mmc_blk_remove(), which calls mmc_blk_remove_req()
then it goes to -> mmc_cleanup_queue() -> kthread_stop(), which waits for
the mmc-block thread to stop. If the mmc-block thread at that time is
processing block requests, it will also try to claim the host in
mmc_blk_issue_rq() and block there. This patch fixes the problem by
calling .remove() before claiming the host.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
mmc: omap_hsmmc: fix timeout for cmd and data soft reset

With HSMMC_HAS_UPDATED_RESET reset of cmd/data (SRC/SRD) can be to
quick and can be missed resulting in wait for software timeout.
With cpu_relax timeout can be long and unpredictable. Use udelay
instead for timeout implementation.

Reported-by: Yuzheng Ma <mayuzheng@kedacom.com>
Tested-by: Yuzheng Ma <mayuzheng@kedacom.com>
Reviewed-by: Hein Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
OMAP4430/60: EMIF: errata: Prohibit usage of Power-Down mode

A ZQ calibration long command is issued every time on exit
from active power-down and precharge power-down modes
when EMIF is configured to use Power-down mode
(EMIF_PWR_MGMT_CTRL.REG_LP_MODE=0x4).

Due to very short periods of power-down cycles, ZQ calibration
overhead creates bandwidth issues and increases overall system
power consumption.

As result, the guideline is to not allow Power-down mode and,
therefore, to not have set the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.

TI Errata i743; IMPACTED: OMAP4430/60 all revisions

Change-Id: Ib82f28e6e0c6c046ea277b90a78dc82c1ee82417
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
Android alarm: IOCTL command encoding fix

commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 upstream.

Fixed a bug. Data was being written to user space using an IOCTL
command encoded with _IOC_WRITE access mode.

Backported: 3.4 -> 3.0

Change-Id: I228662c2da6ff3df087d2c97486f3ef1fd9a2280
Signed-off-by: Dae S. Kim <dae@velatum.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrii Beregovenko <a.beregovenko@ti.com>
 usb: musb: Fix memory corruption

rx_count, the number of bytes in the rx fifo, may be larger than the
size of the transfer buffer. Make sure we don't overflow the transfer
buffer in that case.

Bug: 6497399
Change-Id: I5bcf6dd543f9da4ee22944aa6c41673f2cca4c1f
Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
GPIO: OMAP: Fix the sequence to clear the IRQ status

The recommended way to clear the GPIO IRQ status is to:

- Enable the IRQ
- clear the status

If this above sequence is not followed, i.e., if the status
is cleared after disabling the IRQ then sWAKEUP will not be
cleared and gates the module transition.

Change-Id: I8bd1b820ac8be70530cd6430f26ce541bfd3f9d9
Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Andrii Anisov <andrii.anisov@ti.com>
usb: musb: Fix crash when dma is nuked while irq handler is pending

It appears possible for the dma to get nuked while the irq handler
is pending/about to run.  The dma is cancelled by nuke() but the
irq handler will still run and wind up dereferencing NULL, so add
a check.

Crash log:

[ 7629.098815] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 7629.099273] pgd = c0004000
[ 7629.099456] [00000004] *pgd=00000000
[ 7629.099761] Internal error: Oops: 17 [#1] PREEMPT SMP
[ 7629.100067] Modules linked in:
[ 7629.100402] CPU: 0    Not tainted  (3.0.8-gcb25bf2 #1)
[ 7629.100585] PC is at txstate+0x74/0x1ec
[ 7629.100891] LR is at musb_g_tx+0x138/0x1d8
[ 7629.101074] pc : [<c033f1cc>]    lr : [<c033fc9c>]    psr: 20000193
[ 7629.101074] sp : c06efd60  ip : c06efd98  fp : c06efd94
[ 7629.101531] r10: 00000018  r9 : 00000000  r8 : 00000200
[ 7629.101684] r7 : 00000000  r6 : fc0ab110  r5 : c7852448  r4 : c7125c00
[ 7629.101867] r3 : 00000000  r2 : 00000000  r1 : 00000002  r0 : c78520e4
...
[ 7629.228668] [<c033f158>] (txstate+0x0/0x1ec) from [<c033fc9c>] (musb_g_tx+0x138/0x1d8)
[ 7629.229003] [<c033fb64>] (musb_g_tx+0x0/0x1d8) from [<c033d35c>] (musb_interrupt+0x104/0x8cc)
[ 7629.229187] [<c033d258>] (musb_interrupt+0x0/0x8cc) from [<c033db7c>] (generic_interrupt+0x58/0x8c)
[ 7629.229522] [<c033db24>] (generic_interrupt+0x0/0x8c) from [<c00da008>] (handle_irq_event_percpu+0x54/0x188)
[ 7629.229827]  r6:00000000 r5:c06f3f4c r4:c78f49c0 r3:c033db24

Change-Id: I305c80a246f5161f2d3d20839c5603376d5b746c
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
I2C: omap: Fix error condition when slave sends a NAK

Fix an issue in the omap i2c host controller driver where it was not properly
clearing out an error condition in the unit after a NAK'ed transaction causing
the subsequent transaction to time out.

Change-Id: I5cdc8e740acdbc8116dca4d13f1a2cee37f75582
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
 Enable the ARM security extension when compiling some files

Change-Id: I5704b5b0edc55b66d4917352198d921f246ad404
Signed-off-by: Jason Simmons <jsimmons@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP4: trim_quirks: Repair the wrong comparison

The omap_rev() returns value not comparable with CHIP_IS_* constants.

Change-Id: I4f21fc84b37f09d1c14c2656bf13337a453d783e
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP: HDCP: Cancel pending start on disable/hpd drop

We observed a race condition where userland invoked
an ioctl do blank/unblank the display while HDCP
was pending to start (but hadn't yet started).

The hdcp_irq_cb() wasn't cancelling that pending start.
This caused the hdcp state machine to start when it
shouldn't have been, interfering with the hpd state
machine's reading of EDID once the unblank happened.

The two state machines should really be unified at
some point.

Change-Id: Ief74d7eaa099f5455f6a42c65e98b965cdc50217
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>