linux-stable.git/drivers, branch linux-4.8.y

drm/i915: skip the first 4k of stolen memory on everything >= gen8

2017-01-09T07:22:05+00:00

commit 6ba0566cf2afcdb17bff882e3a95cbbcb22c4a83 upstream.

BSpec got updated and this workaround is now listed as standard
required programming for all subsequent projects. This is confirmed to
fix Skylake screen flickering issues (probably caused by the fact that
we initialized a ring in the first page of stolen, but I didn't 100%
confirm this theory).

v2: this is the patch that fixes the screen flickering, document it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Tested-by: Dominik Klementowski 
Signed-off-by: Paulo Zanoni 
Acked-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

2017-01-09T07:22:04+00:00

commit 1f3dc3e334c1192ebe2939ea17ba12f4776f90c3 upstream.

Looks like we're only initializing dev_priv->atomic_cdclk_freq
at resume and commit times, not at init time. Let's do that as
well.

We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
hsw_compute_linetime_wm() on account of populating
intel_state->cdclk from dev_priv->atomic_cdclk_freq.
Previously we were mispopulating intel_state->cdclk with
dev_priv->cdclk_freq which always had a proper value at init
time and hence the WARN_ON() didn't trigger.

Cc: Matthew Auld 
Reported-by: Matthew Auld 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
Fixes: 14676ec6b1a6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.com
Tested-by: Matthew Auld 
Reviewed-by: Matthew Auld 
(cherry picked from commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

2017-01-09T07:22:04+00:00

commit 14676ec6b1a6f2f7fa0bafd98ab42ce77be7a7d4 upstream.

When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.

This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.

v2: Drop the dev_cdclk stuff (Maarten)

Cc: Maarten Lankhorst 
Cc: Mika Kahola 
Cc: bruno.pagani@ens-lyon.org
Cc: Daniel J Blueman 
Cc: Paul Bolle 
Cc: Joseph Yasi 
Tested-by: Paul Bolle 
Tested-by: Joseph Yasi  (v1)
Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit e0ca7a6be38ce603d26df5707c22e53870a623e0)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

2017-01-09T07:22:04+00:00

commit bb98e72adaf9d19719aba35f802d4836f5d5176c upstream.

On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.

The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.

Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.

This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.

Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and
comment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Signed-off-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com
Signed-off-by: Ville Syrjälä 
(cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

2017-01-09T07:22:04+00:00

commit 22ca0d4991169b76e753d767a45f1105c356bbb8 upstream.

Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.

Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161201202925.12220-3-hdegoede@redhat.com
Signed-off-by: Ville Syrjälä 
(cherry picked from commit b2b45fcd921e864a5e9bbc7aa55dee96d5e11c06)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

net: mvpp2: fix dma unmapping of TX buffers for fragments

2017-01-09T07:22:03+00:00

commit 8354491c9d5b06709384cea91d13019bf5e61449 upstream.

Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.

Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:

 - We have a NULL physical address when calling DMA unmap
 - skb_headlen(skb) crashes because skb is NULL

This causes random crashes when fragments are used.

To solve this problem, we need to:

 - Store the physical address of the buffer to be unmapped
   unconditionally, regardless of whether it is tied to a SKB or not.

 - Store the length of the buffer to be unmapped, which requires a new
   field.

Instead of adding a third array to store the length of the buffer to be
unmapped, and as suggested by David Miller, this commit refactors the
tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
added. Therefore, instead of having three arrays to allocate/free, we
have a single one, which also improve data locality, reducing the
impact on the CPU cache.

Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G 
Cc: Raphael G 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sg_write()/bsg_write() is not fit to be called under KERNEL_DS

2017-01-09T07:22:03+00:00

commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

target/user: Fix use-after-free of tcmu_cmds if they are expired

2017-01-09T07:22:03+00:00

commit d0905ca757bc40bd1ebc261a448a521b064777d7 upstream.

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Reported-by: Bryant G Ly 
Tested-by: Bryant G Ly 
Signed-off-by: Andy Grover 
Signed-off-by: Bart Van Assche 
Signed-off-by: Greg Kroah-Hartman

libnvdimm, pfn: fix align attribute

2017-01-09T07:22:03+00:00

commit af7d9f0c57941b465043681cb5c3410f7f3f1a41 upstream.

Fix the format specifier so that the attribute can be parsed correctly.
Currently it returns decimal 1000 for a 4096-byte alignment.

Reported-by: Dave Jiang 
Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

PCI: Check for PME in targeted sleep state

2017-01-09T07:22:00+00:00

commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil 
Tested-by: Pierre de Villemereuil 
Signed-off-by: Alan Stern 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: Lukas Wunner 
Signed-off-by: Greg Kroah-Hartman