linux-toradex.git, branch v4.9.7

Linux 4.9.7

2017-02-01T07:33:31+00:00

drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround.

2017-02-01T07:33:14+00:00

commit 4fc020d864647ea3ae8cb8f17d63e48e87ebd0bf upstream.

The WaDisableLSQCROPERFforOCL workaround has the side effect of
disabling an L3SQ optimization that has huge performance implications
and is unlikely to be necessary for the correct functioning of usual
graphic workloads.  Userspace is free to re-enable the workaround on
demand, and is generally in a better position to determine whether the
workaround is necessary than the DRM is (e.g. only during the
execution of compute kernels that rely on both L3 fences and HDC R/W
requests).

The same workaround seems to apply to BDW (at least to production
stepping G1) and SKL as well (the internal workaround database claims
that it does for all steppings, while the BSpec workaround table only
mentions pre-production steppings), but the DRM doesn't do anything
beyond whitelisting the L3SQCREG4 register so userspace can enable it
when it sees fit.  Do the same on KBL platforms.

Improves performance of the GFXBench4 gl_manhattan31 benchmark by 60%,
and gl_4 (AKA car chase) by 14% on a KBL GT2 running Mesa master --
This is followed by a regression of 35% and 10% respectively for the
same benchmarks and platform caused by my recent patch series
switching userspace to use the dataport constant cache instead of the
sampler to implement uniform pull constant loads, which caused us to
hit more heavily the L3 cache (and on platforms other than KBL had the
opposite effect of improving performance of the same two benchmarks).
The overall effect on KBL of this change combined with the recent
userspace change is respectively 4.6% and 2.6%.  SynMark2 OglShMapPcf
was affected by the constant cache changes (though it improved as it
did on other platforms rather than regressing), but is not
significantly affected by this patch (with statistical significance of
5% and sample size 20).

v2: Drop some more code to avoid unused variable warning.

Fixes: 738fa1b3123f ("drm/i915/kbl: Add WaDisableLSQCROPERFforOCL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99256
Signed-off-by: Francisco Jerez 
Cc: Matthew Auld 
Cc: Eero Tamminen 
Cc: Jani Nikula 
Cc: Mika Kuoppala 
Cc: beignet@lists.freedesktop.org
Reviewed-by: Mika Kuoppala 
[Removed double Fixes tag]
Signed-off-by: Mika Kuoppala 
Link: http://patchwork.freedesktop.org/patch/msgid/1484217894-20505-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 8726f2faa371514fba2f594d799db95203dfeee0)
Signed-off-by: Jani Nikula 
[ Francisco Jerez: Rebase on v4.9 branch. ]
Signed-off-by: Francisco Jerez 
Signed-off-by: Greg Kroah-Hartman

perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race

2017-02-01T07:33:14+00:00

commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.

Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.

The problem is exactly that described in commit:

  f63a8daa5812 ("perf: Fix event->ctx locking")

... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.

That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.

So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).

Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.

Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Min Chong 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

mm, memcg: do not retry precharge charges

2017-02-01T07:33:14+00:00

commit 3674534b775354516e5c148ea48f51d4d1909a78 upstream.

When memory.move_charge_at_immigrate is enabled and precharges are
depleted during move, mem_cgroup_move_charge_pte_range() will attempt to
increase the size of the precharge.

Prevent precharges from ever looping by setting __GFP_NORETRY.  This was
probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is
pointless as written.

Fixes: 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge path")
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1701130208510.69402@chino.kir.corp.google.com
Signed-off-by: David Rientjes 
Acked-by: Michal Hocko 
Cc: Johannes Weiner 
Cc: Vladimir Davydov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

2017-02-01T07:33:14+00:00

commit 5a00b6c2438460b870a451f14593fc40d3c7edf6 upstream.

The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
starts refusing misconfigured interrupt handlers. This makes
intel_mid_powerbtn not working anymore.

Add a mandatory flag to a threaded IRQ request in the driver.

Fixes: 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

platform/x86: mlx-platform: free first dev on error

2017-02-01T07:33:13+00:00

commit 63d762b88cb5510f2bfdb5112ced18cde867ae61 upstream.

There is an off-by-one error so we don't unregister priv->pdev_mux[0].
Also it's slightly simpler as a while loop instead of a for loop.

Fixes: 58cbbee2391c ("x86/platform/mellanox: Introduce support for Mellanox systems platform")
Signed-off-by: Dan Carpenter 
Acked-by: Vadim Pasternak 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

virtio_mmio: Set DMA masks appropriately

2017-02-01T07:33:13+00:00

commit f7f6634d23830ff74335734fbdb28ea109c1f349 upstream.

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
inadvertently relying on the default 32-bit DMA mask, which leads to
problems like rapidly exhausting SWIOTLB bounce buffers.

Ensure that we set the appropriate 64-bit DMA mask whenever possible,
with the coherent mask suitably limited for the legacy vring as per
a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
devices").

Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Reported-by: Jean-Philippe Brucker 
Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
Signed-off-by: Robin Murphy 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman

memory_hotplug: make zone_can_shift() return a boolean value

2017-02-01T07:33:13+00:00

commit 8a1f780e7f28c7c1d640118242cf68d528c456cd upstream.

online_{kernel|movable} is used to change the memory zone to
ZONE_{NORMAL|MOVABLE} and online the memory.

To check that memory zone can be changed, zone_can_shift() is used.
Currently the function returns minus integer value, plus integer
value and 0. When the function returns minus or plus integer value,
it means that the memory zone can be changed to ZONE_{NORNAL|MOVABLE}.

But when the function returns 0, there are two meanings.

One of the meanings is that the memory zone does not need to be changed.
For example, when memory is in ZONE_NORMAL and onlined by online_kernel
the memory zone does not need to be changed.

Another meaning is that the memory zone cannot be changed. When memory
is in ZONE_NORMAL and onlined by online_movable, the memory zone may
not be changed to ZONE_MOVALBE due to memory online limitation(see
Documentation/memory-hotplug.txt). In this case, memory must not be
onlined.

The patch changes the return type of zone_can_shift() so that memory
online operation fails when memory zone cannot be changed as follows:

Before applying patch:
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320
   # echo online_movable > memory4097/state
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   
      node_scanned  0
           spanned  8388608
           present  8388608
           managed  8388608

   online_movable operation succeeded. But memory is onlined as
   ZONE_NORMAL, not ZONE_MOVABLE.

After applying patch:
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320
   # echo online_movable > memory4097/state
   bash: echo: write error: Invalid argument
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320

   online_movable operation failed because of failure of changing
   the memory zone from ZONE_NORMAL to ZONE_MOVABLE

Fixes: df429ac03936 ("memory-hotplug: more general validation of zone during online")
Link: http://lkml.kernel.org/r/2f9c3837-33d7-b6e5-59c0-6ca4372b2d84@gmail.com
Signed-off-by: Yasuaki Ishimatsu 
Reviewed-by: Reza Arbab 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Rectify debounce support

2017-02-01T07:33:13+00:00

commit 04ff5a095d662e0879f0eb04b9247e092210aeff upstream.

The commit 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
implements debounce for Baytrail pin control, but seems wasn't tested properly.

The register which keeps debounce value is separated from the configuration
one. Writing wrong values to the latter will guarantee wrong behaviour of the
driver and even might break something physically.

Besides above there is missed case how to disable it, which is actually done
through the bit in configuration register.

Rectify implementation here by using proper register for debounce value.

Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
Cc: Cristina Ciocan 
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: uniphier: fix Ethernet (RMII) pin-mux setting for LD20

2017-02-01T07:33:13+00:00

commit df1539c25cce98e2ac69881958850c6535240707 upstream.

Fix the pin-mux values for the MDC, MDIO, MDIO_INTL, PHYRSTL pins.

Fixes: 1e359ab1285e ("pinctrl: uniphier: add Ethernet pin-mux settings")
Signed-off-by: Masahiro Yamada 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman