i2c-omap: use usleep_range(), get rid out of jiffies

Use usleep_range() with return value to implement time-bounded
wait-for hardware loop where delay is applicable; use ktime
instead of jiffies for a busy-wait loop.

Signed-off-by: Dmitry Antipov <dmitry.antipov@linaro.org>

Conflicts:
	drivers/i2c/busses/i2c-omap.c
regulator driver backport of Linux 3.2-r7. Up to 58fb5cf.
linux backport 3.2-rc7 credit to imoseyon

Conflicts:
	sound/soc/omap/omap-mcbsp.c
mmc: change mmc_delay() to use usleep_range()

Use the usleep_range() to simplify mmc_delay() and give some more
accuracy to it - but with an exception of mmc_card_sleepawake():
since sleep/awake timeout varies in a wide range, different
delay methods should be used.

Signed-off-by: Dmitry Antipov <dmitry.antipov@linaro.org>
mmc: fix deadlock from mmc core when suspend the device

Hi Chris Ball & Greg KH,

This patch can fix the mmc deadlock when suspen the mmc devices.

when mmc_pm_notify to do the host->bus_ops->remove, there is deadlock,
because it was locked at mmc_claim_host, so it modify the mmc_claim_host
after the host->bus_ops->remove.
the problem can reproduce at lots of the emmc/sd devices when create
multi partitions,and I have tested this modify at lots of the platform.

Can this patch fixed?

Signed-off-by: LiuQi <liuqi@thundersoft.com>
Signed-off-by: Jack Qin <qinjian@thundersoft.com>
smp: Start up non-boot CPUs asynchronously

The starting of the "not first" CPUs actually takes a lot of boot time
of the kernel... upto "minutes" on some of the bigger SGI boxes.
Right now, this is a fully sequential operation with the rest of the kernel
boot.

This patch turns this bringup of the other cpus into an asynchronous operation,
saving significant kernel boot time (40% on my laptop!!). Basically
now CPUs get brought up in parallel to disk enumeration, graphic mode bringup
etc etc etc.

Note that the implementation in this patch still waits for all CPUs to
be brought up before starting userspace; I would love to remove that
restriction over time (technically that is simple), but that becomes
then a change in behavior... I'd like to see more discussion on that
being a good idea before I write that patch.

Second note: We add a small delay between the bring up of cpus, this is
needed to actually get a boot time improvement. If we bring up CPUs
straight back-to-back, we hog the cpu hotplug lock for write, and
that lock is used everywhere during initialization for read. By
adding a small delay, we allow those tasks to make progress.

CC: Milton Miller <miltonm@bga.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>

Conflicts:
	kernel/smp.c
adjust DSS latency constraint for deeper power state
adjusted TSHUT_HOT and TSHUT_COLD thresholds to their correct (and safer) levels

Conflicts:

	drivers/misc/omap_temp_sensor.c

Conflicts:
	drivers/misc/omap_temp_sensor.c
derp