| Age | Commit message (Collapse) | Author |
|---|
|
vring_create_virtqueue() allows the caller to specify via the
may_reduce_num parameter whether the vring code is allowed to
allocate a smaller ring than specified.
However, the split ring allocation code tries to allocate a
smaller ring on allocation failure regardless of what the
caller specified. This may cause trouble for e.g. virtio-pci
in legacy mode, which does not support ring resizing. (The
packed ring code does not resize in any case.)
Let's fix this by bailing out immediately in the split ring code
if the requested size cannot be allocated and may_reduce_num has
not been specified.
While at it, fix a typo in the usage instructions.
Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
|
|
A couple of machines in the farm show quite frequent errors in the
powerwells not being released. Either there is an external agent
interferring with the powerwells, or the powerwell doesn't quite behave
as we anticipate -- either way, the test is not reliable enough to be
enabled by default in CI. It has served its immediate purpose in
providing coverage as we made tweaks to forcewake, so keep it available
for future testing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407192649.14750-1-chris@chris-wilson.co.uk
|
|
This interlaced mode restriction applies to all gens, not only to
Haswell.
Also while at it updating the debug message to.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-4-jose.souza@intel.com
|
|
Even when driver is reloaded and hits this scenario the PSR mutex
should be initialized, otherwise reading PSR debugfs status will
execute mutex_lock() over a mutex that was not initialized.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-3-jose.souza@intel.com
|
|
PSR support for VLV and CHV was dropped in commit ce3508fd2a77
("drm/i915/psr: Nuke PSR support for VLV and CHV") so no need to keep
this registers around.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-2-jose.souza@intel.com
|
|
Turn out it is not a DMC bug it is actually a HW one, so this
workaround will be needed for current gens, lets update the comment
and remove the FIXME.
BSpec: 7723
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-1-jose.souza@intel.com
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: In function 'vmw_fb_init':
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:29: warning:
variable 'fb_offset' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:19: warning:
variable 'fb_depth' set but not used [-Wunused-but-set-variable]
They're not used any more, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
|
|
When building with -Wsometimes-uninitialized, Clang warns:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3964:7: warning: variable
'handle' is used uninitialized whenever '?:' condition is false
[-Wsometimes-uninitialized]
It's not wrong; however, in practice, this is never an issue because
the value of handle isn't used when user_fence_rep is NULL because
vmw_execbuf_copy_fence_user returns immediately when that is the case.
Just zero initialize this variable so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/397
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
|
|
Whenever FIFO allocation fails an error message is printed to dmesg.
Since this is common operation a lot of similar messages are scattered
everywhere. Use preprocessor macro to remove this cluttering.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
No functional change with this change, just fixing formatting and
spaces.
v2: Rebase.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
DRM_ERROR overwhelms dmesgi so use VMW_DEBUG_USER instead. Any malformed
command should not really go to device so WARN_ONCE to spot this.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Now that vmw_cmd_check prints debug message whenever a command verifier
fails, some of debug statements are unnecessary. Also rearranged some
debug print-out with this patch.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Whenever command verifier function returns with an error, print a debug
message using VMW_DEBUG_USER. This will make sure failing commands can
be easily tracked for debugging purpose.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Error messages or debugging message reported during user-space command
submission should not be printed to dmesg by default. So add a new
preprocessor define called VMW_DEBUG_USER which translates to
DRM_DEBUG_DRIVER.
v2: Use VMW_DEBUG_USER instead of using DRM_DEBUG_DRIVER directly.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Use preprocessor macro for repetitive device command struct format.
v2: Name-space distinction for preprocessor macro.
v3: Struct name as macro parameter and rebase.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Several command verifier function check if context node is present or
not and if not present print an error and return. Use a preprocessor
macro to print the message.
v2: Name-space distinction for preprocessor macro
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
unlikely has already included in IS_ERR(), so just
remove redundant unlikely annotation.
Signed-off-by: Chengguang Xu <cgxu519@gmx.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_work_func':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:514:7: warning:
variable 'restart' set but not used [-Wunused-but-set-variable]
It not used any more after commit dc366364c4ef ("drm/vmwgfx: Fix multiple
command buffer context use")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Fixes: dc366364c4ef ("drm/vmwgfx: Fix multiple command buffer context use")
|
|
Currently we flag resources as dirty (GPU contents not yet read back to
the backing MOB) whenever they have been part of a command stream.
Obviously many resources can't be dirty and others can only be dirty when
written to by the GPU. That is when they are either bound to the context as
render-targets, depth-stencil, copy / clear destinations and
stream-output targets, or similarly when there are corresponding views into
them.
So mark resources dirty only in these special cases. Context- and cotable
resources are always marked dirty when referenced.
This is important for upcoming emulated coherent memory, since we can avoid
issuing automatic readbacks to non-dirty resources when the CPU tries to
access part of the backing MOB.
Testing: Unigine Heaven with max GPU memory set to 256MB resulting in
heavy resource thrashing.
---
v2: Addressed review comments by Deepak Rawat.
v3: Added some documentation
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
|
|
When moving the documentation for the ieee802154 subsystem from
plain text to rst the file pattern in the MAINTAINERS file got wrong.
Updating it here to fix scripts using this file.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Calling dump_backtrace() with a pt_regs argument corresponding to
userspace doesn't make any sense and our unwinder will simply print
"Call trace:" before unwinding the stack looking for user frames.
Rather than go through this song and dance, just return early if we're
passed a user register state.
Cc: <stable@vger.kernel.org>
Fixes: 1149aad10b1e ("arm64: Add dump_backtrace() in show_regs")
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
This options spawns a kernel side thread that will poll for submissions
(and completions, if IORING_SETUP_IOPOLL is set). As this allows a user
to potentially use more cycles outside of the normal hierarchy,
restrict the use of this feature to root.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This ended up not being included in the mainline version of io_uring,
so drop it from the test app as well.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The method of hem free for SCC context is different from qp context.
In the current version, if free SCC hem during the execution of qp free,
there may be smmu error as below:
arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
arm-smmu-v3 arm-smmu-v3.1.auto: 0x00007d0000000010
arm-smmu-v3 arm-smmu-v3.1.auto: 0x000012000000017c
arm-smmu-v3 arm-smmu-v3.1.auto: 0x00000000000009e0
arm-smmu-v3 arm-smmu-v3.1.auto: 0x0000000000000000
As SCC context is still used by hardware after qp free, we can solve this
problem by removing SCC hem free from hns_roce_qp_free.
Fixes: 6a157f7d1b14 ("RDMA/hns: Add SCC context allocation support for hip08")
Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
|
|
Due to the incorrect use of the seg and obj information, the position of
the mtt is calculated incorrectly, and the free space of the page is not
enough to store the entire mtt, resulting in access to the next page. This
patch fixes this problem.
Unable to handle kernel paging request at virtual address ffff00006e3cd000
...
Call trace:
hns_roce_write_mtt+0x154/0x2f0 [hns_roce]
hns_roce_buf_write_mtt+0xa8/0xd8 [hns_roce]
hns_roce_create_srq+0x74c/0x808 [hns_roce]
ib_create_srq+0x28/0xc8
Fixes: 0203b14c4f32 ("RDMA/hns: Unify the calculation for hem index in hip08")
Signed-off-by: chenglang <chenglang@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
|
|
Make sure to free the DSR on pvrdma_pci_remove() to avoid the memory leak.
Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Acked-by: Adit Ranadive <aditr@vmware.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
|
|
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-4-chris@chris-wilson.co.uk
|
|
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073] ======================================================
<4> [39.085273] WARNING: possible circular locking dependency detected
<4> [39.085552] 5.1.0-rc3-CI-Trybot_4088+ #1 Tainted: G U
<4> [39.085752] ------------------------------------------------------
<4> [39.085949] kswapd0/32 is trying to acquire lock:
<4> [39.086121] 00000000004b5f91 (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.086493]
but task is already holding lock:
<4> [39.086682] 00000000dd009a9a (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
<4> [39.086910]
which lock already depends on the new lock.
<4> [39.087139]
the existing dependency chain (in reverse order) is:
<4> [39.087356]
-> #2 (fs_reclaim){+.+.}:
<4> [39.087604] fs_reclaim_acquire.part.24+0x24/0x30
<4> [39.087785] kmem_cache_alloc_trace+0x2a/0x290
<4> [39.087998] i915_globals_park+0x22/0xa0 [i915]
<4> [39.088478] idle_work_handler+0x1df/0x220 [i915]
<4> [39.089016] process_one_work+0x245/0x610
<4> [39.089447] worker_thread+0x37/0x380
<4> [39.089956] kthread+0x119/0x130
<4> [39.090374] ret_from_fork+0x3a/0x50
<4> [39.090868]
-> #1 (wakeref#4){+.+.}:
<4> [39.091569] __mutex_lock+0x8c/0x960
<4> [39.092054] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.092521] intel_gt_pm_put+0x1b/0x40 [i915]
<4> [39.093047] intel_engine_park+0xeb/0x1d0 [i915]
<4> [39.093514] __intel_wakeref_put_once+0x10/0x30 [i915]
<4> [39.094062] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.094547] ring_retire_requests+0x86/0x160 [i915]
<4> [39.095110] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.095587] i915_gem_wait_for_idle.part.22+0xb2/0xf0 [i915]
<4> [39.096142] switch_to_kernel_context_sync+0x2a/0x70 [i915]
<4> [39.096633] i915_gem_init+0x59c/0x9c0 [i915]
<4> [39.097174] i915_driver_load+0xd96/0x1880 [i915]
<4> [39.097640] i915_pci_probe+0x29/0xa0 [i915]
<4> [39.098145] pci_device_probe+0xa1/0x120
<4> [39.098607] really_probe+0xf3/0x3e0
<4> [39.099031] driver_probe_device+0x10a/0x120
<4> [39.099599] device_driver_attach+0x4b/0x50
<4> [39.100033] __driver_attach+0x97/0x130
<4> [39.100525] bus_for_each_dev+0x74/0xc0
<4> [39.100954] bus_add_driver+0x13f/0x210
<4> [39.101441] driver_register+0x56/0xe0
<4> [39.101891] do_one_initcall+0x58/0x2e0
<4> [39.102319] do_init_module+0x56/0x1ea
<4> [39.102805] load_module+0x2701/0x29e0
<4> [39.103231] __se_sys_finit_module+0xd3/0xf0
<4> [39.103727] do_syscall_64+0x55/0x190
<4> [39.104153] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [39.104736]
-> #0 (wakeref#3){+.+.}:
<4> [39.105437] lock_acquire+0xa6/0x1c0
<4> [39.105923] __mutex_lock+0x8c/0x960
<4> [39.106345] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.106897] intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.107375] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.107930] ring_retire_requests+0x86/0x160 [i915]
<4> [39.108412] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.108934] i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [39.109431] i915_gem_shrinker_scan+0x59/0x130 [i915]
<4> [39.109884] do_shrink_slab+0x131/0x3e0
<4> [39.110380] shrink_slab+0x228/0x2c0
<4> [39.110810] shrink_node+0x177/0x460
<4> [39.111317] balance_pgdat+0x239/0x580
<4> [39.111743] kswapd+0x186/0x570
<4> [39.112221] kthread+0x119/0x130
<4> [39.112641] ret_from_fork+0x3a/0x50
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-3-chris@chris-wilson.co.uk
|
|
Replace the WARN with a simple if() + error message to squech the sparse
warning that entire wait_for() macro was being stringified:
drivers/gpu/drm/i915/intel_guc_submission.c:658:9: error: too long token expansion
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-2-chris@chris-wilson.co.uk
|
|
The ftrace trampoline code (which deals with modules loaded out of
BL range of the core kernel) uses plt_entries_equal() to check whether
the per-module trampoline equals a zero buffer, to decide whether the
trampoline has already been initialized.
This triggers a BUG() in the opcode manipulation code, since we end
up checking the ADRP offset of a 0x0 opcode, which is not an ADRP
instruction.
So instead, add a helper to check whether a PLT is initialized, and
call that from the frace code.
Cc: <stable@vger.kernel.org> # v5.0
Fixes: bdb85cd1d206 ("arm64/module: switch to ADRP/ADD sequences for PLT entries")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The only bpc information in pipe registers for BXT/GLK DSI
is the PIPEMISC dither bpc. Let's try to use that to read
out pipe_bpp on these platforms. However, I'm not sure if
this will be correctly populated by the GOP since bspec
suggests it's only needed if dithering is actually enabled.
If not I guess we'll have to go one step further and
extract pipe_bpp from the DSI pixel format when dithering
is disabled.
Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: ca0b04db14a5 ("drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats")
References: https://bugs.freedesktop.org/show_bug.cgi?id=109516
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405141349.11950-1-ville.syrjala@linux.intel.com
(cherry picked from commit 499653501baf27d26e73cb5ce744869df3400509)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
[Why]
If the cursor pos passed from DM is less than the plane_state->dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.
There was an attempt to guard against this in hubp1_cursor_set_position
by checking the src_x_offset and src_y_offset and offseting the
cursor hotspot within hubp1_cursor_set_position.
However, the cursor position itself is still being programmed
incorrectly as a large value.
This manifests itself visually as the cursor disappearing or containing
strange artifacts near the middle of the screen on raven.
[How]
Don't subtract the destination rect top left corner from the pos but
add it to the hotspot instead. This happens before the pos gets
passed into hubp1_cursor_set_position.
This achieves the same result but avoids the subtraction wrap around.
With this fix the original cursor programming logic can be used again.
v2: add hunk that got dropped accidently when this patch was originally
committed. (Alex)
Fixes: 0921c41e1902831 ("drm/amd/display: Fix negative cursor pos programming")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Murton Liu <Murton.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit 6dc4f100c175 ("block: allow bio_for_each_segment_all() to
iterate over multi-page bvec") changes bio_for_each_segment_all()
to use for-inside-for.
This way breaks all bio_for_each_segment_all() call with error out
branch via 'break', since now 'break' can only break from the inner
loop.
Fixes this issue by implementing bio_for_each_segment_all() via
single 'for' loop, and now the logic is very similar with normal
bvec iterator.
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: Omar Sandoval <osandov@fb.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-and-Tested-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Fixes: 6dc4f100c175 ("block: allow bio_for_each_segment_all() to iterate over multi-page bvec")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Jason doesn't really have the time to review blk/scsi
patches. Paolo and Setfan agreed to help out.
Thanks guys!
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
|
If the msix_affinity_masks is alloced failed, then we'll
try to free some resources in vp_free_vectors() that may
access it directly.
We met the following stack in our production:
[ 29.296767] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 29.311151] IP: [<ffffffffc04fe35a>] vp_free_vectors+0x6a/0x150 [virtio_pci]
[ 29.324787] PGD 0
[ 29.333224] Oops: 0000 [#1] SMP
[...]
[ 29.425175] RIP: 0010:[<ffffffffc04fe35a>] [<ffffffffc04fe35a>] vp_free_vectors+0x6a/0x150 [virtio_pci]
[ 29.441405] RSP: 0018:ffff9a55c2dcfa10 EFLAGS: 00010206
[ 29.453491] RAX: 0000000000000000 RBX: ffff9a55c322c400 RCX: 0000000000000000
[ 29.467488] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9a55c322c400
[ 29.481461] RBP: ffff9a55c2dcfa20 R08: 0000000000000000 R09: ffffc1b6806ff020
[ 29.495427] R10: 0000000000000e95 R11: 0000000000aaaaaa R12: 0000000000000000
[ 29.509414] R13: 0000000000010000 R14: ffff9a55bd2d9e98 R15: ffff9a55c322c400
[ 29.523407] FS: 00007fdcba69f8c0(0000) GS:ffff9a55c2840000(0000) knlGS:0000000000000000
[ 29.538472] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 29.551621] CR2: 0000000000000000 CR3: 000000003ce52000 CR4: 00000000003607a0
[ 29.565886] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 29.580055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 29.594122] Call Trace:
[ 29.603446] [<ffffffffc04fe8a2>] vp_request_msix_vectors+0xe2/0x260 [virtio_pci]
[ 29.618017] [<ffffffffc04fedc5>] vp_try_to_find_vqs+0x95/0x3b0 [virtio_pci]
[ 29.632152] [<ffffffffc04ff117>] vp_find_vqs+0x37/0xb0 [virtio_pci]
[ 29.645582] [<ffffffffc057bf63>] init_vq+0x153/0x260 [virtio_blk]
[ 29.658831] [<ffffffffc057c1e8>] virtblk_probe+0xe8/0x87f [virtio_blk]
[...]
Cc: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Longpeng <longpeng2@huawei.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
|
|
Note that the lima mailing list is moderated.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Qiang Yu <yuq825@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: lima@lists.freedesktop.org
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9138d8e8-5390-0650-9bc3-050b869e978c@infradead.org
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
|
|
Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when
configuring the kernel, then two machines were reported to have noise
after installing the new kernel. Put them in the blacklist, the
noise disappears.
https://bugs.launchpad.net/bugs/1821663
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We can unconditionally release the power references during encoder
disabling. The references for each port used by the encoder are
guaranteed to be enabled at this point.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405153657.20921-2-imre.deak@intel.com
|
|
Push getting the reference for the encoders' power domains into the
encoder get_power_domains() hook instead of doing this from the caller.
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these
power references it acquired during HW state readout.
Note that longtime ownership for the corresponding wakerefs can be thus
acquired / released in two ways. Nevertheless there is always only one
owner for them:
After HW readout (booting/system resume):
- encoder->get_power_domains() acquires
- encoder->disable*() releases
After a modeset (calling intel_atomic_commit()):
- encoder->enable*() acquires
- encoder->disable*() releases
* can be any of the encoder enable/disable hooks.
v2:
- Check that the DSI io_wakerefs are unset both during encoder HW
readout and enabling. (Chris)
Fixes: 0e6e0be4c9523 ("drm/i915: Markup paired operations on display power domains")
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407124655.31536-1-imre.deak@intel.com
|
|
Commit 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C")
broke the radix-mode segment exception handler. In radix mode, this is
exception is not an SLB miss, rather it signals that the EA is outside
the range translated by any page table.
The commit lost the radix feature alternate code patch, which can
cause faults to some EAs to kernel BUG at arch/powerpc/mm/slb.c:639!
The original radix code would send faults to slb_miss_large_addr,
which would end up faulting due to slb_addr_limit being 0. This patch
sends radix directly to do_bad_slb_fault, which is a bit clearer.
Fixes: 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C")
Cc: stable@vger.kernel.org # v4.20+
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
sun8i_tcon_top_un/bind
There are two problems here:
1. Not all clk_data->hws[] need to be initialized, depending on various
configured quirks. This leads to NULL ptr deref in
clk_hw_unregister_gate() in sun8i_tcon_top_unbind()
2. If there is error when registering the clk_data->hws[],
err_unregister_gates error path will try to unregister
IS_ERR()=true (invalid) pointer.
For problem (1) I have this stack trace:
Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000008
Call trace:
clk_hw_unregister+0x8/0x18
clk_hw_unregister_gate+0x14/0x28
sun8i_tcon_top_unbind+0x2c/0x60
component_unbind.isra.4+0x2c/0x50
component_bind_all+0x1d4/0x230
sun4i_drv_bind+0xc4/0x1a0
try_to_bring_up_master+0x164/0x1c0
__component_add+0xa0/0x168
component_add+0x10/0x18
sun8i_dw_hdmi_probe+0x18/0x20
platform_drv_probe+0x3c/0x70
really_probe+0xcc/0x278
driver_probe_device+0x34/0xa8
Problem (2) was identified by head scratching.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405233048.3823-1-megous@megous.com
|
|
We haven't backmerged for a while and this creates some coherency issues
across DRM drivers.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Setting the module_get_upon_open field for component driver
prevents the module refcount from being incremented during
component probe(). This could lead to the module being
allowed to be unloaded when a pcm stream is open. So,
if this field is set, the module's refcount should be
incremented during pcm open to prevent module removal
when the component is in use. And, the refcount should
be decremented upon pcm close.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Recently, for Intel platforms the "ignore_module_refcount" field
was introduced for the component driver. In order to avoid a
deadlock preventing the PCI modules from being removed
even when the card was idle, the refcounts were not incremented
for the device driver module during component probe.
However, this change introduced a nasty side effect:
the device driver module can be unloaded while a pcm stream is open.
This patch proposes to change the field to be renamed as
"module_get_upon_open". When this field is set, the module
refcount should be incremented on pcm open amd decremented
upon pcm close. This will enable modules to be removed
when no PCM playback/capture happens and prevent removal
when the component is actually in use.
Also, align with the skylake component driver with the new name.
Fixes: b450b878('ASoC: core: don't increase component module refcount
unconditionally'
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
While transitioning to having better clarity between the modules, it's
desirable to have the function name prefixes reflect the
module. Functions in intel_foo.c should be prefixed intel_foo_.
Expose only one CDCLK init/uninit function from intel_cdclk.c instead of
one per platform. Obviously this adds one "unnecessary" if ladder within
the entry points. However it should be considered more of a CDCLK
implementation detail how this is done per platform, instead of exposing
the fact. In other words, abstract the CDCLK module better.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f63ed6e129098a32c63735be6cffa4756e7947af.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c128d7be3f621391e571e86b03f302f3ffd0ed2b.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/679c857a1933ee3d0706f978ab05ca880cd30a00.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1ccf9000ad33b895aea06be41053a5b7bac8459e.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5d54d02cf7b7bfe3f78ed60d28534c5726371af3.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f44c21e3d154e47233ebef4267ce1a924fa38df7.1554461791.git.jani.nikula@intel.com
|
