cpufreq: exynos5420: set minimum A7 frequency to 600Mhz

The A7 cluster needs to be clocked at atleast 600Mhz in order
to get the maximum memory bandwidth on the A15 and there is
not a major power consumption increase from 200Mhz to 600Mhz.

BUG=chrome-os-partner:20830
TEST=Boot Pit; see that the minimum in scaling_available_frequencies
is 300000 (600Mhz on A7s)

Change-Id: Ideadf800a966d5e2ec2141f7f4f8a71925a6b686
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63412
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
drm/exynos: Consolidate suspend/resume in drm_drv

This patch removes all of the suspend/resume logic from the individual
drivers and consolidates it in drm_drv. This consolidation reduces the
number of functions which enable/disable the hardware to just one -- the
dpms callback. This ensures that we always power up/down in a consistent
manner.

BUG=chromium:234847
TEST=Tested on snow, no regressions

Change-Id: I0bd1cb3457bff4f8b5c6bc56adf54dfda2962496
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59480
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
usb: samsung-usbphy: Simplify PMU register handling

This patch simplifies the way the samsung-usbphy code finds the correct
power management register to enable PHY clock gating. Previously, the
code would calculate the register address from a device tree supplied
base address and add an offset based on the PHY type.

Since every PHY has its own device tree entry and needs only one
register, we can just encode the address itself in the device tree and
remove the diffentiation in the code. The bitmask needed to specify the
bit within that register stays in place, allowing support for platforms
like s3c64xx that use different bits within the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.

BUG=chrome-os-partner:19719
TEST=Make sure EHCI and XHCI ports on Exynos5 devices still work,
including across suspend/resume.

Change-Id: Ida01f3703c551782954a5a9ce011b22350af081b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61231
Reviewed-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
drm/exynos: Update HDMI internal HPD status

This patch updates the HDMI block's internal HPD status when we
configure things. This takes the HDCP status registers out of reset so
we can make use of them.

BUG=chrome-os-partner:12667
TEST=Build and run on snow

Change-Id: I8e9aab5a3de298e37cef356cab2d4e14dde24b6b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63344
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
drm/exynos: Implement set_property connector callback

This patch implements the set_property connector callback which
translates to a display op.

BUG=chrome-os-partner:12667
TEST=Tested on snow

Change-Id: I9b54167d9c9050b3001dea7e45e845b7c8bd6496
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63345
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
cpufreq: exynos5420: Modify switching parent from mpll to spll

Modify the parent for MSPLL_CPU and MSPLL_KFC to SPLL
from MPLL as the recommended setting for switching parent
is SPLL.
Before this change MSPLL_CPU and MSPLL_KFC were running
at 800MHz, and after this they run at 400MHz.

BUG=chrome-os-partner:20827
TEST=Build and boot kernel on peach EVT1.
See from clk_summary:
Before:
cat /sys/kernel/debug/clk/clk_summary |grep spll
fout_spll                   0           0            400000000
   sclk_spll                0           0            400000000
        mout_mspll_cpu        0           0		800000000
	mout_mspll_kfc        0           0	        800000000
After:
cat /sys/kernel/debug/clk/clk_summary |grep spll
fout_spll                   0           0            400000000
   sclk_spll                0           0            400000000
      mout_mspll_cpu        0           0	     400000000
      mout_mspll_kfc        0           0	     400000000

See bL switching happen correctly and run video, webGL to make
sure performance has not regressed.

Change-Id: Ic30586e643dbfd4320fca6f29362810503dda2a3
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63200
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
ARM: dts: Put exynos5250-snow charger in polling mode

The tps65090 charger driver now supports polling mode.  Use that for
snow so that we don't stomp all over the EC's management of the
tps65090 interrupts.

BUG=chrome-os-partner:16407
TEST=Unplug power and see charge status change.

Change-Id: I4d68b07e562cb0062867030ecbdbc2bc7df08c6d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62973
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: config: Normalize all configs

This patch normalizes the configs.

BUG=None
TEST=Booted on snow and peach-pit

Change-Id: I084bef90e1cf511fea3e48f7c240c3d280555d13
Signed-off-by: Shirish S <s.shirish@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63574
Tested-by: Shirish S <shirish@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
BACKPORT: mmc: fix null pointer use in mmc_blk_remove_req

A previous commit (fdfa20c1631210d0) reordered the
shutdown sequence in mmc_blk_remove_req. However,
mmc_cleanup_queue is now called before we get the
card pointer and, sadly, mmc_cleanup_queue set
mq->card to NULL.

This patch moves the card pointer assignment before
mmc_cleanup_queue.

Signed-off-by: Franck Jullien <franck.jullien@gmail.com>

[original patch would not apply - had to apply by hand.]

BUG=chromium:264814
TEST=Required for running MMC_TEST

Change-Id: I99a6eb85a54a9bbc6e2e6d9b794045e4813cb6d8
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63480
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Paul Taysom <taysom@chromium.org>
mcpm: exynos: wait for outbound CPU to power off before powering off L2

__mcpm_is_cpu_down() only indicates whether or not the outbound CPU
has reached __mcpm_cpu_down() - the outbound CPU must enter WFI
before the PMU actually powers it off.  Use the PMU's CORE_STATUS
register instead to indicate if the CPU has completed the power-down
sequence.

BUG=chrome-os-partner:21189
TEST=Boot Pit; IKS seems stable.  Observe that manually inserting a
delay between __mcpm_cpu_down() and wfi() no longer causes the machine
to hang.

Change-Id: I31ae0818c29164b5980c75e4cda66cf340bee8a6
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63618
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
cpufreq: exynos5420: use ASV for A7 cluster

Although there is ASV support for both clusters, we were previously
only using it for the A15s.  Add support for actually using ASV on the
A7s as well.

BUG=chrome-os-partner:20642
TEST=Boot on a Pit in ASV group 3; set frequency to 500Mhz (1Ghz A7)
and check that vdd_kfc is set correctly according to ASV group 3:
localhost ~ # cat /sys/class/regulator/regulator.42/microvolts
1087500

Change-Id: I7bff76c049357cdd388a3245feb82ee43db77213
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63795
Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Arjun.K.V <arjun.kv@samsung.com>
arm: dts: exynos5420: Add the errata reg for TMU channels

On Exynos5420 the TRIMINFO register was misplaced(address) for
TMU channels 2, 3 and 4

TRIMINFO at 0x1006c000 contains data for TMU channel 3 (instead of 2)
TRIMINFO at 0x100a0000 contains data for TMU channel 4 (instead of 3)
TRIMINFO at 0x10068000 contains data for TMU channel 2 (instead of 4)

This patch adds the misplaced register address to the TMU device node

BUG=chrome-os-partner:21030
TEST=booted on peach and saw  TMU is registered and
operating normally.
localhost ~ #  grep ""  /sys/class/thermal/thermal_zone*/*temp
/sys/class/thermal/thermal_zone0/temp:38000
/sys/class/thermal/thermal_zone0/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone0/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone0/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone1/temp:38000
/sys/class/thermal/thermal_zone1/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone1/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone1/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone2/temp:38000
/sys/class/thermal/thermal_zone2/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone2/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone2/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone3/temp:38000
/sys/class/thermal/thermal_zone3/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone3/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone3/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone4/temp:38000
/sys/class/thermal/thermal_zone4/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone4/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone4/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone5/temp:32600

Change-Id: Ibe15accb2331cda05fa8959c8aed345c44a1d067
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62335
Reviewed-by: naveen krishna chatradhi <naveen@chromium.org>
Tested-by: naveen krishna chatradhi <naveen@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
thermal: exynos: Handle the misplaced TRIMINFO register

This patch adds code to handle the misplaced TRIMINFO register
incase of Exynos5420.

On Exynos5420 we have a TRIMINFO register being misplaced for
TMU channels 2, 3 and 4

TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a0000 contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2

The misplaced register address is passed through devicetree and
map it seperately during probe.
Also, adds the documentation under devicetree/bindings/thermal/

BUG=chrome-os-partner:21030
TEST=Booted on peach and saw that TMU is being registered and
working properly
localhost ~ #  grep ""  /sys/class/thermal/thermal_zone*/*temp
/sys/class/thermal/thermal_zone0/temp:38000
/sys/class/thermal/thermal_zone0/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone0/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone0/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone1/temp:38000
/sys/class/thermal/thermal_zone1/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone1/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone1/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone2/temp:38000
/sys/class/thermal/thermal_zone2/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone2/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone2/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone3/temp:38000
/sys/class/thermal/thermal_zone3/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone3/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone3/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone4/temp:38000
/sys/class/thermal/thermal_zone4/trip_point_0_temp:85000
/sys/class/thermal/thermal_zone4/trip_point_1_temp:103000
/sys/class/thermal/thermal_zone4/trip_point_2_temp:108000
/sys/class/thermal/thermal_zone5/temp:32600

Change-Id: Idd8b81f80c7bf73cba4a8ff9c2ebdefb0566aff2
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62336
Tested-by: naveen krishna chatradhi <naveen@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Revert "CHROMIUM: drivers/tty: Don't hangup shared ttys"

This reverts commit 172fd3f45ad55346c3d7b953b28090d0746afa8f.

Issue chromium:243812 is now fixed by a different solution CL:63707.

BUG=chromium:263854,chrome-os-partner:21407
CQ-DEPEND=CL:63707
TEST=Tested the following:
1. Plug in a 3G dongle, connect it to network, and the unplug it. Verify
   that the kernel does not crash.
2. Follow the test instruction in CL:63707.

Change-Id: I600c4c3dad3e51cfba59c2c863979d150cf0b763
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63816
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: ALSA: hda/realtek - Don't hum in codec-D3

Power down NID 0x19 and its MIC voltage reference in D3 mode.  This is
the lowest power solution found by Realtek to prevent humming in
codec-D3.

BUG=chrome-os-partner:21059
TEST=Put codec in D3, make sure headphones don't hum.

Change-Id: I151295522b98a727aa61976d95c1875f2950047e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63714
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
ARM: MALI: fix race in calculating GPU utilisation

Since kbasep_pm_record_gpu_{active,idle}() get the current
time before grabbing the PM metrics spinlock, they race with
kbase_pm_get_dvfs_utilisation() which may time_period_start
between that time.  Once kbasep_pm_record_gpu_{active,idle}()
acquire the spinlock, they will be using a timestamp which
is now before time_period_start, causing the idle and/or busy
counters to overflow.

BUG=chrome-os-partner:21219
TEST=Boot Pit; haven't been able to reproduce utilisation
overflow BUG.

Change-Id: I096aba45f37a0a7a40d1c5c4796da152eb9b56f2
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63938
mfd: max77xxx: Support using a nonzero DVS index for BUCKs

At the moment, the max77xxx driver doesn't support the GPIO-DVS
feature of the max77686 and max77802.  The existing code always just
assumed that the DVS and SELB lines on the PMIC were hardwired to 0.
That meant that updating the voltages invloved updating "slot 1"
(index 0) of the BUCK config registers.

One downside of using slot 1 of the PMIC is that, on all boards I've
seen including exynos5420-pit, slot 1 is automatically selected at
warm reset time.  Also on all boards that I've seen, warm reset is not
communicated to the max77xxx PMIC.  That means that if we modify slot
1 and do a warm reset we'll be running at voltages that may be lower
than the initial power on voltages of the board.  This can make it
difficult for the bootloader to come up at full speed.

There is no downside to the kernel using a different slot, so we can
be a little kinder to the bootloader by allowing the kernel to specify
a different slot to run in.

Note that this change _doesn't_ enable GPIO-DVS support: it merely
changes which default DVS slot the kernel works with.  This change
doesn't preclude someone later coming along and enabling GPIO-DVS
support if they found it useful, so long as they were aware of any
assumptions that the bootloader makes about the state of slot 1 at
warm reset time.

Note also that bindings and code are based loosely on the
max8997-regulator bindings, which actually does support DVS.

BUG=chrome-os-partner:21430
TEST=Boot up the system; seems reliable.
TEST=suspend_stress_test
TEST=Run tests as per chrome-os-partner:21341

Change-Id: I33ef19a67149e487ef993e7c8d4326c2f1d90edb
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63779
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: pci: default d3cold_allowed to false

We are not quite ready to enable d3cold just yet. Default
d3cold_allowed to false for now.  We will want to revisit
this in the not too distant a future, though.

BUG=chrome-os-partner:21524
TEST=run the command below and check to make
sure that it returns 0 for all devices:
for i in /sys/devices/pci*/00*; do cat $i/d3cold_allowed; done

Change-Id: I9e26fa952c6b481d929374e856c5b1df7a6b3871
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63981
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
CHROMIUM: ASoC: max98095 - Enable DC blocking filter.

Enable the DC blocking filter on the record path.  This removes a
negative DC offset that can originate from the digital microphone.

BUG=none
TEST=arecord and open file in audacity check there isn't a DC offset.

Change-Id: I5744a33fc2bf704027fcefa5c8497b07b78fc819
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56345
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63669
ARM: dts: Choose DVS "slot 2" (index 1) for exynos5420-peach-pit

A previous CL added the ability for the max77xxx driver to use
something other than slot 1 for DVS.  Choose slot 2 so that nothing
that the kernel does will affect the voltages from the BUCKs at warm
reset time.

Note:
- The kernel can still affect warm reset voltages for anything other
  than BUCK1-4, 6.  We will need to make sure that the bootloader can
  handle whatever we expect the kernel will throw at it.  Luckily the
  kernel doesn't change the LDOs much so shouldn't affect reset.

BUG=chrome-os-partner:21430
TEST=Boot up the system; seems reliable.
TEST=suspend_stress_test
TEST=Run tests as per chrome-os-partner:21341

Change-Id: Idec178688dfbe5e53e990e599948ad72c37ad6ae
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63780
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>