| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull misc vfs updates from Al Viro:
"All kinds of misc stuff, without any unifying topic, from various
people.
Neil's d_anon patch, several bugfixes, introduction of kvmalloc
analogue of kmemdup_user(), extending bitfield.h to deal with
fixed-endians, assorted cleanups all over the place..."
* 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (28 commits)
alpha: osf_sys.c: use timespec64 where appropriate
alpha: osf_sys.c: fix put_tv32 regression
jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path
dcache: delete unused d_hash_mask
dcache: subtract d_hash_shift from 32 in advance
fs/buffer.c: fold init_buffer() into init_page_buffers()
fs: fold __inode_permission() into inode_permission()
fs: add RWF_APPEND
sctp: use vmemdup_user() rather than badly open-coding memdup_user()
snd_ctl_elem_init_enum_names(): switch to vmemdup_user()
replace_user_tlv(): switch to vmemdup_user()
new primitive: vmemdup_user()
memdup_user(): switch to GFP_USER
eventfd: fold eventfd_ctx_get() into eventfd_ctx_fileget()
eventfd: fold eventfd_ctx_read() into eventfd_read()
eventfd: convert to use anon_inode_getfd()
nfs4file: get rid of pointless include of btrfs.h
uvc_v4l2: clean copyin/copyout up
vme_user: don't use __copy_..._user()
usx2y: don't bother with memdup_user() for 16-byte structure
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull poll annotations from Al Viro:
"This introduces a __bitwise type for POLL### bitmap, and propagates
the annotations through the tree. Most of that stuff is as simple as
'make ->poll() instances return __poll_t and do the same to local
variables used to hold the future return value'.
Some of the obvious brainos found in process are fixed (e.g. POLLIN
misspelled as POLL_IN). At that point the amount of sparse warnings is
low and most of them are for genuine bugs - e.g. ->poll() instance
deciding to return -EINVAL instead of a bitmap. I hadn't touched those
in this series - it's large enough as it is.
Another problem it has caught was eventpoll() ABI mess; select.c and
eventpoll.c assumed that corresponding POLL### and EPOLL### were
equal. That's true for some, but not all of them - EPOLL### are
arch-independent, but POLL### are not.
The last commit in this series separates userland POLL### values from
the (now arch-independent) kernel-side ones, converting between them
in the few places where they are copied to/from userland. AFAICS, this
is the least disruptive fix preserving poll(2) ABI and making epoll()
work on all architectures.
As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and
it will trigger only on what would've triggered EPOLLWRBAND on other
architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered
at all on sparc. With this patch they should work consistently on all
architectures"
* 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits)
make kernel-side POLL... arch-independent
eventpoll: no need to mask the result of epi_item_poll() again
eventpoll: constify struct epoll_event pointers
debugging printk in sg_poll() uses %x to print POLL... bitmap
annotate poll(2) guts
9p: untangle ->poll() mess
->si_band gets POLL... bitmap stored into a user-visible long field
ring_buffer_poll_wait() return value used as return value of ->poll()
the rest of drivers/*: annotate ->poll() instances
media: annotate ->poll() instances
fs: annotate ->poll() instances
ipc, kernel, mm: annotate ->poll() instances
net: annotate ->poll() instances
apparmor: annotate ->poll() instances
tomoyo: annotate ->poll() instances
sound: annotate ->poll() instances
acpi: annotate ->poll() instances
crypto: annotate ->poll() instances
block: annotate ->poll() instances
x86: annotate ->poll() instances
...
|
|
Single irq regression fix
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau: Move irq setup/teardown to pci ctor/dtor
|
|
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.
This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:
a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation)
After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.
For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.
So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.
As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <efault@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Two vc4 fixes that were applied in the last day.
One fixes a NULL dereference, and the other fixes
a flickering bug.
Cc: Eric Anholt <eric@anholt.net>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
* tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc:
drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
drm/vc4: Flush the caches before the bin jobs, as well.
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Display corruption regression bugfix with both a prep patch and a
follow-up fix
* tag 'drm-intel-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Fix deadlock in i830_disable_pipe()
drm/i915: Redo plane sanitation during readout
drm/i915: Add .get_hw_state() method for planes
|
|
Thought I'd try my luck getting one more in:
- Two fixes for Tegra (one is to common code, but our userspace doesn't hit it).
- One for NV5x-class MCPs
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling
drm/nouveau/bar/gk20a: Avoid bar teardown during init
drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()
|
|
- Fixes addition of stolen memory base address to PTEs.
- Removes support for compression.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
|
|
Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.
This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.
Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.
Suggested-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
When saving BOs in the hang state we skip one entry of the
kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
pointer dereference when, later in this function, we iterate over all
BOs to check their ->madv state.
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180118145821.22344-1-boris.brezillon@free-electrons.com
|
|
If the frame samples from a render target that was just written, its
cache flush during the binning step may have occurred before the
previous frame's RCL was completed. Flush the texture caches again
before starting each RCL job to make sure that the sampling of the
previous RCL's output is correct.
Fixes flickering in the top left of 3DMMES Taiji.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Link: https://patchwork.freedesktop.org/patch/msgid/20171221221722.23809-1-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Final 4.15 drm-misc pull:
Just 3 sun4i patches to fix clock computation/checks.
* tag 'drm-misc-fixes-2018-01-17' of git://anongit.freedesktop.org/drm/drm-misc:
drm/sun4i: hdmi: Add missing rate halving check in sun4i_tmds_determine_rate
drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
|
|
git://people.freedesktop.org/~thomash/linux into drm-fixes
Last minute fixes for vmwgfx.
One fix for a drm helper warning introduced in 4.15
One important fix for a longer standing memory corruption issue on older
hardware versions.
* 'vmwgfx-fixes-4.15' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: fix memory corruption with legacy/sou connectors
drm/vmwgfx: Fix a boot time warning
|
|
It looks like in all cases 'struct vmw_connector_state' is used. But
only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
subclassed. Leading to writes beyond the end of the allocated connector
state block and all sorts of fun memory corruption related crashes.
Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Cc: <stable@vger.kernel.org>
Signed-off-by: Rob Clark <rclark@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
The 4.15 vmwgfx driver shows a warning during boot.
It is caused by a mismatch between the result of vmw_enable_vblank()
and what the drm_atomic_helper expects.
Signed-off by: Woody Suwalski <terraluna977@gmail.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.
Replace the assert_plane() calls (which calls ->get_hw_state()) with
just raw register reads in i830_disable_pipe(). As a bonus we can
now get a warning if plane C is enabled even though we don't even
expose it as a drm plane.
v2: Do a separate WARN_ON() for each plane (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: d87ce7640295 ("drm/i915: Add .get_hw_state() method for planes")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129125411.29055-1-ville.syrjala@linux.intel.com
(cherry picked from commit 5816d9cbc0a0fbf232fe297cefcb85361a3cde90)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Unify the plane disabling during state readout by pulling the code into
a new helper intel_plane_disable_noatomic(). We'll also read out the
state of all planes, so that we know which planes really need to be
diabled.
Additonally we change the plane<->pipe mapping sanitation to work by
simply disabling the offending planes instead of entire pipes. And
we do it before we otherwise sanitize the crtcs, which means we don't
have to worry about misassigned planes during crtc sanitation anymore.
v2: Reoder patches to not depend on enum old_plane_id
v3: s/for_each_pipe/for_each_intel_crtc/
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alex Villacís Lasso <alexvillacislasso@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103223
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-3-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit b1e01595a66dc206a2c75401ec4c285740537f3f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add a .get_hw_state() method for planes, returning true or false
depending on whether the plane is enabled. Use it to rewrite the
plane enabled/disabled asserts in platform agnostic fashion.
We do lose the pre-gen4 plane<->pipe mapping checks, but since we're
supposed sanitize that anyway it doesn't really matter.
v2: Reoder patches to not depend on enum old_plane_id
Just call assert_plane_disabled() from assert_planes_disabled()
v3: Deal with disabled power wells in .get_hw_state()
v4: Rebase due skl primary plane code removal
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alex Villacís Lasso <alexvillacislasso@hotmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2
Tested-by: Thierry Reding <thierry.reding@gmail.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-2-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 51f5a096398433a881e845d3685a2c1dac756019)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes
* tag 'drm-intel-fixes-2018-01-11-1' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Don't adjust priority on an already signaled fence
drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser
drm/i915/gvt: Clear the shadow page table entry after post-sync
|
|
git://people.freedesktop.org/~thomash/linux into drm-fixes
Two important fixes for vmwgfx.
The off-by-one fix could cause a malicious user to potentially crash the
kernel.
The framebuffer map cache fix can under some circumstances enable a user to
read from or write to freed pages.
* 'vmwgfx-fixes-4.15' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Potential off by one in vmw_view_add()
drm/vmwgfx: Don't cache framebuffer maps
|
|
It was only checking the divider when determing the closest match if
it could not match the requested rate exactly.
For a projector connected to an Olimex A20-OLinuXino-LIME using HDMI
with a native resolution of 1280x800 and pixel clock of 83.5 MHz, this
resulted in 1280x800 mode not being available and the following in dmesg
when the kernel is booted with drm.debug=0x3e:
[drm:drm_mode_debug_printmodeline] Modeline 37:"1280x800" 60 83500 1280 1352 1480 1680 800 810 816 831 0x48 0x5
[drm:drm_mode_prune_invalid] Not using 1280x800 mode: NOCLOCK
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109020323.11852-4-net147@gmail.com
|
|
best_div is set to i which corresponds to rate halving when it should be
set to j which corresponds to the divider.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109020323.11852-3-net147@gmail.com
|
|
It is possible that if there is no exact rate match and
"rounded = clk_hw_round_rate(parent, ideal)" gives high enough values
(e.g. if rounded is 2 * ideal) that the condition
"abs(rate - rounded / i) < abs(rate - best_parent / best_div)" is never
met and best_parent is never set. This results in req->rate and
req->best_parent_rate being assigned 0.
To avoid this, we set best_parent to the first calculated rate if it is
unset. The sun4i_tmds_calc_divider function already has a similar check.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109020323.11852-2-net147@gmail.com
|
|
When we retire a signaled fence, we free the dependency tree. However,
we skip clearing the list so that if we then try to adjust the priority
of the signaled fence, we may walk the list of freed dependencies.
[ 3083.156757] ==================================================================
[ 3083.156806] BUG: KASAN: use-after-free in execlists_schedule+0x199/0x660 [i915]
[ 3083.156810] Read of size 8 at addr ffff8806bf20f400 by task Xorg/831
[ 3083.156815] CPU: 0 PID: 831 Comm: Xorg Not tainted 4.15.0-rc6-no-psn+ #1
[ 3083.156817] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017
[ 3083.156818] Call Trace:
[ 3083.156823] dump_stack+0x5c/0x7a
[ 3083.156827] print_address_description+0x6b/0x290
[ 3083.156830] kasan_report+0x28f/0x380
[ 3083.156872] ? execlists_schedule+0x199/0x660 [i915]
[ 3083.156914] execlists_schedule+0x199/0x660 [i915]
[ 3083.156956] ? intel_crtc_atomic_check+0x146/0x4e0 [i915]
[ 3083.156997] ? execlists_submit_request+0xe0/0xe0 [i915]
[ 3083.157038] ? i915_vma_misplaced.part.4+0x25/0xb0 [i915]
[ 3083.157079] ? __i915_vma_do_pin+0x7c8/0xc80 [i915]
[ 3083.157121] ? intel_atomic_state_alloc+0x44/0x60 [i915]
[ 3083.157130] ? drm_atomic_helper_page_flip+0x3e/0xb0 [drm_kms_helper]
[ 3083.157145] ? drm_mode_page_flip_ioctl+0x7d2/0x850 [drm]
[ 3083.157159] ? drm_ioctl_kernel+0xa7/0xf0 [drm]
[ 3083.157172] ? drm_ioctl+0x45b/0x560 [drm]
[ 3083.157211] i915_gem_object_wait_priority+0x14c/0x2c0 [i915]
[ 3083.157251] ? i915_gem_get_aperture_ioctl+0x150/0x150 [i915]
[ 3083.157290] ? i915_vma_pin_fence+0x1d8/0x320 [i915]
[ 3083.157331] ? intel_pin_and_fence_fb_obj+0x175/0x250 [i915]
[ 3083.157372] ? intel_rotation_info_size+0x60/0x60 [i915]
[ 3083.157413] ? intel_link_compute_m_n+0x80/0x80 [i915]
[ 3083.157428] ? drm_dev_printk+0x1b0/0x1b0 [drm]
[ 3083.157443] ? drm_dev_printk+0x1b0/0x1b0 [drm]
[ 3083.157485] intel_prepare_plane_fb+0x2f8/0x5a0 [i915]
[ 3083.157527] ? intel_crtc_get_vblank_counter+0x80/0x80 [i915]
[ 3083.157536] drm_atomic_helper_prepare_planes+0xa0/0x1c0 [drm_kms_helper]
[ 3083.157587] intel_atomic_commit+0x12e/0x4e0 [i915]
[ 3083.157605] drm_atomic_helper_page_flip+0xa2/0xb0 [drm_kms_helper]
[ 3083.157621] drm_mode_page_flip_ioctl+0x7d2/0x850 [drm]
[ 3083.157638] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
[ 3083.157652] ? drm_lease_owner+0x1a/0x30 [drm]
[ 3083.157668] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
[ 3083.157681] drm_ioctl_kernel+0xa7/0xf0 [drm]
[ 3083.157696] drm_ioctl+0x45b/0x560 [drm]
[ 3083.157711] ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
[ 3083.157725] ? drm_getstats+0x20/0x20 [drm]
[ 3083.157729] ? timerqueue_del+0x49/0x80
[ 3083.157732] ? __remove_hrtimer+0x62/0xb0
[ 3083.157735] ? hrtimer_try_to_cancel+0x173/0x210
[ 3083.157738] do_vfs_ioctl+0x13b/0x880
[ 3083.157741] ? ioctl_preallocate+0x140/0x140
[ 3083.157744] ? _raw_spin_unlock_irq+0xe/0x30
[ 3083.157746] ? do_setitimer+0x234/0x370
[ 3083.157750] ? SyS_setitimer+0x19e/0x1b0
[ 3083.157752] ? SyS_alarm+0x140/0x140
[ 3083.157755] ? __rcu_read_unlock+0x66/0x80
[ 3083.157757] ? __fget+0xc4/0x100
[ 3083.157760] SyS_ioctl+0x74/0x80
[ 3083.157763] entry_SYSCALL_64_fastpath+0x1a/0x7d
[ 3083.157765] RIP: 0033:0x7f6135d0c6a7
[ 3083.157767] RSP: 002b:00007fff01451888 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
[ 3083.157769] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f6135d0c6a7
[ 3083.157771] RDX: 00007fff01451950 RSI: 00000000c01864b0 RDI: 000000000000000c
[ 3083.157772] RBP: 00007f613076f600 R08: 0000000000000001 R09: 0000000000000000
[ 3083.157773] R10: 0000000000000060 R11: 0000000000003246 R12: 0000000000000000
[ 3083.157774] R13: 0000000000000060 R14: 000000000000001b R15: 0000000000000060
[ 3083.157779] Allocated by task 831:
[ 3083.157783] kmem_cache_alloc+0xc0/0x200
[ 3083.157822] i915_gem_request_await_dma_fence+0x2c4/0x5d0 [i915]
[ 3083.157861] i915_gem_request_await_object+0x321/0x370 [i915]
[ 3083.157900] i915_gem_do_execbuffer+0x1165/0x19c0 [i915]
[ 3083.157937] i915_gem_execbuffer2+0x1ad/0x550 [i915]
[ 3083.157950] drm_ioctl_kernel+0xa7/0xf0 [drm]
[ 3083.157962] drm_ioctl+0x45b/0x560 [drm]
[ 3083.157964] do_vfs_ioctl+0x13b/0x880
[ 3083.157966] SyS_ioctl+0x74/0x80
[ 3083.157968] entry_SYSCALL_64_fastpath+0x1a/0x7d
[ 3083.157971] Freed by task 831:
[ 3083.157973] kmem_cache_free+0x77/0x220
[ 3083.158012] i915_gem_request_retire+0x72c/0xa70 [i915]
[ 3083.158051] i915_gem_request_alloc+0x1e9/0x8b0 [i915]
[ 3083.158089] i915_gem_do_execbuffer+0xa96/0x19c0 [i915]
[ 3083.158127] i915_gem_execbuffer2+0x1ad/0x550 [i915]
[ 3083.158140] drm_ioctl_kernel+0xa7/0xf0 [drm]
[ 3083.158153] drm_ioctl+0x45b/0x560 [drm]
[ 3083.158155] do_vfs_ioctl+0x13b/0x880
[ 3083.158156] SyS_ioctl+0x74/0x80
[ 3083.158158] entry_SYSCALL_64_fastpath+0x1a/0x7d
[ 3083.158162] The buggy address belongs to the object at ffff8806bf20f400
which belongs to the cache i915_dependency of size 64
[ 3083.158166] The buggy address is located 0 bytes inside of
64-byte region [ffff8806bf20f400, ffff8806bf20f440)
[ 3083.158168] The buggy address belongs to the page:
[ 3083.158171] page:00000000d43decc4 count:1 mapcount:0 mapping: (null) index:0x0
[ 3083.158174] flags: 0x17ffe0000000100(slab)
[ 3083.158179] raw: 017ffe0000000100 0000000000000000 0000000000000000 0000000180200020
[ 3083.158182] raw: ffffea001afc16c0 0000000500000005 ffff880731b881c0 0000000000000000
[ 3083.158184] page dumped because: kasan: bad access detected
[ 3083.158187] Memory state around the buggy address:
[ 3083.158190] ffff8806bf20f300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158192] ffff8806bf20f380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158195] >ffff8806bf20f400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158196] ^
[ 3083.158199] ffff8806bf20f480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158201] ffff8806bf20f500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158203] ==================================================================
Reported-by: Alexandru Chirvasitu <achirvasub@gmail.com>
Reported-by: Mike Keehan <mike@keehan.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104436
Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its lifetime")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alexandru Chirvasitu <achirvasub@gmail.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Tested-by: Alexandru Chirvasitu <achirvasub@gmail.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180106105618.13532-1-chris@chris-wilson.co.uk
(cherry picked from commit c218ee03b9315073ce43992792554dafa0626eb8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Geminilake requires the 3D driver to select whether barriers are
intended for compute shaders, or tessellation control shaders, by
whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
switching pipelines. Failure to do this properly can result in GPU
hangs.
Unfortunately, this means it needs to switch mid-batch, so only
userspace can properly set it. To facilitate this, the kernel needs
to whitelist the register.
The workarounds page currently tags this as applying to Broxton only,
but that doesn't make sense. The documentation for the register it
references says the bit userspace is supposed to toggle only exists on
Geminilake. Empirically, the Mesa patch to toggle this bit appears to
fix intermittent GPU hangs in tessellation control shader barrier tests
on Geminilake; we haven't seen those hangs on Broxton.
v2: Mention WA #0862 in the comment (it doesn't have a name).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180105085905.9298-1-kenneth@whitecape.org
(cherry picked from commit ab062639edb0412daf6de540725276b9a5d217f9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error.
It's one element beyond the end of the vmw_view_cotables[] table.
My read on this is that it's possible to hit this failure. header->id
comes from vmw_cmd_check() and it's a user controlled number between
1040 and 1225 so we can hit that error. But I don't have the hardware
to test this code.
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>
|
|
The SOR0 found on Tegra124 and Tegra210 only supports eDP and LVDS and
therefore has a slightly different clock tree than the SOR1 which does
not support eDP, but HDMI and DP instead.
Commit e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock") breaks
setups with eDP because the sor->clk_out clock is uninitialized and
therefore setting the parent clock (either the safe clock or either of
the display PLLs) fails, which can cause hangs later on since there is
no clock driving the module.
Fix this by falling back to the module clock for sor->clk_out on those
setups. This guarantees that the module will always be clocked by an
enabled clock and hence prevents those hangs.
Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Buffer objects need to be either pinned or reserved while a map is active,
that's not the case here, so avoid caching the framebuffer map.
This will cause increasing mapping activity mainly when we don't do
page flipping.
This fixes occasional garbage filled screens when the framebuffer has been
evicted after the map.
Since in-kernel mapping of whole buffer objects is error-prone on 32-bit
architectures and also quite inefficient, we will revisit this later.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Cc: <stable@vger.kernel.org>
|
|
nouveau displayport regression fix.
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau/disp/gf119: add missing drive vfunc ptr
|
|
Fixes broken dp on GF119:
Call Trace:
? nvkm_dp_train_drive+0x183/0x2c0 [nouveau]
nvkm_dp_acquire+0x4f3/0xcd0 [nouveau]
nv50_disp_super_2_2+0x5d/0x470 [nouveau]
? nvkm_devinit_pll_set+0xf/0x20 [nouveau]
gf119_disp_super+0x19c/0x2f0 [nouveau]
process_one_work+0x193/0x3c0
worker_thread+0x35/0x3b0
kthread+0x125/0x140
? process_one_work+0x3c0/0x3c0
? kthread_park+0x60/0x60
ret_from_fork+0x25/0x30
Code: Bad RIP value.
RIP: (null) RSP: ffffb1e243e4bc38
CR2: 0000000000000000
Fixes: af85389c614a drm/nouveau/disp: shuffle functions around
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103421
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Just one vc4 fix.
* tag 'drm-misc-fixes-2018-01-08' of git://anongit.freedesktop.org/drm/drm-misc:
drm/vc4: Move IRQ enable to PM path
|
|
drm-intel-fixes
gvt-fixes-2018-01-08
- clear shadow entry for post-sync (Zhi)
- fix stack out-of-bound warning in cmd parser (Changbin)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180108061130.ucwtumhpbfbu4psu@zhen-hp.sh.intel.com
|
|
for_each_set_bit() only accepts variable of type unsigned long, and we can
not cast it from smaller types.
[ 16.499365] ==================================================================
[ 16.506655] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x1d/0x70
[ 16.513313] Read of size 8 at addr ffff8803616cf510 by task systemd-udevd/180
[ 16.521998] CPU: 0 PID: 180 Comm: systemd-udevd Tainted: G U O 4.15.0-rc3+ #14
[ 16.530317] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
[ 16.537760] Call Trace:
[ 16.540230] dump_stack+0x7c/0xbb
[ 16.543569] print_address_description+0x6b/0x290
[ 16.548306] kasan_report+0x28a/0x370
[ 16.551993] ? find_first_bit+0x1d/0x70
[ 16.555858] find_first_bit+0x1d/0x70
[ 16.559625] intel_gvt_init_cmd_parser+0x127/0x3c0 [i915]
[ 16.565060] ? __lock_is_held+0x8f/0xf0
[ 16.568990] ? intel_gvt_clean_cmd_parser+0x10/0x10 [i915]
[ 16.574514] ? __hrtimer_init+0x5d/0xb0
[ 16.578445] intel_gvt_init_device+0x2c3/0x690 [i915]
[ 16.583537] ? unregister_module_notifier+0x20/0x20
[ 16.588515] intel_gvt_init+0x89/0x100 [i915]
[ 16.592962] i915_driver_load+0x1992/0x1c70 [i915]
[ 16.597846] ? __i915_printk+0x210/0x210 [i915]
[ 16.602410] ? wait_for_completion+0x280/0x280
[ 16.606883] ? lock_downgrade+0x2c0/0x2c0
[ 16.610923] ? __pm_runtime_resume+0x46/0x90
[ 16.615238] ? acpi_dev_found+0x76/0x80
[ 16.619162] ? i915_pci_remove+0x30/0x30 [i915]
[ 16.623733] local_pci_probe+0x74/0xe0
[ 16.627518] pci_device_probe+0x208/0x310
[ 16.631561] ? pci_device_remove+0x100/0x100
[ 16.635871] ? __list_add_valid+0x29/0xa0
[ 16.639919] driver_probe_device+0x40b/0x6b0
[ 16.644223] ? driver_probe_device+0x6b0/0x6b0
[ 16.648696] __driver_attach+0x11d/0x130
[ 16.652649] bus_for_each_dev+0xe7/0x160
[ 16.656600] ? subsys_dev_iter_exit+0x10/0x10
[ 16.660987] ? __list_add_valid+0x29/0xa0
[ 16.665028] bus_add_driver+0x31d/0x3a0
[ 16.668893] driver_register+0xc6/0x170
[ 16.672758] ? 0xffffffffc0ad8000
[ 16.676108] do_one_initcall+0x9c/0x206
[ 16.679984] ? initcall_blacklisted+0x150/0x150
[ 16.684545] ? do_init_module+0x35/0x33b
[ 16.688494] ? kasan_unpoison_shadow+0x31/0x40
[ 16.692968] ? kasan_kmalloc+0xa6/0xd0
[ 16.696743] ? do_init_module+0x35/0x33b
[ 16.700694] ? kasan_unpoison_shadow+0x31/0x40
[ 16.705168] ? __asan_register_globals+0x82/0xa0
[ 16.709819] do_init_module+0xe7/0x33b
[ 16.713597] load_module+0x4481/0x4ce0
[ 16.717397] ? module_frob_arch_sections+0x20/0x20
[ 16.722228] ? vfs_read+0x13b/0x190
[ 16.725742] ? kernel_read+0x74/0xa0
[ 16.729351] ? get_user_arg_ptr.isra.17+0x70/0x70
[ 16.734099] ? SYSC_finit_module+0x175/0x1b0
[ 16.738399] SYSC_finit_module+0x175/0x1b0
[ 16.742524] ? SYSC_init_module+0x1e0/0x1e0
[ 16.746741] ? __fget+0x157/0x240
[ 16.750090] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 16.754747] entry_SYSCALL_64_fastpath+0x23/0x9a
[ 16.759397] RIP: 0033:0x7f8fbc837499
[ 16.762996] RSP: 002b:00007ffead76c138 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 16.770618] RAX: ffffffffffffffda RBX: 0000000000000012 RCX: 00007f8fbc837499
[ 16.777800] RDX: 0000000000000000 RSI: 000056484e67b080 RDI: 0000000000000012
[ 16.784979] RBP: 00007ffead76b140 R08: 0000000000000000 R09: 0000000000000021
[ 16.792164] R10: 0000000000000012 R11: 0000000000000246 R12: 000056484e67b460
[ 16.799345] R13: 00007ffead76b120 R14: 0000000000000005 R15: 0000000000000000
[ 16.808052] The buggy address belongs to the page:
[ 16.812876] page:00000000dc4b8c1e count:0 mapcount:0 mapping: (null) index:0x0
[ 16.820934] flags: 0x17ffffc0000000()
[ 16.824621] raw: 0017ffffc0000000 0000000000000000 0000000000000000 00000000ffffffff
[ 16.832416] raw: ffffea000d85b3e0 ffffea000d85b3e0 0000000000000000 0000000000000000
[ 16.840208] page dumped because: kasan: bad access detected
[ 16.847318] Memory state around the buggy address:
[ 16.852143] ffff8803616cf400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 16.859427] ffff8803616cf480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
[ 16.866708] >ffff8803616cf500: f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
[ 16.873988] ^
[ 16.877770] ffff8803616cf580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 16.885042] ffff8803616cf600: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[ 16.892312] ==================================================================
Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for v4.15-rc7
- couple of documentation build fixes
- serialize non-blocking modesets
- prevent DMC from messing up GMBUS transfers
- PSR regression fix
* tag 'drm-intel-fixes-2018-01-04' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Apply Display WA #1183 on skl, kbl, and cfl
docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c
documentation/gpu/i915: fix docs build error after file rename
drm/i915: Put all non-blocking modesets onto an ordered wq
drm/i915: Disable DC states around GMBUS on GLK
drm/i915/psr: Fix register name mess up.
|
|
into drm-fixes
- backport of a DC change which fixes a greenish tint on some RV hw
- properly handle kzalloc fail in ttm
* 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux:
drm/ttm: check the return value of kzalloc
drm/amd/display: call set csc_default if enable adjustment is false
|
|
git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes
Armada fixes.
* 'drm-armada-fixes-4.15' of git://git.armlinux.org.uk/~rmk/linux-arm:
drm/armada: fix YUV planar format framebuffer offsets
drm/armada: improve efficiency of armada_drm_plane_calc_addrs()
drm/armada: fix UV swap code
drm/armada: fix SRAM powerdown
drm/armada: fix leak of crtc structure
|
|
Display WA #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
(cherry picked from commit 53421c2fe99ce16838639ad89d772d914a119a49)
[ Lucas: Backport to 4.15 adding back variable that has been removed on
commits not meant to be backported ]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180102201837.6812-1-lucas.demarchi@intel.com
|
|
A shadow page table entry needs to be cleared after being set as
post-sync. This patch fixes the recent error reported in Win7-32 test.
Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
We were calling enable_irq on bind, where it was already enabled previously
by the IRQ helper. Additionally, dev->irq is not set correctly until after
postinstall and so was always zero here, triggering a warning in 4.15.
Fix both by moving the enable to the power management resume path, where we
know there was a previous disable invocation during suspend.
Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
Signed-off-by: Stefan Schake <stschake@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-email-stschake@gmail.com
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fixes a greenish tint on RV displays.
Signed-off-by: Yue Hin Lau <Yuehin.Lau@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[drake@endlessm.com: backport to 4.15]
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The omap4 CEC hardware cannot tell a Nack from a Low Drive from an
Arbitration Lost error, so just report a Nack, which is almost
certainly the reason for the error anyway.
This also simplifies the implementation. The only three interrupts
that need to be enabled are:
Transmit Buffer Full/Empty Change event: triggered when the
transmit finished successfully and cleared the buffer.
Receiver FIFO Not Empty event: triggered when a message was received.
Frame Retransmit Count Exceeded event: triggered when a transmit
failed repeatedly, usually due to the message being Nacked. Other
reasons are possible (Low Drive, Arbitration Lost) but there is no
way to know. If this happens the TX buffer needs to be cleared
manually.
While testing various error conditions I noticed that the hardware
can receive messages up to 18 bytes in total, which exceeds the legal
maximum of 16. This could cause a buffer overflow, so we check for
this and constrain the size to 16 bytes.
The old incorrect interrupt handler could cause the CEC framework to
enter into a bad state because it mis-detected the "Start Bit Irregularity
event" as an ARB_LOST transmit error when it actually is a receive error
which should be ignored.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Henrik Austad <haustad@cisco.com>
Tested-by: Henrik Austad <haustad@cisco.com>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
We have plenty of global registers and whatnot programmed without
any further locking by the modeset code. Currently non-bocking
modesets are allowed to execute in parallel which could corrupt
said registers.
To avoid the problem let's run all non-blocking modesets on an
ordered workqueue. We still put page flips etc. to system_unbound_wq
allowing page flips on one pipe to execute in parallel with page flips
or a modeset on a another pipe (assuming no known state is shared
between them, at which point they would have been added to the same
atomic commit and serialized that way).
Blocking modesets are already serialized with each other by
connection_mutex, and thus are safe. To serialize them with
non-blocking modesets we just flush the workqueue before executing
blocking modesets.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 94f050246b42 ("drm/i915: nonblocking commit")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113133622.8593-1-ville.syrjala@linux.intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 757fffcfdffb6c0dd46c1b264091c36b4e5a86ae)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS
lives in PG1 so DC off is all we need.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
(cherry picked from commit 156961ae7bdf6feb72778e8da83d321b273343fd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Commit 77affa31722b ("drm/i915/psr: Fix compiler warnings for
hsw_psr_disable()") swapped status and control registers while fixing
indentation. The _ctl at the end of the status register name must have to
led to this.
Fixes: 77affa31722b ("drm/i915/psr: Fix compiler warnings for hsw_psr_disable()")
References: https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220043520.2599-1-dhinakaran.pandiyan@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 14c6547d6df641d3e41fa4f4164f6e267ebfab89)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
GLK pipe C related fix, and a gvt fix.
* tag 'drm-intel-fixes-2017-12-22-1' of git://anongit.freedesktop.org/drm/drm-intel:
i915: Reject CCS modifiers for pipe C on Geminilake
drm/i915/gvt: Fix pipe A enable as default for vgpu
|
|
one nouveau regression fix
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau: fix race when adding delayed work items
|
|
kernel.org bz#198221.
Reported-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
