Maciej S. Szmigiero
0c55f867f0
selftests: kvm/set_memory_region_test: Fix race in move region test
...
The current memory region move test correctly handles the situation that
the second (realigning) memslot move operation would temporarily trigger
MMIO until it completes, however it does not handle the case in which the
first (misaligning) move operation does this, too.
This results in false test assertions in case it does so.
Fix this by handling temporary MMIO from the first memslot move operation
in the test guest code, too.
Fixes: 8a0639fe92 ("KVM: sefltests: Add explicit synchronization to move mem region test")
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com >
Message-Id: <0fdddb94bb0e31b7da129a809a308d91c10c0b5e.1606941224.git.maciej.szmigiero@oracle.com >
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com >
2020-12-03 12:38:58 -05:00
Mike Travis
8dcc0e19df
x86/platform/uv: Fix UV4 hub revision adjustment
...
Currently, UV4 is incorrectly identified as UV4A and UV4A as UV5. Hub
chip starts with revision 1, fix it.
[ bp: Massage commit message. ]
Fixes: 647128f153 ("x86/platform/uv: Update UV MMRs for UV5")
Signed-off-by: Mike Travis <mike.travis@hpe.com >
Signed-off-by: Borislav Petkov <bp@suse.de >
Reviewed-by: Steve Wahl <steve.wahl@hpe.com >
Acked-by: Dimitri Sivanich <dimitri.sivanich@hpe.com >
Link: https://lkml.kernel.org/r/20201203152252.371199-1-mike.travis@hpe.com
2020-12-03 18:09:18 +01:00
Kuogee Hsieh
c58eb1b54f
drm/msm/dp: fix connect/disconnect handled at irq_hpd
...
Some usb type-c dongle use irq_hpd request to perform device connection
and disconnection. This patch add handling of both connection and
disconnection are based on the state of hpd_state and sink_count.
Changes in V2:
-- add dp_display_handle_port_ststus_changed()
-- fix kernel test robot complaint
Changes in V3:
-- add encoder_mode_set into struct dp_display_private
Reported-by: kernel test robot <lkp@intel.com >
Fixes: 26b8d66a39 ("drm/msm/dp: promote irq_hpd handle to handle link training correctly")
Tested-by: Stephen Boyd <swboyd@chromium.org >
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org >
Signed-off-by: Rob Clark <robdclark@chromium.org >
2020-12-03 08:51:40 -08:00
Abhinav Kumar
854f6f1c65
drm/msm/dpu: update the qos remap only if the client type changes
...
Update the qos remap only if the client type changes for the plane.
This will avoid unnecessary register programming and also avoid log
spam from the dpu_vbif_set_qos_remap() function.
changes in v2:
- get rid of the dirty flag and simplify the logic to call
_dpu_plane_set_qos_remap()
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org >
Signed-off-by: Rob Clark <robdclark@chromium.org >
2020-12-03 08:49:24 -08:00
Lee Jones
849652c1ab
drm/msm/disp/dpu1/dpu_hw_interrupts: Demote kernel-doc formatting misuse
...
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:246: error: Cannot parse struct or union!
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:756: error: Cannot parse struct or union!
Cc: Rob Clark <robdclark@gmail.com >
Cc: Sean Paul <sean@poorly.run >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Shubhashree Dhar <dhar@codeaurora.org >
Cc: linux-arm-msm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org >
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org >
Signed-off-by: Rob Clark <robdclark@chromium.org >
2020-12-03 08:47:08 -08:00
Dan Carpenter
74a8c816fa
rtw88: debug: Fix uninitialized memory in debugfs code
...
This code does not ensure that the whole buffer is initialized and none
of the callers check for errors so potentially none of the buffer is
initialized. Add a memset to eliminate this bug.
Fixes: e3037485c6 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com >
Signed-off-by: Kalle Valo <kvalo@codeaurora.org >
Link: https://lore.kernel.org/r/X8ilOfVz3pf0T5ec@mwanda
2020-12-03 18:00:45 +02:00
Johan Hovold
bf193bfc12
USB: serial: ch341: sort device-id entries
...
Keep the device-id entries sorted to make it easier to add new ones in
the right spot.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org >
2020-12-03 10:28:55 +01:00
Jan-Niklas Burfeind
46ee4abb10
USB: serial: ch341: add new Product ID for CH341A
...
Add PID for CH340 that's found on a ch341 based Programmer made by keeyees.
The specific device that contains the serial converter is described
here: http://www.keeyees.com/a/Products/ej/36.html
The driver works flawlessly as soon as the new PID (0x5512) is added to
it.
Signed-off-by: Jan-Niklas Burfeind <kernel@aiyionpri.me >
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org >
2020-12-03 10:09:45 +01:00
Stephane Eranian
fc17db8aa4
perf/x86/intel: Check PEBS status correctly
...
The kernel cannot disambiguate when 2+ PEBS counters overflow at the
same time. This is what the comment for this code suggests. However,
I see the comparison is done with the unfiltered p->status which is a
copy of IA32_PERF_GLOBAL_STATUS at the time of the sample. This
register contains more than the PEBS counter overflow bits. It also
includes many other bits which could also be set.
Signed-off-by: Namhyung Kim <namhyung@kernel.org >
Signed-off-by: Stephane Eranian <eranian@google.com >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Link: https://lkml.kernel.org/r/20201126110922.317681-2-namhyung@kernel.org
2020-12-03 10:00:26 +01:00
Namhyung Kim
5debf02131
perf/x86/intel: Fix a warning on x86_pmu_stop() with large PEBS
...
The commit 3966c3feca ("x86/perf/amd: Remove need to check "running"
bit in NMI handler") introduced this. It seems x86_pmu_stop can be
called recursively (like when it losts some samples) like below:
x86_pmu_stop
intel_pmu_disable_event (x86_pmu_disable)
intel_pmu_pebs_disable
intel_pmu_drain_pebs_nhm (x86_pmu_drain_pebs_buffer)
x86_pmu_stop
While commit 35d1ce6bec ("perf/x86/intel/ds: Fix x86_pmu_stop
warning for large PEBS") fixed it for the normal cases, there's
another path to call x86_pmu_stop() recursively when a PEBS error was
detected (like two or more counters overflowed at the same time).
Like in the Kan's previous fix, we can skip the interrupt accounting
for large PEBS, so check the iregs which is set for PMI only.
Fixes: 3966c3feca ("x86/perf/amd: Remove need to check "running" bit in NMI handler")
Reported-by: John Sperbeck <jsperbeck@google.com >
Suggested-by: Peter Zijlstra <peterz@infradead.org >
Signed-off-by: Namhyung Kim <namhyung@kernel.org >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Link: https://lkml.kernel.org/r/20201126110922.317681-1-namhyung@kernel.org
2020-12-03 10:00:26 +01:00
Peter Zijlstra
4d916140bf
intel_idle: Build fix
...
Because CONFIG_ soup.
Fixes: 6e1d2bc675 ("intel_idle: Fix intel_idle() vs tracing")
Reported-by: Randy Dunlap <rdunlap@infradead.org >
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org >
Link: https://lkml.kernel.org/r/20201130115402.GO3040@hirez.programming.kicks-ass.net
2020-12-03 10:00:23 +01:00
Boyuan Zhang
efd6d85a18
drm/amdgpu/vcn3.0: remove old DPG workaround
...
Port from VCN2.5
SCRATCH2 is used to keep decode wptr as a workaround
which fix a hardware DPG decode wptr update bug for
vcn2.5 beforehand.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com >
Reviewed-by: James Zhu <James.Zhu@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: stable@vger.kernel.org # 5.9.x
2020-12-02 22:55:48 -05:00
Boyuan Zhang
ac2db9488c
drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset
...
Port from VCN2.5
Add vcn dpg harware synchronization to fix race condition
issue between vcn driver and hardware.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com >
Reviewed-by: James Zhu <James.Zhu@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: stable@vger.kernel.org # 5.9.x
2020-12-02 22:55:00 -05:00
Brandon Syu
7e0b367db8
drm/amd/display: Init clock value by current vbios CLKs
...
[Why]
While booting into OS, driver updates DPP/DISP CLKs.
But init clock value is zero which is invalid.
[How]
Get current clocks value to update init clocks.
To avoid underflow.
Signed-off-by: Brandon Syu <Brandon.Syu@amd.com >
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com >
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 22:53:01 -05:00
Arunpravin
acab02c1af
drm/amdgpu/pm/smu11: Fix fan set speed bug
...
Fix fan set speed calculation.
Suggested-by: Kenneth Feng <kenneth.feng@amd.com >
Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com >
Acked-by: Alex Deucher <alexander.deucher@amd.com >
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: stable@vger.kernel.org
2020-12-02 22:51:10 -05:00
Dave Airlie
5eb3c85e34
Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next
...
Again, nothing big this time. Mostly a new performance counter from
Christian, some more lockdep annotations from Guido and removal of
functionality that duplicates driver core from Robin.
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Lucas Stach <l.stach@pengutronix.de >
Link: https://patchwork.freedesktop.org/patch/msgid/81367a99b8949584e5becd334ac001b9ad3dc37a.camel@pengutronix.de
2020-12-03 13:25:23 +10:00
Dave Airlie
e6c7c9d01f
Merge tag 'mediatek-drm-next-5.11-2' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next
...
Mediatek DRM Next for Linux 5.11-2
1. Add MT8167 support
2. Cleanup function
3. Convert the dpi bindings to yaml
4. Drop local dma_parms
5. Fix formatting and provide missing member description
6. Introduce GEM object functions
7. Fix aliases name
8. Move MIPI DSI phy driver to phy folder
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Chun-Kuang Hu <chunkuang.hu@kernel.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20201130234807.936-1-chunkuang.hu@kernel.org
2020-12-03 13:23:57 +10:00
Dave Airlie
207665fd37
Merge tag 'exynos-drm-next-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
...
Add a new mode support for HDMI
- support for 1920x1200x60Hz mode.
Cleanups
- Drop in_bridge_node from exynos_dsi
- Use a exynos_dsi object instead of a encoder object as drvdata.
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Inki Dae <inki.dae@samsung.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1606798227-31967-1-git-send-email-inki.dae@samsung.com
2020-12-03 13:05:29 +10:00
Dave Airlie
46fe37b98e
Merge tag 'drm-intel-next-queued-2020-11-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
...
drm/i915 features for v5.11:
Highlights:
- Enable big joiner to join two pipes to one port to overcome pipe restrictions
(Manasi, Ville, Maarten)
Display:
- More DG1 enabling (Lucas, Aditya)
- Fixes to cases without display (Lucas, José, Jani)
- Initial PSR state improvements (José)
- JSL eDP vswing updates (Tejas)
- Handle EDID declared max 16 bpc (Ville)
- Display refactoring (Ville)
Other:
- GVT features
- Backmerge
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/87czzzkk1s.fsf@intel.com
2020-12-03 13:01:44 +10:00
Zhang Changzhong
832e09798c
vxlan: fix error return code in __vxlan_dev_create()
...
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 0ce1822c2a ("vxlan: add adjacent link to limit depth level")
Reported-by: Hulk Robot <hulkci@huawei.com >
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com >
Link: https://lore.kernel.org/r/1606903122-2098-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
2020-12-02 18:04:02 -08:00
Zhang Changzhong
aba84871bd
net: pasemi: fix error return code in pasemi_mac_open()
...
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 72b05b9940 ("pasemi_mac: RX/TX ring management cleanup")
Fixes: 8d636d8bc5 ("pasemi_mac: jumbo frame support")
Reported-by: Hulk Robot <hulkci@huawei.com >
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com >
Link: https://lore.kernel.org/r/1606903035-1838-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
2020-12-02 18:03:58 -08:00
Zhang Changzhong
ff9924897f
cxgb3: fix error return code in t3_sge_alloc_qset()
...
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: b1fb1f280d ("cxgb3 - Fix dma mapping error path")
Reported-by: Hulk Robot <hulkci@huawei.com >
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com >
Acked-by: Raju Rangoju <rajur@chelsio.com >
Link: https://lore.kernel.org/r/1606902965-1646-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
2020-12-02 18:03:53 -08:00
Dave Airlie
aac06646aa
Merge tag 'drm/tegra/for-5.10-rc7' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes
...
drm/tegra: Fixes for v5.10-rc7
This is a set of small fixes for various issues found during the last
couple of weeks.
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Thierry Reding <thierry.reding@gmail.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201127145324.125776-1-thierry.reding@gmail.com
2020-12-03 11:42:29 +10:00
Dan Carpenter
6ee50c8e26
net/x25: prevent a couple of overflows
...
The .x25_addr[] address comes from the user and is not necessarily
NUL terminated. This leads to a couple problems. The first problem is
that the strlen() in x25_bind() can read beyond the end of the buffer.
The second problem is more subtle and could result in memory corruption.
The call tree is:
x25_connect()
--> x25_write_internal()
--> x25_addr_aton()
The .x25_addr[] buffers are copied to the "addresses" buffer from
x25_write_internal() so it will lead to stack corruption.
Verify that the strings are NUL terminated and return -EINVAL if they
are not.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Fixes: a9288525d2 ("X25: Dont let x25_bind use addresses containing characters")
Reported-by: "kiyin(尹亮)" <kiyin@tencent.com >
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com >
Acked-by: Martin Schiller <ms@dev.tdt.de >
Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda
Signed-off-by: Jakub Kicinski <kuba@kernel.org >
2020-12-02 17:26:36 -08:00
Linus Torvalds
34816d20f1
Merge tag 'gfs2-v5.10-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
...
Pull gfs2 fixes from Andreas Gruenbacher:
"Various gfs2 fixes"
* tag 'gfs2-v5.10-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
gfs2: Fix deadlock between gfs2_{create_inode,inode_lookup} and delete_work_func
gfs2: Upgrade shared glocks for atime updates
gfs2: Don't freeze the file system during unmount
gfs2: check for empty rgrp tree in gfs2_ri_update
gfs2: set lockdep subclass for iopen glocks
gfs2: Fix deadlock dumping resource group glocks
2020-12-02 17:25:23 -08:00
Chris Wilson
ccc9e67ab2
drm/i915/display: Defer initial modeset until after GGTT is initialised
...
Prior to sanitizing the GGTT, the only operations allowed in
intel_display_init_nogem() are those to reserve the preallocated (and
active) regions in the GGTT leftover from the BIOS. Trying to allocate a
GGTT vma (such as intel_pin_and_fence_fb_obj during the initial modeset)
may then conflict with other preallocated regions that have not yet been
protected.
Move the initial modesetting from the end of init_nogem to the beginning
of init so that any vma pinning (either framebuffers or DSB, for example),
is after the GGTT is ready to handle it.
This will prevent the DSB object from being destroyed too early:
[ 53.449241] BUG: KASAN: use-after-free in i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.449309] Read of size 8 at addr ffff88811b1e8070 by task systemd-udevd/345
[ 53.449399] CPU: 1 PID: 345 Comm: systemd-udevd Tainted: G W 5.10.0-rc5+ #12
[ 53.449409] Call Trace:
[ 53.449418] dump_stack+0x9a/0xcc
[ 53.449558] ? i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.449565] print_address_description.constprop.0+0x3e/0x60
[ 53.449577] ? _raw_spin_lock_irqsave+0x4e/0x50
[ 53.449718] ? i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.449849] ? i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.449857] kasan_report.cold+0x1f/0x37
[ 53.449993] ? i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.450130] i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.450273] ? i915_ggtt_suspend+0x1f0/0x1f0 [i915]
[ 53.450281] ? static_obj+0x69/0x80
[ 53.450289] ? lockdep_init_map_waits+0xa9/0x310
[ 53.450431] ? intel_wopcm_init+0x96/0x3d0 [i915]
[ 53.450581] ? i915_gem_init+0x75/0x2d0 [i915]
[ 53.450720] i915_gem_init+0x75/0x2d0 [i915]
[ 53.450852] i915_driver_probe+0x8c2/0x1210 [i915]
[ 53.450993] ? i915_pm_prepare+0x630/0x630 [i915]
[ 53.451006] ? check_chain_key+0x1e7/0x2e0
[ 53.451025] ? __pm_runtime_resume+0x58/0xb0
[ 53.451157] i915_pci_probe+0xa6/0x2b0 [i915]
[ 53.451285] ? i915_pci_remove+0x40/0x40 [i915]
[ 53.451295] ? lockdep_hardirqs_on_prepare+0x124/0x230
[ 53.451302] ? _raw_spin_unlock_irqrestore+0x42/0x50
[ 53.451309] ? lockdep_hardirqs_on+0xbf/0x130
[ 53.451315] ? preempt_count_sub+0xf/0xb0
[ 53.451321] ? _raw_spin_unlock_irqrestore+0x2f/0x50
[ 53.451335] pci_device_probe+0xf9/0x190
[ 53.451350] really_probe+0x17f/0x5b0
[ 53.451365] driver_probe_device+0x13a/0x1c0
[ 53.451376] device_driver_attach+0x82/0x90
[ 53.451386] ? device_driver_attach+0x90/0x90
[ 53.451391] __driver_attach+0xab/0x190
[ 53.451401] ? device_driver_attach+0x90/0x90
[ 53.451407] bus_for_each_dev+0xe4/0x140
[ 53.451414] ? subsys_dev_iter_exit+0x10/0x10
[ 53.451423] ? __list_add_valid+0x2b/0xa0
[ 53.451440] bus_add_driver+0x227/0x2e0
[ 53.451454] driver_register+0xd3/0x150
[ 53.451585] i915_init+0x92/0xac [i915]
[ 53.451592] ? 0xffffffffa0a20000
[ 53.451598] do_one_initcall+0xb6/0x3b0
[ 53.451606] ? trace_event_raw_event_initcall_finish+0x150/0x150
[ 53.451614] ? __kasan_kmalloc.constprop.0+0xc2/0xd0
[ 53.451627] ? kmem_cache_alloc_trace+0x4a4/0x8e0
[ 53.451634] ? kasan_unpoison_shadow+0x33/0x40
[ 53.451649] do_init_module+0xf8/0x350
[ 53.451662] load_module+0x43de/0x47f0
[ 53.451716] ? module_frob_arch_sections+0x20/0x20
[ 53.451731] ? rw_verify_area+0x5f/0x130
[ 53.451780] ? __do_sys_finit_module+0x10d/0x1a0
[ 53.451785] __do_sys_finit_module+0x10d/0x1a0
[ 53.451792] ? __ia32_sys_init_module+0x40/0x40
[ 53.451800] ? seccomp_do_user_notification.isra.0+0x5c0/0x5c0
[ 53.451829] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 53.451835] ? mark_held_locks+0x24/0x90
[ 53.451856] do_syscall_64+0x33/0x80
[ 53.451863] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.451868] RIP: 0033:0x7fde09b4470d
[ 53.451875] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 53 f7 0c 00 f7 d8 64 89 01 48
[ 53.451880] RSP: 002b:00007ffd6abc1718 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 53.451890] RAX: ffffffffffffffda RBX: 000056444e528150 RCX: 00007fde09b4470d
[ 53.451895] RDX: 0000000000000000 RSI: 00007fde09a21ded RDI: 000000000000000f
[ 53.451899] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
[ 53.451904] R10: 000000000000000f R11: 0000000000000246 R12: 00007fde09a21ded
[ 53.451909] R13: 0000000000000000 R14: 000056444e329200 R15: 000056444e528150
[ 53.451957] Allocated by task 345:
[ 53.451995] kasan_save_stack+0x1b/0x40
[ 53.452001] __kasan_kmalloc.constprop.0+0xc2/0xd0
[ 53.452006] kmem_cache_alloc+0x1cd/0x8d0
[ 53.452146] i915_vma_instance+0x126/0xb70 [i915]
[ 53.452304] i915_gem_object_ggtt_pin_ww+0x222/0x3f0 [i915]
[ 53.452446] intel_dsb_prepare+0x14f/0x230 [i915]
[ 53.452588] intel_atomic_commit+0x183/0x690 [i915]
[ 53.452730] intel_initial_commit+0x2bc/0x2f0 [i915]
[ 53.452871] intel_modeset_init_nogem+0xa02/0x2af0 [i915]
[ 53.452995] i915_driver_probe+0x8af/0x1210 [i915]
[ 53.453120] i915_pci_probe+0xa6/0x2b0 [i915]
[ 53.453125] pci_device_probe+0xf9/0x190
[ 53.453131] really_probe+0x17f/0x5b0
[ 53.453136] driver_probe_device+0x13a/0x1c0
[ 53.453142] device_driver_attach+0x82/0x90
[ 53.453148] __driver_attach+0xab/0x190
[ 53.453153] bus_for_each_dev+0xe4/0x140
[ 53.453158] bus_add_driver+0x227/0x2e0
[ 53.453164] driver_register+0xd3/0x150
[ 53.453286] i915_init+0x92/0xac [i915]
[ 53.453292] do_one_initcall+0xb6/0x3b0
[ 53.453297] do_init_module+0xf8/0x350
[ 53.453302] load_module+0x43de/0x47f0
[ 53.453307] __do_sys_finit_module+0x10d/0x1a0
[ 53.453312] do_syscall_64+0x33/0x80
[ 53.453318] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.453345] Freed by task 82:
[ 53.453379] kasan_save_stack+0x1b/0x40
[ 53.453384] kasan_set_track+0x1c/0x30
[ 53.453389] kasan_set_free_info+0x1b/0x30
[ 53.453394] __kasan_slab_free+0x112/0x160
[ 53.453399] kmem_cache_free+0xb2/0x3f0
[ 53.453536] i915_gem_flush_free_objects+0x31a/0x3b0 [i915]
[ 53.453542] process_one_work+0x519/0x9f0
[ 53.453547] worker_thread+0x75/0x5c0
[ 53.453552] kthread+0x1da/0x230
[ 53.453557] ret_from_fork+0x22/0x30
[ 53.453584] The buggy address belongs to the object at ffff88811b1e8040
which belongs to the cache i915_vma of size 968
[ 53.453692] The buggy address is located 48 bytes inside of
968-byte region [ffff88811b1e8040, ffff88811b1e8408)
[ 53.453792] The buggy address belongs to the page:
[ 53.453842] page:00000000b35f7048 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88811b1ef940 pfn:0x11b1e8
[ 53.453847] head:00000000b35f7048 order:3 compound_mapcount:0 compound_pincount:0
[ 53.453853] flags: 0x8000000000010200(slab|head)
[ 53.453860] raw: 8000000000010200 ffff888115596248 ffff888115596248 ffff8881155b6340
[ 53.453866] raw: ffff88811b1ef940 0000000000170001 00000001ffffffff 0000000000000000
[ 53.453870] page dumped because: kasan: bad access detected
[ 53.453895] Memory state around the buggy address:
[ 53.453944] ffff88811b1e7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 53.454011] ffff88811b1e7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 53.454079] >ffff88811b1e8000: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
[ 53.454146] ^
[ 53.454211] ffff88811b1e8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 53.454279] ffff88811b1e8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 53.454347] ==================================================================
[ 53.454414] Disabling lock debugging due to kernel taint
[ 53.454434] general protection fault, probably for non-canonical address 0xdead0000000000d0: 0000 [#1 ] PREEMPT SMP KASAN PTI
[ 53.454446] CPU: 1 PID: 345 Comm: systemd-udevd Tainted: G B W 5.10.0-rc5+ #12
[ 53.454592] RIP: 0010:i915_init_ggtt+0x26f/0x9e0 [i915]
[ 53.454602] Code: 89 8d 48 ff ff ff 4c 8d 60 d0 49 39 c7 0f 84 37 02 00 00 4c 89 b5 40 ff ff ff 4d 8d bc 24 90 00 00 00 4c 89 ff e8 c1 97 f8 e0 <49> 83 bc 24 90 00 00 00 00 0f 84 0f 02 00 00 49 8d 7c 24 08 e8 a8
[ 53.454618] RSP: 0018:ffff88812247f430 EFLAGS: 00010286
[ 53.454625] RAX: 0000000000000000 RBX: ffff888136440000 RCX: ffffffffa03fb78f
[ 53.454633] RDX: 0000000000000000 RSI: 0000000000000008 RDI: dead000000000160
[ 53.454641] RBP: ffff88812247f500 R08: ffffffff8113589f R09: 0000000000000000
[ 53.454648] R10: ffffffff83063843 R11: fffffbfff060c708 R12: dead0000000000d0
[ 53.454656] R13: ffff888136449ba0 R14: 0000000000002000 R15: dead000000000160
[ 53.454664] FS: 00007fde095c4880(0000) GS:ffff88840c880000(0000) knlGS:0000000000000000
[ 53.454672] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 53.454679] CR2: 00007fef132b4f28 CR3: 000000012245c002 CR4: 00000000003706e0
[ 53.454686] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 53.454693] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 53.454700] Call Trace:
[ 53.454833] ? i915_ggtt_suspend+0x1f0/0x1f0 [i915]
Reported-by: Matthew Auld <matthew.auld@intel.com >
Fixes: afeda4f3b1 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Lucas De Marchi <lucas.demarchi@intel.com >
Tested-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201125193032.29282-1-chris@chris-wilson.co.uk
(cherry picked from commit b3bf99daae )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 17:05:58 -08:00
Jani Nikula
37eade64eb
drm/i915/display: return earlier from intel_modeset_init() without display
...
!HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so
return earlier from intel_modeset_init() for clarity.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: José Roberto de Souza <jose.souza@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-4-lucas.demarchi@intel.com
(cherry picked from commit 71c8415d0d )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 17:05:58 -08:00
Chris Wilson
aff76ab795
drm/i915/gt: Limit frequency drop to RPe on parking
...
We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do also need to update the frequencies so that workloads
that run for less than 1ms are autotuned by RPS (otherwise we leave
compositors running at max clocks, draining excess power). Conversely,
if we try to run too slowly, the next workload has to run longer. Since
there is a hysteresis in the power graph, below a certain frequency
running a short workload for longer consumes more energy than running it
slightly higher for less time. The exact balance point is unknown
beforehand, but measurements with 30fps media playback indicate that RPe
is a better choice.
Reported-by: Edward Baker <edward.baker@intel.com >
Tested-by: Edward Baker <edward.baker@intel.com >
Fixes: 043cd2d14e ("drm/i915/gt: Leave rps->cur_freq on unpark")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Edward Baker <edward.baker@intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: Lyude Paul <lyude@redhat.com >
Cc: <stable@vger.kernel.org > # v5.8+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201124183521.28623-1-chris@chris-wilson.co.uk
(cherry picked from commit f7ed83cc19 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 17:05:58 -08:00
Venkata Ramana Nayana
78b2eb8a1f
drm/i915/gt: Retain default context state across shrinking
...
As we use a shmemfs file to hold the context state, when not in use it
may be swapped out, such as across suspend. Since we wrote into the
shmemfs without marking the pages as dirty, the contents may be dropped
instead of being written back to swap. On re-using the shmemfs file,
such as creating a new context after resume, the contents of that file
were likely garbage and so the new context could then hang the GPU.
Simply mark the page as being written when copying into the shmemfs
file, and it the new contents will be retained across swapout.
Fixes: be1cb55a07 ("drm/i915/gt: Keep a no-frills swappable copy of the default context state")
Cc: Sudeep Dutt <sudeep.dutt@intel.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Ramalingam C <ramalingam.c@intel.com >
Signed-off-by: CQ Tang <cq.tang@intel.com >
Signed-off-by: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: <stable@vger.kernel.org > # v5.8+
Link: https://patchwork.freedesktop.org/patch/msgid/20201127120718.454037-161-matthew.auld@intel.com
(cherry picked from commit a9d71f76cc )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 17:05:58 -08:00
Chris Wilson
2bfdf30246
drm/i915/gt: Split the breadcrumb spinlock between global and contexts
...
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.
Furthermore, this closes the race between enabling the signaling context
while it is in the process of being signaled and removed:
<4>[ 416.208555] list_add corruption. prev->next should be next (ffff8881951d5910), but was dead000000000100. (prev=ffff8882781bb870).
<4>[ 416.208573] WARNING: CPU: 7 PID: 0 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70
<4>[ 416.208575] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul snd_intel_dspcfg crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core e1000e snd_pcm ptp pps_core mei_me mei prime_numbers intel_lpss_pci [last unloaded: i915]
<4>[ 416.208611] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G U 5.8.0-CI-CI_DRM_8852+ #1
<4>[ 416.208614] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112 05/21/2019
<4>[ 416.208627] RIP: 0010:__list_add_valid+0x4d/0x70
<4>[ 416.208631] Code: c3 48 89 d1 48 c7 c7 60 18 33 82 48 89 c2 e8 ea e0 b6 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 b0 18 33 82 e8 d3 e0 b6 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 00 19 33 82 e8
<4>[ 416.208633] RSP: 0018:ffffc90000280e18 EFLAGS: 00010086
<4>[ 416.208636] RAX: 0000000000000000 RBX: ffff888250a44880 RCX: 0000000000000105
<4>[ 416.208639] RDX: 0000000000000105 RSI: ffffffff82320c5b RDI: 00000000ffffffff
<4>[ 416.208641] RBP: ffff8882781bb870 R08: 0000000000000000 R09: 0000000000000001
<4>[ 416.208643] R10: 00000000054d2957 R11: 000000006abbd991 R12: ffff8881951d58c8
<4>[ 416.208646] R13: ffff888286073880 R14: ffff888286073848 R15: ffff8881951d5910
<4>[ 416.208669] FS: 0000000000000000(0000) GS:ffff88829c180000(0000) knlGS:0000000000000000
<4>[ 416.208671] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 416.208673] CR2: 0000556231326c48 CR3: 0000000005610001 CR4: 0000000000760ee0
<4>[ 416.208675] PKRU: 55555554
<4>[ 416.208677] Call Trace:
<4>[ 416.208679] <IRQ>
<4>[ 416.208751] i915_request_enable_breadcrumb+0x278/0x400 [i915]
<4>[ 416.208839] __i915_request_submit+0xca/0x2a0 [i915]
<4>[ 416.208892] __execlists_submission_tasklet+0x480/0x1830 [i915]
<4>[ 416.208942] execlists_submission_tasklet+0xc4/0x130 [i915]
<4>[ 416.208947] tasklet_action_common.isra.17+0x6c/0x1c0
<4>[ 416.208954] __do_softirq+0xdf/0x498
<4>[ 416.208960] ? handle_fasteoi_irq+0x150/0x150
<4>[ 416.208964] asm_call_on_stack+0xf/0x20
<4>[ 416.208966] </IRQ>
<4>[ 416.208969] do_softirq_own_stack+0xa1/0xc0
<4>[ 416.208972] irq_exit_rcu+0xb5/0xc0
<4>[ 416.208976] common_interrupt+0xf7/0x260
<4>[ 416.208980] asm_common_interrupt+0x1e/0x40
<4>[ 416.208985] RIP: 0010:cpuidle_enter_state+0xb6/0x410
<4>[ 416.208987] Code: 00 31 ff e8 9c 3e 89 ff 80 7c 24 0b 00 74 12 9c 58 f6 c4 02 0f 85 31 03 00 00 31 ff e8 e3 6c 90 ff e8 fe a4 94 ff fb 45 85 ed <0f> 88 c7 02 00 00 49 63 c5 4c 2b 24 24 48 8d 14 40 48 8d 14 90 48
<4>[ 416.208989] RSP: 0018:ffffc90000143e70 EFLAGS: 00000206
<4>[ 416.208991] RAX: 0000000000000007 RBX: ffffe8ffffda8070 RCX: 0000000000000000
<4>[ 416.208993] RDX: 0000000000000000 RSI: ffffffff8238b4ee RDI: ffffffff8233184f
<4>[ 416.208995] RBP: ffffffff826b4e00 R08: 0000000000000000 R09: 0000000000000000
<4>[ 416.208997] R10: 0000000000000001 R11: 0000000000000000 R12: 00000060e7f24a8f
<4>[ 416.208998] R13: 0000000000000003 R14: 0000000000000003 R15: 0000000000000003
<4>[ 416.209012] cpuidle_enter+0x24/0x40
<4>[ 416.209016] do_idle+0x22f/0x2d0
<4>[ 416.209022] cpu_startup_entry+0x14/0x20
<4>[ 416.209025] start_secondary+0x158/0x1a0
<4>[ 416.209030] secondary_startup_64+0xa4/0xb0
<4>[ 416.209039] irq event stamp: 10186977
<4>[ 416.209042] hardirqs last enabled at (10186976): [<ffffffff810b9363>] tasklet_action_common.isra.17+0xe3/0x1c0
<4>[ 416.209044] hardirqs last disabled at (10186977): [<ffffffff81a5e5ed>] _raw_spin_lock_irqsave+0xd/0x50
<4>[ 416.209047] softirqs last enabled at (10186968): [<ffffffff810b9a1a>] irq_enter_rcu+0x6a/0x70
<4>[ 416.209049] softirqs last disabled at (10186969): [<ffffffff81c00f4f>] asm_call_on_stack+0xf/0x20
<4>[ 416.209317] list_del corruption, ffff8882781bb870->next is LIST_POISON1 (dead000000000100)
<4>[ 416.209317] WARNING: CPU: 7 PID: 46 at lib/list_debug.c:47 __list_del_entry_valid+0x4e/0x90
<4>[ 416.209317] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul snd_intel_dspcfg crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core e1000e snd_pcm ptp pps_core mei_me mei prime_numbers intel_lpss_pci [last unloaded: i915]
<4>[ 416.209317] CPU: 7 PID: 46 Comm: ksoftirqd/7 Tainted: G U W 5.8.0-CI-CI_DRM_8852+ #1
<4>[ 416.209317] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112 05/21/2019
<4>[ 416.209317] RIP: 0010:__list_del_entry_valid+0x4e/0x90
<4>[ 416.209317] Code: 2e 48 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 c3 48 89 fe 48 89 c2 48 c7 c7 38 19 33 82 e8 62 e0 b6 ff <0f> 0b 31 c0 c3 48 89 fe 48 c7 c7 70 19 33 82 e8 4e e0 b6 ff 0f 0b
<4>[ 416.209317] RSP: 0018:ffffc90000280de8 EFLAGS: 00010086
<4>[ 416.209317] RAX: 0000000000000000 RBX: ffff8882781bb848 RCX: 0000000000010104
<4>[ 416.209317] RDX: 0000000000010104 RSI: ffffffff8238b4ee RDI: 00000000ffffffff
<4>[ 416.209317] RBP: ffff8882781bb880 R08: 0000000000000000 R09: 0000000000000001
<4>[ 416.209317] R10: 000000009fb6666e R11: 00000000feca9427 R12: ffffc90000280e18
<4>[ 416.209317] R13: ffff8881951d5930 R14: dead0000000000d8 R15: ffff8882781bb880
<4>[ 416.209317] FS: 0000000000000000(0000) GS:ffff88829c180000(0000) knlGS:0000000000000000
<4>[ 416.209317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 416.209317] CR2: 0000556231326c48 CR3: 0000000005610001 CR4: 0000000000760ee0
<4>[ 416.209317] PKRU: 55555554
<4>[ 416.209317] Call Trace:
<4>[ 416.209317] <IRQ>
<4>[ 416.209317] remove_signaling_context.isra.13+0xd/0x70 [i915]
<4>[ 416.209513] signal_irq_work+0x1f7/0x4b0 [i915]
This is caused by virtual engines where although we take the breadcrumb
lock on each of the active engines, they may be different engines on
different requests, It turns out that the b->irq_lock was not a
sufficient proxy for the engine->active.lock in the case of more than
one request, so introduce an explicit lock around ce->signals.
v2: ce->signal_lock is acquired with only RCU protection and so must be
treated carefully and not cleared during reallocation. We also then need
to confirm that the ce we lock is the same as we found in the breadcrumb
list.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2276
Fixes: c18636f763 ("drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs")
Fixes: 2854d86632 ("drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201126140407.31952-4-chris@chris-wilson.co.uk
(cherry picked from commit c744d50363 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 17:05:58 -08:00
Chris Wilson
9261a1db80
drm/i915/gt: Protect context lifetime with RCU
...
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.
This is required for a later patch to handle locking around virtual
requests in the signaler, as those requests may want to move between
engines and be destroyed while we are holding b->irq_lock on a physical
engine.
v2: Drop mutex_reinit(), if we never mark the mutex as destroyed we
don't need to reset the debug code, at the loss of having the mutex
debug code spot us attempting to destroy a locked mutex.
v3: As the intended use will remain strongly referenced counted, with
very little inflight access across reuse, drop the ctor.
v4: Drop the unrequired change to remove the temporary reference around
dropping the active context, and add back some more missing ctor
operations.
v5: The ctor is back. Tvrtko spotted that ce->signal_lock [introduced
later] maybe accessed under RCU and so needs special care not to be
reinitialised.
v6: Don't mix SLAB_TYPESAFE_BY_RCU and RCU list iteration.
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/20201126140407.31952-3-chris@chris-wilson.co.uk
(cherry picked from commit 14d1eaf088 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2020-12-02 16:53:00 -08:00
Xuan Zhuo
3413f04141
xsk: Change the tx writeable condition
...
Modify the tx writeable condition from the queue is not full to the
number of present tx queues is less than the half of the total number
of queues. Because the tx queue not full is a very short time, this will
cause a large number of EPOLLOUT events, and cause a large number of
process wake up.
Fixes: 35fcde7f8d ("xsk: support for Tx")
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com >
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net >
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com >
Link: https://lore.kernel.org/bpf/508fef55188d4e1160747ead64c6dcda36735880.1606555939.git.xuanzhuo@linux.alibaba.com
2020-12-03 01:14:38 +01:00
Xuan Zhuo
f5da54187e
xsk: Replace datagram_poll by sock_poll_wait
...
datagram_poll will judge the current socket status (EPOLLIN, EPOLLOUT)
based on the traditional socket information (eg: sk_wmem_alloc), but
this does not apply to xsk. So this patch uses sock_poll_wait instead of
datagram_poll, and the mask is calculated by xsk_poll.
Fixes: c497176cb2 ("xsk: add Rx receive functions and poll support")
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com >
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net >
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com >
Link: https://lore.kernel.org/bpf/e82f4697438cd63edbf271ebe1918db8261b7c09.1606555939.git.xuanzhuo@linux.alibaba.com
2020-12-03 01:14:14 +01:00
Simon Ser
9bf1019c5f
drm/amd/display: add cursor pitch check
...
Replace the width check with a pitch check, which matches DM internals.
Add a new check to make sure the pitch (in pixels) matches the width.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com >
Signed-off-by: Simon Ser <contact@emersion.fr >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: Harry Wentland <hwentlan@amd.com >
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:39:29 -05:00
Simon Ser
03a6636730
drm/amd/display: use FB pitch to fill dc_cursor_attributes
...
Instead of relying on pitch (in pixels) == width, use the FB pitch. This
is less confusing to readers, and works correctly if we ever support FBs
with a pitch (in pixels) != width.
This also makes the code symmetrical with fill_plane_buffer_attributes.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com >
Signed-off-by: Simon Ser <contact@emersion.fr >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: Harry Wentland <hwentlan@amd.com >
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:39:29 -05:00
Simon Ser
ea9522f5e5
drm/amd/display: add debug logs for dm_crtc_helper_atomic_check
...
Instead of silently failing the atomic check, explain what happened via
a debug log. This makes it easier for user-space to figure out why
something failed.
Signed-off-by: Simon Ser <contact@emersion.fr >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: Harry Wentland <hwentlan@amd.com >
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:39:07 -05:00
Alex Deucher
22ca75ea6a
drm/amdgpu/swsmu/renoir: simplify sensor handling (v2)
...
Just query the metrics table directly rather than going through
an extra level of functions.
v2: use proper enum
Reviewed-by: Evan Quan <evan.quan@amd.com >
Reviewed-by: Huang Rui <ray.huang@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:18 -05:00
Alex Deucher
2139d12b3b
drm/amdgpu/swsmu/vangogh: use metrics table for voltages (v2)
...
Fixes voltage reading for vddgfx and adds support for vddsoc.
v2: use new voltage enum
Reviewed-by: Evan Quan <evan.quan@amd.com >
Reviewed-by: Huang Rui <ray.huang@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:18 -05:00
Alex Deucher
6cc24d8d48
drm/amdgpu/swsmu/vangogh: simplify sensor handling
...
Just query the metrics table directly rather than going through
an extra level of functions.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Reviewed-by: Huang Rui <ray.huang@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:17 -05:00
Alex Deucher
e408f2ba43
drm/amdgpu/swsmu: add metrics enums for voltage
...
To be used in subsequent patches.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Reviewed-by: Huang Rui <ray.huang@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:17 -05:00
Alex Deucher
60e317a277
drm/amdgpu/swsmu/sienna_cichlid: simplify sensor handling
...
Just query the metrics table directly rather than going through
an extra level of functions.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:17 -05:00
Alex Deucher
2bebe9148a
drm/amdgpu/swsmu/arcturus: simplify sensor handling
...
Just query the metrics table directly rather than going through
an extra level of functions.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:17 -05:00
Alex Deucher
fae3a572c9
drm/amdgpu/swsmu/navi1x: simplify sensor handling
...
Just query the metrics table directly rather than going through
an extra level of functions.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:16 -05:00
Alex Deucher
902bc65de0
drm/amdgpu/powerplay/psm: return an error in power state init
...
Rather than just silently dropping it. Also fixes a set but
unused variable warning.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:16 -05:00
Alex Deucher
9805e1adab
drm/amdgpu/powerplay/vega10: handle error in getting pptable
...
Rather than just silently dropping it. Also fixes a set but
unused variable warning.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:16 -05:00
Alex Deucher
402bdef8a5
drm/amdgpu/powerplay/iceland: return an error if copying to smc fails
...
Rather than just silently dropping it. Also fixes a set but
unused variable warning.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:16 -05:00
Alex Deucher
cfcc59d4c1
drm/amdgpu/powerplay/ci: return an error if copying to smc fails
...
Rather than just silently dropping it. Also fixes a set but
unused variable warning.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:16 -05:00
Alex Deucher
54915feea3
drm/amdgpu/powerplay/tonga: return an error if copying to smc fails
...
Rather than just silently dropping it. Also fixes a set but
unused variable warning.
Reviewed-by: Evan Quan <evan.quan@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:15 -05:00
Boyuan Zhang
3fabf0fdff
drm/amdgpu/vcn3.0: remove old DPG workaround
...
Port from VCN2.5
SCRATCH2 is used to keep decode wptr as a workaround
which fix a hardware DPG decode wptr update bug for
vcn2.5 beforehand.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com >
Reviewed-by: James Zhu <James.Zhu@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:37:07 -05:00
Boyuan Zhang
7643023eef
drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset
...
Port from VCN2.5
Add vcn dpg harware synchronization to fix race condition
issue between vcn driver and hardware.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com >
Reviewed-by: James Zhu <James.Zhu@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2020-12-02 17:36:50 -05:00