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 <email address hidden>
Signed-off-by: Paulo Zanoni <email address hidden>
Acked-by: Chris Wilson <email address hidden>
Reviewed-by: Daniel Vetter <email address hidden>
Link: http://patchwork.freedesktop<email address hidden>
(cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd)
Signed-off-by: Jani Nikula <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
000e612...
by
=?utf-8?b?VmlsbGUgU3lyasOkbMOk?= <email address hidden>
drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time
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 <email address hidden>
Reported-by: Matthew Auld <email address hidden>
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ä <email address hidden>
Link: http://patchwork.freedesktop<email address hidden>
Tested-by: Matthew Auld <email address hidden>
Reviewed-by: Matthew Auld <email address hidden>
(cherry picked from commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54)
Signed-off-by: Jani Nikula <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
22aba47...
by
=?utf-8?b?VmlsbGUgU3lyasOkbMOk?= <email address hidden>
drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
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 <email address hidden>
Cc: Mika Kahola <email address hidden>
Cc: <email address hidden>
Cc: Daniel J Blueman <email address hidden>
Cc: Paul Bolle <email address hidden>
Cc: Joseph Yasi <email address hidden>
Tested-by: Paul Bolle <email address hidden>
Tested-by: Joseph Yasi <email address hidden> (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ä <email address hidden>
Reviewed-by: Maarten Lankhorst <email address hidden>
Link: http://patchwork.freedesktop<email address hidden>
(cherry picked from commit e0ca7a6be38ce603d26df5707c22e53870a623e0)
Signed-off-by: Jani Nikula <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
294bb34...
by
Hans de Goede <email address hidden>
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
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 <email address hidden>
Reviewed-by: Ville Syrjälä <email address hidden>
Link: http://patchwork<email address hidden>
Signed-off-by: Ville Syrjälä <email address hidden>
(cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756)
Signed-off-by: Jani Nikula <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
6a412ff...
by
Hans de Goede <email address hidden>
drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
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 <email address hidden>
Cc: Raphael G <email address hidden>
Signed-off-by: Thomas Petazzoni <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
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.
Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters. dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid. It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.
The additions in the offset calculations also don't match the intended
size of the window.
Limit the window size and calculate the offset similarly to
show_scroll_win().
Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
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 <email address hidden>
Tested-by: Bryant G Ly <email address hidden>
Signed-off-by: Andy Grover <email address hidden>
Signed-off-by: Bart Van Assche <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
