cascardo/linux.git
11 years agoUPSTREAM: mwifiex: process RX packets in SDIO IRQ thread directly
Bing Zhao [Fri, 2 Nov 2012 02:32:36 +0000 (19:32 -0700)]
UPSTREAM: mwifiex: process RX packets in SDIO IRQ thread directly

ksdioirqd has higher priority than kworker. Process RX packets
in SDIO IRQ thread (ksdioirqd/mmcX) directly instead of deferring
the work to kworker to avoid the extra latency.
This improves TCP throughput 15~20% on an ARM platform with SDIO
2.0 controller.

BUG=chrome-os-partner:15867
TEST=TCP throughput improvements (TX 17%, RX 18%) are measured in
shieldroom with '*_CPU_GOVERNOR' set to 'performance' in
/etc/laptop-mode/conf.d/cpufreq.conf

Change-Id: I2de0020540d4b24e3084be21efa880daf186d43a
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/37182
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: ramoops: Avoid calling time functions when timekeeping disabled
Doug Anderson [Mon, 5 Nov 2012 19:35:20 +0000 (11:35 -0800)]
CHROMIUM: ramoops: Avoid calling time functions when timekeeping disabled

Calling the time functions when timekeeping is disabled will cause a
WARN_ON() to happen.  This appears to deadlock things.  Better to just
not call the function when we shouldn't.

BUG=chrome-os-partner:15655
TEST=suspend_stress_test
...ran with no serial console (AKA "console=" on kernel cmdline).

Change-Id: I1fa3430ea279c4bc79c3fb5e82228b380fecb60a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37364
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
11 years agoBACKPORT: module: add flags arg to sys_finit_module()
Rusty Russell [Mon, 22 Oct 2012 07:39:41 +0000 (18:09 +1030)]
BACKPORT: module: add flags arg to sys_finit_module()

Thanks to Michael Kerrisk for keeping us honest.  These flags are actually
useful for eliminating the only case where kmod has to mangle a module's
internals: for overriding module versioning.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Acked-by: Kees Cook <keescook@chromium.org>
(backported from Rusty's modules-next tree)

BUG=None, keeping us in sync with upstream for this API
TEST=daisy build, manual testing
CQ-DEPEND=I5b5a9bee3f9e73eb076f01e8aacee51eff095c56

Change-Id: I40f0b55ff903dda411a04b088f4ca5b6ab5cf05e
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37278
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
11 years agoUPSTREAM: r8169: 8168c and later require bit 0x20 to be set in Config2 for PME signaling.
Francois Romieu [Tue, 17 Apr 2012 09:12:01 +0000 (11:12 +0200)]
UPSTREAM: r8169: 8168c and later require bit 0x20 to be set in Config2 for PME signaling.

The new 84xx stopped flying below the radars.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
(cherry picked from commit d387b427c973974dd619a33549c070ac5d0e089f)

Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
BUG=chrome-os-partner:14994
TEST=suspend/resume, then check ethernet function on 8168c

Change-Id: I978ff6a80e8575848094ffd85a8aab5cd80ec97a
Reviewed-on: https://gerrit.chromium.org/gerrit/37328
Tested-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Ready: Shawn Nematbakhsh <shawnn@google.com>

11 years agoUPSTREAM: r8169: Config1 is read-only on 8168c and later.
Francois Romieu [Tue, 17 Apr 2012 09:10:11 +0000 (11:10 +0200)]
UPSTREAM: r8169: Config1 is read-only on 8168c and later.

Suggested by Hayes.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
(cherry picked from commit 851e60221926a53344b4227879858bef841b0477)

Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
BUG=chrome-os-partner:14994
TEST=suspend/resume, then check ethernet function on 8168c

Change-Id: If48adfd0f35b7727fd0d76764c53291a197963f2
Reviewed-on: https://gerrit.chromium.org/gerrit/37327
Tested-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Ready: Shawn Nematbakhsh <shawnn@google.com>

11 years agoRevert "samsung: pm-check: Cleanup chunk exclude code"
Simon Que [Fri, 2 Nov 2012 23:39:02 +0000 (16:39 -0700)]
Revert "samsung: pm-check: Cleanup chunk exclude code"

This reverts commit a16583b2a0799fffc4f3df22a15a282f851e3735.

BUG=chrome-os-partner:15906
TEST=Run powerd_suspend, should suspend and resume successfully

Change-Id: I5ce64a89a045e1576c45249af2c95ff0cfea06fa
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37312
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoHID: multitouch: Add 6673 PID for Ideacom
Dave Parker [Fri, 2 Nov 2012 20:23:52 +0000 (13:23 -0700)]
HID: multitouch: Add 6673 PID for Ideacom

BUG=None
TEST=Boot kernel on machine with ideacom 6673 controller attached.
Verify usbhid module is loaded for the USB device.

Change-Id: I856f2386b889fb88dcd12300080d28626d0ab528
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37281
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
11 years agoCHROMIUM: ARM: MALI: correct hw counter support locking
Sam Leffler [Tue, 30 Oct 2012 23:28:07 +0000 (16:28 -0700)]
CHROMIUM: ARM: MALI: correct hw counter support locking

Fix locking in the hw counter support.  We cannot use a spinlock
to synchronize the collection work against start/stop because
kbase_instr_hwcnt_dump can block; switch to a mutex.  While here also
synchronize start work which can race in multiple ways with the other
uses of mali_hwcs.  Extend coverage of the mutex in the collection thread
for readability though it's not really needed as the event dispatch work
references only static data which is unaffected by polling being stopped.

While here unique-ify error returns.

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:14556
TEST=verify there are no longer console msgs of the form "BUG: spinlock wrong CPU"; also run concurrent start/stop loops from the shell

Change-Id: Ib74fc5c199212441e0e0ea312f7ca57da7c35278
Reviewed-on: https://gerrit.chromium.org/gerrit/36969
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Michael Spang <spang@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>

11 years agomwifiex: add multi-queue support
Bing Zhao [Mon, 22 Oct 2012 23:44:53 +0000 (16:44 -0700)]
mwifiex: add multi-queue support

This patch adds support for multiple TX queues inside mwifiex
driver. Four different queues according to WMM access categories
are defined for each virtual interface. When a packet is
received from netdev for transmission, tx pending count for
particular queue is incremented and if tx pending count has
reached upper water-mark, this queue is stopped instead of
stopping all queues. Similarly when a packet is successfully
transmitted from device, tx pending count is decremented per
queue and if pending count falls below lower water-mark, queue
operations are again resumed. This ensures that not all
tranmission is blocked if traffic with particular TOS value
suddenly increases.

Also wake all queues when association/IBSS_join happens to
enable traffic on all queues.

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:15536
TEST=pass pre-WiFi Cert. test case 5.2.30

Change-Id: I7b11c6f3f90943f09deaa7ef37b2975982bc02d3
Reviewed-on: https://gerrit.chromium.org/gerrit/36286
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
11 years agoCHROMIUM: drm/i915: Add backlight support for Link
Stéphane Marchesin [Wed, 31 Oct 2012 00:01:10 +0000 (17:01 -0700)]
CHROMIUM: drm/i915: Add backlight support for Link

This adds device-specific backlight support for Link, and also
enables adaptive backlight by default there.

BUG=chrome-os-partner:13276,chrome-os-partner:15248
TEST=by hand

Change-Id: I9ef546bba9f121657a653aa9cfc6a80bbde55cb0
Reviewed-on: https://gerrit.chromium.org/gerrit/36976
Reviewed-by: Daniel Erat <derat@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: drm/i915: Remove adaptive backlight from gen6/lvds.
Stéphane Marchesin [Tue, 30 Oct 2012 02:52:01 +0000 (19:52 -0700)]
CHROMIUM: drm/i915: Remove adaptive backlight from gen6/lvds.

We'll only enable it through the adaptive_backlight device on
Link/gen7/eDP, so prune everything else.

BUG=chrome-os-partner:13276,chrome-os-partner:15248
TEST=by hand

Change-Id: Ib5633a370e736d9afbee441d968f718be814d081
Reviewed-on: https://gerrit.chromium.org/gerrit/36975
Reviewed-by: Daniel Erat <derat@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: drm/i915: Move the backlight accessor functions in dev_priv
Stéphane Marchesin [Tue, 23 Oct 2012 20:02:22 +0000 (13:02 -0700)]
CHROMIUM: drm/i915: Move the backlight accessor functions in dev_priv

This abstracts those functions, so that we can plug-in
platform-specific alternatives.

BUG=chrome-os-partner:3276,chrome-os-partner:15248
TEST=by hand: compiles, works

Change-Id: I29dd15722ffed8f5813b34bf0ce4431ce0524cc2
Reviewed-on: https://gerrit.chromium.org/gerrit/36974
Reviewed-by: Daniel Erat <derat@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: gobi: Keep struct qcusbnet alive while cdev is alive
Michael Spang [Thu, 1 Nov 2012 20:52:46 +0000 (16:52 -0400)]
CHROMIUM: gobi: Keep struct qcusbnet alive while cdev is alive

This fixes an issue where struct qcusbnet is freed while the embedded
character device is still alive.

This uses the ability of cdev to pin an arbitrary kobject by setting
cdev.kobj.parent. We have to switch from kref to kobject to use that.
This is arguably misuse of kobject, but char_dev requires it.t t

BUG=chrome-os-partner:15849
TEST=suspend_stress_test

Change-Id: I309e80c6ec91e491d30ea0bfcb062ae7e55f7198
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37135
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoUPSTREAM: char_dev: pin parent kobject
Dmitry Torokhov [Mon, 22 Oct 2012 00:57:19 +0000 (17:57 -0700)]
UPSTREAM: char_dev: pin parent kobject

In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of
character device so that related object is not freed until after
char_dev object is freed.

To achieve this let's pin kobject's parent when doing cdev_add() and
unpin when last reference to cdev structure is being released.

BUG=chrome-os-partner:15849
TEST=suspend_stress_test

Change-Id: I35d1762c94afa8b3eda6329a0bf0cfc7dde98b7b
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37134
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
11 years agosamsung: pm-check: Cleanup chunk exclude code
Doug Anderson [Tue, 30 Oct 2012 15:27:33 +0000 (08:27 -0700)]
samsung: pm-check: Cleanup chunk exclude code

In a recent change to pm-check we added some more chunks of
memory to the list to exclude.  This cleans up how that works
a little bit:
* We now use a linker script to exclude printk buffers.  This has an
  advange of being generic (can add extra bits to exclusion without
  modifying pm-check) and also segregating printk buffers to their own
  chunk of memory.  If we do CRC on an 8K chunk we now won't exclude
  any extra memory when we exclude the printk buffers.
* Don't exclude *sleep_save_sp.  That was a physical address and is
  also already handled by current_thread_info().
* Don't exclude sleep_save_sp.  Instead: we zero it out before out
  code runs.  This is a transitory value and zeroing it is fine.  Now
  we won't exclude chunks of memory stored near sleep_save_sp.

This also has a few other minor fixes:
* Changes the in_region() function to fix some off-by-one errors and
  also to use physical addresses.
* Skips regions in s3c_pm_makecheck() too.
* Avoids goto in s3c_pm_runcheck() loop.

BUG=chrome-os-partner:15655
TEST=suspend_stress_test

Change-Id: Ic4febb1eb9aaa78d70984c149e26731af738727a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37031
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Michael Spang <spang@chromium.org>
11 years agodrm/ptn3460: Add edid emulation selection
Sean Paul [Tue, 16 Oct 2012 20:20:53 +0000 (16:20 -0400)]
drm/ptn3460: Add edid emulation selection

This patch adds edid selection to the ptn3460 driver so we can select
the appropriate display resolution from the device tree.

BUG=chrome-os-partner:11158
TEST=Tested on snow, no regressions detected

Change-Id: I19709a5b95d61061d415f3812dc7568d28e8b4ad
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36700
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: exynos: snow: Add PTN edid emulation
Sean Paul [Fri, 26 Oct 2012 17:50:06 +0000 (13:50 -0400)]
CHROMIUM: exynos: snow: Add PTN edid emulation

Add an entry in the ptn3460 node to specify which edid emulation value
to use. The value corresponds to 1366x768, which is the resolution of
snow's lcd panel.

BUG=chrome-os-partner:11158
TEST=Tested on snow, verified EDID was 1366x768

Change-Id: Ie0cd390af41cef9a5eb51b1202c91ebc07d35458
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36699
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: CONFIG: exynos: Use PTN3460 DRM driver
Sean Paul [Mon, 29 Oct 2012 18:18:26 +0000 (14:18 -0400)]
CHROMIUM: CONFIG: exynos: Use PTN3460 DRM driver

Change CONFIG_PTN3460 to CONFIG_DRM_PTN3460 so we use the PTN3460 driver
that is in gpu/drm/i2c

BUG=chrome-os-partner:11158
TEST=compiles, runs

Change-Id: I3591448c85ced88afb404b6cd4c5829eab87c3b9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36792
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agodrm/i2c: Move ptn driver from auxdisplay to drm
Sean Paul [Fri, 26 Oct 2012 20:07:49 +0000 (16:07 -0400)]
drm/i2c: Move ptn driver from auxdisplay to drm

In order to properly synchronize setting up the ptn bridge chip with the
displayport drm driver, we need to move ptn into drm.

The original hope was to keep ptn completely seperate from drm, and have
it just act like a regular monitor. Unfortunately, the bridge is
designed such that it cannot be configured until after it asserts
hotplug. This creates a race between the DP driver detecting hotplug and
reading edid, and the ptn driver configuring its edid emulation setting.

By moving it into the drm subsystem, we can hold off reading edid until
the bridge is properly set up.

BUG=chrome-os-partner:11158
TEST=Tested on snow, no regressions detected.

Change-Id: I99f696b4eeabf36f3055c3772482013397da5002
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36791
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: drm/i915: Check the current edp backlight state before changing it.
Stéphane Marchesin [Wed, 31 Oct 2012 19:06:04 +0000 (12:06 -0700)]
CHROMIUM: drm/i915: Check the current edp backlight state before changing it.

This speeds up boot and suspend/resume times.

BUG=chrome-os-partner:13364
TEST=by hand

Change-Id: I8d7b7a22c50bcf32828d492e123ce301cefa297d
Reviewed-on: https://gerrit.chromium.org/gerrit/37047
Reviewed-by: Simon Que <sque@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoCHROMIUM: mali-t6xx: Convert mali_dvfs_spinlock to IRQ-safe spinlock
Michael Spang [Fri, 26 Oct 2012 19:04:40 +0000 (15:04 -0400)]
CHROMIUM: mali-t6xx: Convert mali_dvfs_spinlock to IRQ-safe spinlock

This fixes the following potential deadlock reported by lockdep:

[    2.204853] =================================
[    2.209181] [ INFO: inconsistent lock state ]
[    2.213523] 3.4.0 #101 Not tainted
[    2.216906] ---------------------------------
[    2.221247] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[    2.227237] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[    2.232357]  (&((&mali_dvfs_spinlock))->rlock){?.+...}, at: [<402cef00>] kbase_platform_dvfs_event+0x28/0x54
[    2.242165] {HARDIRQ-ON-W} state was registered at:
[    2.247026]   [<4007a77c>] mark_lock+0x290/0x630
[    2.251626]   [<4007b17c>] __lock_acquire+0x660/0x180c
[    2.256747]   [<4007c8ac>] lock_acquire+0x104/0x128
[    2.261608]   [<40516464>] _raw_spin_lock+0x3c/0x4c
[    2.266469]   [<402cdf00>] kbase_platform_dvfs_init+0x64/0xb0
[    2.272198]   [<402ce17c>] kbase_platform_init+0x164/0x1cc
[    2.277666]   [<402ce200>] kbase_platform_exynos5_init+0x1c/0x124
[    2.283742]   [<402c7118>] kbasep_platform_device_init+0x48/0x54
[    2.289731]   [<402b9128>] kbase_device_init+0x44/0x400
[    2.294939]   [<402ca6ec>] kbase_platform_device_probe+0x1b4/0x6c8
[    2.301102]   [<402d56fc>] platform_drv_probe+0x24/0x28
[    2.306310]   [<402d42b4>] driver_probe_device+0xd8/0x214
[    2.311691]   [<402d4468>] __driver_attach+0x78/0x9c
[    2.316639]   [<402d28e4>] bus_for_each_dev+0x60/0x9c
[    2.321673]   [<402d3d88>] driver_attach+0x28/0x30
[    2.326448]   [<402d38f0>] bus_add_driver+0xc0/0x248
[    2.331395]   [<402d49d8>] driver_register+0xac/0x138
[    2.336429]   [<402d5a18>] platform_driver_register+0x54/0x68
[    2.342158]   [<40767a94>] kbase_driver_init+0xb4/0xd0
[    2.347279]   [<4000869c>] do_one_initcall+0xa0/0x174
[    2.352314]   [<4074db90>] kernel_init+0xf8/0x1b4
[    2.357001]   [<4000f240>] kernel_thread_exit+0x0/0x8
[    2.362036] irq event stamp: 41284
[    2.365421] hardirqs last  enabled at (41281): [<4000f304>] default_idle+0x34/0x40
[    2.372973] hardirqs last disabled at (41282): [<4000db74>] __irq_svc+0x34/0x60
[    2.380264] softirqs last  enabled at (41284): [<40032af8>] _local_bh_enable+0x1c/0x20
[    2.388163] softirqs last disabled at (41283): [<40033340>] irq_enter+0x50/0x7c
[    2.395454]
[    2.395455] other info that might help us debug this:
[    2.401964]  Possible unsafe locking scenario:
[    2.401967]
[    2.407866]        CPU0
[    2.410296]        ----
[    2.412727]   lock(&((&mali_dvfs_spinlock))->rlock);
[    2.417674]   <Interrupt>
[    2.420278]     lock(&((&mali_dvfs_spinlock))->rlock);
[    2.425399]
[    2.425401]  *** DEADLOCK ***
[    2.425403]
[    2.431302] no locks held by swapper/0/0.
[    2.435295]
[    2.435296] stack backtrace:
[    2.439642] [<40015580>] (unwind_backtrace+0x0/0xec) from [<4050e2ec>] (dump_stack+0x20/0x24)
[    2.448146] [<4050e2ec>] (dump_stack+0x20/0x24) from [<4050f5ac>] (print_usage_bug+0x250/0x2b8)
[    2.456826] [<4050f5ac>] (print_usage_bug+0x250/0x2b8) from [<4007a844>] (mark_lock+0x358/0x630)
[    2.465593] [<4007a844>] (mark_lock+0x358/0x630) from [<4007b0f8>] (__lock_acquire+0x5dc/0x180c)
[    2.474359] [<4007b0f8>] (__lock_acquire+0x5dc/0x180c) from [<4007c8ac>] (lock_acquire+0x104/0x128)
[    2.483387] [<4007c8ac>] (lock_acquire+0x104/0x128) from [<40516464>] (_raw_spin_lock+0x3c/0x4c)
[    2.492154] [<40516464>] (_raw_spin_lock+0x3c/0x4c) from [<402cef00>] (kbase_platform_dvfs_event+0x28/0x54)
[    2.501876] [<402cef00>] (kbase_platform_dvfs_event+0x28/0x54) from [<402c6498>] (dvfs_callback+0x28/0x74)
[    2.511511] [<402c6498>] (dvfs_callback+0x28/0x74) from [<400514ec>] (__run_hrtimer+0x144/0x220)
[    2.520276] [<400514ec>] (__run_hrtimer+0x144/0x220) from [<400522f4>] (hrtimer_interrupt+0x120/0x248)
[    2.529566] [<400522f4>] (hrtimer_interrupt+0x120/0x248) from [<400244d8>] (exynos4_mct_tick_isr+0x58/0x60)
[    2.539289] [<400244d8>] (exynos4_mct_tick_isr+0x58/0x60) from [<40091968>] (handle_irq_event_percpu+0x8c/0x248)
[    2.549442] [<40091968>] (handle_irq_event_percpu+0x8c/0x248) from [<40091b70>] (handle_irq_event+0x4c/0x6c)
[    2.559251] [<40091b70>] (handle_irq_event+0x4c/0x6c) from [<40094b50>] (handle_fasteoi_irq+0xe4/0x150)
[    2.568624] [<40094b50>] (handle_fasteoi_irq+0xe4/0x150) from [<40091110>] (generic_handle_irq+0x3c/0x50)
[    2.578173] [<40091110>] (generic_handle_irq+0x3c/0x50) from [<4000efc4>] (handle_IRQ+0x88/0xc8)
[    2.586939] [<4000efc4>] (handle_IRQ+0x88/0xc8) from [<40008564>] (gic_handle_irq+0x44/0x68)
[    2.595358] [<40008564>] (gic_handle_irq+0x44/0x68) from [<4000db84>] (__irq_svc+0x44/0x60)
[    2.603688] Exception stack(0x40797f18 to 0x40797f60)
[    2.608723] 7f00:                                                       00000001 00000004
[    2.616883] 7f20: 00000000 00000000 40796000 4080a1c8 4051a564 407be97c 4000406a 410fc0f4
[    2.625042] 7f40: 00000000 40797f6c 40797f30 40797f60 4007d1b0 4000f308 20000013 ffffffff
[    2.633204] [<4000db84>] (__irq_svc+0x44/0x60) from [<4000f308>] (default_idle+0x38/0x40)
[    2.641363] [<4000f308>] (default_idle+0x38/0x40) from [<4000f570>] (cpu_idle+0xb4/0x10c)
[    2.649523] [<4000f570>] (cpu_idle+0xb4/0x10c) from [<404fccac>] (rest_init+0xb4/0xdc)
[    2.657421] [<404fccac>] (rest_init+0xb4/0xdc) from [<4074d9e0>] (start_kernel+0x46c/0x524)
[    2.665753] [<4074d9e0>] (start_kernel+0x46c/0x524) from [<40008044>] (0x40008044)
[

BUG=chrome-os-partner:15688
TEST=boot with CONFIG_PROVE_LOCKING, check dmesg for warning

Change-Id: Ie2c9fa5b57de6d8f9769d5969142ad7b5ede6440
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36705
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: USB: ohci-exynos: initialize registers pointer earlier
Vincent Palatin [Mon, 29 Oct 2012 18:54:14 +0000 (11:54 -0700)]
CHROMIUM: USB: ohci-exynos: initialize registers pointer earlier

In the former code, we have a race condition between the first interrupt
and the regs field initilization in the usb_hcd structure.
If the OHCI irq fires before hcd->regs is set, we are getting a null
pointer dereference in ohci_irq.

When calling usb_add_hcd(), it first executes the reset() callback,
then enables the ohci interrupt, and finally executes the start()
callback. So moving the ohci_init() call which actually initializes the
reg field from start() to reset() should remove the race.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:15731
TEST=run on Spring with USB2.0 on internal PHY on HSIC hub initialized
in the bootloader, and see no kernel panic at startup.

Change-Id: If98070a3cd16b7f735c8cfb62c20cebf410953d2
Reviewed-on: https://gerrit.chromium.org/gerrit/36823
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: samsung: Enable suspend memory check only on old bios
Jonathan Kliegman [Wed, 31 Oct 2012 18:57:26 +0000 (14:57 -0400)]
CHROMIUM: samsung: Enable suspend memory check only on old bios

The bios bug only exists in 2695.90.0 so change default to disabled
and only turn on if the RO bios version is Google_Snow.2695.90.0

Also fix a bug where we don't check if crcs are allocated before trying
to access them on resume.

BUG=chrome-os-partner:15811
TEST=deployed on 2695.90.0 bios, 2695.90.2 and unversioned (dev) bios
  Observed /sys/module/pm_check/paramaters/pm_check_enabled set correctly
  Ran power_Resume test on both devices, saw 1 second difference between them.
  Set CONFIG_SAMSUNG_PM_CHECK=n, build, deploy and suspend/resume
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Change-Id: I7eb89ffc7cbd5c6318d02f21d2e598dc383a68b3
Reviewed-on: https://gerrit.chromium.org/gerrit/37032
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Michael Spang <spang@chromium.org>
11 years agoath9k: do not start rx poll work when flushing pending rx frames
Felix Fietkau [Mon, 29 Oct 2012 21:18:53 +0000 (22:18 +0100)]
ath9k: do not start rx poll work when flushing pending rx frames

__ath_cancel_work has stopped the rx poll work timer, and it needs to
stay stopped until after the reset

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
BUG=chrome-os-partner:15169
TEST=Boot, associate

Change-Id: If65461674dd41507891c0a66f188276a614c6b64
Signed-off-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36829
Reviewed-by: Wade Guthrie <wdg@google.com>
Reviewed-by: Christopher Wiley <wiley@chromium.org>
11 years agoCHROMIUM: exynos: dts: configure hotplug pin on Spring
Vincent Palatin [Sat, 27 Oct 2012 01:04:06 +0000 (18:04 -0700)]
CHROMIUM: exynos: dts: configure hotplug pin on Spring

Spring does not use the dedicated DP hotplug detection pin but a
standard GPIO.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=boot on Spring, see the display coming up automatically.

Change-Id: I716b8d0a070503d3d94bfb995d7d7ed2427de41d
Reviewed-on: https://gerrit.chromium.org/gerrit/36827
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: drm: exynos: optional DP hotplug on a GPIO
Vincent Palatin [Sat, 27 Oct 2012 00:54:01 +0000 (17:54 -0700)]
CHROMIUM: drm: exynos: optional DP hotplug on a GPIO

Allow to setup the Display Port hotplug detection on a vanilla GPIO
instead of the dedicated DP_HPD pin.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=boot on Spring, see the display coming up automatically.

Change-Id: I8eaba89bff0fcdc56d05abf769d7097df05807e1
Reviewed-on: https://gerrit.chromium.org/gerrit/36825
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: exynos: add DP hotplug gpio configuration
Vincent Palatin [Sat, 27 Oct 2012 01:01:10 +0000 (18:01 -0700)]
CHROMIUM: exynos: add DP hotplug gpio configuration

Allow to define an optional gpio in DP platform data used for
DP hotplug detection if the machine is not using the dedicated DP_HPD
pin.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=build and run on Spring and Snow.

Change-Id: Ib1a552b369bceffd739e7d09aeea70cbc80785df
Reviewed-on: https://gerrit.chromium.org/gerrit/36826
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: Input: atmel_mxt_ts - make mxt_initialize async
Yufeng Shen [Tue, 30 Oct 2012 20:06:51 +0000 (16:06 -0400)]
CHROMIUM: Input: atmel_mxt_ts - make mxt_initialize async

mxt_probe() calles mxt_initialize() to initialize the device, which includes
a soft reset and then msleep for the reset to finish. This has big impact on
the system boot time. This patch makes the mxt_initizlize() call async to
reduce the system boot time.

BUG=chrome-os-partner:15743
TEST=Boot the device and check the kernel timestamp in dmesg to see that
     the device initialization is parallelized.

Signed-off-by: Yufeng Shen <miletus@chromium.org>
Change-Id: If106af37a52a0fa874cdc8255c91fdde36776e1f
Reviewed-on: https://gerrit.chromium.org/gerrit/36964
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Simon Que <sque@chromium.org>
Commit-Ready: Yufeng Shen <miletus@chromium.org>

11 years agoCHROMIUM: avoid deadlock in OOM killer
Luigi Semenzato [Tue, 30 Oct 2012 20:35:18 +0000 (13:35 -0700)]
CHROMIUM: avoid deadlock in OOM killer

This removes code that prevents a memory starvation in low-memory situations.

select_bad_process may fail to find a victim for the OOM-kill by returning
ERR_PTR(-1).  In theory this should happen only when there is a guarantee
that memory will be freed shortly.  But in some cases this is not true.
If any process tries to allocate memory between setting the PF_EXITING
bit of p->flags and setting p->exit_state to non-zero, it prevents
the OOM-killer from making any progress, and nobody is able to
allocate memory.

I have found a process that does exactly that:

[ 4687.418818]  [<8104512d>] __cond_resched+0x1b/0x2b
[ 4687.418828]  [<813b67a7>] _cond_resched+0x18/0x21
[ 4687.418840]  [<81093940>] shrink_slab+0x224/0x22f
[ 4687.418856]  [<81095a96>] try_to_free_pages+0x1b7/0x2e6
[ 4687.418868]  [<8108df2a>] __alloc_pages_nodemask+0x40a/0x61f
[ 4687.418882]  [<810a9dbe>] read_swap_cache_async+0x4a/0xcf
[ 4687.418894]  [<810a9ea4>] swapin_readahead+0x61/0x8d
[ 4687.418906]  [<8109fff4>] handle_pte_fault+0x310/0x5fb
[ 4687.418918]  [<810a0420>] handle_mm_fault+0xae/0xbd
[ 4687.418932]  [<8101d0f9>] do_page_fault+0x265/0x284
[ 4687.419002]  [<813b7887>] error_code+0x67/0x6c
[ 4687.419060]  [<8102351d>] mm_release+0x1d/0xc3
[ 4687.419070]  [<81026ce9>] exit_mm+0x1d/0xe9
[ 4687.419090]  [<81028082>] do_exit+0x19b/0x640

mm_release gets its page fault in the vicinity of this
code which is related to futexes:

if (unlikely(tsk->robust_list)) {
exit_robust_list(tsk);
tsk->robust_list = NULL;
}

Since robust_list is a userspace structure, the page
fault looks legitimate, and this is likely a design bug
(also see comment about deadlocks earlier in select_bad_process)
and difficult to fix completely.

In any case we're happy to trade spurious OOM kills for no hangs.

BUG=chromium-os:32321
TEST=tested with a load that reliably causes a hang before and none after

Change-Id: I7037e68cc3eef3a36ca355b9535af0f559b3a148
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36953
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
11 years agoCHROMIUM: config: enable mali hw counter support
Sam Leffler [Thu, 25 Oct 2012 16:35:33 +0000 (09:35 -0700)]
CHROMIUM: config: enable mali hw counter support

Enable support for collecting mali hw counter data via trace events.

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:14556
TEST=boot on snow and collect data

Change-Id: I6b905f2469004238d2e0c7e1fc6c8362d0416f71
Reviewed-on: https://gerrit.chromium.org/gerrit/36565
Tested-by: Sam Leffler <sleffler@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>

11 years agoCHROMIUM: ASoC: samsung: Fix warnings in daisy_max98095
Michael Spang [Tue, 30 Oct 2012 17:13:58 +0000 (13:13 -0400)]
CHROMIUM: ASoC: samsung: Fix warnings in daisy_max98095

This fixes the following build warnings:

sound/soc/samsung/daisy_max98095.c: In function 'daisy_init':
sound/soc/samsung/daisy_max98095.c:407:9: warning: assignment makes pointer from integer without a cast
sound/soc/samsung/daisy_max98095.c: In function 'daisy_resume_post':
sound/soc/samsung/daisy_max98095.c:437:1: warning: no return statement in function returning non-void

BUG=none
TEST=build

Change-Id: I287ddfe7f48afd2bb519af3b3ec1ae10ee7f60e8
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36912
Reviewed-by: Dylan Reid <dgreid@chromium.org>
11 years agoCHROMIUM: block: Fix warning in disk_block_events
Michael Spang [Tue, 30 Oct 2012 17:08:23 +0000 (13:08 -0400)]
CHROMIUM: block: Fix warning in disk_block_events

This fixes the following warning due to type mismatch for
spin_lock_irqsave() flags.

block/genhd.c: In function 'disk_unblock_events':
block/genhd.c:1504:79: warning: comparison of distinct pointer types lacks a cast

BUG=none
TEST=build

Change-Id: Ia692f29445053eef05e94a8b3e8df9a8b59d193f
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36911
Reviewed-by: Paul Taysom <taysom@chromium.org>
11 years agoARM: MALI: connect kbase trace events to system tracing
Sam Leffler [Fri, 12 Oct 2012 16:28:19 +0000 (09:28 -0700)]
ARM: MALI: connect kbase trace events to system tracing

Adapt kbase's trace event mechanism to system trace events.  This facility
is enabled with a new CONFIG_MALI_SYSTEM_TRACE config knob (hidden under
CONFIG_MALI_EXPERT).

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:14556
TEST=verify kbase trace events are generated when enabled

Change-Id: Ic5df3133619c52ae52e9bcd7264494b892e47c86
Reviewed-on: https://gerrit.chromium.org/gerrit/35994
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoacpi: thermal: initialize tz_enabled to 1
Sameer Nanda [Tue, 30 Oct 2012 18:50:34 +0000 (11:50 -0700)]
acpi: thermal: initialize tz_enabled to 1

In the acpi_thermal_add path, acpi_thermal_get_info gets called before
acpi_thermal_register_thermal_zone.  Since tz_enabled was getting set to
1 only in acpi_thermal_register_thermal_zone, acpi_thermal_get_info
ended up disabling thermal polling.

Moved setting of tz_enabled to 1 into acpi_thermal_add itself.

BUG=chrome-os-partner:15697
TEST=on kiev, run CPU soaker threads ("while true; do true; done") and ensure
that the fan turns on as the CPU heats up.

Change-Id: Ib2ad69621ce32f252a8b913387e1560d0750b822
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36927
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
11 years agoCHROMIUM: ARM: MALI: add hardware performance counter support
Sam Leffler [Fri, 12 Oct 2012 16:28:19 +0000 (09:28 -0700)]
CHROMIUM: ARM: MALI: add hardware performance counter support

Add support for dispatching hardware performance counter data through
system trace events.  To enable a counter the associated trace event must
be enabled before turning on hardware counter polling through sysfs.
Data are collected at each vblank event.  Note the set of counters
collected is fixed at the time polling is enabled; to change the set of
counters first disable polling.

This functionality is enabled by CONFIG_MALI_HWC_TRACE.

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:14556
TEST=enable events (e.g. mali_hwc_FRAG_TRANS_ELIM); cat trace_pipe&; echo 1 > /sys/devices/platform/mali.0/hwc_enable; monitor trace data

Change-Id: I801fbfbd87abe69ba5832a1720532ee331fb0314
Reviewed-on: https://gerrit.chromium.org/gerrit/36564
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Anush Elangovan <anush@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: drm: add vblank notifier
Sam Leffler [Mon, 29 Oct 2012 17:52:44 +0000 (10:52 -0700)]
CHROMIUM: drm: add vblank notifier

Add a notifier for vblank events.

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:14556
TEST=collect hardware counter data (dependent cl)

Change-Id: I314186947f9c93b46d3729ffdd5b8f0b0317b88f
Reviewed-on: https://gerrit.chromium.org/gerrit/36781
Reviewed-by: Anush Elangovan <anush@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: config: exynos: turn on CONFIG_SAMSUNG_PM_CHECK
Jonathan Kliegman [Thu, 25 Oct 2012 18:49:28 +0000 (14:49 -0400)]
CHROMIUM: config: exynos: turn on CONFIG_SAMSUNG_PM_CHECK

Enable checking memory on suspend/resume cycles.

BUG=chrome-os-partner:15600
TEST=Ensure /sys/modules/pm_check exists
  Full pm_check functionality tested in CL 36475
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Change-Id: If13496c68ff97a0d6335d9dbfa9ad58b03af377c
Reviewed-on: https://gerrit.chromium.org/gerrit/36575
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>

11 years agoHACK: samsung: pm-check: Add runtime options to enable and panic
Jonathan Kliegman [Thu, 18 Oct 2012 22:16:16 +0000 (18:16 -0400)]
HACK: samsung: pm-check: Add runtime options to enable and panic

Add runtime options to enable, panic and switch between xor and crc
checks of memory.

Update the exclusions to ignore log_buf and sleep_save_sp

BUG=chrome-os-partner:15600
TEST=Tested that with pm_check_should_panic system panics after an
  error and continues running when not set
  Set and unset pm_check_use_xor - confirmed differences in time and
    difference in values for errors
  Set and unset pm_check_enabled, validated log messages for running or not
  Chanaged pm_check_chunksize, saw size of crc error blocks change
  Confirmed correct error messages with pm_check_printskips
  Confirmed suspend_stress_test still catches errors correctly

Change-Id: I4275782391de32378be2f717bd48852ffde634ce
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36475
Reviewed-by: Michael Spang <spang@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
11 years agoCHROMIUM: add stack trace on gpu reset
Sam Leffler [Tue, 23 Oct 2012 17:42:06 +0000 (10:42 -0700)]
CHROMIUM: add stack trace on gpu reset

Add a stack trace for every gpu reset.  This is temporary
for helping with problems in the field.

Signed-off-by: sleffler@chromium.org
BUG=chrome-os-partner:1556
TEST=force gpu reset and verify a stack trace is dumped to the console

Change-Id: I4543367a2bf7321a292bb585bd46e7dfe92cb6e0
Reviewed-on: https://gerrit.chromium.org/gerrit/36498
Reviewed-by: Anush Elangovan <anush@chromium.org>
Commit-Ready: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: iio: isl29018: Support suspend and resume.
Bryan Freed [Tue, 28 Aug 2012 23:52:40 +0000 (16:52 -0700)]
CHROMIUM: iio: isl29018: Support suspend and resume.

The driver leaves the device in power-down state anyway,
so there is nothing to do on suspend.
On resume, we just have to make sure the range and ADC
values are updated in the device since it may have been
powered down in suspend.

BUG=chrome-os-partner:9494
TEST=Verify that lux values are generally unchanged after suspend/resume.
This is a bit difficult to reproduce on snow because we have to simulate
a FET5 power-down on suspend by manually hitting the TPS.  We also have
to modify a range or resolution value that gets pushed to the device, and
we do not normally do that.  This can reproduce the problem:
cd /sys/bus/iio/devices/*
cat in_illuminance0_input
echo 4000 > range
cat in_illuminance0_input # The value changes just a little bit.
i2cset -f -y 4 0x48 0x13 0x02 # Turn off FET5
i2cset -f -y 4 0x48 0x13 0x1f # Turn FET5 back on
powerd_suspend
cat in_illuminance0_input # The value is 4x expected without this patch.

Change-Id: I73e9f9357db3ae3c240a6e1cc5c8acbcf97b6971
Signed-off-by: Bryan Freed <bfreed@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31662
Reviewed-by: Benson Leung <bleung@chromium.org>
11 years agoCHROMIUM: Input: cyapa - Add debug messages for bl_exit failure cases.
Benson Leung [Wed, 17 Oct 2012 02:20:27 +0000 (19:20 -0700)]
CHROMIUM: Input: cyapa - Add debug messages for bl_exit failure cases.

Print the contents of the three status bytes before concluding
that the current state is CYAPA_STATE_BL_IDLE.

Print these in bl_exit error path after setting
cyapa->debug on the failure to exit bootloader in issue 14206.

Also, fix the debug message for "bl_activate" error path
to be correct. Previously it said "bl_exit"

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:14206
TEST=Boot the system, and then force a firmware update using
/opt/google/touchpad/firmware/chromeos-touch-firmwareupdate.sh -d cyapa -f
Then, shut the system down to interrupt the firmware update.
Boot the system the next time.
Check dmesg after the recovery firmware update is complete.
Verify that the following appears :
[    0.863010] cyapa 1-0067: bl_exit failed. Now in state BL_IDLE.
[    0.863019] cyapa 1-0067: status[REG_OP_STATUS] = 0x00
[    0.863031] cyapa 1-0067: status[REG_BL_STATUS] = 0x10
[    0.863038] cyapa 1-0067: status[REG_BL_ERROR] = 0x00
[    0.863045] cyapa 1-0067: failed to bl_exit. -11
[    0.863052] cyapa 1-0067: device detected, but not operational, -11

Change-Id: I0680fd06164306f521f052c3027c0389dc501cb6
Reviewed-on: https://gerrit.chromium.org/gerrit/35791
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
11 years agodrm/exynos: vidi: Fix compilation error re: pitch
Sean Paul [Wed, 24 Oct 2012 20:53:30 +0000 (16:53 -0400)]
drm/exynos: vidi: Fix compilation error re: pitch

Was getting "'struct exynos_drm_overlay' has no member named 'pitch'"
compilation errors when compiling with VIDI enabled.

BUG=None
TEST=Compiles

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

11 years agoCHROMIUM: i915: do not set redundant DP dpms mode
Simon Que [Tue, 23 Oct 2012 18:54:26 +0000 (11:54 -0700)]
CHROMIUM: i915: do not set redundant DP dpms mode

Add a check to intel_dp_dpms() to skip setting the DP's DPMS mode if
the current mode is the same as the new one.

BUG=chrome-os-partner:13364,chrome-os-partner:12423
TEST=Run power_Resume autotest with screen on and screen off on Link.
The resume time should be about the same in each case.

Change-Id: I4269c84bdbd7101b1f71b9fce9935901df917381
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36356
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoUPSTREAM: cfg80211/mac80211: avoid state mishmash on deauth
Stanislaw Gruszka [Mon, 15 Oct 2012 12:52:41 +0000 (14:52 +0200)]
UPSTREAM: cfg80211/mac80211: avoid state mishmash on deauth

Avoid situation when we are on associate state in mac80211 and
on disassociate state in cfg80211. This can results on crash
during modules unload (like showed on this thread:
http://marc.info/?t=134373976300001&r=1&w=2) and possibly other
problems.

Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:14187
TEST=Boot, run, suspend and resume

Change-Id: Ia0fb26d9c5f4df84d460a7b236d9112998ec08ee
Reviewed-on: https://gerrit.chromium.org/gerrit/36438
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: exynos: dts: configure SDIO for Wifi
Vincent Palatin [Tue, 23 Oct 2012 01:15:58 +0000 (18:15 -0700)]
CHROMIUM: exynos: dts: configure SDIO for Wifi

The Wifi SDIO card is on the MMC1 interface,
and the MMC3 interface is no longer connected to anything.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14489
TEST=run on Spring and attach to the guest wifi network from the UI

Change-Id: I42b2a96c67b61a6f220e12c1bd1242d7919c5e9a
Reviewed-on: https://gerrit.chromium.org/gerrit/36301
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
11 years agoCHROMIUM: exynos5: enable/reset Wifi module on Spring
Vincent Palatin [Tue, 23 Oct 2012 20:57:30 +0000 (13:57 -0700)]
CHROMIUM: exynos5: enable/reset Wifi module on Spring

The Wifi SDIO module is controlled by the same GPIOs as Daisy and Snow.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14490
TEST=run on Spring and attach to the guest wifi network from the UI

Change-Id: I6b0e32c09b25f9b279eb57205a098196753882c5
Reviewed-on: https://gerrit.chromium.org/gerrit/36690
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: Input: cyapa - Disable irq before changing power modes
Benson Leung [Wed, 24 Oct 2012 02:04:29 +0000 (19:04 -0700)]
CHROMIUM: Input: cyapa - Disable irq before changing power modes

There could be a potential race condition here as the irq may
be active as we are trying to read and write to device registers
to change power modes. In order to resolve this, disable irq
before cyapa_set_power_mode in cyapa_suspend.

BUG=chromium-os:35663
TEST=Builds clean.
Check that suspend with power/wakeup enabled and disabled
both work correctly to disable and enable the touchpad wake.
1. echo disabled > /sys/bus/i2c/devices/1-0067/power/wakeup
2. powerd_suspend
3. check that trackpad cannot wake the system.
4. Wake using keyboard. Check mouse is functional.
5. echo enabled > /sys/bus/i2c/devices/1-0067/power/wakeup
6. powerd_suspend
7. check that trackpad can wake the system.
8. Check that the trackpad is operational after resume

Change-Id: Ifd8715c51ddea138c5c4c28b4a4337af8d6021cc
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36409

11 years agodrm/exynos: mixer: support for 800x600 resolution
Akshay Saraswat [Wed, 24 Oct 2012 06:25:31 +0000 (15:25 +0900)]
drm/exynos: mixer: support for 800x600 resolution

Extend the mixer configuration to include all resolutions that can be
generated by the mixer. This patch adds 800x600 resolution with the
help of workaround 3.
Workaround summary:
1. Set the resolution mode as HD_1080.
2. Set HD_1080 and all kinds of destination X with biasing 0x20.
3. Start display as 3D one path mode, wait 1 frame and change
   to 3D two path mode.

BUG=chrome-os-partner:12643
TEST=Tested on snow with mentioned resolution

Change-Id: Ib653291acaf5f2f0c5d4545b876223614be642c5
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34746
Tested-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Akshay Saraswat <akshay.s@samsung.com>

11 years agodrm/exynos: mixer: support for 1440x900 resolution
Akshay Saraswat [Wed, 24 Oct 2012 05:11:00 +0000 (14:11 +0900)]
drm/exynos: mixer: support for 1440x900 resolution

Extend the mixer configuration to include all resolutions that can be
generated by the mixer. This patch adds 1440x900 resolution with the
help of workaround 4.
Workaround summary:
1. Set the resolution mode as HD_1080.
2. Set HD_1080 and all kinds of destination X with biasing 0xE0.

BUG=chrome-os-partner:12643
TEST=Tested on snow with mentioned resolution

Change-Id: Iaa0cb9ddfe2995a760b4c72a724807c1b6a2031c
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/33860
Tested-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Akshay Saraswat <akshay.s@samsung.com>

11 years agoUPSTREAM: mwifiex: correction in MSDU padding logic
Yogesh Ashok Powar [Sat, 4 Aug 2012 01:06:01 +0000 (18:06 -0700)]
UPSTREAM: mwifiex: correction in MSDU padding logic

Padding arithmetic will always work for MSDUs provided first MSDU
ends on 4-byte boundary. Fixing it by making sure that all MSDU ends
on 4-byte boundary.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
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>
Signed-off-by: Paul Stewart <pstew@chromium.org>
(cherry picked from commit bda1b1b77918ea340bbfb2938a0fd7d5203e430c)

BUG=chrome-os-partner:14732
TEST=Over-the-air TCP bitrate increases 14% / 11% downlink/uplink

Change-Id: I7c038453504bb399473f9f3cf0c350fbb2a4094f
Reviewed-on: https://gerrit.chromium.org/gerrit/35914
Tested-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>

11 years agoCHROMIUM: Input: cyapa - Fix warning in cyapa_bl_enter
Benson Leung [Wed, 24 Oct 2012 19:22:51 +0000 (12:22 -0700)]
CHROMIUM: Input: cyapa - Fix warning in cyapa_bl_enter

Fix a warning introduced by https://gerrit.chromium.org/gerrit/#/c/35792.
Used a %d instead of a %s.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:14206,chromium-os:35682
TEST=Builds clean.
No warnings when building cyapa.

Change-Id: Ib89e10d60639725098fb6d566c39b0e58f5e8998
Reviewed-on: https://gerrit.chromium.org/gerrit/36452
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
11 years agoUPSTREAM: e1000e: add device IDs for i218
Bruce Allan [Tue, 9 Oct 2012 01:11:26 +0000 (01:11 +0000)]
UPSTREAM: e1000e: add device IDs for i218

i218 is the next-generation LOM that will be available on systems with the
Lynx Point LP Platform Controller Hub (PCH) chipset from Intel.  This patch
provides the initial support of those devices.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 16e310ae6ed352c4963b1f2413fcd88fa693eeda.)
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
BUG=None
TEST=Build and run on a system with an i218 Ethernet controller; verify
     connectivity.

Change-Id: I3676d75ea99e893f69be0b7acc2a14e383d2f9c2
Reviewed-on: https://gerrit.chromium.org/gerrit/36441
Commit-Ready: Josh Triplett <josh@joshtriplett.org>
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: Input : atkbd - Map standard F14, F15 scancode to keycode 184
agnescheng [Wed, 24 Oct 2012 06:10:04 +0000 (14:10 +0800)]
CHROMIUM: Input : atkbd - Map standard F14, F15 scancode to keycode 184
(KEY_F14) and 185

Signed-off-by: agnescheng <agnescheng@chromium.org>
BUG=chrome-os-partner:14339

TEST=Stout EC maps PrtSC to F14, Fn to F15.
Test on stout. Run evtest and get below result.

(Press PrtSc)
Event: time 1350876553.697803, type 4 (EV_MSC), code 4 (MSC_SCAN), value
65
Event: time 1350876553.697812, type 1 (EV_KEY), code 184 (KEY_F14),
value 1

(Press Fn)
Event: time 1350876555.477358, type 4 (EV_MSC), code 4 (MSC_SCAN), value
66
Event: time 1350876555.477367, type 1 (EV_KEY), code 185 (KEY_F15),
value 1

Change-Id: Ie5161d5952d98b6db24571db5152b02f856d2d4e
Reviewed-on: https://gerrit.chromium.org/gerrit/36420
Tested-by: Agnes Cheng <agnescheng@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Agnes Cheng <agnescheng@chromium.org>

11 years agoCHROMIUM: Input: cyapa - remove unused includes
Benson Leung [Wed, 24 Oct 2012 01:10:02 +0000 (18:10 -0700)]
CHROMIUM: Input: cyapa - remove unused includes

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:21047
TEST=builds clean

Change-Id: Ie0e19481dcab432f97e6ba31a45880230dc3b33c
Reviewed-on: https://gerrit.chromium.org/gerrit/36407
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
11 years agoCHROMIUM: Input: cyapa - get_state at the beginning of cyapa_bl_enter
Benson Leung [Wed, 17 Oct 2012 02:26:36 +0000 (19:26 -0700)]
CHROMIUM: Input: cyapa - get_state at the beginning of cyapa_bl_enter

Rather than trusting the cached value of cyapa->state at the beginning
of cyapa_bl_enter, get state before deciding to return 0 from bl_enter.

If bl_exit failed in early probe, but the trackpad entered operational
mode later, then we may have a discrepancy in state between trackpad
and driver. This will make sure we sync state before we try to
write bytes to the trackpad in bl_activate.

On i2c cypress trackpads, this could result in the bl_activate array
being written into the operational firmware's registers, causing the
trackpad to stop functioning. Instead, this will successfully
update the trackpad firmware.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:14206
TEST=Run a forced firmware update.
/opt/google/touchpad/firmware/chromeos-touch-firmwareupdate.sh -d cyapa -f
Verify that the trackpad is functional afterward and that there are no
error messages in dmesg regarding failed firmware update -11.

Change-Id: Ifaf483f30e3f4788d9ef42d023db54cec5c3a44f
Reviewed-on: https://gerrit.chromium.org/gerrit/35792
Commit-Ready: Benson Leung <bleung@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
11 years agoUPSTREAM: staging/gdm72xx: sdio_boot: replace firmware upgrade API
Macpaul Lin [Fri, 28 Sep 2012 00:40:57 +0000 (08:40 +0800)]
UPSTREAM: staging/gdm72xx: sdio_boot: replace firmware upgrade API

Replace firmware upgrade API in download_image().

Signed-off-by: Macpaul Lin <macpaul.from.taiwan@gmail.com>
Cc: Macpaul Lin <macpaul@gmail.com>
Cc: Paul Stewart <pstew@chromium.org>
Cc: Ben Chan <benchan@chromium.org>
Cc: Sage Ahn <syahn@gctsemi.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9e412a0a581e07cf1551bbd9b4ae69654e474a3c)

Change-Id: Ic39b571f4d99709826fcba6384413de76f7aa774
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36310
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: staging/gdm72xx: gdm_wimax: fix compile error when enable debug
Macpaul Lin [Sat, 29 Sep 2012 10:08:06 +0000 (18:08 +0800)]
UPSTREAM: staging/gdm72xx: gdm_wimax: fix compile error when enable debug

Fix compile error when enable DEBUG_SDU and DEBUG_HCI.
Replace deprecated NIPQUAD marco to C code.

Signed-off-by: Macpaul Lin <macpaul.from.taiwan@gmail.com>
Cc: Macpaul Lin <macpaul@gmail.com>
Cc: Paul Stewart <pstew@chromium.org>
Cc: Ben Chan <benchan@chromium.org>
Cc: Sage Ahn <syahn@gctsemi.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2874762b31d8d0eebcfdf189ec9906be9c1460f6)

Change-Id: I4966ab22bddf2225b39a975abbd50e545b8c1a04
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36309
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agoARM: Update kbase to wk42
JasonRuddARM [Tue, 23 Oct 2012 02:43:13 +0000 (19:43 -0700)]
ARM: Update kbase to wk42

Catch up to tip of Barium

BUG=chrome-os-partner:15562
TEST=tested on snow, video playback and webgl aquarium

Change-Id: I5356847b662cafcdbe45ab587f4e79afa666e798
Reviewed-on: https://gerrit.chromium.org/gerrit/36357
Reviewed-by: Anush Elangovan <anush@chromium.org>
Commit-Ready: Anush Elangovan <anush@chromium.org>
Tested-by: Anush Elangovan <anush@chromium.org>
11 years agoUPSTREAM: ath9k_hw: fix ar9462 selfgen chainmask
Rajkumar Manoharan [Fri, 7 Sep 2012 10:54:39 +0000 (16:24 +0530)]
UPSTREAM: ath9k_hw: fix ar9462 selfgen chainmask

When the 9462 is operating in 2G mode and MCI is enabled then
reduce the selfgen chain mask to chain 1. Otherwise poor performance
was reported at short range at Rx side when COEX is enabled.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: I48b2bba6637673112c95ca9c67c7f02d0abcd824
Reviewed-on: https://gerrit.chromium.org/gerrit/36145
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoARM: EXYNOS5: Increase granularity of snow's backlight PWM.
Bryan Freed [Mon, 22 Oct 2012 23:00:43 +0000 (16:00 -0700)]
ARM: EXYNOS5: Increase granularity of snow's backlight PWM.

Explicitly set max_brightness to 2800 from its default of 255.
This gives increased granularity in PWM duty cycles to better
utilize the panel's LED driver.

BUG=chromium-os:34821
TEST=cat /sys/clall/backlight/pwm-backlight.0/max_brightness
  Also, set the backlight a bit low (like the 4th step from the bottom),
  then cover and uncover the backlight to confirm smooth backlight
  transitions that each last about 2 seconds.

Signed-off-by: Bryan Freed <bfreed@chromium.org>
Change-Id: If0565d3cf48b02bec178ac2f0c998cb257c062bf
Reviewed-on: https://gerrit.chromium.org/gerrit/36278
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
Commit-Ready: Bryan Freed <bfreed@chromium.org>

11 years agoCHROMIUM: exynos: dts: configure eDP/LVDS bridge
Vincent Palatin [Thu, 18 Oct 2012 16:38:16 +0000 (09:38 -0700)]
CHROMIUM: exynos: dts: configure eDP/LVDS bridge

Put correct settings for Parade PS8622 eDP/LVDS :
- GPIO settings for control signals.
- re-configure properly MMC blocks as MMC2 is now used for GPIO.
- the MAX77686 LDO17 regulator is used to provide 1.2v to the bridge.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=on Spring, see screen coming up at startup.

Change-Id: Ic305d0b6f6aaf6739ad19818dbfcd8cda90df44a
Reviewed-on: https://gerrit.chromium.org/gerrit/36234
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: exynos5: add support for LCD on Spring
Vincent Palatin [Mon, 22 Oct 2012 17:18:34 +0000 (10:18 -0700)]
CHROMIUM: exynos5: add support for LCD on Spring

Allow to configure DP output for either NXP or Parade eDP-LVDS bridge.
Set sensible LCD panel settings for Spring.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=run on Spring and Snow and see display coming up on ChromeOS
startup on both machines.

Change-Id: I3cd46327a9d8fd6010c8d308111c6c0267fedae4
Reviewed-on: https://gerrit.chromium.org/gerrit/36233
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: config: enable Parade bridge
Vincent Palatin [Thu, 18 Oct 2012 17:40:54 +0000 (10:40 -0700)]
CHROMIUM: config: enable Parade bridge

Compile Parade PS8622 eDP/LVDS.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=on Spring, boot and see the ps8622 initializing with the right
device tree configuration.

Change-Id: I7eb8cb13ee2a742cb5dd025266e4e1db52ee7656
Reviewed-on: https://gerrit.chromium.org/gerrit/36232
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agoCHROMIUM: auxdisplay/ps8620: Add driver for Parade PS8622 bridge
Vincent Palatin [Sat, 4 Aug 2012 16:12:33 +0000 (09:12 -0700)]
CHROMIUM: auxdisplay/ps8620: Add driver for Parade PS8622 bridge

Add a new driver to handle the Parade PS8622 eDP/LVDS bridge chip.
The driver sets properly the SLP_N and RST_N pins and configure the
bridge through I2C.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14491
TEST=Tested on Spring, see the screen coming up on boot.

Change-Id: I3fd15f9780abe45b1cc93f9234db7d79c65ac5a3
Reviewed-on: https://gerrit.chromium.org/gerrit/36231
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
11 years agodrm/exynos: Don't enable vblank irq early
Sean Paul [Thu, 18 Oct 2012 21:12:01 +0000 (17:12 -0400)]
drm/exynos: Don't enable vblank irq early

This patch fixes a bug where the vsync interrupt was being enabled right
from the win_reset routine. If enable_vblank wasn't called before that,
we would finish pageflip on crtc 0 which would cause tearing on fimd.

BUG=chrome-os-partner:15054
TEST=Tested on snow, tested with boot/hotplug/suspend/resume

Change-Id: I067b2d18dcc48ce5d6cdcfc147d64b7e31f47475
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35979
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agodrm/exynos: hdmi: support for interlaced mode
Akshay Saraswat [Wed, 10 Oct 2012 09:47:10 +0000 (18:47 +0900)]
drm/exynos: hdmi: support for interlaced mode

This patch adds interlaced mode support for exynos 5 HDMI IP
as per the spec requirement and differing quirk register
values between progressive and interlaced in exynos drm
hdmi driver.

BUG=chrome-os-partner:12642
TEST=Tested with two differnet monitors and
        Agilent Technologies N5998A HDMI
        protocol analyzer and generator
        for 1080i modes at 60Hz and 50Hz
        frequencies.

Change-Id: I61743b91d4553089c72c376cfc94b4bb96f1edf6
Signed-off-by: Shirish S <s.shirish@samsung.com>
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/33427
Tested-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Akshay Saraswat <akshay.s@samsung.com>

11 years agoCHROMIUM: ALSA: hda/ca0132: Stop streaming when turning on/off Crystal Voice.
Chih-Chung Chang [Tue, 23 Oct 2012 03:57:00 +0000 (11:57 +0800)]
CHROMIUM: ALSA: hda/ca0132: Stop streaming when turning on/off Crystal Voice.

Similar to the previous fix for switching between microphones, if an
active recording stream is running, it has to be stopped before turning
on/off Crystal Voice, otherwise the parameters won't be applied correctly.

The patch is provided by Creative.

BUG=chrome-os-partner:14920
TEST=use "arecord -f cd -B 10000 -d 20 1.wav"
to record audio, and plug/unplug headphone while recording.

Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: Ic9296b07942cfaeb66c58cc1024dd20bf924a231
Reviewed-on: https://gerrit.chromium.org/gerrit/36314
Reviewed-by: Dylan Reid <dgreid@chromium.org>
11 years agoUPSTREAM: mwifiex: minor cleanup and a fix in scan semaphore usage
Amitkumar Karwar [Sat, 20 Oct 2012 01:27:23 +0000 (21:27 -0400)]
UPSTREAM: mwifiex: minor cleanup and a fix in scan semaphore usage

mwifiex_request_scan() takes care of synchronous internal scan
performed by driver during association.
Currently the semaphore acquired for the scan is unnecessarily
released at the end of different paths. Also, failure paths
returning error code other than "-1" are not considered.

We will release it at the end of routine to fix above issues.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15390
TEST="iw mlan0 scan trigger; ifconfig mlan0 down"

Change-Id: I5b305ad3eca54659e764008bc2373c6dc7d08be8
Reviewed-on: https://gerrit.chromium.org/gerrit/36160
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>
11 years agoCHROMIUM: ath9k_hw: fix signal strength / noise measurements on ar9462
Felix Fietkau [Wed, 17 Oct 2012 22:57:35 +0000 (00:57 +0200)]
CHROMIUM: ath9k_hw: fix signal strength / noise measurements on ar9462

The nominal noise floor for most channels is -120, though on some it can
reach -127. Use -120 for converting noise floor to channel noise to avoid
overestimating rx signal strength and channel noise.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:13074
TEST=Compare RSSI to neighboring device

Change-Id: I88f0e700097a3961ef5e1bb6400f4d84e13d6ffc
Reviewed-on: https://gerrit.chromium.org/gerrit/36149
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: i915: Allow 0 level when turning on backlight.
Daniel Erat [Thu, 18 Oct 2012 23:11:49 +0000 (16:11 -0700)]
CHROMIUM: i915: Allow 0 level when turning on backlight.

Previously, the i915 panel driver would set the backlight to
its maximum level if the level was 0 when turning the
display on.  We don't need this (powerd already does it),
and removing it avoids a potential race where we jump to
100% brightness when the brightness-up key is pressed due to
Chrome turning on the display before powerd sets a non-zero
level.

BUG=chromium-os:31795,chromium-os:32447,chromium-os:35481
TEST=manual: no bright flash when increasing the backlight
     from 0% on lumpy or resuming from suspend
CQ-DEPEND=I26f11562df8e01927c0220cddd91e665fe087be9
CQ-DEPEND=Ia961baae656044c3713fb967d8ad173d317c4217

Signed-off-by: Daniel Erat <derat@chromium.org>
Change-Id: I4bafa1c2e1254b09906245b59c935a4be1088d71
Reviewed-on: https://gerrit.chromium.org/gerrit/36135
Reviewed-by: Simon Que <sque@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
11 years agoUPSTREAM: ath9k: fix queuing MCI work twice
Rajkumar Manoharan [Wed, 12 Sep 2012 12:41:12 +0000 (18:11 +0530)]
UPSTREAM: ath9k: fix queuing MCI work twice

Right now MCI work is being queued twice by profile and status
updation. Queue MCI work once when it is needed.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: I6b6bebbef160ab0f68ab56c08d57732dab65507f
Reviewed-on: https://gerrit.chromium.org/gerrit/36148
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: move coex param updation within mci work
Rajkumar Manoharan [Tue, 11 Sep 2012 08:42:47 +0000 (14:12 +0530)]
UPSTREAM: ath9k: move coex param updation within mci work

Update all coex parameters in sigle place. So that we can avoid
redoing the same operation in mutiple places and it eases debugging.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: Ia694a641418647b90012b891b873aae9b9aa8f26
Reviewed-on: https://gerrit.chromium.org/gerrit/36147
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: flush bt profile whenever it is requested
Rajkumar Manoharan [Wed, 12 Sep 2012 17:38:52 +0000 (23:08 +0530)]
UPSTREAM: ath9k: flush bt profile whenever it is requested

Before processing BT profiles or status messages, check whether
it is requested to flush BT profile. Otherwise it might increase
number of BT profiles that affects the WLAN performance. Also
flush the profiles when MCI is recovering from broken rx. After
flushing BT profiles, query BT topology to refetch them.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: If6b1d76594407dbddc0b6549491846247fe1c3ca
Reviewed-on: https://gerrit.chromium.org/gerrit/36146
Commit-Ready: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoUPSTREAM: ath9k: Fix BTCOEX timer triggering comparision
Mohammed Shafi Shajakhan [Wed, 12 Sep 2012 17:33:44 +0000 (23:03 +0530)]
UPSTREAM: ath9k: Fix BTCOEX timer triggering comparision

Its more correct to convert btcoex_period to 'us' while
comparing with btcoex_no_stomp which is in 'us'.
Did not find any functionality issues being fixed,
as the generic hardware timer triggers are usually
refreshed with the newer duty cycle.

Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15083
TEST=Use bluetooth and WiFi

Change-Id: I98778ad94bf4affd2b7e0443fda6f25950a89488
Reviewed-on: https://gerrit.chromium.org/gerrit/36144
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: mwifiex: Abort scan when interface is down
Paul Stewart [Fri, 19 Oct 2012 21:51:37 +0000 (14:51 -0700)]
CHROMIUM: mwifiex: Abort scan when interface is down

When the interface is marked down, scans should be aborted,
otherwise we risk memory leaks and code paths that may cause
a crash.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:15390
TEST="iw mlan0 scan trigger; ifconfig mlan0 down"

Change-Id: I7a9010ce3086a19fbcd143db60dee27290f1e78b
Reviewed-on: https://gerrit.chromium.org/gerrit/36151
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>
11 years agoCHROMIUM: gobi: fix a crash due to use-after-free of the qcusbnet object
Ben Chan [Sat, 20 Oct 2012 02:56:58 +0000 (19:56 -0700)]
CHROMIUM: gobi: fix a crash due to use-after-free of the qcusbnet object

usbnet_disconnect() calls qcnet_unbind(), which accesses the qcusbnet
object. This patch makes sure that the qcusbnet object is freed after
usbnet_disconnect() is called.

BUG=chrome-os-partner:14889
TEST=Tested the following:
1. emerge-lumpy chromeos-kernel
2. Turn on full SLUB debugging and run suspend_stress_test on a system
   with a Gobi 3000 modem.

Change-Id: I3172565bc0df0c3a283d239424d59b58ae1c262f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36177
Reviewed-by: Olof Johansson <olofj@chromium.org>
11 years agoCHROMIUM: cdc_ether: handle Novatel E362 modem with updated firmware
Ben Chan [Sat, 13 Oct 2012 21:53:03 +0000 (14:53 -0700)]
CHROMIUM: cdc_ether: handle Novatel E362 modem with updated firmware

This patch is suggested by Novatel Wireless to allow cdc_ether to
correctly detect a Novatel E362 modem with updated firmware.

BUG=chromium-os:15365
TEST=Verified that the cdc_ether driver correctly detects Novatel E362
modem with firmware 1.41 and 4.08.

Change-Id: If880d26140448fcbdaf89ea1fc546ee861882a19
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36043
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agoCHROMIUM: usb: option: handle identity morphing on Novatel E362 modem
Ben Chan [Sat, 13 Oct 2012 20:41:16 +0000 (13:41 -0700)]
CHROMIUM: usb: option: handle identity morphing on Novatel E362 modem

This patch is suggested by Novatel Wireless to address identity morphing
on Novatel E362 modem such that the correct USB configuration is
selected and detected by the option driver.

BUG=chromium-os:15365
TEST=Verified that the option driver correctly detects Novatel E362
modem with firmware 1.41 and 4.08.

Change-Id: I3449de2327e2b42417e26ff6024f84b72b140853
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36042
Reviewed-by: Paul Stewart <pstew@chromium.org>
11 years agodrm/exynos: Switch debug message DRM_DEBUG_KMS.
Stéphane Marchesin [Mon, 15 Oct 2012 18:43:33 +0000 (11:43 -0700)]
drm/exynos: Switch debug message DRM_DEBUG_KMS.

BUG=none
TEST=by hand; boots, works, doesn't display debug message.

Change-Id: I5f798f352a5455059dcf9241b1dd1ebc02924352
Reviewed-on: https://gerrit.chromium.org/gerrit/35596
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>

11 years agoCHROMIUM: Log RTM_NEWLINK messages broadcast from the kernel (temporary)
Julius Werner [Fri, 19 Oct 2012 20:37:36 +0000 (13:37 -0700)]
CHROMIUM: Log RTM_NEWLINK messages broadcast from the kernel (temporary)

Several recent bug reports document a problem where attached USB
Ethernet adapters are not correctly detected by shill. The issue
persists until reboot once it has happened, but is not generally
reproducable. Logs show that the kernel correctly loads the appropriate
driver, so the issue is believed to be caused by communication problems
between the kernel and shill (via NETLINK_ROUTE sockets).

This patch logs every broadcast of a netlink message with the
RTM_NEWLINK type from the kernel. The surrounding code is slightly
augmented to gather a little more information about the amount of
receipients, but preserves the overall program logic in all cases.

This patch is intended to be temporary. It shall run on production
systems until more reports of the problem (with now more detailed info)
show up, which will hopefully help us nail it down. It should be rolled
back as soon as enough data is available. The additional log burden is
expected to be small (one message per addition, removal and flags change
of a network interface).

BUG=chrome-os-partner:14952,chromium-os:35479
TEST=Add new network interfaces to the system (e.g. by plugging in a USB
Ethernet adapter). Watch RTM_NEWLINK(...) messages appear in dmesg.

Change-Id: I5cf47d0991451679b8a52f9e982d1d695a4f2810
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36150
Reviewed-by: Sameer Nanda <snanda@chromium.org>
11 years agoBACKPORT: e1000e: update driver version number
Bruce Allan [Fri, 17 Aug 2012 06:18:23 +0000 (06:18 +0000)]
BACKPORT: e1000e: update driver version number

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 076d807024052a2c0d76050edd89cd94d0515684)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I60ff19e8f775efa79df42ae406a2a0c7049684c9
Reviewed-on: https://gerrit.chromium.org/gerrit/36132
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup - remove unnecessary variable
Bruce Allan [Fri, 17 Aug 2012 06:18:13 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup - remove unnecessary variable

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 70443ae9d07f1c1de2431327814b2594b86a99bb)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I702db3cc922690b83b364c829bbcf3d60751bdb8
Reviewed-on: https://gerrit.chromium.org/gerrit/36131
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup - remove inapplicable comment
Bruce Allan [Fri, 17 Aug 2012 06:18:02 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup - remove inapplicable comment

Early Receive has been disabled in the driver so this comment is no longer
applicable.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 419e551caa9e9689aa2f68a8897f9eaf44958eb3)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I9dda059f86d3cc49ccbe031fb06b78800524c46a
Reviewed-on: https://gerrit.chromium.org/gerrit/36130
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup strict checkpatch check
Bruce Allan [Fri, 17 Aug 2012 06:17:57 +0000 (06:17 +0000)]
BACKPORT: e1000e: cleanup strict checkpatch check

CHECK: multiple assignments should be avoided

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 06a402ef51b374f2308b0a6c790b301311df786f)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: If5583527e5abab52556e983e204c6395a8eccae5
Reviewed-on: https://gerrit.chromium.org/gerrit/36129
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: cleanup strict checkpatch MEMORY_BARRIER checks
Bruce Allan [Fri, 17 Aug 2012 06:18:07 +0000 (06:18 +0000)]
BACKPORT: e1000e: cleanup strict checkpatch MEMORY_BARRIER checks

Add comments to memory barriers per strict checkpatch.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit bc76329d4a788b1c5f2de7208b2fae4e9204223c)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ia389d29fab4068e1130a8d77aede0f7f3f94bce2
Reviewed-on: https://gerrit.chromium.org/gerrit/36128
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: use correct type for read of 32-bit register
Bruce Allan [Fri, 17 Aug 2012 06:17:51 +0000 (06:17 +0000)]
BACKPORT: e1000e: use correct type for read of 32-bit register

The POEMB register is 32 bits, not 16.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit efc38d2af55d80b4420dab71f6634ad7aa34a38c)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ic86f71b0f7f36c989b9b5dbefa693617331392d7
Reviewed-on: https://gerrit.chromium.org/gerrit/36127
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: DoS while TSO enabled caused by link partner with small MSS
Bruce Allan [Fri, 24 Aug 2012 20:38:11 +0000 (20:38 +0000)]
BACKPORT: e1000e: DoS while TSO enabled caused by link partner with small MSS

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Cc: Stable <stable@vger.kernel.org> [2.6.24+]
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d821a4c4d11ad160925dab2bb009b8444beff484)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I74b2ec062acf7236a5617d2cc5bc09e2206245ec
Reviewed-on: https://gerrit.chromium.org/gerrit/36126
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: implement MDI/MDI-X control
Jesse Brandeburg [Thu, 26 Jul 2012 02:31:14 +0000 (02:31 +0000)]
BACKPORT: e1000e: implement MDI/MDI-X control

Some users report issues with link failing when connected to certain
switches.  This gives the user the ability to control the MDI state
from the driver, allowing users to work around some improperly
behaving switches.

Forcing in this driver is for now only allowed when auto-neg is
enabled.

This is in regards to the related ethtool app patch and
bugzilla.kernel.org bug 11998

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: bruce.w.allan@intel.com
CC: n.poppelier@xs4all.nl
CC: bastien@durel.org
CC: jsveiga@it.eng.br
Tested-by: Aaron Brown aaron.f.brown@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4e8186b68fb944ad9e7fd4080cd8bd8f10eb7cbd)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Id19381f7f9233f5d44d4cf9ceeb7cbb339fe9b2f
Reviewed-on: https://gerrit.chromium.org/gerrit/36125
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: implement 82577/579 MDI setting support
Bruce W Allan [Thu, 26 Jul 2012 02:30:59 +0000 (02:30 +0000)]
BACKPORT: e1000e: implement 82577/579 MDI setting support

In order for e1000e to support MDI setting support via
ethtool this code is needed to allow setting the MDI state
via software.

This is in regards to the related ethtool patch and
fixes bugzilla.kernel.org bug 11998

Signed-off-by: Bruce W Allan <bruce.w.allan@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown aaron.f.brown@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e86fd89188abcc3288ca760a064000054110b2bb)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I69a6ca5367e05cc73551c65857497b41080efc67
Reviewed-on: https://gerrit.chromium.org/gerrit/36124
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix panic while dumping packets on Tx hang with IOMMU
Emil Tantilov [Wed, 1 Aug 2012 08:12:21 +0000 (08:12 +0000)]
BACKPORT: e1000e: fix panic while dumping packets on Tx hang with IOMMU

This patch resolves a "BUG: unable to handle kernel paging request at ..."
oops while dumping packet data. The issue occurs with IOMMU enabled due to
the address provided by phys_to_virt().

This patch avoids phys_to_virt() by using skb->data and the address of the
pages allocated for Rx.

Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
(cherry picked from commit f0c5dadff3fbda77a65b8577fee437c3d771233d)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I1631ae1da604c1c805deb5119319599903989e32
Reviewed-on: https://gerrit.chromium.org/gerrit/36123
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: 82571 Tx Data Corruption during Tx hang recovery
Tushar Dave [Wed, 1 Aug 2012 02:11:15 +0000 (02:11 +0000)]
BACKPORT: e1000e: 82571 Tx Data Corruption during Tx hang recovery

A bus trace shows that while executing e1000e_down, TCTL is cleared except
for the PSP bit.  This occurs while in the middle of fetching a TSO packet
since the Tx packet buffer is full at that point. Before the device is
reset, the e1000_watchdog_task starts to run from the middle (it was
apparently pre-empted earlier, although that is not in the trace) and sets
TCTL.EN.  At that point, 82571 transmits the corrupted packet, apparently
because TCTL.MULR was cleared in the middle of fetching a packet, which is
forbidden.

Driver should just clear TCTL.EN in e1000_reset_hw_82571 instead of
clearing the entire register, so as not to change any settings in the
middle of fetching a packet.

Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
(cherry picked from commit eca90f550494171f54f8a700caee65ec16455a5b)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Ie6c609dda317b0abcb3ded958a04d31f18040914
Reviewed-on: https://gerrit.chromium.org/gerrit/36122
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: NIC goes up and immediately goes down
Tushar Dave [Tue, 31 Jul 2012 02:02:43 +0000 (02:02 +0000)]
BACKPORT: e1000e: NIC goes up and immediately goes down

commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream.

Found that commit d478eb44 was a bad commit.
If the link partner is transmitting codeword (even if NULL codeword),
then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
Ref: RH BZ 840642

Reported-by: Fabio Futigami <ffutigam@redhat.com>
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 733e9ad978a1530328ff78aff3186c20000e5b4e)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3b2347514d74ec7dff07a3cb73bebc91f26c016d
Reviewed-on: https://gerrit.chromium.org/gerrit/36121
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Program the correct register for ITR when using MSI-X.
Matthew Vick [Thu, 12 Jul 2012 00:02:42 +0000 (00:02 +0000)]
BACKPORT: e1000e: Program the correct register for ITR when using MSI-X.

When configuring interrupt throttling on 82574 in MSI-X mode, we need to
be programming the EITR registers instead of the ITR register.

-rc2: Renamed e1000_write_itr() to e1000e_write_itr(), fixed whitespace
      issues, and removed unnecessary !! operation.
-rc3: Reduced the scope of the loop variable in e1000e_write_itr().

Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 22a4cca2f4c2d60c703cdc42158c907570f508e6)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I884a0620d5a87dd3a493b09a27227d084a7419d1
Reviewed-on: https://gerrit.chromium.org/gerrit/36120
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Cleanup code logic in e1000_check_for_serdes_link_82571()
Tushar Dave [Thu, 12 Jul 2012 08:00:15 +0000 (08:00 +0000)]
BACKPORT: e1000e: Cleanup code logic in e1000_check_for_serdes_link_82571()

Cleanup code to make it more clean and readable.

Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 18115f82bc93094a3554f3013cc314ee366a6e7a)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: Iac1ad06a179c454a5ae88a676f24bfb3112df1de
Reviewed-on: https://gerrit.chromium.org/gerrit/36119
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix test for PHY being accessible on 82577/8/9 and I217
Bruce Allan [Sat, 14 Jul 2012 04:23:58 +0000 (04:23 +0000)]
BACKPORT: e1000e: fix test for PHY being accessible on 82577/8/9 and I217

Occasionally, the PHY can be initially inaccessible when the first read of
a PHY register, e.g. PHY_ID1, happens (signified by the returned value
0xFFFF) but subsequent accesses of the PHY work as expected.  Add a retry
counter similar to how it is done in the generic e1000_get_phy_id().

Also, when the PHY is completely inaccessible (i.e. when subsequent reads
of the PHY_IDx registers returns all F's) and the MDIO access mode must be
set to slow before attempting to read the PHY ID again, the functions that
do these latter two actions expect the SW/FW/HW semaphore is not already
set so the semaphore must be released before and re-acquired after calling
them otherwise there is an unnecessarily inordinate amount of delay during
device initialization.

Reported-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a52359b56c29f55aaadf1dab80a0e1043b982676)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I464fb0f854f1b77749a54e72622af23f8cefe123
Reviewed-on: https://gerrit.chromium.org/gerrit/36118
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: Correct link check logic for 82571 serdes
Tushar Dave [Thu, 12 Jul 2012 08:56:56 +0000 (08:56 +0000)]
BACKPORT: e1000e: Correct link check logic for 82571 serdes

commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.

SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits,
RXCW should be read twice to filter out one-time false events and have correct
values for these bits. Incorrect values of these bits in link check logic can
cause weird link stability issues if auto-negotiation fails.

Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3cc4e0e187e4187a6ec13a79dafc1b0f72e31afa)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I8e72c4b8430345d5abb0c15f6887710ba50baf1b
Reviewed-on: https://gerrit.chromium.org/gerrit/36117
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: remove use of IP payload checksum
Bruce Allan [Sat, 30 Jun 2012 20:02:42 +0000 (20:02 +0000)]
BACKPORT: e1000e: remove use of IP payload checksum

commit 2e1706f234f86ff71056ef69683d734fbf7e9e40 upstream.

Currently only used when packet split mode is enabled with jumbo frames,
IP payload checksum (for fragmented UDP packets) is mutually exclusive with
receive hashing offload since the hardware uses the same space in the
receive descriptor for the hardware-provided packet checksum and the RSS
hash, respectively.  Users currently must disable jumbos when receive
hashing offload is enabled, or vice versa, because of this incompatibility.
Since testing has shown that IP payload checksum does not provide any real
benefit, just remove it so that there is no longer a choice between jumbos
or receive hashing offload but not both as done in other Intel GbE drivers
(e.g. e1000, igb).

Also, add a missing check for IP checksum error reported by the hardware;
let the stack verify the checksum when this happens.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e10e76db80d80227dea2a55ea83613c6a4023e67)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I11aed1e04df72a2f2a47c2934624915765ca0f1c
Reviewed-on: https://gerrit.chromium.org/gerrit/36116
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: use more informative logging macros when netdev not yet registered
Bruce Allan [Thu, 7 Jun 2012 02:23:37 +0000 (02:23 +0000)]
BACKPORT: e1000e: use more informative logging macros when netdev not yet registered

Based on a report from Ethan Zhao, before calling register_netdev() the
driver should be using logging macros that do not display the potentially
confusing "(unregistered net_device)" yet still display the useful driver
name and PCI bus/device/function.

Reported-by: Ethan Zhao <ethan.kernel@gmail.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 185095fb80ce57c0f3db8738e36ad7c02dc34d33)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I3daf6ec165251830e364ee3aea010b5f6e199098
Reviewed-on: https://gerrit.chromium.org/gerrit/36115
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: test for valid check_reset_block function pointer
Bruce Allan [Sat, 26 May 2012 06:08:48 +0000 (06:08 +0000)]
BACKPORT: e1000e: test for valid check_reset_block function pointer

commit 470a54207ccf7045a59df727573bd9d148988582 upstream.

commit 44abd5c12767a8c567dc4e45fd9aec3b13ca85e0 introduced NULL pointer
dereferences when attempting to access the check_reset_block function
pointer on 8257x and 80003es2lan non-copper devices.

This fix should be applied back through 3.4.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e831cf2d290e1ecf7825d2ecfabeb0d6733b133d)

Conflicts:
drivers/net/ethernet/intel/e1000e/ethtool.c

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I487be15ace5bdf6ffdebbf0a699dcbcb3132ef91
Reviewed-on: https://gerrit.chromium.org/gerrit/36114
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
11 years agoBACKPORT: e1000e: fix Rapid Start Technology support for i217
Bruce Allan [Thu, 10 May 2012 02:51:17 +0000 (02:51 +0000)]
BACKPORT: e1000e: fix Rapid Start Technology support for i217

The definition of I217_PROXY_CTRL must use the BM_PHY_REG() macro instead
of the PHY_REG() macro for PHY page 800 register 70 since it is for a PHY
register greater than the maximum allowed by the latter macro, and fix a
typo setting the I217_MEMPWR register in e1000_suspend_workarounds_ich8lan.

Also for clarity, rename a few defines as bit definitions instead of masks.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 6d7407bfba0b4eb21d843ff1f9e9c86156e502b2)

BUG=chromium-os:35241
TEST=Checked connectivity on a board with an i217 Ethernet controller

Change-Id: I68b2fc4a603469f39583a24d49f65fc20caabaa8
Reviewed-on: https://gerrit.chromium.org/gerrit/36113
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>