Shan Wei [Wed, 28 Nov 2012 02:54:31 +0000 (10:54 +0800)]
UPSTREAM: staging: gdm72xx: use %pI4 format to print IPv4 address and remove last usage of NIP6
commit cf4ca4874fc45 removed the definition of NIPQUAD and NIPQUAD_FMT,
and NIP6 also is out of date.
commit 2874762b31d8d replace deprecated NIPQUAD marco to C code, but we can use %pI4 to
print IPv4 address more simply. And remove constant condition judge.
Because DEBUG_SDU is not defined in gdm_wimax.h, no error message when compiling.
Ben Chan [Tue, 27 Nov 2012 04:18:45 +0000 (20:18 -0800)]
UPSTREAM: staging: gdm72xx: fix unused variable warning in gdm_usb_send
This patch fixes an unused variable warning in gdm_usb_send
(when CONFIG_WIMAX_GDM72XX_K_MODE=n), which was introduced in
commit 1a276b80466bbd195cf94ec7178f68f2ab351467 (staging:
gdm72xx: protect access of rx / tx structs).
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Ben Chan <benchan@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a7e4a982fe2a9375952798294ebfb38dc0ed6782)
Change-Id: Ifcc7f122a8342f51d697a48b55d604f71a582f52 Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38962 Reviewed-by: Olof Johansson <olofj@chromium.org>
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:57 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in usb_boot.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:43 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in gdm_usb.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:30 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in sdio_boot.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:05:16 +0000 (20:05 +0900)]
UPSTREAM: staging/gdm72xx: Use dev_ printks in gdm_sdio.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:04:42 +0000 (20:04 +0900)]
UPSTREAM: staging/gdm72xx: Use netdev_ or pr_ printks in gdm_qos.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ...
YAMANE Toshiaki [Mon, 29 Oct 2012 11:03:47 +0000 (20:03 +0900)]
UPSTREAM: staging/gdm72xx: Use netdev_ or pr_ printks in gdm_wimax.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer netdev_emerg(netdev, ... then dev_emerg(dev, ... then pr_emerg(... to printk(KERN_EMERG ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Russell Webb <russell.webb@linux.intel.com>
BUG=None
TEST=Boot from USB3 key in a USB3 port with Lynx Point LP Chipset
Change-Id: Id2406402f53dccd98c5b4916c55b69cf3ea7179e
Reviewed-on: https://gerrit.chromium.org/gerrit/37927
Commit-Ready: Russell Webb <russell.webb@intel.com> Tested-by: Russell Webb <russell.webb@intel.com> Reviewed-by: Olof Johansson <olofj@chromium.org>
Sarah Sharp [Thu, 9 Feb 2012 23:55:13 +0000 (15:55 -0800)]
UPSTREAM: xhci: Add Lynx Point to list of Intel switchable hosts.
The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host. This time, ports from both EHCI
hosts can be switched to the xHCI host controller. The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.
Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
BUG=None
TEST=Boot from USB3 key in a USB3 port with Lynx Point Chipset
Change-Id: I38de395b5c7812bbc61fd11e0d27c3ec12514978
Reviewed-on: https://gerrit.chromium.org/gerrit/37926
Commit-Ready: Russell Webb <russell.webb@intel.com> Tested-by: Russell Webb <russell.webb@intel.com> Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: drm/exynos: get/put the fb for every page flip
We had been using kds to prevent unmapping the fb while its
under scanout. But not all fbs are KDS-backed nor is it a
good idea to assume user-space is exporting all fbs.
Michael Spang [Fri, 9 Nov 2012 01:06:06 +0000 (20:06 -0500)]
CHROMIUM: serial: samsung: Restore IRQ mask during noirq resume
This closes a window where the system may hang in resume as soon as the
UART interrupt is enabled and before the mask is restored. The hang occurs
because the driver can't handle IRQs it thinks are masked.
This also removes the code to mask all irqs from s3c24xx_serial_resetport,
which would overwrite the restored mask. The mask is now always already
set when this function is called.
BUG=chrome-os-partner:10932
TEST=powerd_suspend with no_console_suspend but not SAMSUNG_PM_DEBUG
Change-Id: I421db634443d331ee8762236d08151c5be4d4e81 Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37713 Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com> Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Michael Spang [Fri, 26 Oct 2012 21:55:34 +0000 (17:55 -0400)]
CHROMIUM: exynos: Fix lockdep warning in exynos_ohci_suspend
On the first suspend with lockdep (CONFIG_PROVE_LOCKING) enabled I get
the following warning:
[ 27.873728] powerd_suspend/2517 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 27.873734] (clocks_mutex){+.+...}, at: [<403ea954>] clk_get_sys+0x34/0xd8
[ 27.873752]
[ 27.873754] and this task is already holding:
[ 27.873759] (&(&ohci->lock)->rlock){-.....}, at: [<40335d6c>] exynos_ohci_suspend+0x34/0x94
[ 27.873774] which would create a new lock dependency:
[ 27.873779] (&(&ohci->lock)->rlock){-.....} -> (clocks_mutex){+.+...}
[ 27.873794]
[ 27.873795] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 27.873800] (&(&ohci->lock)->rlock){-.....}
We can avoid this by not calling phy_exit() with the OHCI mutex held.
TEST=suspend with CONFIG_PROVE_LOCKING enabled
BUG=chromium-os:35769
Change-Id: I1c1616b4958094bae5a97ea522262606f4aa749e Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36730 Reviewed-by: Olof Johansson <olofj@chromium.org>
Sean Paul [Thu, 29 Nov 2012 21:37:05 +0000 (16:37 -0500)]
drm/exynos: Remove the i2c drivers and use devtree
The i2c client was previously being passed into the hdmi driver via a
dedicated i2c driver, and then a global variable. This patch removes all
of that and just uses the device tree to get the i2c_client. This patch
also properly references the client so we don't lose it before we're
done with it.
BUG=None
TEST=Tested boot & hotplug, no regressions found
Change-Id: I11b8565cecf6c8290851339f923c46ae5513dc74 Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38940 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
As we have fixed the limitation of the SDIO stack to handle more then
4K of data, limiting mwifi driver to 4K is not needed.
Switing back to the original 8K/8K rx/tx buffer size for mwifi driver.
BUG=chrome-os-partner:10987
TEST=with CL 38513, we are not seeing the wifi error we use to see with
8k/8k buffer size and its improves the wifi performance.
Change-Id: Iee0f9274332aabd337d9ed461f5a3ffbff43e12a Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/38990 Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Sam Leffler <sleffler@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Kyoungil Kim [Mon, 22 Oct 2012 11:01:00 +0000 (20:01 +0900)]
UPSTREAM: mmc: sdio: Use multiple scatter/gather list
Before this patch, we always used only single sg entry for SDIO transfer.
This patch switches to using multiple sg entries. In the case of dwmci,
it supports only up to 4KB size per single sg entry. So if we want to
transfer more than 4KB, we should send more than 1 command.
When we tested before applying this patch, it took around 335 us for
5K(5120) bytes transfer with dwmci controller. After applying this patch,
it takes 242 us for 5K bytes. So this patch makes around 38% performance
improvement for 5K bytes transfer. If the transfer size is bigger, then
the performance improvement ratio will be increased.
BUG=chrome-os-partner:10987
BUG=chrome-os-partner:11963
TEST=with this CL we can use 8k/8k tx/rx buffer size from mwifi driver,
can see wifi performace improved. See bug 10987 for actual data.
Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
(cherry picked from commit 221d82616bcea64dfa8787fc6fc78f669f8d2e3e)
Change-Id: Ia578078e610766b5dcb593506d07407b9e654d46
Reviewed-on: https://gerrit.chromium.org/gerrit/38513 Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org> Tested-by: Sam Leffler <sleffler@chromium.org>
Daniel Kurtz [Thu, 29 Nov 2012 08:59:20 +0000 (16:59 +0800)]
CHROMIUM: drm/exynos: Fix compile warning in dp_core
In function 'exynos_dp_hotplug':
warning: 'voltage_swing' may be used uninitialized in this function
[-Wmaybe-uninitialized]
While it may be impossible for dp->link_train.lane_count to be 0, the
compiler can't know that. If it is 0 for some reason, then voltage_swing
does not get set in the lane loop and therefore
exynos_dp_check_max_cr_loop() gets called with a bogus voltage_swing.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:36770
TEST=builds without the warning
Change-Id: Ia19a0439487995bd600570e0f32bf4a4c31e4407
Reviewed-on: https://gerrit.chromium.org/gerrit/38901
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Remove the obj parameter from exynos_drm_framebuffer_init.
This allows us to simplify the code and makes it easier to
implement some of later CLs in this series.
BUG=chrome-os-partner:15349,chrome-os-partner:14965
TEST=Multiple VT switch. Sign out/Sign in.
Ben Widawsky [Thu, 12 Jul 2012 18:01:05 +0000 (11:01 -0700)]
BACKPORT: drm/i915: add register read IOCTL
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access through
libpciaccess, the IOCTL can provide this service instead.
Currently the implementation whitelists only the render ring timestamp
register, because that is the only thing we need to expose at this time.
v2: make size implicit based on the register offset
Add a generation check
Reviewed-by: Eric Anholt <eric@anholt.net> Cc: Jacek Lawrynowicz <jacek.lawrynowicz@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: fixup the ioctl numerb:] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit c0c7babc48c4f6943ed3070d04630ea3ac9272ee) Signed-off-by: Frank Henigman <fjhenigman@chromium.org>
Conflicts:
In stop_streaming, DPB_FLUSH was called un-conditionally earlier.
So it causes issues when the DPB_FLUSH command is given even before
MFC initialization is completed. The patch modifies the stop_streaming
function to call DPB_FLUSH only if the current state is RUNNING.
Also some cleanup is done for the DPB flush implementation.
BUG=chrome-os-partner:16083
TEST=Tested with VDA app and playback tested in browser
Daniel Kurtz [Sat, 24 Nov 2012 13:22:39 +0000 (21:22 +0800)]
CHROMIUM: drm/exynos: Pass drm_display_mode to exynos_panel_ops.mode_set
Specifying the actual type is cleaner and lets the compiler type check
for us. It will also make it possible to add some DRM_DEBUG messages
that access the mode object in the mode_set() handlers.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:36608
TEST=builds clean
Change-Id: Ida2149a2e1bf3a3c57b528350f36e31fef8f6b4d
Reviewed-on: https://gerrit.chromium.org/gerrit/38889
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Sat, 24 Nov 2012 12:12:57 +0000 (20:12 +0800)]
CHROMIUM: drm/exynos: Fix compiler warning in hdmi_get_edid
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:36607
TEST=compiles without:
warning: return makes pointer from integer without a cast
Change-Id: I0d20f309180329f2875fcfd3259de87e56751cab
Reviewed-on: https://gerrit.chromium.org/gerrit/38887 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Johannes Berg [Wed, 28 Nov 2012 20:53:45 +0000 (21:53 +0100)]
mwifiex: fix struct member mismatch
Using bss->information_elements and treating
bss->len_beacon_ies as its size is wrong, the
real size is len_information_elements.
Found while I was reviewing the use of this
cfg80211 API (as it is actually potentially
broken due to races.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=None
TEST=Boot, associate
Change-Id: I52a58aaa3b7abf66f032e9f1f4ce5248fdb60c89
Reviewed-on: https://gerrit.chromium.org/gerrit/38846 Reviewed-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Chih-Chung Chang [Tue, 27 Nov 2012 03:54:01 +0000 (11:54 +0800)]
CHROMIUM: ALSA: hda/ca0132: Set effect settings during initialization.
We did not restore the effect settings after resume, so the hardware
used default values for them. This caused "Surround" to be turned on
after resume.
Now we always set the effect settings in ca0132_init(), so the settings
in hardware and in kernel are in sync.
This patch is provided by Creative.
BUG=chrome-os-partner:16197
TEST=check the output from headphone.
Che-Liang Chiou [Mon, 19 Nov 2012 21:04:22 +0000 (13:04 -0800)]
CHROMIUM: chromeos_arm: factor out vbc access
Factor out vbc access from chromeos_arm in preparation for abstracting
vbc interface and for supporting access of vbc on ec.
Also, make it try to search device from phandle (though not it does not
fully work yet).
BUG=chrome-os-partner:15609
TEST=manual, add debugging sysfs entry to call
chromeos_platform_read/write_vboot_context, and test that the
driver can actually access vboot context on disk.
Paul Stewart [Wed, 28 Nov 2012 20:32:46 +0000 (12:32 -0800)]
CHROMIUM: config: Remove duplicate CONFIG_RT2xxx
Fix-up entires so global chromeos/config/base.config entries
are all we need.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium-os:36732,chromium-os:35699
TEST=emerge-{parrot,daisy,x86-alex} chromeos-kernel:
Ensure prepareconfig does not fail due to CONFIG_RT* (it fails in
all of these platforms but for other reasons than my changes)
Change-Id: I32be7178c5cf255392d9b015797b0a17cba5918f
Reviewed-on: https://gerrit.chromium.org/gerrit/38839 Tested-by: Grant Grundler <grundler@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Doug Anderson [Tue, 27 Nov 2012 21:24:30 +0000 (13:24 -0800)]
samsung: snow: bitfix: Bail if any pages in a bad chunk were skipped
If we didn't store recovery info for any of the pages in a bad chunk
then we'll consider it an unrecoverable error and reboot. The old
code only checked the first page in the chunk. With 8K chunks this
was only a 50% hit rate.
We could just choose to recover the page whose recovery info we have.
We don't do that because there is often more than one bit error in a
chunk and it seems better to error on the side of rebooting.
Simon Glass [Mon, 26 Nov 2012 22:59:01 +0000 (14:59 -0800)]
regulator: tps65090: Retry FET enable in case of failure
Sometimes the FET fails to enable but instead gives a timeout error. This
may be a fault with the TPS65090. Turning off the FET and trying again seems
to clear the fault, so do this.
BUG=chrome-os-partner:16222
TEST=manual
Build and boot kernel using a firmware which does not enable the backlight.
See that LCD backlight turns on.
Also need to test on a unit which enhibits the 'no backlight on resume'
problem.
Change-Id: Idb5d867d32b4a290c6afd3d326e8c8f8678588d3 Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38679 Reviewed-by: Michael Spang <spang@chromium.org> Tested-by: Michael Spang <spang@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org>
Derek Basehore [Tue, 27 Nov 2012 04:07:12 +0000 (20:07 -0800)]
CHROMIUM: rts_pstor: prevent deadlock and detection issues
Patch from Realtek that fixes a deadlock issue when combined with removing the
sdhci_pci module from the kernel. This disables the card interrupt over the bus
and something else that's undocumented.
The change also prevents issues with the card reader either not detecting an SD
card insertion or removal.
NeilBrown [Sun, 5 Aug 2012 20:56:20 +0000 (22:56 +0200)]
UPSTREAM: RTC: Avoid races between RTC alarm wakeup and suspend.
If an RTC alarm fires just as suspend is happening, it is possible for
suspend to complete and the alarm to be missed.
To avoid the race, we must register the event with the PM core.
As the event is made visible to userspace through a thread which is
only scheduled by the interrupt, we need a pm_stay_awake/pm_relax
pair preventing suspend from the interrupt until the thread completes
its work.
This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as
it provides suspend protection for all RTCs that use rtc_update_irq.
Change-Id: I7dfc88bf6f95d0c5916b7e6ba751a56c62b5b82d Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38480 Reviewed-by: Grant Grundler <grundler@chromium.org> Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Julius Werner [Tue, 13 Nov 2012 02:10:14 +0000 (18:10 -0800)]
UPSTREAM: cpuidle: Measure idle state durations with monotonic clock
Many cpuidle drivers measure their time spent in an idle state by
reading the wallclock time before and after idling and calculating the
difference. This leads to erroneous results when the wallclock time gets
updated by another processor in the meantime, adding that clock
adjustment to the idle state's time counter.
If the clock adjustment was negative, the result is even worse due to an
erroneous cast from int to unsigned long long of the last_residency
variable. The negative 32 bit integer will zero-extend and result in a
forward time jump of roughly four billion milliseconds or 1.3 hours on
the idle state residency counter.
This patch changes all affected cpuidle drivers to either use the
monotonic clock for their measurements or make use of the generic time
measurement wrapper in cpuidle.c, which was already working correctly.
Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
should always already be disabled before entering the idle function, and
not get reenabled until the generic wrapper has performed its second
measurement). It also removes the erroneous cast, making sure that
negative residency values are applied correctly even though they should
not appear anymore.
BUG=chrome-os-partner:15864
TEST=Print /sys/.../cpuidle/state*/time in a loop, and update the
system clock concurrently.
Has been accepted upstream by Rafael J. Wysocki at
https://lkml.org/lkml/2012/11/27/435
Change-Id: If53c1e60358f62679d29130b14a68487125ff164 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Len Brown <len.brown@intel.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/37874 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Paul Stewart [Wed, 24 Oct 2012 23:03:04 +0000 (16:03 -0700)]
CHROMIUM: config: Don't pre-empt RT2800USB module in ARM
Allow RT2800USB module to build on ARM platforms.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium-os:35699
TEST=Boot system, do "ifconfig"
Change-Id: Ib24debfda9cfe2956a53656c3209fd6f9fcea3c9
Reviewed-on: https://gerrit.chromium.org/gerrit/38744 Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
LVDS allowed changing panel fitting scaling mode, while eDP didn't.
Copied relevant code from LVDS to eDP.
This also changed eDP default scaling mode to respect aspect ratio.
This version of the patch is a bit different from aforementioned commits,
but since backporting them would require cherry-picking 17 more commits,
it was decided to use this version instead.
BUG=chrome-os-partner:13682
TEST=Plug external monitor, switch to mirror mode,
check that aspect ratio is preserved (image is letterboxed/pillarboxed).
Vincent Palatin [Tue, 27 Nov 2012 00:13:41 +0000 (16:13 -0800)]
CHROMIUM: usb: dwc3: allow to configure the XHCI to use the internal clock
Remove the hardcoded assumption that we have an external PLL for the USB3 clock.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16351
TEST=on Spring, plug on usb key on USB3 port and browse the content.
Change-Id: I0bf2a3604b3009abbcdfe3b0daf9d7fcccf1438c
Reviewed-on: https://gerrit.chromium.org/gerrit/38684 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Michael Spang [Wed, 14 Nov 2012 23:27:08 +0000 (18:27 -0500)]
CHROMIUM: gobi: Move qcusbnet_put locking into free_dev
If the qcusbnet struct is freed through kobject_put instead of
qcusbnet_put, then we're not taking the lock that protects qcusbnet_list.
That's currently only possible if the struct is freed in cdev_put.
This bug was introduced in ae884f3 ("gobi: Keep struct qcusbnet alive
while cdev is alive").
Vincent Palatin [Tue, 27 Nov 2012 00:17:06 +0000 (16:17 -0800)]
CHROMIUM: exynos: dts: do not use external PLL for USB3 on Spring
Move the enable gpio configuration for the USB3 PLL to the machine
device tree files, and do not define it on Spring, so the dwc3 driver
assumes that we only use the internal clock.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16351
TEST=on Spring, plug on usb key on USB3 port and browse the content.
Change-Id: If8f91a34a0cadedada2ad627681a7fe83a6e5c12
Reviewed-on: https://gerrit.chromium.org/gerrit/38685 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Prathyush K [Mon, 19 Nov 2012 07:36:54 +0000 (13:06 +0530)]
drm/exynos: do not support CONTIG gem buffer allocation
Currently, drm framework only supports allocation and mapping of
non-contig gem buffers. In the next versions of drm (v3.7),
this option to choose contig/non-contig is not supported. So for now,
we just return error in case user asks for contig gem buffers.
BUG=chrome-os-partner:15569
TEST=Built kernel and booted on snow.
Change-Id: Ibb164e812f4d175b6601145dffab1aaec28de4f5 Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/38291 Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Michael Spang <spang@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Tested-by: Akshu Agrawal <akshu@chromium.org>
Luigi Semenzato [Tue, 21 Aug 2012 21:52:20 +0000 (14:52 -0700)]
UPSTREAM: perf tools: do not flush maps on COMM for perf report
This fixes a long-standing bug caused by the lack of separate COMM and EXEC
record types, which makes "perf report" lose track of symbols when a process
renames itself.
With this fix (suggested by Stephane Eranian), a COMM (rename) no longer
flushes the maps, which is the correct behavior. An EXEC also no longer
flushes the maps, but this doesn't matter because as new mappings are created
(for the executable and the libraries) the old mappings are automatically
removed. This is not by accident: the functionality is necessary because DLLs
can be explicitly loaded at any time with dlopen(), possibly on top of existing
text, so "perf report" handles correctly the clobbering of new mappings on top
of old ones.
An alternative patch (which I proposed earlier) would be to introduce a
separate PERF_RECORD_EXEC type, but it is a much larger change (about 300
lines) and is not necessary.
Signed-off-by: Luigi Semenzato <semenzato@chromium.org> Tested-by: Stephane Eranian <eranian@google.com> Acked-by: Stephane Eranian <eranian@google.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Olof Johansson <olofj@chromium.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Robert Richter <robert.richter@amd.com> Cc: Sonny Rao <sonnyrao@chromium.org> Cc: Stephane Eranian <eranian@google.com> Cc: Stephen Wilson <wilsons@start.ca> Cc: Tejun Heo <tj@kernel.org> Cc: Vasiliy Kulikov <segoon@openwall.com> Link: http://lkml.kernel.org/r/1345585940-6497-1-git-send-email-semenzato@chromium.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
(cherry picked from commit 9fdbf671ba7e8adb2cbb93d716232ebcab55f6bd)
BUG=chromium-os:26115
TEST=manual (see bug/original commit in 3.0)
Change-Id: Ie1fe97535430a989c3c925b30aa90e462e6eb37d Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38676 Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Doug Anderson [Fri, 7 Sep 2012 18:12:01 +0000 (11:12 -0700)]
watchdog: s3c2410: Avoid excessive petting during cpufreq
On more modern Samsung SoCs (like exynos5) the watchdog is
parented on a clock that doesn't change. Avoid all of the extra
petting, disabling, and re-enabling of the watchdog in the case
that the clock never changes.
NOTE: As pointed out in
<https://gerrit.chromium.org/gerrit/#/c/31465/>
...the proper way would be to register a notifier for the clock
directly, but CONFIG_COMMON_CLK isn't enabled.
BUG=chrome-os-partner:9403
TEST=If I open /dev/watchdog now it eventually dies.
Change-Id: I4f982dc85caf091444633aff94b90d524bdfe829 Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32566 Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Grant Grundler <grundler@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Tested-by: Grant Grundler <grundler@chromium.org>
Paul Stewart [Wed, 21 Nov 2012 22:28:44 +0000 (14:28 -0800)]
CHROMIUMOS: mwifiex: Disable transmit aggregation
Disable requesting transmit aggregation. In situations where
the firmware receives a particular type of ADDBA response, it
enters a Block-Ack-Request loop and no further frames are
transmitted. Until this larger issue is addressed, we cannot
safely request aggregation.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:12192
TEST=Associate with modified mac80211-based AP which returns
a Block-Ack-ADDBA response with only 1 buffer allowed.
Change-Id: Icb532a118bb90eca867784fd9b05bf850404e974
Reviewed-on: https://gerrit.chromium.org/gerrit/38483 Reviewed-by: Christopher Wiley <wiley@chromium.org> Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Michael Spang [Tue, 13 Nov 2012 23:13:42 +0000 (18:13 -0500)]
CHROMIUM: gobi: Fix qcusbnet leak in QMI_CLOSE ioctl
The handle cleanup path in the QMI_CLOSE ioctl leaks a reference to
qcusbnet (taken in devqmi_open). This patch unifies that cleanup code
with the code from devqmi_release and fixes the leak.
BUG=chrome-os-partner:16158
TEST=suspended the machine a few times, started and stopped cromo
Change-Id: I970a20fd67ebf8d1e65526ccca41f13c2aa97b44 Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37955 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Ben Chan <benchan@chromium.org>
Michael Spang [Wed, 14 Nov 2012 22:14:51 +0000 (17:14 -0500)]
CHROMIUM: gobi: Remove leaky replacement of fops in devqmi_write
The devqmi_write function sometimes overwrites devqmi_fops with
def_chr_fops. When that happens, the devqmi_fops reference is leaked,
and the file is never cleaned up because devqmi_release is not called.
It's not clear what this is for, and it looks like the other file
callbacks already check device_valid() before doing anything.
Therefore we can probably just remove this.
Sean Paul [Tue, 20 Nov 2012 15:56:54 +0000 (10:56 -0500)]
drm/exynos: Clean up fimd mode handling
FIMD has been using the panel timing data straight from the driver's
platform data instead of the data that is provided via the drm layer.
This makes things difficult if we want to use EDID data from the dp
driver, since it would be ignored. This patch changes FIMD to just
use the platform panel data as a seed to get_panel. From then on, we use
the overlay data that is set via modeset.
This patch also removes the panel array, since we only want one
resolution from platform data.
BUG=chrome-os-partner:11158
TEST=Tested on snow, no regressions noted
Change-Id: I345c3663509e6820a745b85c4b9a37f77f42c0d2 Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38409 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Sean Paul [Mon, 19 Nov 2012 19:49:29 +0000 (14:49 -0500)]
drm/exynos: dp: Check hp gpio in hp detect function
Check the hotplug gpio in the hpd function so we know when it's
asserted. This fixes the return value of the is_connected callback.
BUG=chrome-os-partner:16280
TEST=None
Change-Id: I1ab0c7d830ecdc7b7f38ffd81895038978e4e57a Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38319 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Mon, 19 Nov 2012 19:41:09 +0000 (14:41 -0500)]
drm/i2c: ptn3460: Add dev node check to ready wait
Check for the ptn dev node in the ready wait function to avoid blocking
boards without ptn for 30 seconds.
BUG=chrome-os-partner:16280
TEST=None
Change-Id: I0057e7b72d9841447a56167617b9f081f5bbbe18 Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38317 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Paul Stewart [Wed, 24 Oct 2012 23:03:04 +0000 (16:03 -0700)]
CHROMIUM: config: Add RT2800USB module
Add support for the RT2800 USB WiFi device.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium-os:35699
TEST=Boot system, do "ifconfig"
CQ-DEPEND=Iea82c1e6b1d7f9c5181cef11fcf25a5ee2da114b
Change-Id: Ic02543da81191c8e6bf39e9e90d8fc2c86128b39
Reviewed-on: https://gerrit.chromium.org/gerrit/36834 Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Sean Paul [Tue, 20 Nov 2012 19:19:00 +0000 (14:19 -0500)]
drm/exynos: Let drm handle edid allocations
There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.
BUG=chromium-os:36513
TEST=Tested on snow boot/hotplug/idle suspend/lid suspend
Change-Id: Ifb971a7a6c6ae66ce431b9a256886d9699adbd09 Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38406
Sean Paul [Tue, 20 Nov 2012 19:33:09 +0000 (11:33 -0800)]
Revert "DRM/exynos: Fix Memory Leak: free EDID block returned by drm_get_edid()."
This reverts commit e04984d087c95d7dd09be7cb6cb84e1f339c4f17. The patch causes kernel panic since it frees that memory twice once in the panel_op, and then again in the connector function.
Change-Id: I26173e1664733acea4abad9a731c4f7d98efe18a
Reviewed-on: https://gerrit.chromium.org/gerrit/38405 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Sean Paul <seanpaul@chromium.org> Tested-by: Sean Paul <seanpaul@chromium.org>
Che-Liang Chiou [Fri, 9 Nov 2012 01:34:50 +0000 (17:34 -0800)]
CHROMIUM: platform: rename nvram to vbc
As we are actually accessing vboot context and vboot context is not
limited to be stored on nvram, it is clearer to just call it vbc.
This change also removes obsolete comments and makes API interface
consistent (all read/write should return number of bytes instead of zero
on success).
BUG=none
TEST=manual, add debugging sysfs entry to read/write vboot context and
make sure it works.
On x86 chromeos systems with vmx support, the feature is controlled by
the disablevmx flag. There are several boot paths for the CPUs
and this patch ensures that the resume path for the BSP is covered.
Rename cpu_disable_vmx to cpu_control_vmx. It's a bit more
descriptive since it does not disable vmx in all cases.
Further, have the function itself test the variable; this
is more in keeping with how other such capabilities
are controlled anyway and it keeps the variable in
file scope. Finally, make it all conditional on
CONFIG_CHROMEOS.
We use the variable to control the enable/disable instead
of saved CPU context. I could add the FEATURES MSR
to the saved context and use that on restore but
that adds more changes, and I've seen no evidence that anyone
outside chromeos is interested in disabling VMX, so it
makes more sense to me to limit the footprint of this
patch.
BUG=chrome-os-partner:10449
TEST=apply and boot with this patch.
dmesg | grep Disabling.VMX
Note that all four CPUs have it disabled.
Also
rdmsr 0 0x3a
and see the value.
Suspend any way you want. (powerd_suspend, close the lid, whatever).
Repeat and notice the Disabling message appears again,
for all four cores this time,
and the 0x3a MSRs all have the correct value.
Change-Id: Ie0160db31a1a058ce4d3e4f8752cd0e5d696ea84 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38235 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org>
CHROMIUM: ath9k: do not schedule rx poll on invalid state
During system suspend, the rx poll timer is cancelled at
the driver stop. But occasionally it will be scheduled again by
beacon reception before stopping rx. Since the timer is never
stopped again, it tries to queue work on suspend path.
This patch ensures that rx poll timer is cancelled on driver stop.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
BUG=chrome-os-partner:15168
TEST=Boot, run suspend-resume test with powersave ON.
Change-Id: I2eae50a4b35335249f0a530c9eb6161951abe5fc Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org> Tested-by: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38316 Reviewed-by: mukesh agrawal <quiche@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org>
Bing Zhao [Thu, 15 Nov 2012 21:48:19 +0000 (13:48 -0800)]
UPSTREAM: mwifiex: report error to MMC core if we cannot suspend
When host_sleep_config command fails we should return error to
MMC core to indicate the failure for our device.
The misspelled variable is also removed as it's redundant.
Cc: "3.0+" <stable@vger.kernel.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15129
TEST=Boot, associate, speed test, suspend, resume
Change-Id: I9d53425b29050274840030e63f95969601ee622f
Reviewed-on: https://gerrit.chromium.org/gerrit/38285 Reviewed-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Bing Zhao [Thu, 15 Nov 2012 20:29:42 +0000 (12:29 -0800)]
UPSTREAM: mwifiex: fix system hang issue in cmd timeout error case
Reported by Tim Shepard:
I was seeing sporadic failures (wedgeups), and the majority of those
failures I saw printed the printouts in mwifiex_cmd_timeout_func with
cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH. When this happens, two
minutes later I get notified that the rtcwake thread is blocked, like
this:
INFO: task rtcwake:3495 blocked for more than 120 seconds.
To get the hung thread unblocked we wake up the cmd wait queue and
cancel the ioctl.
Cc: "3.4+" <stable@vger.kernel.org> Reported-by: Tim Shepard <shep@laptop.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15129
TEST=Boot, associate
Change-Id: Icdf3dd71b12b8110c5b13df5c5c9ebbb0820441c
Reviewed-on: https://gerrit.chromium.org/gerrit/38284 Reviewed-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Vincent Palatin [Fri, 12 Oct 2012 23:12:29 +0000 (16:12 -0700)]
CHROMIUM: ASoC: samsung: fix error for hdmi-audio
The result of the device tree look-up for the hdmi-audio device
was checked against the wrong variable.
As a consequence, if the hdmi-audio device is disabled, the kernel will
crash at startup instead of skipping the plugin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14489
TEST=boot on Spring with hdmi-audio disabled in the device tree
and see we are longer crashing in the max98095 probing.
Change-Id: I613b53633eb7814e63a7459704f3780ded62a2a0
Reviewed-on: https://gerrit.chromium.org/gerrit/38261
Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
This change documents the enable/disable-low-jitter
bindings for the mfd/max77686.
Signed-off-by: Will Drewry <wad@chromium.org>
TEST=none
BUG=chrome-os-partner:15785
Change-Id: I0c980d5a2fa730c8d8681041a5627d84c3f1f4bb
Reviewed-on: https://gerrit.chromium.org/gerrit/38238 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org>
Ben Chan [Fri, 16 Nov 2012 01:57:54 +0000 (17:57 -0800)]
CHROMIUM: staging: gdm72xx: protect access of rx / tx structs
This patch applies spinlock to protect access to rx / tx structs in
certain call sites, which fixes the following crash in gdm_suspend.
It also fixes usb_set_intfdata() in gdm_usb_probe to avoid setting an
already freed phy_dev.
<5>[ 4996.815018] [<7f0074b0>] (gdm_suspend+0x1c/0x2b4 [gdmwm]) from [<803020a4>] (usb_suspend_both+0x80/0x1a0)
<5>[ 4996.815055] [<803020a4>] (usb_suspend_both+0x80/0x1a0) from [<80302c84>] (usb_runtime_suspend+0x38/0x64)
<5>[ 4996.815089] [<80302c84>] (usb_runtime_suspend+0x38/0x64) from [<802becc0>] (__rpm_callback+0x48/0x78)
<5>[ 4996.815118] [<802becc0>] (__rpm_callback+0x48/0x78) from [<802bf8dc>] (rpm_suspend+0x394/0x5ec)
<5>[ 4996.815145] [<802bf8dc>] (rpm_suspend+0x394/0x5ec) from [<802c0550>] (pm_runtime_work+0x8c/0xa4)
<5>[ 4996.815177] [<802c0550>] (pm_runtime_work+0x8c/0xa4) from [<800456cc>] (process_one_work+0x264/0x438)
<5>[ 4996.815209] [<800456cc>] (process_one_work+0x264/0x438) from [<80045acc>] (worker_thread+0x22c/0x3b8)
<5>[ 4996.815239] [<80045acc>] (worker_thread+0x22c/0x3b8) from [<8004a43c>] (kthread+0x9c/0xa8)
<5>[ 4996.815270] [<8004a43c>] (kthread+0x9c/0xa8) from [<8000f160>] (kernel_thread_exit+0x0/0x8)
<0>[ 4996.815295] Code: e92d4000e8bd4000e2800020eb4ab9a1 (e5905000)
Will Drewry [Fri, 16 Nov 2012 02:13:39 +0000 (20:13 -0600)]
CHROMIUM: mfd/max77686: enable low-jitter mode
This change adds three valid device-tree configured settings
for the max77686 "low jitter" mode:
* max77686,enable-low-jitter
* max77686,disable-low-jitter
* (no entry)
With either entry, the third bit of the 32KHZ register
is updated.
Low jitter mode is desirable on some platforms with components that are
sensitive to the clock signal. The clock sometimes appears to stutter when
being updated. For most uses, this is inconsequential, but if the RTC is
supplying a signal to more sensitive hardware, it can cause undesirable
results.
BUG=chrome-os-partner:15785
TEST=It boots :) semenzato@ has confirmed that if the register is set, the errors do not reproduce with the scope.
To check the register state:
$ i2cget -f -y 0 0x9 0x7f
0x0f
Reported-by: Luigi Semenzato <semenzato@chromium.org> Suggested-by: Luigi Semenzato <semenzato@chromium.org> Signed-off-by: Will Drewry <wad@chromium.org>
Change-Id: Ib40d1d0728535b10c8438eaa6eacd74fb83cb697
Reviewed-on: https://gerrit.chromium.org/gerrit/38180 Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org>
Vincent Palatin [Fri, 16 Nov 2012 17:28:50 +0000 (09:28 -0800)]
CHROMIUM: ASoC: samsung: Spring is using max98095 codec
Spring is also using the Maxim max98095 codec for audio.
Add it to the list of supported boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14490
TEST=on Spring, plug a headset, play a video on Youtube and hear the
sound.
Change-Id: If17a3ba240943412acf03b24058218c40781944f
Reviewed-on: https://gerrit.chromium.org/gerrit/38205 Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Thu, 15 Nov 2012 16:24:27 +0000 (11:24 -0500)]
drm/exynos: Implement DPMS_STANDBY for HDMI
Enable the "blue screen" when we get a DPMS_STANDBY request for HDMI.
This allows us to turn off the mixer, but maintain audio over HDMI when
we turn the screen idle.
BUG=chrome-os-partner:15709
TEST=Tested on snow by ensuring audio continues to play during idle
Change-Id: I2639c0d1cd7384881b5fd651039fef71b27c76ed Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38122 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Paul Stewart [Wed, 14 Nov 2012 01:21:55 +0000 (17:21 -0800)]
UPSTREAM: ath9k_hw: Fix wrong peak detector DC offset
An issue is reported in AR9462 that NF_cal_not_done is not observed
when HW peak detector calibration is disabled. At that state, the HW
is stuck at NF calibration which prevents tx output. The root cause
is wrong peak detector offset calibrated by HW. To resolve this issue,
peak detector calibration is done manually by SW for AR9462.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:36266
TEST=Boot and run bandwith tests
Change-Id: I9b79e9b51ef86cc73800b7bb3e80875b1c0e2705
Reviewed-on: https://gerrit.chromium.org/gerrit/38025 Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Paul Stewart [Wed, 14 Nov 2012 02:40:50 +0000 (18:40 -0800)]
CHROMIUM: mwifiex: Add SDIO register debugging
This patch retrieves firmware/hardware status upon tx watchdog
timeout or command timeout. Hopefully with this debug patch we
can get some clues on what is causing the timeout issue.
BUG=chrome-os-partner:15129
TEST=Boot, connect to network
Change-Id: I058fe07746e6a1ccd8debde0c0d3d8debd700502 Signed-off-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37972
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15129
TEST=Boot, connect to network
Change-Id: I9b2fa79803605bc8b92d93a57fb0c850113c9fac
Reviewed-on: https://gerrit.chromium.org/gerrit/38119 Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Mike Frysinger [Fri, 2 Nov 2012 21:12:15 +0000 (17:12 -0400)]
CHROMIUM: config: enable usb net drivers (dm9601/net1080/rtl8150) for all targets
Some configs had these drivers enabled while others did not. Update the
common arch configs to all enable these drivers.
BUG=chromium-os:35943
TEST=`emerge-daisy chromeos-kernel` included these three drivers
TEST=`emerge-stumpy chromeos-kernel` included these three drivers
TEST=`emerge-x86-alex chromeos-kernel` included these three drivers
Change-Id: I9615109a5b17af293855595ba8f06f397db360c4 Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37296 Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org>
Che-Liang Chiou [Wed, 7 Nov 2012 00:45:06 +0000 (16:45 -0800)]
CHROMIUM: mfd: chromeos_ec: support command version numbers
ec supports versioned command and non-versioned command should be
deprecated. To minimize changes to ec clients, driver will accept not
8-bits but 16-bits command code and interpret top 8-bits as version
number. Because current ec clients all use commands of version-zero,
they will not be effected by this API change.
BUG=chrome-os-partner:15609
TEST=manual, add debugging sysfs entry to exercise kernel code path, and
make sure ec driver still works on snow.
Yufeng Shen [Wed, 14 Nov 2012 21:13:59 +0000 (16:13 -0500)]
CHROMIUM: Input: atmel_mxt_ts - recalibrate on system resume
In the suspend path, if we don't allow device wakeup, we put the
chip into deepsleep mode and the chip stops scanning during suspen.
On resume if the environment changes, the calibrated baseline before
suspend will no longer be valid.
In this patch we force a recalibration on resume if device wakeup is
disabled during suspend to handle the environment change.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chrome-os-partner:16171
TEST=I don't have a controlled environment to test this. So I only test
normal suspend/resume to make sure no noise touches happen on resume
and touch devices work as expected.
1. With lid open, using powerd_suspend to suspend the system. Wakeup
the system and make sure the touch device still works.
Run "demsg | grep atmel" to make sure no calibration message reported.
2. Use lid close to suspend the system. Wakeup the system and make
sure touch device still works.
Run "demsg | grep atmel" to make sure calibration message are reported.
3. Also notice the case of lid open caused system resume, if something is
on the touch surface (like opening the lid and quickly put the palm on the
touch surface for a while), the system will get calibrated into a wrong
baseline and touch device then won't work.
Abhilash Kesavan [Wed, 14 Nov 2012 03:57:53 +0000 (09:27 +0530)]
arm: exynos: Retry "wfi" on failure
We are seeing suspend failures occuring once in a while. In case
there still exists a race with another interrupt let us retry "wfi"
a 100 times before failing.
BUG=chrome-os-partner:14956
TEST=suspend_stress_test with no suspend failures yet.
Change-Id: I1c59ae77e12be40dec1ee027f8f1d0e0a2a2f66c Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/37991 Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org> Tested-by: Jon Kliegman <kliegs@chromium.org>
Sonny Rao [Wed, 14 Nov 2012 21:27:17 +0000 (13:27 -0800)]
CHROMIUM: pm-check: make pm-check sum function stronger
Add a rotate to the sum function and switch back to 32-bit.
The rotate seems to help in catching more instances of corruption than
a pure checksum. So far we haven't seen sum + ror miss a corruption
in over 2000 known cases whereas pure sum misses 10 of those. There
seems to be some kind of optimizer bug when I try to use 64-bit + ror
so let's go back to 32-bit and take a speed hit. This code seems to
run in about 760 msec vs about 540 msec for the pure checksum.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:16148
TEST=run suspend_stress_test, ensure errors are still detected
Sam Leffler [Mon, 12 Nov 2012 17:12:56 +0000 (09:12 -0800)]
CHROMIUM: cpufreq_interactive: correct cpu idle time calculation
Each cpu has a timer that tracks load and decides whether to adjust the
clock for that processor. The timer callback may, however, execute on
any cpu, not just the one it manages. Fix the idle time calculation to
take this into consideration--it was assuming smp_processor_id() returned
the cpu id of the processor to manage, causing incorrect decisions.
Signed-off-by: sleffler@chromium.org
BUG=none
TEST=run cpu intensive benchmark like octane on a multi-core system; check trace results and note that sometimes v8 runs for extended times on cpu operating at low freq (contributing to poor score)
Change-Id: I2b5c21b5d8cae31679e844ac67037cc760c5dfc0
Reviewed-on: https://gerrit.chromium.org/gerrit/37830 Reviewed-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Sameer Nanda <snanda@chromium.org> Tested-by: Sam Leffler <sleffler@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
drm/exynos: make event parameter optional for page_flip
We no longer need to enforce that event is non-NULL. We also need
to be able to call page_flip with a NULL event so that we can
call it from the mode_set paths.