Commit Graph

970548 Commits

Author SHA1 Message Date
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