We have varied reports of swizzling corruption on gen4 desktop, and
confirmation that one at least is triggered by uneven memory banks
(L-shaped memory). The implication is that the swizzling varies between
the paired channels and the remainder of memory on the single channel. As
the object then has unpredictable swizzling (it will vary depending on
exact page allocation and may even change during the object's lifetime as
the pages are replaced), we have to report to userspace that the swizzling
is unknown.
However, some existing userspace is buggy when it meets an unknown
swizzling configuration and so we need to tell another white lie and
mark the swizzling as NONE but report it as UNKNOWN through the extended
get-tiling-ioctl. See
commit 5eb3e5a5e1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Jun 28 09:19:26 2015 +0100
drm/i915: Declare the swizzling unknown for L-shaped configurations
for the previous example where we found that telling the truth to
userspace just ends up in a world of hurt.
Also since we don't truly know what the swizzling is on the pages, we
need to keep them pinned to prevent swapping as the reports also
suggest that some gen4 devices have previously undetected bit17
swizzling.
v2: Combine unknown + quirk patches to prevent userspace ever seeing
unknown swizzling through the normal get-tiling-ioctl. Also use the same
path for the existing uneven bank detection for mobile gen4.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Tested-by: Matti Hämäläinen <ccr@tnsp.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matti Hämäläinen <ccr@tnsp.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447927085-31726-1-git-send-email-chris@chris-wilson.co.uk
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts
commit 6764e9f872
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Thu Aug 27 15:44:06 2015 +0200
drm/i915: skip modeset if compatible for everyone.
Bring back the i915.fastboot module parameter, disabled by default, due
to backlight regression on Chromebook Pixel 2015.
Apparently the firmware of the Chromebook in question enables the panel
but disables backlight to avoid a brief garbage scanout upon loading the
kernel/module. With fastboot, we leave the backlight untouched, in this
case disabled. The user would have to do a modeset (i.e. not just crank
up the brightness) to enable the backlight.
There is no clean fix readily available, so get back to the drawing
board by reverting.
[N.B. The reference below is for when the thread was included on public
lists, and some of the context had already been dropped by then.]
Reported-and-tested-by: Olof Johansson <olof@lixom.net>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: http://marc.info/?i=CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6T+fGK9J3X7cQ@mail.gmail.com
Fixes: 6764e9f872 ("drm/i915: skip modeset if compatible for everyone.")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447921590-3785-1-git-send-email-jani.nikula@intel.com
When diagnosing a unrelated bug for someone on irc, it would seem the hardware can
be brought up by the BIOS with the embedded displayport using the SPLL for spread spectrum.
Right now this is not handled well in i915, and it calculates the crtc needs to
be reprogrammed on the first modeset without SSC, but the SPLL itself was kept
active. Fix this by exposing SPLL as a shared pll that will not be returned
by intel_get_shared_dpll; you have to know it exists to use it.
Changes since v1:
- Create a separate dpll_hw_state.spll for spll, and use
separate pll functions for spll.
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Gabriel Feceoru <gabriel.feceoru@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447681332-6318-1-git-send-email-maarten.lankhorst@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With gen < 9 we have had always 50Mhz units as our hw
ratio. With gen >= 9 the hw ratio changed to 16.667Mhz (50/3).
The result was that our gpu frequency tracing started to output
values 3 times larger than expected due to hardcoded scaling
value. Fix this by using Use intel_gpu_freq() when generating Mhz
value from ratio for 'intel_gpu_freq_change' trace event.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92591
Cc: stable@vger.kernel.org # v4.3+
Reported-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447776866-29384-1-git-send-email-mika.kuoppala@intel.com
We try to convert the old way of of specifying fb tiling (obj->tiling)
into the new fb modifiers. We store the result in the passed in mode_cmd
structure. But that structure comes directly from the addfb2 ioctl, and
gets copied back out to userspace, which means we're clobbering the
modifiers that the user provided (all 0 since the DRM_MODE_FB_MODIFIERS
flag wasn't even set by the user). Hence if the user reuses the struct
for another addfb2, the ioctl will be rejected since it's now asking for
some modifiers w/o the flag set.
Fix the problem by making a copy of the user provided structure. We can
play any games we want with the copy.
IGT-Version: 1.12-git (x86_64) (Linux: 4.4.0-rc1-stereo+ x86_64)
...
Subtest basic-X-tiled: SUCCESS (0.001s)
Test assertion failure function pitch_tests, file kms_addfb_basic.c:167:
Failed assertion: drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0
Last errno: 22, Invalid argument
Stack trace:
#0 [__igt_fail_assert+0x101]
#1 [pitch_tests+0x619]
#2 [__real_main426+0x2f]
#3 [main+0x23]
#4 [__libc_start_main+0xf0]
#5 [_start+0x29]
#6 [<unknown>+0x29]
Subtest framebuffer-vs-set-tiling failed.
**** DEBUG ****
Test assertion failure function pitch_tests, file kms_addfb_basic.c:167:
Failed assertion: drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0
Last errno: 22, Invalid argument
**** END ****
Subtest framebuffer-vs-set-tiling: FAIL (0.003s)
...
IGT-Version: 1.12-git (x86_64) (Linux: 4.4.0-rc1-stereo+ x86_64)
Subtest framebuffer-vs-set-tiling: SUCCESS (0.000s)
Cc: stable@vger.kernel.org # v4.1+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 2a80eada32 ("drm/i915: Add fb format modifier support")
Testcase: igt/kms_addfb_basic/clobbered-modifier
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447261890-3960-1-git-send-email-ville.syrjala@linux.intel.com
After Damien's D3 fix I started to get runtime suspend residency for the
first time and that revealed a breakage on the set_caching IOCTL path
that accesses the HW but doesn't take an RPM ref. Fix this up.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1446665132-22491-1-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When we set and later readback a frequency value through
sysfs interface, igt/pm_rpm assumes that we get same value back
if it matches hw granularity.
On bxt we have found out that this is not always the case.
Currently frequency - hw ratio - frequency conversions round down,
with few exceptions on platforms that have more specific conversions.
On bxt the supported range can be for example from 100Mhz to 650Mhz.
Midpoint is then calculated by test to be 375 which pm_rps uses to find a
closest hw supported frequency. That is 366 (ratio 22),
which it then writes back. But as the rounding down kicks in,
driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.
Fix this by rounding to closest instead of rounding down in
freq-ratio-freq conversions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
Testcase: igt/pm_rps/basic-api
Tested-by: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447435781-23416-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Let's set crtc_y to 0 instead of setting src_y twice.
Multiple assignments in one statement is a good way to hide bugs.
Please don't do that.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: be5651f2d5 ("drm/i915: Update missing properties in find_initial_plane_obj")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447434973-12369-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Pull drm updates from Dave Airlie:
"I Was Almost Tempted To Capitalise Every Word, but then I decided I
couldn't read it myself!
I've also got one pull request for the sti driver outstanding. It
relied on a commit in Greg's tree and I didn't find out in time, that
commit is in your tree now so I might send that along once this is
merged.
I also had the accidental misfortune to have access to a Skylake on my
desk for a few days, and I've had to encourage Intel to try harder,
which seems to be happening now.
Here is the main drm-next pull request for 4.4.
Highlights:
New driver:
vc4 driver for the Rasberry Pi VPU.
(From Eric Anholt at Broadcom.)
Core:
Atomic fbdev support
Atomic helpers for runtime pm
dp/aux i2c STATUS_UPDATE handling
struct_mutex usage cleanups.
Generic of probing support.
Documentation:
Kerneldoc for VGA switcheroo code.
Rename to gpu instead of drm to reflect scope.
i915:
Skylake GuC firmware fixes
HPD A support
VBT backlight fallbacks
Fastboot by default for some systems
FBC work
BXT/SKL workarounds
Skylake deeper sleep state fixes
amdgpu:
Enable GPU scheduler by default
New atombios opcodes
GPUVM debugging options
Stoney support.
Fencing cleanups.
radeon:
More efficient CS checking
nouveau:
gk20a instance memory handling improvements.
Improved PGOB detection and GK107 support
Kepler GDDR5 PLL statbility improvement
G8x/GT2xx reclock improvements
new userspace API compatiblity fixes.
virtio-gpu:
Add 3D support - qemu 2.5 has it merged for it's gtk backend.
msm:
Initial msm88896 (snapdragon 8200)
exynos:
HDMI cleanups
Enable mixer driver byt default
Add DECON-TV support
vmwgfx:
Move to using memremap + fixes.
rcar-du:
Add support for R8A7793/4 DU
armada:
Remove support for non-component mode
Improved plane handling
Power savings while in DPMS off.
tda998x:
Remove unused slave encoder support
Use more HDMI helpers
Fix EDID read handling
dwhdmi:
Interlace video mode support for ipu-v3/dw_hdmi
Hotplug state fixes
Audio driver integration
imx:
More color formats support.
tegra:
Minor fixes/improvements"
[ Merge fixup: remove unused variable 'dev' that had all uses removed in
commit 4e270f0880: "drm/gem: Drop struct_mutex requirement from
drm_gem_mmap_obj" ]
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits)
drm/vmwgfx: Relax irq locking somewhat
drm/vmwgfx: Properly flush cursor updates and page-flips
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT
drm/amdgpu: group together common fence implementation
drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
drm/amdgpu: remove now unused fence functions
drm/amdgpu: fix fence fallback check
drm/amdgpu: fix stoping the scheduler timeout
drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
drm/i915: Fix locking around GuC firmware load
drm/amdgpu: update Fiji's Golden setting
drm/amdgpu: update Fiji's rev id
drm/amdgpu: extract common code in vi_common_early_init
drm/amd/scheduler: don't oops on failure to load
drm/amdgpu: don't oops on failure to load (v2)
drm/amdgpu: don't VT switch on suspend
...
Merge second patch-bomb from Andrew Morton:
- most of the rest of MM
- procfs
- lib/ updates
- printk updates
- bitops infrastructure tweaks
- checkpatch updates
- nilfs2 update
- signals
- various other misc bits: coredump, seqfile, kexec, pidns, zlib, ipc,
dma-debug, dma-mapping, ...
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (102 commits)
ipc,msg: drop dst nil validation in copy_msg
include/linux/zutil.h: fix usage example of zlib_adler32()
panic: release stale console lock to always get the logbuf printed out
dma-debug: check nents in dma_sync_sg*
dma-mapping: tidy up dma_parms default handling
pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode
kexec: use file name as the output message prefix
fs, seqfile: always allow oom killer
seq_file: reuse string_escape_str()
fs/seq_file: use seq_* helpers in seq_hex_dump()
coredump: change zap_threads() and zap_process() to use for_each_thread()
coredump: ensure all coredumping tasks have SIGNAL_GROUP_COREDUMP
signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT)
signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread()
signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
signals: kill block_all_signals() and unblock_all_signals()
nilfs2: fix gcc uninitialized-variable warnings in powerpc build
nilfs2: fix gcc unused-but-set-variable warnings
MAINTAINERS: nilfs2: add header file for tracing
nilfs2: add tracepoints for analyzing reading and writing metadata files
...
Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.
* tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel:
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)
drm/i915/skl: Prevent unclaimed register writes on skylake.
drm/i915: disable CPU PWM also on LPT/SPT backlight disable
drm/i915: Fix maxfifo watermark calc on vlv cursor planes
drm/i915: add hotplug activation period to hotplug update mask
There are many places which use mapping_gfp_mask to restrict a more
generic gfp mask which would be used for allocations which are not
directly related to the page cache but they are performed in the same
context.
Let's introduce a helper function which makes the restriction explicit and
easier to track. This patch doesn't introduce any functional changes.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep. Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep. The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.
[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".
Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.
This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.
This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.
o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.
o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.
o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.
The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.
The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The display power well support on this platform is in a somewhat broken
state atm, so disable it by default.
This in effect will get rid of incorrect assert WARNs about the CSR/DMC
firmware not being loaded during power well toggling. It also removes a
problem during driver loading where a register is accessed while its
backing power well is down, resulting in another WARN. Until we come up
with the root cause of the second problem and the proper fix for both
issues, keep all display side power wells on.
Also clarify a bit the option description.
Reported-by: Dave Airlie <airlied@redhat.com>
Reference: http://mid.gmane.org/CAPM=9tyjBQjSBTKa49cRr6SYkpNW7Pq-fUFznZZ8Y1snvvk7mA@mail.gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446757451-2777-1-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have a timed release of a forcewake when using
I915_READ/WRITE macros. wait_for() macro will go to quite
long sleep if the first read doesn't satisfy the condition for
successful exit. With these two interacting, it is possible that
we lose the forcewake during the wait_for() and the subsequent read
will reaquire forcewake.
Further experiments with skl shows that when we lose forcewake,
we lose the reset request we submitted. So reset request register
is not power context saved.
Grab forcewakes for all engines before starting the reset/request
dance so that all requests stay valid for the duration of reset
requisition across all the engines.
v2: Add comment on power well sleeps. Wrap the reset handling
under forcewake instead of just reset requests (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.
v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).
v3:
Pin and unpin a fence only if the current view type is normal.
v4:
Extend the "view type is normal" check for pin_fence as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I'm getting unclaimed register writes when checking the WM registers
after the crtc is disabled. So I would imagine those are guarded by
the crtc power well. Fix this by not reading out wm state when the
power well is off.
Cc: stable@vger.kernel.org # v4.3
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.
* tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits)
drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
drm/i915: Kill the leftover RMW from ivb_sprite_disable()
drm/i915: restore ggtt double-bind avoidance
drm/i915/skl: Enable pipe gamma for sprite planes.
drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)
MAINTAINERS: add link to the Intel Graphics for Linux web site
drm/i915: Move skl/bxt gt specific workarounds to ring init
drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
drm/i915: revert a few more watermark commits
drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE
drm/i915: Clean up LVDS register handling
drm/i915: Throw out some useless variables
drm/i915: Parametrize and fix SWF registers
drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.
drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function
drm/i915: Fix a few bad hex numbers in register defines
drm/i915: Protect register macro arguments
drm/i915: Include gpio_mmio_base in GMBUS reg defines
drm/i915: Parametrize HSW video DIP data registers
drm/i915: Eliminate weird parameter inversion from BXT PPS registers
...
Although we don't support or enable CPU PWM with LPT/SPT based systems,
it may have been enabled prior to loading the driver. Disable the CPU
PWM on LPT/SPT backlight disable to avoid warnings on LCPLL disable.
The issue has been present on BDW since BDW enabling, but was recently
introduced on HSW with
commit 437b15b801
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 4 16:55:13 2015 +0300
drm/i915: use pch backlight override on hsw too
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reference: http://mid.gmane.org/87y4frhwsn.fsf@yhuang-dev.intel.com
Reported-by: kernel test robot <ying.huang@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446033429-8006-1-git-send-email-jani.nikula@intel.com
A typo resulted in the watermarks for cursor planes not being calculated
correctly. Fixed the typo.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Not much core work here, a few small tweaks to interfaces but mainly the
changes here are driver ones. Highlights include:
- Updates to the topology userspace interface
- Big updates to the Renesas support from Morimoto-san
- Most of the support for Intel Sky Lake systems.
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825 and Rockchip
S/PDIF.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWLbbGAAoJECTWi3JdVIfQH7oH/1VdN2ozP9A03p24aC5qso1F
VWOBnG4pkw1G6J5qK2lemMDeJdRdTfreICUAa9Tw9kOSfTIb6F3X8kCw8tbwlw0I
4phgmyo23P53OfLZFMkQi/RCfwItnE0sszqhvoumUg0ryjYxg2JT+gTMgwvVo7Pq
hf6m6a3we5pxLIIYP4wlQgOKwUJe4B4nC37ExySf24Dlo/DzmWDtfQbGvmyluFzb
MB1qzEvAc/KC3LZFkIFmhfg2/caNRhcQrzkUCYrLR3t+oz9P1zCpYTII7VDdMg7L
SM2VoL+ynEAdBqa38Ozwxvd/mpHwinlAeiikuwz1PyxVOqZvZqqiWzD8eUJkhZk=
=/F/Q
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v4.4
Not much core work here, a few small tweaks to interfaces but mainly the
changes here are driver ones. Highlights include:
- Updates to the topology userspace interface
- Big updates to the Renesas support from Morimoto-san
- Most of the support for Intel Sky Lake systems.
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825 and Rockchip
S/PDIF.
- A new driver for the Atmel Class D speaker drivers
commit 0706f17c30
Author: Egbert Eich <eich@suse.de>
Date: Wed Sep 23 16:15:27 2015 +0200
drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2
added a check with WARN to ensure only bits within the mask are
enabled. Turns out that doesn't hold for G4X, which spits out:
[ 2.641439] ------------[ cut here ]------------
[ 2.641444] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:182 i915_hotplug_interrupt_update_locked+0x45/0x83()
[ 2.641446] WARN_ON(bits & ~mask)
etc.
Add CRT_HOTPLUG_ACTIVATION_PERIOD_64 to the mask to fix the warning.
Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de>
References: https://bugzilla.kernel.org/show_bug.cgi?id=104991
Fixes: 0706f17c30 ("drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2")
Cc: Egbert Eich <eich@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1445437363-3030-1-git-send-email-jani.nikula@intel.com
More drm-misc for 4.4.
- fb refcount fix in atomic fbdev
- various locking reworks to reduce drm_global_mutex and dev->struct_mutex
- rename docbook to gpu.tmpl and include vga_switcheroo stuff, plus more
vga_switcheroo (Lukas Wunner)
- viewport check fixes for atomic drivers from Ville
- DRM_DEBUG_VBL from Ville
- non-contentious header fixes from Mikko Rapeli
- small things all over
* tag 'topic/drm-misc-2015-10-19' of git://anongit.freedesktop.org/drm-intel: (31 commits)
drm/fb-helper: Fix fb refcounting in pan_display_atomic
drm/fb-helper: Set plane rotation directly
drm: fix mutex leak in drm_dp_get_mst_branch_device
drm: Check plane src coordinates correctly during page flip for atomic drivers
drm: Check crtc viewport correctly with rotated primary plane on atomic drivers
drm: Refactor plane src coordinate checks
drm: Swap w/h when converting the mode to src coordidates for a rotated primary plane
drm: Don't leak fb when plane crtc coodinates are bad
ALSA: hda - Spell vga_switcheroo consistently
drm/gem: Use kref_get_unless_zero for the weak mmap references
drm/vgem: Drop vgem_drm_gem_mmap
drm: Fix return value of drm_framebuffer_init()
drm/gem: Use container_of in drm_gem_object_free
drm/gem: Check locking in drm_gem_object_unreference
drm/gem: Drop struct_mutex requirement from drm_gem_mmap_obj
drm/i810_drm.h: include drm/drm.h
r128_drm.h: include drm/drm.h
savage_drm.h: include <drm/drm.h>
gpu/doc: Convert to markdown harder
gpu/doc: Add vga_switcheroo documentation
...
- dmc fixes from Animesh (not yet all) for deeper sleep states
- piles of prep patches from Ville to make mmio functions type-safe
- more fbc work from Paulo all over
- w/a shuffling from Arun Siluvery
- first part of atomic watermark updates from Matt and Ville (later parts had to
be dropped again unfortunately)
- lots of patches to prepare bxt dsi support ( Shashank Sharma)
- userptr fixes from Chris
- audio rate interface between i915/snd_hda plus kerneldoc (Libin Yang)
- shrinker improvements and fixes (Chris Wilson)
- lots and lots of small patches all over
* tag 'drm-intel-next-2015-10-10' of git://anongit.freedesktop.org/drm-intel: (134 commits)
drm/i915: Update DRIVER_DATE to 20151010
drm/i915: Partial revert of atomic watermark series
drm/i915: Early exit from semaphore_waits_for for execlist mode.
drm/i915: Remove wrong warning from i915_gem_context_clean
drm/i915: Determine the stolen memory base address on gen2
drm/i915: fix FBC buffer size checks
drm/i915: fix CFB size calculation
drm/i915: remove pre-atomic check from SKL update_primary_plane
drm/i915: don't allocate fbcon from stolen memory if it's too big
Revert "drm/i915: Call encoder hotplug for init and resume cases"
Revert "drm/i915: Add hot_plug hook for hdmi encoder"
drm/i915: use error path
drm/i915/irq: Fix misspelled word register in kernel-doc
drm/i915/irq: Fix kernel-doc warnings
drm/i915: Hook up ring workaround writes at context creation time on Gen6-7.
drm/i915: Don't warn if the workaround list is empty.
drm/i915: Resurrect golden context on gen6/7
drm/i915/chv: remove pre-production hardware workarounds
drm/i915/snb: remove pre-production hardware workaround
drm/i915/bxt: Set time interval unit to 0.833us
...
drm_edid.c now computes the alternate CEA clocks using
DIV_ROUND_CLOSEST(), so follow suit in the N/CTS setup to make sure we
pick the right setting for the mode.
Unfortunately we can't actually use DIV_ROUND_CLOSEST() here due to the
({}) construct used, so just stick in raw numbers instead.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
everywhere.
Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.
v2: admgpu happened, include that one too. And i915 lost its UMS
support which means we can change all the i915 ioctls too.
v3: Rebased on top of new vmwgfx DX interface extensions.
v4: Rebase on top of render-node support in exynos.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED, besides that we obviously don't need
it any more in kms mode.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Another round of drm-misc. Unfortunately the DRM_UNLOCKED removal for
DRIVER_MODESET isn't complete yet for lack of review on 1-2 patches.
Otherwise just various stuff all over.
* tag 'topic/drm-misc-2015-10-08' of git://anongit.freedesktop.org/drm-intel:
drm: Stop using drm_vblank_count() as the hw frame counter
drm/irq: Use unsigned int pipe in public API
drm: Use DRM_ROTATE_MASK and DRM_REFLECT_MASK
drm: Add DRM_ROTATE_MASK and DRM_REFLECT_MASK
vga_switcheroo: Add missing locking
vgaarb: use kzalloc in vga_arbiter_add_pci_device()
drm: Don't zero vblank timestamps from the irq handler
drm: Hack around CONFIG_AGP=m build failures
drm/i915: Remove setparam ioctl
drm: Remove dummy agp ioctl wrappers
drm/vmwgfx: Stop checking for DRM_UNLOCKED
drm/drm_ioctl.c: kerneldoc
drm: Define a drm_invalid_op ioctl implementation
drm: Remove __OS_HAS_AGP
drm/doc: Update docs about device instance setup
We still had one lingering RMW in ivb_sprite_disable(), all the other
RMWs were killed off from the sprite code some time ago. Kill the
straggler too.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was accidentally lost in
commit 75d04a3773
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Apr 28 17:56:17 2015 +0300
drm/i915/gtt: Allocate va range only if vma is not bound
While at it implement an improved version suggested by Chris which
avoids the double-bind irrespective of what type of bind is done
first.
Note that this exact bug was already addressed in
commit d0e30adc42
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 29 20:02:48 2015 +0100
drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt
but the problem is still that originally in
commit 0875546c53
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Apr 20 09:04:05 2015 -0700
drm/i915: Fix up the vma aliasing ppgtt binding
if forgotten to take into account there case where we have a
GLOBAL_BIND before a LOCAL_BIND. This patch here fixes that.
v2: Pimp commit message and revert the partial fix.
v3: Split into two functions to specialize on aliasing_ppgtt y/n.
v4: WARN_ON for paranoia in the init sequence, since the ggtt probe
and aliasing ppgtt setup are far apart.
v5: Style nits.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444911781-32607-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since SKL has universal planes, we should configure the sprite planes
and the primary plane the same. For the primary plane we do enable
the pipe gamma on the plane so do the same for the non-primary planes.
Without this, the pipe CRC values will be different for something
displayed on the primary plane and something displayed on a sprite
plane when the ARGB8888 format is used.
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extend this to SKL and BXT as it's needed for these platforms as well.
v2: Change if condition to HAS_DDI() instead of listing each platform
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes the warnings like
"plane A assertion failure, should be disabled but not"
that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.
Most likely caused by
commit 36750f284b
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 1 12:49:54 2015 +0200
drm/i915: update plane state during init
This is a new version of
commit 721a09f739
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Sep 15 14:28:54 2015 +0200
drm/i915: Add primary plane to mask if it's visible
That was reverted in order to facilitate easier backporting of some
commits from -next to v4.3.
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429
Reported-and-tested-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().
The plane disabling was first added in
4cf0ebbd4f drm/i915: Rework plane readout.
I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.
Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled
v2: Steal Maarten's idea to move crtc->mode etc. assignment too
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts commit 721a09f739.
There is nothing wrong with the commit per se. We had two versions of
the commit, one in -next headed for v4.4 and this one for v4.3. Turns
out we'll need to backport more fixes from -next, and they conflict with
the v4.3 version. It gets messy. It will be easiest to revert this one,
and backport all the relevant commits from -next without modifications;
they apply cleanly after this revert.
Requested-by: Joseph Yasi <joe.yasi@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910#c4
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Some registers are, naturally, lost in gpu reset/suspend cycle.
And some registers, for example in display domain, are not subject
to gpu reset so they retain their contents.
As hang recovery triggers a reset, recoverable gpu hang can currently
flush out essential workarounds and cause havoc later on.
When register GEN8_GARBNTL is missing the WaEnableGapsTsvCreditFix:skl,
it can cause random system hangs [1]. This workaround was added in:
commit 245d96670d ("drm/i915:skl: Add WaEnableGapsTsvCreditFix")
But another set of system hangs were observed and the failure pattern
indicated that there was random gpu hang preceding the system hang [2].
This lead to the realization that we lose this workaround and BDW_SCRATCH1
on reset.
Add these workarounds setup in display init to skl/bxt ring init
where LRI workarounds are also setup. This way their setup is not
dependent on display side init.
References: [1] https://bugs.freedesktop.org/show_bug.cgi?id=90854
References: [2] https://bugs.freedesktop.org/show_bug.cgi?id=92315
Reported-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Cc: Tomi Sarvela <tomix.p.sarvela@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apparently writing the DPLL register P1/P2 divider fields won't trigger
an actual change in the DPLL output unless VGA mode is enabled for
prior to the register write that changes the P1/P2 dividers. The write
with the new P1/P2 divider can itself disable VGA mode again without
problems.
I tested the behaviour on my 946GZ, and when manually frobbing the
register with the display on, the behaviour is very clear. However I
can't explain why this machine actually works. The P1/P2 divider
changes caused by normal modesets do seem to make it through to the
hardware somehow since I get a stable picture on the monitor with
any resolution. Maybe it's the "three times for luck" stuff that
somehow masks the problem, or something.
But apparently there are machines (eg. Nick Bowler's G45) where that
isn't the case and we fail to get the correct clock from the DPLL.
Things used to work because we enabled VGA mode for disabled DPLLs,
so when re-enabling the DPLL VGA mode was enabled just prior to the
first register write, and hence the P1/P2 change went through without
a hitch. That got changed in
b8afb9113c drm/i915: Keep GMCH DPLL VGA mode always disabled
in the name of consistency. In order to keep the consistency part,
leave VGA mode disabled for disabled DPLLs, but turn it on just prior
to updating the P1/P2 dividers to make sure the hardware picks up
on the new values.
Cc: Nick Bowler <nbowler@draconx.ca>
Reported-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We accidentally lost the initial DPLL register write in
1c4e027461 drm/i915: Fix DVO 2x clock enable on 830M
The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.
Reported-and-tested-by: Nick Bowler <nbowler@draconx.ca>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: stable@vger.kernel.org
Cc: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to flush the results from in-batch pipecontrol writes (used for
example in glQuery) before declaring the batch complete (and so declaring
the query results coherent), we need to set the FlushEnable bit in our
flushing pipecontrol. The FlushEnable bit "waits until all previous
writes of immediate data from post-sync circles are complete before
executing the next command".
I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. By knowing that only objects pinned to the hardware
will have an elevated vma->pin_count, so we can coallesce many of the
linear walks over the obj->vma_list.
v2: Try and retrospectively add comments explaining the steps in
rebinding the active VMA.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've botched this in
commit eb0b44adc0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 18 14:47:59 2015 +0100
drm/i915: kerneldoc for i915_gem_shrinker.c
so let's fix it.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
