usb: dwc3: Make fetching of usb-phys configurable

Few platforms using DWC3 controller may use only
one handler for PHY, wherein both UTMI+ and PIPE3
PHYs are configured; such as Samsung which just uses
samsung-usb3phy driver to configure both types of PHYs
required for DWC3 operation.

So DWC3 can have separate phandles for USB2-phy type and
USB3-phy type so that each platform may give either of them
or both USB2 and USB3 phy handlers as required.

BUG=chrome-os-partner:19719
TEST=build and boot on peach and snow, test USB 3.0 port for
     device detection and enumeration

Change-Id: Ib09e26742646c7c38e54fa1014ba6810a2b5c694
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60091
Reviewed-by: Julius Werner <jwerner@chromium.org>
drm: exynos : restore lost configuration on dpms off

In the case of restart ui or user signng out, all
the configuration is lost in DPMS OFF as a result
for proper functioning of display, the lost
configuration needs to be restored, this patch
restores it.

This patch also  modifies fimd, as in the case
if there are no page flips, the same may be required.

BUG=chrome-os-partner:21758
TEST=suspend_stress_test,hotplug restart ui
     and user sign out with HDMI connected on peach

Change-Id: If09e158016c67212f7505a136c4d288884b141de
Signed-off-by: Shirish S <s.shirish@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65181
Tested-by: Shirish S <shirish@chromium.org>
Commit-Queue: dongwon.jung <dw3333.jung@samsung.com>
Reviewed-by: dongwon.jung <dw3333.jung@samsung.com>
Tested-by: dongwon.jung <dw3333.jung@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
CHROMIUM: cpufreq: interactive: fix racy timer stopping

When stopping the governor, del_timer_sync() can race against an
invocation of the idle notifier callback, which has the potential
to reactivate the timer.

To fix this issue, a read-write semaphore is used. Multiple readers are
allowed as long as pcpu->governor_enabled is true.  However it can be
moved to false only after taking a write semaphore which would wait for
any on-going asynchronous activities to complete and prevent any more of
those activities to be initiated.

[toddpoynor@google.com: cosmetic and commit text changes]
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
(cherry picked from android-3.4 commit
	052ca409658cc4128e846da23c0fae9c5d018c45)

BUG=chrome-os-partner:22075
TEST=suspend_stress_test on Pit

Change-Id: Idb06d84795364fd54f2af095b1f7b7989350f52d
[prathyush: rebased to chromeos-3.8 kernel with minor changes]
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
[abrestic: fixed lock leak in cpufreq_interactive_updown_task]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66506
Reviewed-by: Prathyush Kalashwaram <prathyush@chromium.org>
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
CHROMIUM: cpufreq: interactive: fix race on timer restart on governor start

Starting the governor, or restarting on a hotplugged-in CPU, can race
with the timer start in idle, triggering a BUG on timer already pending.
Start the timer before setting the enable flag, and use enable_sem to
protect the sequence (and ensure correct order of the update to the
enable flag).  Delete any existing timer for safety.

Reported-by: Francisco Franco <francisco.franco@cloudcar.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
(cherry picked from android-3.4 commit
	dd09e0f7e558a6c1b1dd0ae71bc454afaf056cf1)

BUG=chrome-os-partner:22075
TEST=suspend_stress_test on Pit

Change-Id: I39c55b04bf798dbbbef222716f936557da71e839
[abrestic: fixed conflict due to android's idle slack timer]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66581
Reviewed-by: Prathyush Kalashwaram <prathyush@chromium.org>
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
exynos5420: devfreq: Remove aclk333 from devfreq

Performance degradation is observed during
multi-instance video(1080p) playback when aclk_333 frequency is being
controlled by devfreq.
Bumping aclk_333 down to lower frequencies doesn't make
much difference on the power consumption when
MFC clock is already controlled by the driver by clock-gating
Hence keep aclk_333 at 333 Mhz

BUG=chrome-os-partner:20714
TEST=Ran multi-instance video playback (3 1080p 24fps videos)
10 mw increase in power is observed on INT rail
during single instance 480p playback

Change-Id: I694305dd16c6a7f6af15bf1c2d1ff2d6bdd82045
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64183
Reviewed-by: Prathyush Kalashwaram <prathyush@chromium.org>
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>