cascardo/linux.git
11 years agoCHROMIUM: config: turn on HID_CHERRY=m
Olof Johansson [Wed, 22 Aug 2012 17:32:02 +0000 (10:32 -0700)]
CHROMIUM: config: turn on HID_CHERRY=m

Turn on support for the Cherry cymotion keyboards, since some
people might want to use them with Chromeboxes.

BUG=chromium-os:31607
TEST=plug in a cherry cymotion linux keyboard. Sorry, don't have one (external bugreport)

Change-Id: I08839e5ef08d21d7540a609cbb7e2332b069a357
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31119
Reviewed-by: Benson Leung <bleung@chromium.org>
11 years agoRevert "CHROMIUM: drivers: device tree support for gpio-charger"
Simon Que [Wed, 15 Aug 2012 06:14:26 +0000 (23:14 -0700)]
Revert "CHROMIUM: drivers: device tree support for gpio-charger"

This reverts commit 2e42da7e808a2c4f6713fb2618fca0529b4c053c.

BUG=chrome-os-partner:11739
TEST=build kernel succesfully

Signed-off-by: Simon Que <sque@chromium.org>
Change-Id: I35cb59b03e2f6bb1a87fa99f0fceb27d5e4137ad
Reviewed-on: https://gerrit.chromium.org/gerrit/31048
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: input: cyapa: recover from watchdog triggered reset
Du, Dudley [Mon, 16 Jul 2012 11:04:25 +0000 (19:04 +0800)]
CHROMIUM: input: cyapa: recover from watchdog triggered reset

Newer versions of Cypress Trackpad firmware use a watchdog timer
to reset the device after an internal failure. The reset operation
will put the device into bootloader mode, so the kernel driver
must use cyapa_detect to bring the trackpad into operational mode
on a failed i2c transaction.

BUG=chrome-os-partner:12838
TEST=test with trackpad v1.2 firmware on CYTRA_103002-00
Trigger a watchdog reset using an electrostatic discharge.
Ensure that the cyapa_detect case is triggered, and the pad
is functional after the event.

Change-Id: Ib2270eb48d80643756fdc06e944a1c9afac4e64f
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/27496
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Benson Leung <bleung@chromium.org>

11 years agoRevert "CHROMIUM: HACK: mmc: core: Do not rescan after resume"
Alim Akhtar [Fri, 17 Aug 2012 11:23:47 +0000 (16:53 +0530)]
Revert "CHROMIUM: HACK: mmc: core: Do not rescan after resume"

This reverts commit adabba54966cbfd3b0dc9b006bb30f9fa0a1a48e.
This is not needed as we have a fix for this hack.

BUG=chrome-os-partner:12802
TEST= after reverting this CL and with other 2 CL, sd card detection
works fine after s2r cycle.

Change-Id: Idccaf531bc272533e3918b703a55f56f15a8cb48
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30692
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
11 years agoCHROMIUM: exynos: snow: Disable mmc on the external SD card slot
Doug Anderson [Tue, 21 Aug 2012 19:47:35 +0000 (12:47 -0700)]
CHROMIUM: exynos: snow: Disable mmc on the external SD card slot

MMC is not supported on this slot on this system.

BUG=chrome-os-partner:11811

TEST=With patch series, plug in an MMC card and saw that it was
detected before this patch but isn't detected after.

Change-Id: Ie9d1cd13628d27e60b47572837c162b00563bf72
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31023
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: mwifiex: Disable WOW by default.
Todd Broch [Tue, 21 Aug 2012 20:05:10 +0000 (13:05 -0700)]
CHROMIUM: mwifiex: Disable WOW by default.

Disable WOW for two reasons:
1. Appears to have some hand in WIFI device waking during Standby and
entering high energy state.
2. Is not required feature and often burns additional power.

BUG=chrome-os-partner:12164
TEST=manual,  associate wifi and measure power in suspend to be
reasonable.

Change-Id: I039650eb8c986a447022fd87bf87880cc7b47635
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31020
Reviewed-by: Gary Morain <gmorain@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Reviewed-by: Bing Zhao <bzhao@marvell.com>
11 years agoCHROMIUM: scsi: don't wait for disk to wakeup on resume
Derek Basehore [Wed, 8 Aug 2012 21:53:08 +0000 (14:53 -0700)]
CHROMIUM: scsi: don't wait for disk to wakeup on resume

This is done in the same way as the ata ports. Instead of waiting for the disk
to resume in sd_resume, we put a function into the workqueue and return. We also
make sure that a race does not happen between resume and suspend. This is done
by making the suspend code wait until the work_struct in the ata_port finishes.

There does not seem to be any differences between what this change does and what
happened before when it breaks. It seems that the disk will be woken up in
another place if the function to wake it up in resume fails.

Note: I have not decided exactly what to do for error paths and therefore there
are currently none when ata ports or disks fail to resume

BUG=chrome-os-partner:11780
TEST=power_Resume, powerd_suspend, opening and closing laptop, commenting out
the line that wakes up the disk and seeing the system behaviour (same before and
after change)

Change-Id: I05ba125ef55c2cc9e6849d9fec693c574f81221a
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29673

11 years agoCHROMIUM: ata: don't wait on ata ports for resume
Derek Basehore [Wed, 8 Aug 2012 20:20:47 +0000 (13:20 -0700)]
CHROMIUM: ata: don't wait on ata ports for resume

This change causes dpm_resume to not block on resuming ata ports. This is done
by putting the function calls to wake up the ata ports in a workqueue. I make
sure that there is not a race between suspend and resume by making the suspend
code for ata_port wait until the work for resume is done.

I tested what would happen when the ata ports do not resume (by commenting out
the line that resumes and returning -1). We do wake up, but after ~2 minutes,
the machine reboots. The machine blocks on any io that requires disk. Mouse
clicks do not seem to register.

Without the change, pretty much the same thing occurs (from a user experience),
except that the mouse arrow is not visible.

BUG=chrome-os-partner:11780
TEST=power_Resume, powerd_suspend

Change-Id: Ica746d313349a3d8c5f6ba6912f6a3b18e5c2b3f
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29672

11 years agommc: dw_mmc: Add a DISABLE_MMC quirk that sets the core mmc cap
Doug Anderson [Tue, 21 Aug 2012 19:45:40 +0000 (12:45 -0700)]
mmc: dw_mmc: Add a DISABLE_MMC quirk that sets the core mmc cap

This quirk can be set from the device tree to disable mmc on a given
slot.

BUG=chrome-os-partner:11811
TEST=With patch series, plug in an MMC card and saw that it was
detected before this patch but isn't detected after.

Change-Id: I169b070578cff16b74f1556934e09ea3ea542b84
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31022

11 years agommc: core: Add a capability for disabling mmc cards
Doug Anderson [Tue, 21 Aug 2012 19:42:44 +0000 (12:42 -0700)]
mmc: core: Add a capability for disabling mmc cards

On some systems we need a way to disable MMC card support in a MMC/SD
card slot.  Add support in the core SD/MMC code to support this.

BUG=chrome-os-partner:11811
TEST=With patch series, plug in an MMC card and saw that it was
detected before this patch but isn't detected after.

Change-Id: I5b94a1d7deba85e0eb4709a419589cc3e9058eca
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/31021

11 years agoCHROMIUM: ARM: config: cros5250: set HDMI I2C speed to ~400 kHz
Daniel Kurtz [Fri, 10 Aug 2012 13:29:08 +0000 (21:29 +0800)]
CHROMIUM: ARM: config: cros5250: set HDMI I2C speed to ~400 kHz

The HDMI I2C is hooked up internally to the HDMI core which supports
Fast Mode (400 kbit/s) I2C operation.

Note: actual rate is reported as 378 kHz.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:8665
TEST=No i2c-8 (12ce0000.i2c) errors when plugging/unplugging hdmi cable

Change-Id: I79f259ce7d02786ba57bca2cf79ee8650617591e
Reviewed-on: https://gerrit.chromium.org/gerrit/29877
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoCHROMIUM: chromeos: config: CHARGER_TPS65090 option
Simon Que [Tue, 21 Aug 2012 17:34:31 +0000 (10:34 -0700)]
CHROMIUM: chromeos: config: CHARGER_TPS65090 option

Enable for Exynos5 only.

BUG=chrome-os-partner:11739
TEST=Check that the tps65090-charger sysfs is picked up by
"power-supply-info".  Or make sure the sysfs is present.
Check that the "online" and "status" fields are correct when AC is
plugged and unplugged.
Check with "udevadm monitor" that udev events are sent when plugging and
unplugging.

Change-Id: I85c49ceafda7b1775bc733b4576ee63191947379
Signed-off-by: Simon Que <sque@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31000

11 years agoCHROMIUM: dts: cros5250: Add tps65090 charger/irq
Simon Que [Tue, 21 Aug 2012 16:43:16 +0000 (09:43 -0700)]
CHROMIUM: dts: cros5250: Add tps65090 charger/irq

Adding charger and irq to the device tree for cros5250.

BUG=chrome-os-partner:10617,chrome-os-partner:11739,chrome-os-partner:12244
TEST=Check that the tps65090-charger sysfs is picked up by
"power-supply-info".  Or make sure the sysfs is present.
Check that the "online" and "status" fields are correct when AC is
plugged and unplugged.
Check with "udevadm monitor" that udev events are sent when plugging and
unplugging.

Change-Id: Ib3c60c5795354c624f8eaff82941c870fef94200
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30998
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: usb: Add support for root hub port status CAS
Stanislaw Ledwon [Mon, 18 Jun 2012 13:20:00 +0000 (15:20 +0200)]
UPSTREAM: usb: Add support for root hub port status CAS

Adds support for handling the Compliance Mode of USB 3.0 port

The host controller port status register supports CAS (Cold Attach
Status) bit. This bit could be set when USB3.0 device is connected
when system is in Sx state. When the system wakes to S0 this port
status with CAS bit is reported and this port can't be used by any
device.

When CAS bit is set the port should be reset by warm reset. This
was not supported by xhci driver.

The issue was found when pendrive was connected to suspended
platform. The link state of "Compliance Mode" was reported together
with CAS bit. This link state was also not supported by xhci and
core/hub.c.

The CAS bit is defined only for xhci root hub port and it is
not supported on regular hubs. The link status is used to force
warm reset on port. Make the USB core issue a warm reset when port
is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
to report 'compliance mode' when the CAS is set. This force warm reset
on the root hub port.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset."

BUG=chrome-os-partner:12672
TEST=connect USB 3.0 device on 3.0 port and do "rtcwake -m mem -s 10"
Device is detected successfully.

Change-Id: Ie0dbb523b9017c768886ec4e564a812acfe54f01
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554)
Reviewed-on: https://gerrit.chromium.org/gerrit/30691

11 years agoCHROMIUM: drivers: mfd: power supply event on tps65090 irq
Simon Que [Tue, 21 Aug 2012 16:41:15 +0000 (09:41 -0700)]
CHROMIUM: drivers: mfd: power supply event on tps65090 irq

This allows udev events to be generated when the power supply state is
updated.

BUG=chrome-os-partner:11739
TEST=Build successfully

Change-Id: I3b28e9a9af9aaeb6b0eff128ee649fb637e7dad4
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30997
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: drivers: power: Add TPS65090 battery charger
Simon Glass [Sun, 17 Jun 2012 16:51:09 +0000 (09:51 -0700)]
CHROMIUM: drivers: power: Add TPS65090 battery charger

This driver reads AC status from the tps65090 directly.

Note: At present the TPS65090 has a few problems, one of which is that
the status registers do not work. As a result we are reading registers
that we should not. Definitions for these registers have been put into
tps65090-private.h for now.

BUG=chrome-os-partner:10617,chrome-os-partner:11739,chrome-os-partner:12244
TEST=Build successfully

Change-Id: I909fb5919cb782c49a72c488b3b36b245b029112
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30357
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: ARM: cros5250: fix broken card detection on sd
Alim Akhtar [Fri, 17 Aug 2012 12:05:22 +0000 (17:35 +0530)]
CHROMIUM: ARM: cros5250: fix broken card detection on sd

We have a mechanism to detect insertion and removal of sd/mmc card
through cd_gpio. With this property set, even if sd card is not
persent in slot, dwmmc driver always reports that the card is persent.
This CL removes 'card-detection-broken' property and passes a flag
indicating card-detect line the active low.

BUG=chrome-os-partner:12802
TEST=tested with the other CL, sd card insertion/removal is reported
correctly. Also tested sd card insertion/removal after s2r cycle, that
works.

Change-Id: Ib6c0c044407d6a319b53e5f70059536a8454e5a0
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30693

11 years agommc: dw_mmc: fix the incorrect gpio read value for card _persent_
Alim Akhtar [Sun, 19 Aug 2012 16:26:34 +0000 (21:56 +0530)]
mmc: dw_mmc: fix the incorrect gpio read value for card _persent_

When the card detect gpio line is pulled __low__ that indicates the
persent of card and when pulled __high__ indicates card is removed.
This CL assigns correct status for card persent variable.  Implemented
this in a more generic way by using device tree. Handles both active
high and active low card detect gpio.

BUG=chrome-os-partner:12802
TEST=with other CL, tested sd card insertion/removal works fine
     and sd card getting detected after s2r cycle

Change-Id: If1c405d1e0ddf7315697d125813f96570094d714
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30694
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
11 years agoexynos5: usb: dwc3: Add the suspend/resume functionality
Vikas C Sajjan [Fri, 3 Aug 2012 17:25:32 +0000 (22:55 +0530)]
exynos5: usb: dwc3: Add the suspend/resume functionality

Adds the suspend and resume functionality to exynos dwc3 driver

BUG=chrome-os-partner:11740
TEST=tested USB 3.0 and USB 2.0 device on SS hub detected after S2R

Change-Id: Ia1e2d421c0bf1e9d644a8e68b7579a046932b752
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29177

11 years agoexynos5: usb: xhci: Add the suspend/resume functionality
Vikas C Sajjan [Fri, 3 Aug 2012 17:27:13 +0000 (22:57 +0530)]
exynos5: usb: xhci: Add the suspend/resume functionality

Adds the suspend and resume functionality for the exynos XHCI driver

BUG=chrome-os-partner:11740
TEST=Tested USB 3.0 and USB 2.0 devices on SS Hub detected after S2R

Change-Id: I18380012e1c492f505729eec05c8fed47ebd8632
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29178
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
11 years agoCHROMIUM: usb: dwc3: Add suspend/resume functionality
vikas sajjan [Fri, 3 Aug 2012 11:44:19 +0000 (17:14 +0530)]
CHROMIUM: usb: dwc3: Add suspend/resume functionality

This patch adds the suspend and resume funtionality to DWC3 core

BUG=chrome-os-partner:11740
TEST=USB 3.0 and USB 2.0 device on SS Hub detected after S2R
TEST=Tests described in USB PLL-related still work.
  https://gerrit.chromium.org/gerrit/30184

Change-Id: I440b70f6248d56a5369e6867cdc1fd533106f72e
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27636

11 years agoUPSTREAM: ath9k: fix ASPM initialization on resume
Felix Fietkau [Thu, 16 Aug 2012 09:29:56 +0000 (11:29 +0200)]
UPSTREAM: ath9k: fix ASPM initialization on resume

BUG=chrome-os-partner:10677
TEST=Manual (run wifi test suites)

ath_pci_aspm_init is only called on card init, so PCI registers get reset
after a suspend/resume cycle.

Change-Id: I1aa6427810959493895e30a4580f3e7803152b3d
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30885
Reviewed-by: Gary Morain <gmorain@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agoUPSTREAM: mac80211: always set in_reconfig=false on wakeup
Eliad Peller [Mon, 2 Jul 2012 12:08:25 +0000 (15:08 +0300)]
UPSTREAM: mac80211: always set in_reconfig=false on wakeup

BUG=chrome-os-partner:10785
TEST=Manual (run wifi test suites)

If the interfaces were removed just before a restart
work was started, open_count will be 0, and most of
the reconfig work will be skipped, including the
resetting of local->in_reconfig to false.

Leaving local->inconfig = true will result in
dropping any incoming packet.

Fix it by always setting local->in_reconfig = false
(even if there are no active interfaces).

Change-Id: I9ae806c59e0453548bceb8a932950b1a003a42e2
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30883
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agoUPSTREAM: mac80211: stop Rx during HW reconfig
Arik Nemtsov [Wed, 6 Jun 2012 08:25:02 +0000 (11:25 +0300)]
UPSTREAM: mac80211: stop Rx during HW reconfig

BUG=chrome-os-partner:10785
TEST=Manual (run wifi test suites)

While HW reconfig is in progress, drop all incoming Rx. This prevents
incoming packets from changing the internal state of the driver or
calling callbacks of the low level driver while it is in inconsistent
state.

Change-Id: I84efd3b2a45d3ebba6c7827bcd22daa26271fdbb
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30882
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agoUPSTREAM: mac80211: add stations after AP start on reconfig
Arik Nemtsov [Sun, 3 Jun 2012 20:31:56 +0000 (23:31 +0300)]
UPSTREAM: mac80211: add stations after AP start on reconfig

BUG=chrome-os-partner:10785
TEST=Manual (run wifi test suites)

When performing a HW restart for an AP mode interface, add stations back
only after the AP is beaconing. This mimics the normal flow of STA
addition on AP.

Some devices (wlcore) do not support adding stations before beaconing,
so this has the added benefit of making recovery work for them.

Change-Id: I087759324047648092e717ec7fe266e9b15d1776
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30881
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agoUPSTREAM: mac80211: fix error in station state transitions during reconfig
Meenakshi Venkataraman [Wed, 30 May 2012 09:39:33 +0000 (11:39 +0200)]
UPSTREAM: mac80211: fix error in station state transitions during reconfig

BUG=chrome-os-partner:10785
TEST=Manual (run wifi test suites)

As part of hardware reconfig mac80211 tries
to restore the station state to its values
before the hardware reconfig, but it only
goes to the last-state - 1. Fix this
off-by-one error.

Change-Id: Idd7ac847a66c9ef2eea0d6eaf7347d8a1a4fd792
Cc: stable@kernel.org [3.4]
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30880
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agoUPSTREAM: mac80211: fix ADDBA declined after suspend with wowlan
Eyal Shapira [Tue, 29 May 2012 09:00:22 +0000 (02:00 -0700)]
UPSTREAM: mac80211: fix ADDBA declined after suspend with wowlan

BUG=chrome-os-partner:10785
TEST=Manual (run wifi test suites)

WLAN_STA_BLOCK_BA is set while suspending but doesn't get cleared
when resuming in case of wowlan. This causes further ADDBA requests
received to be rejected. Fix it by clearing it in the wowlan path
as well.

Change-Id: I24de4b4957e7f2c96df32672e08ead288eafffb4
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30879
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Tan Gao <tgao@chromium.org>
Tested-by: Tan Gao <tgao@chromium.org>
11 years agousb: dwc3: core: Add constants relating to power down
Doug Anderson [Fri, 17 Aug 2012 23:05:25 +0000 (16:05 -0700)]
usb: dwc3: core: Add constants relating to power down

These constants aren't used anywhere yet but having in the header
could be useful for someone that wanted to use them in the future.

BUG=chrome-os-partner:11740
TEST=Kernel still compiles

Change-Id: I3181e7bfc34edad0a9bc0f9f80bf53f36e7b5768
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30786
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: config: exynos5: remove assorted PS/2 drivers
Daniel Kurtz [Fri, 17 Aug 2012 16:35:51 +0000 (00:35 +0800)]
CHROMIUM: config: exynos5: remove assorted PS/2 drivers

The exynos5 does not have a PS/2 port, nor does it use an emulated PS/2
for mice or trackpads.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=builds clean; notice 114 less functions in
     /sys/kernel/debug/tracing/available_filter_functions

Change-Id: I140f23b2d7f16fc4afa3a05f41b1698ba62b2764
Reviewed-on: https://gerrit.chromium.org/gerrit/30697
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoCHROMIUM: regulator: max77686: cache current output value for regulators
Daniel Kurtz [Fri, 17 Aug 2012 17:17:04 +0000 (01:17 +0800)]
CHROMIUM: regulator: max77686: cache current output value for regulators

When increasing voltages on the BUCK2-BUCK4 regulators, we must wait a
ramp delay that depends on the voltage differential.  To compute this
delay, we need the target and previous settings.

Since all requests to set the voltage levels for the various max77686
regulators go through max77686_set_voltage(), we can cache the most recent
value, saving an i2c transaction to read it.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:10891
TEST=Use ftrace confirm that, when using cpufreq interactive governor,
     each  set_voltage() call only requires one i2c write:
 echo exynos_target > set_ftrace_filter
 echo 'max77686_*' >> set_ftrace_filter
 echo 'i2c_smbus_*' >> set_ftrace_filter
 echo exynos_target > set_graph_function
 echo function_graph > current_tracer

 1)               |  exynos_target() {
 1)               |    max77686_set_voltage() {
 1)               |      max77686_update_reg() {
 1)               |        max77686_write_reg() {
 1)               |          i2c_smbus_write_byte_data() {
 1) ! 164.917 us  |            i2c_smbus_xfer();
 1) ! 172.917 us  |          }
 1) ! 179.000 us  |        }
 1) ! 185.458 us  |      }
 1) ! 224.625 us  |    }
 1)   3.125 us    |    max77686_list_voltage();
 1) ! 367.583 us  |  }

Change-Id: I7b7964a8af88c06dfa53efb6045b6ff0585b08f3
Reviewed-on: https://gerrit.chromium.org/gerrit/30552
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoCHROMIUM: config: renormalize splitconfig
Daniel Kurtz [Fri, 17 Aug 2012 16:34:13 +0000 (00:34 +0800)]
CHROMIUM: config: renormalize splitconfig

Renormalizing after some new config options were added.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=Built and booted on one device.

Change-Id: Ice08c7747d41b8263b859fdd686637d47dca2b54
Reviewed-on: https://gerrit.chromium.org/gerrit/30831
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoarm: exynos5: Add NTC Thermistor attached to S3C-ADC
Naveen Krishna Chatradhi [Mon, 30 Jul 2012 11:23:41 +0000 (20:23 +0900)]
arm: exynos5: Add NTC Thermistor attached to S3C-ADC

This patch allows platform configurations to share information about
the NTC thermistor device attached to ADC port of S3C.

A platform configuration is required to initialize the ADC port for NTC
thermistor by calling "s3c_adc_ntc_init(pdev);" before registering the
NTC thermistor device. Then, registering a platform device,
s3c_device_adc_ntc_thermistor enables NTC thermistor for the platform.
(Modifications implemented by Grant Grundler)

BUG=chrome-os-partner:11688
TEST=Temperature is read using the sysfs entries in NTC Thermistor
driver: cat /sys/class/hwmon/hwmonX/device/temp1_input
X is 0, 1, 2 and 3

Change-Id: Ib7242f18adecf8602660decda670283c7ab68a0e
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28693
Tested-by: naveen krishna chatradhi <naveen@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
11 years agoCHROMIUM: ARM: exynos: snow: Add gpio for enabling the usb3 phy clock
Doug Anderson [Thu, 16 Aug 2012 22:49:04 +0000 (15:49 -0700)]
CHROMIUM: ARM: exynos: snow: Add gpio for enabling the usb3 phy clock

The usb3 phy clock is an external PLL that burns a lot of power but is
needed to pass USB 3.0 compliance testing.

BUG=chrome-os-partner:11066
TEST=With other patches in this series can run:
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb3/power/control
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb4/power/control
  grep phy_clock_en /sys/kernel/debug/gpio
...and see that the phy clock enable goes low when nothing is
plugged into the USB 3.0 port and goes high when something is
in the port.

Change-Id: I3b6f39d3df318c2d5db4a04949db36efcf2e919a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30184
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agousb3: exynos5: Use external phy clock when needed; shut down when not
Doug Anderson [Fri, 17 Aug 2012 19:51:39 +0000 (12:51 -0700)]
usb3: exynos5: Use external phy clock when needed; shut down when not

The usb3 phy clock is an external PLL that burns a lot of power but is
needed to pass USB 3.0 compliance testing.  When nothing is plugged
into the port we can turn the PLL off and switch to a different clock
to save power.  This other clock is enough to detect that a device
has been inserted.

We also do a little bit of cleanup to use register bit constants
introduced in a previous patch.

BUG=chrome-os-partner:11066
TEST=With other patches in this series can run:
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb3/power/control
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb4/power/control
  grep phy_clock_en /sys/kernel/debug/gpio
...and see that the phy clock enable goes low when nothing is
plugged into the USB 3.0 port and goes high when something is
in the port.

Change-Id: I0ca5ab7c8c06187251a8767768e682f43803bd7a
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30511
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agousb: dwc3: exynos5: Add support for powering off an external phy
Vivek Gautam [Fri, 17 Aug 2012 14:12:23 +0000 (10:12 -0400)]
usb: dwc3: exynos5: Add support for powering off an external phy

On exynos we need an external PLL to pass compliance.  That PLL
can burn a lot of power, so provide a mechanism for turning it off
(and switching to a lower power clock) when in runtime suspend.

NOTE: This extends the phy interface that's already there for the
exynos dwc3 controller.  Because of some of the limitations of that
interface (mainly that there's no private data for the phy) we
needed to put some of the phy-related GPIO toggling in the main
dwc3-exynos glue.  That should be cleaned up in a future patch.

BUG=chrome-os-partner:11066
TEST=With other patches in this series can run:
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb3/power/control
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb4/power/control
  grep phy_clock_en /sys/kernel/debug/gpio
...and see that the phy clock enable goes low when nothing is
plugged into the USB 3.0 port and goes high when something is
in the port.

Change-Id: Ia5ccfbd640c8c07fbd3ead8bd6d962eb25532c4a
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30734
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoEXYNOS: USB: phy: Add bit definitions for some clock settings
Doug Anderson [Fri, 17 Aug 2012 18:48:02 +0000 (11:48 -0700)]
EXYNOS: USB: phy: Add bit definitions for some clock settings

Some of these bit settings come straight from the exynos manual and
some were passed on by SLSI in another CL.  Put them in the header
file with good names to make them self-documenting.

BUG=chrome-os-partner:11066
TEST=Use this with other CLs in the series and see USB phy working

Change-Id: Icc62c4128b5e111e0f5450cb8df8dceafaa9ffe2
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30725
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUSB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend
Vivek Gautam [Mon, 13 Aug 2012 11:14:37 +0000 (07:14 -0400)]
USB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend

The current code in the dwc3 probe effectively disables suspend from
ever working because it called a get() that was never put() until
device removal.  Change the runtime pm code to match the standard
formula and allow runtime pm to function.

Note that this doesn't enable full runtime pm on the DWC3 device in
that the port isn't put into a lower power mode when not used.
However it does allow users of dwc3 (like dwc3-exynos) to do some
amount of runtime power management.

BUG=chrome-os-partner:11066
TEST=With other patches in this series can run:
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb3/power/control
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb4/power/control
  grep phy_clock_en /sys/kernel/debug/gpio
...and see that the phy clock enable goes low when nothing is
plugged into the USB 3.0 port and goes high when something is
in the port.

Change-Id: I04ec77e68953afb4365605e6e40f49bd0ca9748e
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30182
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUSB: XHCI: Enable runtime pm in xhci-plat
Vivek Gautam [Mon, 13 Aug 2012 11:17:33 +0000 (07:17 -0400)]
USB: XHCI: Enable runtime pm in xhci-plat

By enabling runtime pm in this driver is allows users of xhci-plat to
enter into runtime pm.  This is not full runtime pm support (AKA
xhci-plat doesn't actually power anything off when in runtime suspend
mode) but just basic enablement.

BUG=chrome-os-partner:11066
TEST=With other patches in this series can run:
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb3/power/control
  echo auto > \
    /sys/devices/exynos-dwc3/dwc3.0/xhci-hcd/usb4/power/control
  grep phy_clock_en /sys/kernel/debug/gpio
...and see that the phy clock enable goes low when nothing is
plugged into the USB 3.0 port and goes high when something is
in the port.

Change-Id: I76814efbe62cccd44c0622c65c393de13b2bbbcc
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30183
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agodrm/exynos: manage kds resources on a per fb-basis rather than globally
Mandeep Singh Baines [Thu, 16 Aug 2012 20:54:02 +0000 (13:54 -0700)]
drm/exynos: manage kds resources on a per fb-basis rather than globally

In order to support HDMI and LCD concurrently, we need to manage the
kds resources on a per fb basis. Having a global pointer doesn't work
when you're flipping to multiple crtcs.

This change also makes the create and destroy fb methods easier to
reason about and get correct.

BUG=chrome-os-partner:12586
TEST=Suspend/resume. VT Switch. LCD off. Some browsing.

Change-Id: I07960b98cadd5880cb4fc52ca20adde426a0a470
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30589

11 years agoRevert "CHROMIUM: regulator: implement startup-delay for boot-time settings"
Sam Leffler [Fri, 17 Aug 2012 16:22:17 +0000 (09:22 -0700)]
Revert "CHROMIUM: regulator: implement startup-delay for boot-time settings"

This reverts commit 5a87074216dedbe1d9ff7a0d2299e538c2d61322.  Don't
need this any more and it turns out it was designed wrong (startup-delay
is meant to go after, not before).

Signed-off-by: Sam Leffler <sleffler@chromium.org>
BUG=none
TEST=boot daisy and verify no regression; hand check all instances of startup-delay-us are for non-boot-time use

Change-Id: If938bef4a31d7a5cce308d2420005286d9f08c20
Reviewed-on: https://gerrit.chromium.org/gerrit/30705
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoASOC: Samsung: Change MAX98095 MCLK input clk
Padmavathi Venna [Thu, 16 Aug 2012 11:35:25 +0000 (17:05 +0530)]
ASOC: Samsung: Change MAX98095 MCLK input clk

This patch configures the codec system clock with xclkout.
with out this patch there is a error while playing 8,22.05,
32KHz sampling rate files. The error was

max98095 7-0011: Invalid master clock frequency
[ 46.194905] asoc: machine hw_params failed: -22
Stream error -22

BUG=chrome-os-partner:12733
TEST=Tested with all supported sampling frequencys in cramfs.
All are playing fine except 8KHz and 32KHz are playing with
some error messages like below

[ 1262.417869] exynos5_epll_set_rate: Invalid Clock EPLL Frequency
[ 1262.417885] failed to clk_set_rate of fout_epll for audio

Change-Id: I5891ac9bbae1eeb6befb6992699e59e3e8977c24
Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30538
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

11 years agoArm: Exynos5: Add 32MHz EPLL out clk frequency
Padmavathi Venna [Fri, 17 Aug 2012 09:09:54 +0000 (14:39 +0530)]
Arm: Exynos5: Add 32MHz EPLL out clk frequency

This patch adds 32MHz EPLL out clk frequency to support
8,32KHz audio sampling rates.The error with out this patch
was,

[ 1262.417869] exynos5_epll_set_rate: Invalid Clock EPLL Frequency
[ 1262.417885] failed to clk_set_rate of fout_epll for audio

and there are also some glitches while playing 8KHz audio file.

BUG:chrome-os-partner:12733
TEST: Tested with all supported sampling rates. 8k ans 32k sampling
rate files are playing fine with out any error and glitch.

Change-Id: If032d006a22e5b5423caa2f7ca782d34ebc48d9a
Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30675
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

11 years agoArm: Exynos5: Save the audio subsystem clocks
Padmavathi Venna [Mon, 13 Aug 2012 12:37:13 +0000 (18:07 +0530)]
Arm: Exynos5: Save the audio subsystem clocks

This patch adds the audio subsystem clocks to the exynos5_clock_save
list.

BUG=chrome-os-partner:12579
TEST=tested on Snow by playing audio before suspend and after resume
using aplay command.

Change-Id: Iae65300e482a39fd17a2697f9003c22d0ad28fdf
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29990
Reviewed-by: Prashanth Godrehal <prashanth.g@samsung.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

11 years agoCHROMIUM: x86: need compat version of sys_prctl
Olof Johansson [Fri, 17 Aug 2012 08:20:53 +0000 (01:20 -0700)]
CHROMIUM: x86: need compat version of sys_prctl

Since PR_SET_PTRACER_ANY is the equvalent of (unsigned long)-1, it
needs to be sign extended for 32-bit compat.

Powerpc was the only arch that did any kind of compat handling for prctl,
so move that code to generic location and add the PR_SET_PTRACER check
as needed for the yama module.

BUG=chromium-os:33531
TEST=run security_ptraceRestrictions

Change-Id: I2c034025de8d71b5c317318cee2e079a38461e6d
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30672
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
11 years agoexynos/mfc: add sysmmu power on/off calls
Prathyush K [Tue, 31 Jul 2012 07:50:52 +0000 (13:20 +0530)]
exynos/mfc: add sysmmu power on/off calls

This patch calls the sysmmu driver helper functions for resuming
and suspending its two sysmmus during mfc power on/off. This is required
for the sysmmus to resume/suspend along with the parent mfc device.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: I2dacc0a2bcd11e53ba8811db75ed05acb2c344c8
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29165
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>

11 years agoexynos/gsc: add sysmmu power on/off calls
Prathyush K [Tue, 31 Jul 2012 07:54:31 +0000 (13:24 +0530)]
exynos/gsc: add sysmmu power on/off calls

This patch calls sysmmu runtime helper functions from the parent
gscalar device driver during gsc start/stop streaming. This
is needed for the sysmmu to suspend/resume along with the parent
device.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: I1c6b54c39757101d36c2a0e3359ba3c00cf75d51
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29166
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>

11 years agoiommu/exynos: add runtime pm functionality
Prathyush K [Mon, 13 Aug 2012 09:53:14 +0000 (15:23 +0530)]
iommu/exynos: add runtime pm functionality

This patch adds runtime resume and runtime suspend functions to the
exynos iommu driver as well as helper functions to the sysmmu driver
interface. The sysmmu devices are enabled by calling
'platform_sysmmu_on' from the parent device driver and not during
attach_dev. Similarily the sysmmu devices are suspended by calling
'platform_sysmmu_off' from the parent device driver and not
during detach_dev. The pm_runtime_get/put calls from
attach_dev/detach_dev functinos are removed.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon video
playback. Tested on Daisy.

Change-Id: I8bdfcb31c6178d52e0c7db9d50f58bd79a560f2a
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30207
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: i2c-s3c2410: grab adapter lock while changing i2c clock
Daniel Kurtz [Sat, 11 Aug 2012 05:22:45 +0000 (13:22 +0800)]
CHROMIUM: i2c-s3c2410: grab adapter lock while changing i2c clock

We probably don't want to change I2C frequency while a transfer is in
progress.  The current implementation grabs a spinlock, but that only
protected the writes to IICCON when starting a message, it didn't protect
against clock changes in the middle of a transaction.

Note: The i2c-core already grabs the adapter lock before calling
s3c24xx_i2c_doxfer(), which ensures that only one caller is issuing a
xfer at a time.  Thus, i2c_claim is already protected by a lock.  Also,
this means it is not necessary to disable interrupts (spin_lock_irqsave)
when changing frequencies, since there won't be any i2c interrupts if
there is no on-going xfer.

Lastly, i2c_lock_adapter() may cause the cpufreq_transition to sleep if
if a xfer is in progress, but this is ok since cpufreq notifiers are
called in a kernel thread, and there are already cases where it could
sleep, such as when using i2c to update the output of a voltage
regulator.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=builds clean; i2c probes, reads and writes work during many cpufreq
     transitions.
TEST=Note: the cpufreq part of this change has no functional affect on
     exynos, where the i2c clock is independent of the cpufreq.
     But, there is a slight perfomance boost since we no longer need to
     lock/unlock an additional spinlock.

Change-Id: Ieba439ef6a4176ff83347e990e537474a1f70b65
Reviewed-on: https://gerrit.chromium.org/gerrit/29971
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoCHROMIUM: i2c-s3c2410: use exponential back off while polling for bus idle
Daniel Kurtz [Thu, 16 Aug 2012 12:25:35 +0000 (20:25 +0800)]
CHROMIUM: i2c-s3c2410: use exponential back off while polling for bus idle

Usually, the i2c controller has finished emitting the i2c STOP before the
driver reaches the bus idle polling loop.  Optimize for this most common
case by reading IICSTAT first and potentially skipping the loop.

If the cpu is faster than the hardware, we wait for bus idle in a polling
loop.  However, since the duration of one iteration of the loop is
dependent on cpu freq, and this i2c IP is used on many different systems,
use a time based loop timeout (5 ms).

We would like very low latencies to detect bus idle for the normal
'fast' case.  However, if a device is slow to release the bus for some
reason, it could hold off the STOP generation for up to several
milliseconds.  Rapidly polling for bus idle would seriously load the CPU
while waiting for it to release the bus.  So, use a partial exponential
backoff as a compromise between idle detection latency and cpu load.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:12003
TEST=On s3c2400 system with cyapa touchpad attached to an i2c port...
TEST=Confirm no large/small EV_SYN/SYN_REPORT gaps when moving finger:
  evtest | awk 'BEGIN{P=0} /SYN_REPORT/ {print ($3-P) " " $3; P=$3}'

Change-Id: Ifbcaaef413c50ef5463238af606512e3ea32a206
Reviewed-on: https://gerrit.chromium.org/gerrit/29031
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoCHROMIUM: mfd: max77686: don't read when updating if mask is 0xff
Daniel Kurtz [Wed, 15 Aug 2012 07:26:25 +0000 (15:26 +0800)]
CHROMIUM: mfd: max77686: don't read when updating if mask is 0xff

If an update is going to set all of the bits of a register, there is no
reason to read its value first.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:10891
TEST=builds clean and snow boots;
TEST=ftrace shows that most update_reg calls, when mask is 0xff, only
     cause a single i2c write

Change-Id: I14270ba5f3ef6d060401a7c6c69b6f493a9f6588
Reviewed-on: https://gerrit.chromium.org/gerrit/30551
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agos5p-mfc: Handle multi-frame input buffer
ARUN MANKUZHI [Mon, 13 Aug 2012 12:53:02 +0000 (18:23 +0530)]
s5p-mfc: Handle multi-frame input buffer

When one input buffer has more than one input frame,
mfc try run is called again with the remaining bytes.

BUG=chrome-os-partner:12027
TEST=Ran VDA unit test for VP8

Change-Id: Ia031d8a7ed0577eb6000bde5eaed86de8faf93aa
Signed-off-by: ARUN MANKUZHI <arun.m@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29986
Reviewed-by: Pawel Osciak <posciak@google.com>
Reviewed-by: Arun Kumar K <arun.kk@samsung.com>
Commit-Ready: Arun Mankuzhi <arun@chromium.org>
Tested-by: Arun Mankuzhi <arun@chromium.org>
11 years agoCHROMIUM: ASoC: Update pointer to account for pending dma transfers.
Dylan Reid [Fri, 17 Aug 2012 00:05:02 +0000 (17:05 -0700)]
CHROMIUM: ASoC: Update pointer to account for pending dma transfers.

Make dma_pointer check how much of the current dma transfer has
completed.  This improves the accuracy of the pointer operation, which
previously was only updated once a period.  Before this change calling
snd_pcm_avail() right before a dma transfer completed would indicate
that the entire transfer was still pending, now it will indicate the
actual count of free frames.

If the dma being used doesn't support the residue operation to query a
pending transfer, then assume that no bytes have been transfered.  This
leads to the same behavior as before the change.

BUG=chrome-os-partner:12278
TEST=aplay -B10000 file assure no dropouts.
cras_test_client --playback_file sine.wav --buffer_frames 960 --callback_threshold 480 --min_cb_level 480 --rate 48000

Change-Id: I9149c1b54a1e56242094ea6ea9ff6246b384851b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30615
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: ARM: SAMSUNG: Add residue DMA operation.
Dylan Reid [Thu, 16 Aug 2012 23:47:32 +0000 (16:47 -0700)]
CHROMIUM: ARM: SAMSUNG: Add residue DMA operation.

Add a new dma op, residue.  It returns the count of bytes left to be
transfered by the dma.  This is useful for Audio, the Samsung dma ASoC
layer will use this to provide an accurate update to the hw_ptr that is
exported to user space.  ASoC wants large transfers to reduce the amount
of wakeups, but needs to be able to know how much audio has been played
for latency estimates.

BUG=chrome-os-partner:12278
TEST=aplay file, add debug prints to watch the residue value change.

Change-Id: I9783e0182f94ef2016d7f424219082005f8d07a0
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30614
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: dmaengine: pl330: Set residue in tx_status callback.
Dylan Reid [Thu, 16 Aug 2012 23:31:57 +0000 (16:31 -0700)]
CHROMIUM: dmaengine: pl330: Set residue in tx_status callback.

Fill txstate.residue with the amount of bytes remaining in the current
transfer if the transfer is not complete.  This will be of particular
use to i2s DMA transfers, providing more accurate hw_ptr values to ASoC.

BUG=chrome-os-partner:12778
TEST='aplay -B10000 <filename>' should be smooth.

Change-Id: I06f49c7193ab127db135678ad8a58c3d0801f7cc
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30613
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agodrm/exynos: move exynos_drm_crtc and exynos_drm_fb defs to exynos_drm_drv.h
Mandeep Singh Baines [Thu, 16 Aug 2012 18:04:53 +0000 (11:04 -0700)]
drm/exynos: move exynos_drm_crtc and exynos_drm_fb defs to exynos_drm_drv.h

Refactoring that is required for follow-up CLs. I need to access to
the crtc and fb struct from the finish_pageflip code called by the
vblank interrupt handler.

BUG=chrome-os-partner:12586
TEST=Suspend/resume. VT switch. Browsing.

Change-Id: Icb77eae4b10d481097abd4441d14d071f99a0e0e
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30588
Reviewed-by: Pawel Osciak <posciak@google.com>
11 years agodrm/exynos: Name the connector properly.
Stéphane Marchesin [Fri, 17 Aug 2012 01:06:55 +0000 (18:06 -0700)]
drm/exynos: Name the connector properly.

If the connector isn't recognized, it won't be named properly, and Chrome
will not pick it up as a laptop LCD (and won't handle it as a laptop,
including detecting the projection). Fix this by identifying our connector
as eDP.

BUG=none
TEST=by hand, run xrandr on an exynos device, and check that the output
TEST=is now named "eDP-1" not "None-1".

Change-Id: Ief7f45818407dfa140540517e994bd0edc5479f9
Reviewed-on: https://gerrit.chromium.org/gerrit/30638
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
11 years agoUPSTREAM: staging: gdm72xx: fix reference counting in gdm_wimax_event_init
Ben Chan [Tue, 24 Jul 2012 14:49:42 +0000 (07:49 -0700)]
UPSTREAM: staging: gdm72xx: fix reference counting in gdm_wimax_event_init

This patch fixes the commit "staging/gdm72xx: cleanup little at
gdm_wimax_event_rcv" (8df858ea76b76dde9a39d4edd9aaded983582cfe),
which mishandles the reference counting of wm_event.

Signed-off-by: Ben Chan <benchan@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 472aba5f91fd6413c9c75e71366f133aa8c7f2f2)

Change-Id: I5aa436ba6a3d01ccd68dd355b6d9405776ea3e2c
Reviewed-on: https://gerrit.chromium.org/gerrit/30133
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
11 years agoUPSTREAM: staging/gdm72xx: cleanup little at gdm_wimax_event_rcv
Devendra Naga [Thu, 12 Jul 2012 06:12:25 +0000 (11:57 +0545)]
UPSTREAM: staging/gdm72xx: cleanup little at gdm_wimax_event_rcv

the event sock check is done at the netlink_init itself.

Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8df858ea76b76dde9a39d4edd9aaded983582cfe)

Change-Id: I8ef8a42bdd6ac462211344371174a20d28b049a9
Reviewed-on: https://gerrit.chromium.org/gerrit/30132
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
11 years agoARM: EXYNOS5: powering on ISP pd before suspend
Prathyush K [Fri, 10 Aug 2012 13:07:14 +0000 (18:37 +0530)]
ARM: EXYNOS5: powering on ISP pd before suspend

The ISP pd needs to be powered on before suspending and then
powered off after resuming. This is a software workaround and should
be removed later. It is noticed that the board does not resume if ISP
is powered off before suspend. ISP is powered down during bootup as
it is an unused IP.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon video
playback. Tested on Daisy.

Change-Id: Ibb1663cb4fb2c2bca8c4df875d90afd6e770d310
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30205
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>

11 years agoCHROMIUM: chromeos_arm: Process ChromeOS GPIOs statically defined in the dt.
Gabe Black [Thu, 16 Aug 2012 09:16:14 +0000 (02:16 -0700)]
CHROMIUM: chromeos_arm: Process ChromeOS GPIOs statically defined in the dt.

This change turns the chromeos_arm init code into a driver and device so that
it can have GPIOs attached to it by links which have nice, friendly names
instead of just numbers. The code which processes the GPIO is split out into
a separate function so that it can be reused in case other switches need the
same treatment.

BUG=chrome-os-partner:11297
TEST=Used update_kernel.sh to put onto a snow. Verified that the gpio showed
up as /sys/devices/platform/chromeos_arm/write-protect/.

Change-Id: Ie52a5b3dd751b05bd03c57aab316abe309821fbc
Signed-off-by: Gabe Black <gabeblack@google.com>
[olofj: cleanup, removed args, bindings update]
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30533

11 years agoCHROMIUM: chromeos_arm: cleanups
Olof Johansson [Thu, 16 Aug 2012 21:01:35 +0000 (14:01 -0700)]
CHROMIUM: chromeos_arm: cleanups

Print with dev_* now that we have a platform device.

Also, u-boot doesn't pass along a copy of the nvblock. :( So remove the
checks for it and revise the comment.

BUG=none
TEST=boot, check for chromeos_arm in dmesg

Change-Id: I9a2258a6c475450479e1ad39b8632c580ad0ab27
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30587
Reviewed-by: Simon Glass <sjg@chromium.org>
11 years agoCHROMIUM: Add the write protect switch to the snow device tree
Gabe Black [Thu, 16 Aug 2012 09:07:32 +0000 (02:07 -0700)]
CHROMIUM: Add the write protect switch to the snow device tree

Having this GPIO statically defined in the device tree instead of having it
passed in by U-Boot avoids the problem of U-Boot's GPIO numbering not matching
the kernel's.

BUG=chrome-os-partner:11297
TEST=Built with other changes, booted, and verified that the chromeos_arm
driver correctly parsed the new device tree entries.

Change-Id: I6b8a39770ef4d904393ccb20e40fffed8d3ad404
Signed-off-by: Gabe Black <gabeblack@google.com>
[olofj: Fixed up bindings, removed compatible field from firmware node]
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30532

11 years agoCHROMIUM: exynos: snow: specify suspend state for all pins
Jonathan Kliegman [Tue, 7 Aug 2012 17:38:02 +0000 (13:38 -0400)]
CHROMIUM: exynos: snow: specify suspend state for all pins

By default all pins go active low on suspend.  As this isn't
the desired state for all circuits on the device, specify
the actual state we want each pin in on suspend.

BUG=chrome-os-partner:11988
TEST=On device, validate:
  i2c devices resume correctly
  i2c arbitration values are correct on EC
  EC battery command works correctly
  resume functions normally
  power_Resume test runtime has no regression

Change-Id: Ia70fe26342ceb6fea974ef7d08d488ce3d12a58f
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30026
Reviewed-by: Frank Hislop <frh@google.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
11 years agoARM: EXYNOS5: save CLK_TOP_SRC3 register before powergating
Prathyush K [Tue, 14 Aug 2012 14:36:40 +0000 (20:06 +0530)]
ARM: EXYNOS5: save CLK_TOP_SRC3 register before powergating

After S2R, the CLK_TOP_SRC3 register gets modified if the GSC/MFC devices are
powergated. This is a software workaround for this problem and will be
removed later.

To reproduce the problem:
Boot the board
Run S2R
Read CLK_TOP_SRC3 (armio 0x1002021C) This will show: 0x01000550
Powergate GSC (armiow 0x10044000 0)
Read CLK_TOP_SRC3 (armio 0x1002021C) This will show: 0x01000050
Power on GSC (armiow 0x10044000 7)
Read CLK_TOP_SRC3 (armio 0x1002021C) This will show: 0x01000050

The clock for gscalar gets set to XXTI which results in the gscalar
device running very slow and we notice a big drop in performance when
running video. Similar issue exists with powergating MFC. This is
observed only after S2R and not before.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: I5901f4cc05fa5a42e7bdabb99bfbf1d31acb060c
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30206
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoARM: EXYNOS5: dts: add power domain property to mfc/gscalar/sysmmu nodes
Prathyush K [Tue, 31 Jul 2012 08:58:07 +0000 (14:28 +0530)]
ARM: EXYNOS5: dts: add power domain property to mfc/gscalar/sysmmu nodes

This patch adds the powerdomain property to the mfc/gsc/sysmmu nodes which
points to their respective power domain nodes. This property is retrieved
during the driver's probe and the device is added to its power domain.
MFC and its sysmmus are added to mfc_pd and all the gscalar devices and
their sysmmus are added to the gsc_pd.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon video
playback. Tested on Daisy.

Change-Id: Ifc811fb847e434b116b76dc85b908b6c0da187a5
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29161
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoARM: EXYNOS: Enable PM_GENERIC_DOMAINS for exynos
Prathyush K [Mon, 13 Aug 2012 12:22:20 +0000 (17:52 +0530)]
ARM: EXYNOS: Enable PM_GENERIC_DOMAINS for exynos

This patch enables PM_GENERIC_DOMAINS for the exynos chipset.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon video
playback. Tested on Daisy.

Change-Id: I3a4f7c4b8f280010608c2f04104b29b6a01a174a
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30204
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoexynos/gsc: add gscalar device to its power domain
Naveen krishna Chatradhi [Tue, 31 Jul 2012 06:29:02 +0000 (11:59 +0530)]
exynos/gsc: add gscalar device to its power domain

This patch adds the gscalar devices to its power domain by calling
the function 'pm_genpd_of_add_device_by_name'. The power domain
is found by searching for a of property 'samsung,pd' in the of node.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: Ia1056b06c85a4bfbd6a44aaa131f6145492767a7
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29163
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoexynos/mfc: add mfc device to power domain
Naveen krishna Chatradhi [Tue, 31 Jul 2012 06:30:19 +0000 (12:00 +0530)]
exynos/mfc: add mfc device to power domain

This patch adds the mfc device to the genpd by calling the
function 'pm_genpd_of_add_device_by_name'. The power domain
is found by searching for a of property 'samsung,pd' in the of node.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: Idc4b08608dec668cdd8bb706c0e4460d3fe5f351
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29164
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoiommu/exynos: add exynos sysmmu device to power domain
Prathyush K [Tue, 31 Jul 2012 06:26:16 +0000 (11:56 +0530)]
iommu/exynos: add exynos sysmmu device to power domain

This patch adds the sysmmu devices to genpd by calling the
function 'pm_genpd_of_add_device_by_name'. The power domain
is found by searching for a of property 'samsung,pd' in the of node.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon video
playback. Tested on Daisy.

Change-Id: I4ce7949a1742d95327420094208583ddbc071bb0
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29162
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoPM / Domains: add generic function 'pm_genpd_of_add_device_by_name'
Prathyush K [Thu, 16 Aug 2012 12:35:16 +0000 (18:05 +0530)]
PM / Domains: add generic function 'pm_genpd_of_add_device_by_name'

A new function pm_genpd_of_add_device_by_name is added to the pm_domain
file. This function takes three parameters - target device to be added to
genpd, a device node and the name of the property. This function reads
the "propname" property from the device node and finds the corresponding
genpd device node. The target device is then added to this genpd by
calling __pm_genpd_of_add_device.

of_property_read_u32(dev_node, propname, &val);
genpd_node = of_find_node_by_phandle(val);
__pm_genpd_of_add_device(genpd_node, dev, NULL);

Change-Id: I03933a2ad95355c154018b40e351d51da1b96867
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30522
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: ath9k: fix decrypt_error initialization in ath_rx_tasklet()
Lorenzo Bianconi [Fri, 10 Aug 2012 09:00:24 +0000 (11:00 +0200)]
UPSTREAM: ath9k: fix decrypt_error initialization in ath_rx_tasklet()

ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium-os:25036
TEST=WiFiSecMat

Change-Id: I200265f25909f06f5ded0c9e75c37b8c0b670155
Reviewed-on: https://gerrit.chromium.org/gerrit/30438
Reviewed-by: Gary Morain <gmorain@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY buses
Daniel Kurtz [Tue, 14 Aug 2012 12:52:54 +0000 (20:52 +0800)]
CHROMIUM: i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY buses

The datasheet says that the STOP sequence should be:
 1) I2CSTAT.5 = 0 - Clear BUSY (or 'generate STOP')
 2) I2CCON.4 = 0 - Clear IRQPEND
 3) Wait until the stop condition takes effect.
 4*) I2CSTAT.4 = 0  - Clear TXRXEN

Where, step "4*" is only for buses with the "HDMIPHY" quirk.

However, after much experimentation, it appears that:
 a) normal buses automatically clear BUSY and transition from
    Master->Slave when they complete generating a STOP condition.
    Therefore, step (3) can be done in doxfer() by polling I2CCON.4
    after starting the STOP generation here.
 b) HDMIPHY bus does neither, so there is no way to do step 3.
    There is no indication when this bus has finished generating STOP.

In fact, we have found that as soon as the IRQPEND bit is cleared in
step 2, the HDMIPHY bus generates the STOP condition, and then immediately
starts transferring another data byte, even though the bus is supposedly
stopped.  This is presumably because the bus is still in "Master" mode,
and its BUSY bit is still set.

To avoid these extra post-STOP transactions on HDMI phy devices, we just
disable Serial Output on the bus (I2CSTAT.4 = 0) directly, instead of
first generating a proper STOP condition.  This should float SDA & SCK
terminating the transfer.  Subsequent transfers start with a proper START
condition, and proceed normally.

The HDMIPHY bus is an internal bus that always has exactly two devices,
the host as Master and the HDMIPHY device as the slave. Skipping the STOP
condition has been tested on this bus and works.

Also, since we disable the bus directly from the isr, we can skip the bus
idle polling loop at the end of doxfer().

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:10089
TEST=No "s3c-i2c 12ce0000.i2c: timeout waiting for bus idle" in dmesg
TEST=HDMI output works after hot plug
 1) EDID displayed in /var/log/Xorg.0.log
 2) Video shown on external monitor

Change-Id: Ic6518aceba46a058b65e6adff1bc7a5a295eb5b0
Reviewed-on: https://gerrit.chromium.org/gerrit/29876
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
11 years agoARM: EXYNOS5: dts: Add power domain nodes for exynos5
Prathyush K [Tue, 31 Jul 2012 06:19:27 +0000 (11:49 +0530)]
ARM: EXYNOS5: dts: Add power domain nodes for exynos5

This patch adds the power domain nodes for various ips to the
exynos5250 dtsi.

BUG=chrome-os-partner:11793
TEST=Kernel boots and genpd is able to parse through all the
power domains. Tested on Daisy.

Change-Id: I9573aaea970af91d23a2679990d219111ef0f1be
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29160
Tested-by: naveen krishna chatradhi <naveen@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: [TG3] : Disable WOL by default
Benson Leung [Wed, 15 Aug 2012 21:51:05 +0000 (14:51 -0700)]
CHROMIUM: [TG3] : Disable WOL by default

Do not set WOL_ENABLE by default at init. WOL_CAP is still enabled,
so it can be set later on.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:12127
TEST=On a system with a tg3 ethernet MAC (parrot), do the following
1. run "ethtool -s eth0 wol g" to enable WOL from PHY activity
2. reboot the system
3. run "ethtool eth0" and check that "g" is not listed in "Wake-on"

Change-Id: I59de49028ef925a08bebf46255220abc9d6d6a2a
Reviewed-on: https://gerrit.chromium.org/gerrit/30473
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
11 years agoARM: SAMSUNG: use spin_lock_irqsave() in clk_set_parent
Mandeep Singh Baines [Fri, 20 Jan 2012 02:03:07 +0000 (11:03 +0900)]
ARM: SAMSUNG: use spin_lock_irqsave() in clk_set_parent

From 0cdf3aff, "ARM: SAMSUNG: use spin_lock_irqsave() in
clk_{enable,disable}":

  The clk_enable()and clk_disable() can be used process and ISR either.
  And actually it is used for real product and other platforms use it
  now. So spin_lock_irqsave() should be used instead.

We need to make a similar change in clk_set_parent(). Otherwise,
you can potentially get spinlock recursion:

BUG: spinlock recursion on CPU#0, kinteractive/68
 lock: 807832a8, .magic: dead4ead, .owner: kinteractive/68, .owner_cpu: 0
[<80015f54>] (unwind_backtrace+0x0/0x128) from [<804f2914>] (dump_stack+0x20/0x24)
[<804f2914>] (dump_stack+0x20/0x24) from [<804f57b8>] (spin_dump+0x80/0x94)
[<804f57b8>] (spin_dump+0x80/0x94) from [<804f57f8>] (spin_bug+0x2c/0x30)
[<804f57f8>] (spin_bug+0x2c/0x30) from [<80222730>] (do_raw_spin_lock+0x54/0x150)
[<80222730>] (do_raw_spin_lock+0x54/0x150) from [<804f96ec>] (_raw_spin_lock_irqsave+0x20/0x28)
[<804f96ec>] (_raw_spin_lock_irqsave+0x20/0x28) from [<80022ea4>] (clk_enable+0x3c/0x84)
[<80022ea4>] (clk_enable+0x3c/0x84) from [<8038336c>] (s5p_mfc_clock_on+0x60/0x74)
[<8038336c>] (s5p_mfc_clock_on+0x60/0x74) from [<8038645c>] (s5p_mfc_read_info+0x20/0x38)
[<8038645c>] (s5p_mfc_read_info+0x20/0x38) from [<8037ca3c>] (s5p_mfc_handle_frame+0x2e4/0x4bc)
[<8037ca3c>] (s5p_mfc_handle_frame+0x2e4/0x4bc) from [<8037d420>] (s5p_mfc_irq+0x1ec/0x6cc)
[<8037d420>] (s5p_mfc_irq+0x1ec/0x6cc) from [<8007fc74>] (handle_irq_event_percpu+0x8c/0x244)
[<8007fc74>] (handle_irq_event_percpu+0x8c/0x244) from [<8007fe78>] (handle_irq_event+0x4c/0x6c)
[<8007fe78>] (handle_irq_event+0x4c/0x6c) from [<80082dd8>] (handle_fasteoi_irq+0xe4/0x150)
[<80082dd8>] (handle_fasteoi_irq+0xe4/0x150) from [<8007f424>] (generic_handle_irq+0x3c/0x50)
[<8007f424>] (generic_handle_irq+0x3c/0x50) from [<8000f7c4>] (handle_IRQ+0x88/0xc8)
[<8000f7c4>] (handle_IRQ+0x88/0xc8) from [<80008564>] (gic_handle_irq+0x44/0x68)
[<80008564>] (gic_handle_irq+0x44/0x68) from [<8000e400>] (__irq_svc+0x40/0x60)
Exception stack(0xef3cbe68 to 0xef3cbeb0)
[<8000e400>] (__irq_svc+0x40/0x60) from [<80022cfc>] (clk_set_parent+0x30/0x74)
[<80022cfc>] (clk_set_parent+0x30/0x74) from [<803ac7f8>] (set_apll.isra.0+0x28/0xb0)
[<803ac7f8>] (set_apll.isra.0+0x28/0xb0) from [<803ac8e4>] (exynos5250_set_frequency+0x64/0xb8)
[<803ac8e4>] (exynos5250_set_frequency+0x64/0xb8) from [<803ac280>] (exynos_target+0x1b0/0x220)
[<803ac280>] (exynos_target+0x1b0/0x220) from [<803a4a0c>] (__cpufreq_driver_target+0xb0/0xd4)
[<803a4a0c>] (__cpufreq_driver_target+0xb0/0xd4) from [<803aab80>] (cpufreq_interactive_updown_task+0x214/0x264)
[<803aab80>] (cpufreq_interactive_updown_task+0x214/0x264) from [<80047d04>] (kthread+0x9c/0xa8)
[<80047d04>] (kthread+0x9c/0xa8) from [<8000fa48>] (kernel_thread_exit+0x0/0x8)

BUG=chrome-os-partner:12565
TEST=Did some browsing.

Change-Id: Ie6541c96aac0648b4fd96d426cddbcde77e7d15f
LKML-Reference: <1345058187-18843-1-git-send-email-msb@chromium.org>
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Suggested-by: Sunil Mazhavanchery <sunilm@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30445
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: printk: prevent unbounded time inside console_unlock
Mandeep Singh Baines [Wed, 15 Aug 2012 06:16:50 +0000 (23:16 -0700)]
CHROMIUM: printk: prevent unbounded time inside console_unlock

We are seeing softlockups inside console_unlock():

BUG: soft lockup - CPU#0 stuck for 12s! [rsyslogd:285]
PC is at _raw_spin_lock_irqsave+0x10/0x28
LR is at down_trylock+0x1c/0x3c
(_raw_spin_lock_irqsave+0x10/0x28) from [<8004d830>] (down_trylock+0x1c/0x3c)
(down_trylock+0x1c/0x3c) from [<80028e40>] (console_trylock+0x1c/0x60)
(console_trylock+0x1c/0x60) from [<800292f8>] (console_unlock+0x1c8/0x1f4)
(console_unlock+0x1c8/0x1f4) from [<80268e74>] (do_con_write.part.14+0x1cc8/0x1cf4)
(do_con_write.part.14+0x1cc8/0x1cf4) from [<80268f34>] (con_write+0x40/0x54)
(con_write+0x40/0x54) from [<802547c0>] (do_output_char+0xa0/0x1c8)
(do_output_char+0xa0/0x1c8) from [<80254928>] (process_output+0x40/0x5c)
(process_output+0x40/0x5c) from [<80255170>] (n_tty_write+0x28c/0x3b4)
(n_tty_write+0x28c/0x3b4) from [<80251ea8>] (tty_write+0x198/0x238)
(tty_write+0x198/0x238) from [<800ed208>] (vfs_write+0xc4/0x140)
(vfs_write+0xc4/0x140) from [<800ed484>] (sys_write+0x4c/0x78)
(sys_write+0x4c/0x78) from [<8000e7c0>] (ret_fast_syscall+0x0/0x30)

The softlockup can be caused by a printk storm. Since console_unlock
can retry an unbounded number of times, we can get stuck in inside
for an unbounded amount of time. The fix is to schedule work instead
of retrying inside console_unlock() when there is more work to do.

Upstream:

printk.c upstream is dramatically different from 3.4 so I'll need to
write a new patch to send upstream.

BUG=chrome-os-partner:12565
TEST=See below.

$ dmesg # verify OK
$ reboot

*reboot*

$ cat /dev/pstore/console-ramoops # verify OK
$ dmesg # verify OK
$ echo bug > /proc/breakme

*crash*

$ cat /dev/pstore/console-ramoops # verify OK
$ cat /var/spool/*.kcrash # verify OK

Change-Id: If2955af0bd96b8a27b87f6a4306094c019a86dc7
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30384
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: gpu: i915: Make RP down timeout shorter
Sameer Nanda [Mon, 13 Aug 2012 21:33:02 +0000 (14:33 -0700)]
CHROMIUM: gpu: i915: Make RP down timeout shorter

Make the GEN6_RP_DOWN_TIMEOUT significantly shorter -- from 1000000 to
10000. This helps save about 1W of power by keeping the GPU running at
lower frequency for longer.

BUG=none
TEST=playback a youtube video at 1080p and ensure there are no dropped
frames.

Change-Id: Id201a8eabdccad9e79fcc6383fdfc53e039300da
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30036
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agodrm/exynos: Fix HDMI for smaller resolutions
Sean Paul [Tue, 14 Aug 2012 23:57:43 +0000 (16:57 -0700)]
drm/exynos: Fix HDMI for smaller resolutions

This patch fixes HDMI output for resolutions smaller than the LCD. The
problem is that the pitch is slightly larger than the LCD width, which
results in the HDMI scanout being slighlty too large. This shifts each
line right by the difference between pitch and width resulting in a
corrupted screen.

BUG=chrome-os-partner:12606
TEST=Tested on snow with 720p/480p

Change-Id: I1764b0c3d4c699a9a87f083ce74331f99f0bc387
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30351
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: config: enable RCU_FAST_NO_HZ
Sameer Nanda [Tue, 14 Aug 2012 19:06:37 +0000 (12:06 -0700)]
CHROMIUM: config: enable RCU_FAST_NO_HZ

Enable RCU_FAST_NO_HZ kernel config option. This allows the CPU to get to
idle state quicker and saves about 100-200mW of power on x86 systems
under medium load conditions.

BUG=none
TEST=build kernel and ensure that CONFIG_RCU_FAST_NO_HZ is to y in the
kernel config file.

Change-Id: I85a0ca5f8cebb55c83582cbc43fffd49984185a3
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30271
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoUPSTREAM: ARM: dma-mapping: fix incorrect freeing of atomic allocations
Aaro Koskinen [Tue, 7 Aug 2012 12:44:05 +0000 (14:44 +0200)]
UPSTREAM: ARM: dma-mapping: fix incorrect freeing of atomic allocations

Commit e9da6e9905e639b0f842a244bc770b48ad0523e9 (ARM: dma-mapping:
remove custom consistent dma region) changed the way atomic allocations
are handled. However, arm_dma_free() was not modified accordingly, and
as a result freeing of atomic allocations does not work correctly when
CMA is disabled. Memory is leaked and following WARNINGs are seen:

[   57.698911] ------------[ cut here ]------------
[   57.753518] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
[   57.811473] trying to free invalid coherent area: e0848000
[   57.867398] Modules linked in: sata_mv(-)
[   57.921373] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
[   58.033924] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
[   58.152024] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
[   58.219592] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
[   58.345526] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
[   58.475782] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
[   58.614260] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
[   58.756527] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
[   58.901648] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
[   59.051447] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
[   59.207996] ---[ end trace 0745420412c0325a ]---
[   59.287110] ------------[ cut here ]------------
[   59.366324] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
[   59.450511] trying to free invalid coherent area: e0847000
[   59.534357] Modules linked in: sata_mv(-)
[   59.616785] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
[   59.790030] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
[   59.972322] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
[   60.070701] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
[   60.256817] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
[   60.445201] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
[   60.634148] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
[   60.823623] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
[   61.013268] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
[   61.203472] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
[   61.393390] ---[ end trace 0745420412c0325b ]---

The patch fixes this.

BUG=chrome-os-partner:12602
TEST=Boot.  Test USB 3.0 across suspend/resume.

Change-Id: I6631d8be7389b397ac533ed0be52aae673b91a2c
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit d9e0d149b5dcc2ef4688afc572b9906bcda941ef)
Reviewed-on: https://gerrit.chromium.org/gerrit/29993
Tested-by: Vikas Sajjan <vikas.sajjan@samsung.com>
11 years agoUPSTREAM: ARM: dma-mapping: fix atomic allocation alignment
Aaro Koskinen [Tue, 7 Aug 2012 12:39:25 +0000 (14:39 +0200)]
UPSTREAM: ARM: dma-mapping: fix atomic allocation alignment

The alignment mask is calculated incorrectly. Fixing the calculation
makes strange hangs/lockups disappear during the boot with Amstrad E3
and 3.6-rc1 kernel.

BUG=chrome-os-partner:12602
TEST=Boot.  Test USB 3.0 across suspend/resume.

Change-Id: Ic801c21c23c6dec1fd0ccf32a50312d6f486ed34
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit e4ea6918c93b9f59d34e8ca2124b2b64b1afe73b)
Reviewed-on: https://gerrit.chromium.org/gerrit/29992
Tested-by: Vikas Sajjan <vikas.sajjan@samsung.com>
11 years agoCHROMIUM: ASoC: max98095 - Export switches for MIC3 route.
Dylan Reid [Mon, 13 Aug 2012 22:31:28 +0000 (15:31 -0700)]
CHROMIUM: ASoC: max98095 - Export switches for MIC3 route.

MIC3 can route to either the MIC1 or MIC2 input.  Add a switch that
selects MIC3 as the source for each.

BUG=chrome-os-partner:10849
TEST=Set control with amixer check value with i2cdump.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I7095202d272f6d61bbf004426b3ce7cd2b710b5e
Reviewed-on: https://gerrit.chromium.org/gerrit/30166
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
11 years agoCHROMIUM: ASoC: max98095 - Add control for DMIC1 enable.
Dylan Reid [Mon, 13 Aug 2012 22:28:44 +0000 (15:28 -0700)]
CHROMIUM: ASoC: max98095 - Add control for DMIC1 enable.

Add ability to switch the digital mic path on and off.  Daisy needs to
change this when an external mic is attached.  Just setting DMIC on/off
in device tree isn't sufficient.

BUG=chrome-os-partner:10849
TEST=Set control with amixer and check value with i2cdump.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: Ied02eccb060a06742208ec7f8c3ef08e5f361964
Reviewed-on: https://gerrit.chromium.org/gerrit/30165
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
11 years agogpio: samsung: Add 'maintain powerup settings' option to powerdown-settings
Jonathan Kliegman [Tue, 14 Aug 2012 14:42:46 +0000 (10:42 -0400)]
gpio: samsung: Add 'maintain powerup settings' option to powerdown-settings

Allow a gpio to be configured to maintain the current active setting when
powered down.  This will preserve the GPIO in its current powered
configuration while suspended.

BUG=None
TEST=Change GPA1(2,3) (an i2c bus) to use the maintain option.
  Observed that the bus remained high during suspend and that
  the GPIO save/restore state messages showed the new value.
  Tested that devices on the i2c bus functioned properly on
  resume.
  Set GPA1(2,3) to default values (active low).  Observed
  devices on the bus did not function on resume due to the bad
  GPIO values confusing it.
  Set GPA2(0,1), GPF0(3) and GPE0(4) to preserve values. (EC i2c bus,
  and arbitration GPIOs).  Battery command from ec console worked during
  suspend and dmesg output confirmed values.

Change-Id: I83965830b6c2b247d2cffbf09884144df039219b
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30199
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agovideo/exynos: dp: Add reporter to log dp errors
Sean Paul [Mon, 13 Aug 2012 18:19:17 +0000 (11:19 -0700)]
video/exynos: dp: Add reporter to log dp errors

This patch adds an error reporter work function to check the error count
from DPCD every 60 seconds and report any errors that have occurred in
the last minute. This will hopefully give us an indication about how
frequently we're getting screen glitches.

BUG=chrome-os-partner:12498
TEST=Tested on flickery snow, saw the errors being printed to logs

Change-Id: Idba96f63f0829c55f3c6378c399403c9de7dc123
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30012
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoCHROMIUM: sysrq: fix Chrome OS specific 'x' key handler to work on ARM
Mandeep Singh Baines [Mon, 13 Aug 2012 20:33:08 +0000 (13:33 -0700)]
CHROMIUM: sysrq: fix Chrome OS specific 'x' key handler to work on ARM

The current handler generates a NULL pointer derefence so you are relying
on a side-effect for the panic. Instead, just call panic directly.

BUG=chromium-os:33505
TEST=alt-F10-x now works on ARM

Change-Id: Ie980a68be4be38b2d80c01b808ccdbc9aaf9bd76
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30025
Reviewed-by: Sameer Nanda <snanda@chromium.org>
11 years agoCHROMIUM: config: enable pstore console
Mandeep Singh Baines [Sat, 11 Aug 2012 04:10:03 +0000 (21:10 -0700)]
CHROMIUM: config: enable pstore console

Enable pstore console so that we can examine dmesg even when the
machine is hard hung.

BUG=chromium-os:33273
TEST=none

Change-Id: Ieff786cdfee41b5be76a9f4a96bd9981b6cdbe86
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29961
Reviewed-by: Kees Cook <keescook@chromium.org>
11 years agoHACK: UPSTREAM: add pstore console support
Mandeep Singh Baines [Sat, 11 Aug 2012 04:01:16 +0000 (21:01 -0700)]
HACK: UPSTREAM: add pstore console support

Pstore console keeps a console in ram that is available next boot via:

/dev/pstore/console-ramoops

PSTORE_CONSOLE is upstream but there has been a lot of churn in the
pstore code that preceded PSTORE_CONSOLE. So rather than backport
a dozen or so patches, I've added support from scratch and made the
user-space interface consistent with what is upstream.

BUG=chromium-os:33273
TEST=See below.

$ reboot
$ cat /dev/pstore/console-ramoops
$ echo bug > /proc/breakme

Crash

$ cat /dev/pstore/console-ramoops
$ cat /dev/pstore/dmesg-ramoops-0

EC reset

$ cat /dev/pstore/console-ramoops
$ rm /dev/pstore/dmesg-ramoops-0
$ reboot
$ cat /dev/pstore/console-ramoops
$ cat /dev/pstore/dmesg-ramoops-0
$ echo panic > /proc/breakme

Crash

$ cat /dev/pstore/console-ramoops
$ cat /dev/pstore/dmesg-ramoops-0

Change-Id: I1069d974679577c980276f822f7835f9d221d12b
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29960
Reviewed-by: Kees Cook <keescook@chromium.org>
11 years agoUPSTREAM: pstore: Add console log messages support
Anton Vorontsov [Sat, 26 May 2012 13:20:19 +0000 (06:20 -0700)]
UPSTREAM: pstore: Add console log messages support

Pstore doesn't support logging kernel messages in run-time, it only
dumps dmesg when kernel oopses/panics. This makes pstore useless for
debugging hangs caused by HW issues or improper use of HW (e.g.
weird device inserted -> driver tried to write a reserved bits ->
SoC hanged. In that case we don't get any messages in the pstore.

Therefore, let's add a runtime logging support: PSTORE_TYPE_CONSOLE.

Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f29e5956aebafe63f81e80f972c44c4a666e5c7f)

BUG=chromium-os:33273
TEST=none

Change-Id: Ie171bdc67bc24b0f47adfd014e21743f0975d941
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29959
Reviewed-by: Kees Cook <keescook@chromium.org>
11 years agoUPSTREAM: mwifiex: notify cfg80211 about MIC failures
Bing Zhao [Sat, 11 Aug 2012 03:49:07 +0000 (20:49 -0700)]
UPSTREAM: mwifiex: notify cfg80211 about MIC failures

Call cfg80211_michael_mic_failure() handler when there is a MIC error
event from firmware.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wireless-testing.git commit 9c7ff73

BUG=chrome-os-partner:12591
TEST=Build and run autotest WiFiMatFunc, WiFiSecMat, WiFiManager

Change-Id: Ifdb80abe98b8f38ccd16c70fd84718799d22930d
Reviewed-on: https://gerrit.chromium.org/gerrit/29958
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
11 years agodrm/exynos: hdmi: Use drm_display_mode to set registers
Sean Paul [Sat, 11 Aug 2012 02:29:22 +0000 (19:29 -0700)]
drm/exynos: hdmi: Use drm_display_mode to set registers

Program the core and timing generator registers using the timing data
provided in drm_display_mode instead of using hardcoded configurations.
This allows us to support more than just 4 video modes.

Due to lack of definition in the datasheet, this patch removes
interlaced mode support for the timing being.

BUG=chrome-os-partner:11790
TEST=Tested on snow using a Samsung panel

Change-Id: I1d8c27c837a38a4b095993c7f029c5374631995c
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29956

11 years agoCHROMIUM: arm: exynos: Only support one LCD mode
Sean Paul [Fri, 10 Aug 2012 23:32:55 +0000 (16:32 -0700)]
CHROMIUM: arm: exynos: Only support one LCD mode

Remove the 1280x720 mode for the internal LCD. The panel doesn't support
it, so it doesn't make sense.

BUG=chrome-os-partner:11790
TEST=Booted snow, switched back and forth between displays

Change-Id: Ifb50080e2f1793c986a8ea5102ddd7f8f9f9ee5c
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29955
Reviewed-by: Mark Hayter <mdhayter@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
11 years agov4l: s5p-mfc: Clean the driver from build macros
Naveen Krishna Chatradhi [Wed, 8 Aug 2012 09:37:41 +0000 (18:37 +0900)]
v4l: s5p-mfc: Clean the driver from build macros

The s5p-mfc uses SAMSUNG_S5P_MFC_V6 to conditionally compile
a part of code specific to MFC_v6, As we are only supporting
MFC_V6 hardware for Chrome. We can remove the conditional
compilation.

The Upstream patches at
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/51225
Will fix it in mainline linux.

BUG=chrome-os-partner:10954
TEST=Build and booted on one device, the MFC probes successfully

Change-Id: If409071ce806bd590d170231b94dd744f8fc0510
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29601
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
11 years agov4l: s5p-mfc: use mclk name as drvdata instead of a macro
Naveen Krishna Chatradhi [Wed, 8 Aug 2012 07:21:10 +0000 (16:21 +0900)]
v4l: s5p-mfc: use mclk name as drvdata instead of a macro

The mclk_name is different in the clock-exynos*.c for
Exynos4 and 5. Instead of using macros to distinguish the clock
name. Pass it through the drvdata available in the driver.

BUG=chrome-os-partner:10954
TEST=build and booted on one board, MFC probes fine

Change-Id: I0dee10b96c8f1df7e28403029bc9016046ccdea3
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29598
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
11 years agoHACK: ARM: exynos: revamp WiFi power-on sequence
Sam Leffler [Tue, 17 Jul 2012 19:37:02 +0000 (12:37 -0700)]
HACK: ARM: exynos: revamp WiFi power-on sequence

Manually sequence the PDn and RESETn lines to match the mlw8797 spec.
The sequence now waits for SLP_CLK to settle before raising RESETn,
waiting 1.5ms (min time specified is 1ms), and then raising PDn.
Remove the explicit BT reset as the BT and WiFi reset lines are tied.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
BUG=chrome-os-partner:11366
TEST=manual:repeated boot of various boards

Change-Id: Id2b02641c6966c6c353ba420c2716df1f8e1da97
Reviewed-on: https://gerrit.chromium.org/gerrit/29441
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: ALSA: hda - Don't resume unless needed.
Dylan Reid [Wed, 8 Aug 2012 00:10:27 +0000 (17:10 -0700)]
CHROMIUM: ALSA: hda - Don't resume unless needed.

When snd_hda_resume is called during system resume, don't resume the
codec unless it is needed.  If power_count is zero then the resume path
will be executed when it increments if the device is later opened.

BUG=chrome-os-partner:11780
TEST=power_Resume run with and without audio playing, also just after audio
stops playing.  Manually test on Lumpy with youtube audio and opening and
closing the lid.

Change-Id: I306e921c1ccbb1ce012a527bb9acbeba0b5ae5a8
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29537
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: Add gpio-charger to cros5250 device tree
Simon Que [Thu, 9 Aug 2012 02:01:16 +0000 (19:01 -0700)]
CHROMIUM: Add gpio-charger to cros5250 device tree

Use the gpio-charger driver to support AC in Exynos 5250.

BUG=chrome-os-partner:11739
TEST=/sys/class/power_supply contains gpio-charger sysfs

Change-Id: I04cb41240a175e7212e5b149fa0245faec333c0a
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29564
Reviewed-by: Benson Leung <bleung@chromium.org>
11 years agoCHROMIUM: chromeos_laptop : Remove Atmel 224s platform data
Yufeng Shen [Thu, 9 Aug 2012 23:37:00 +0000 (19:37 -0400)]
CHROMIUM: chromeos_laptop : Remove Atmel 224s platform data

Loading config data from file now so remove the platform
data for atmel 224s trackpad.

Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chrome-os-partner:11181
TEST=build and test that the trackpad is still working.

Change-Id: Ic2141fd3ab88f96270d17589355b117d036e3596
Reviewed-on: https://gerrit.chromium.org/gerrit/29840
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Yufeng Shen <miletus@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
11 years agoCHROMIUM: drivers: device tree support for gpio-charger
Simon Que [Thu, 9 Aug 2012 01:58:59 +0000 (18:58 -0700)]
CHROMIUM: drivers: device tree support for gpio-charger

This allows the gpio-charger driver to be added to a kernel via a device
tree specification.

BUG=chrome-os-partner:11739
TEST=None

Change-Id: I80389151755fb0bad8a8a5e042a95e8cde938026
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29711
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
11 years agoregulator: tps65090: Check power good after enable
Sean Paul [Thu, 9 Aug 2012 21:43:36 +0000 (14:43 -0700)]
regulator: tps65090: Check power good after enable

Check the power good bit in the control register after enabling a
regulator. If the power good bit fails, print and return an error.

BUG=chrome-os-partner:12360
TEST=Multiple suspend/resume cycles with no issues

Change-Id: I8793e1083ebc304cb9b08209a8af17eca8cafded
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29813
Reviewed-by: Doug Anderson <dianders@chromium.org>