Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 7月, 2019 2 次提交
  3. 19 7月, 2019 18 次提交
    • B
      drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug · 4d352dbd
      由 Ben Skeggs 提交于 
      Appears to be fixed by "flcn/gp102-: improve implementation of
bind_context() on SEC2/GSP".

Tested on GP10[24678] and GV100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      4d352dbd
    • B
      drm/nouveau/flcn/gp102-: improve implementation of bind_context() on SEC2/GSP · 5210e967
      由 Ben Skeggs 提交于 
      Fixes various issues encountered while attempting to initialise ACR.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      5210e967
    • Y
      drm/nouveau: fix memory leak in nouveau_conn_reset() · 09b90e2f
      由 Yongxin Liu 提交于 
      In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to connector->state.

So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.

Here the is the log showing memory leak.

unreferenced object 0xffff8c5480483c80 (size 192):
  comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
  hex dump (first 32 bytes):
    00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
    [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau]
    [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
    [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau]
    [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
    [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
    [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
    [<000000007e961c3e>] local_pci_probe+0x47/0xa0
    [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30
    [<0000000028da4805>] process_one_work+0x27c/0x660
    [<000000001d415b04>] worker_thread+0x22b/0x3f0
    [<0000000003b69f1f>] kthread+0x12f/0x150
    [<00000000c94c29b7>] ret_from_fork+0x3a/0x50
Signed-off-by: NYongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      09b90e2f
    • R
      drm/nouveau/dmem: missing mutex_lock in error path · d304654b
      由 Ralph Campbell 提交于 
      In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING
is enabled:

[ 1294.871933] =====================================
[ 1294.876656] WARNING: bad unlock balance detected!
[ 1294.881375] 5.2.0-rc3+ #5 Not tainted
[ 1294.885048] -------------------------------------
[ 1294.889773] test-malloc-vra/6299 is trying to release lock (&drm->dmem->mutex) at:
[ 1294.897482] [<ffffffffa01a220f>] nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.905782] but there are no more locks to release!
[ 1294.910690]
[ 1294.910690] other info that might help us debug this:
[ 1294.917249] 1 lock held by test-malloc-vra/6299:
[ 1294.921881]  #0: 0000000016e10454 (&mm->mmap_sem#2){++++}, at: nouveau_svmm_bind+0x142/0x210 [nouveau]
[ 1294.931313]
[ 1294.931313] stack backtrace:
[ 1294.935702] CPU: 4 PID: 6299 Comm: test-malloc-vra Not tainted 5.2.0-rc3+ #5
[ 1294.942786] Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1401 05/21/2018
[ 1294.949590] Call Trace:
[ 1294.952059]  dump_stack+0x7c/0xc0
[ 1294.955469]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.962213]  print_unlock_imbalance_bug.cold.52+0xca/0xcf
[ 1294.967641]  lock_release+0x306/0x380
[ 1294.971383]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.978089]  ? lock_downgrade+0x2d0/0x2d0
[ 1294.982121]  ? find_held_lock+0xac/0xd0
[ 1294.985979]  __mutex_unlock_slowpath+0x8f/0x3f0
[ 1294.990540]  ? wait_for_completion+0x230/0x230
[ 1294.995002]  ? rwlock_bug.part.2+0x60/0x60
[ 1294.999197]  nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1295.005751]  ? page_mapping+0x98/0x110
[ 1295.009511]  migrate_vma+0xa74/0x1090
[ 1295.013186]  ? move_to_new_page+0x480/0x480
[ 1295.017400]  ? __kmalloc+0x153/0x300
[ 1295.021052]  ? nouveau_dmem_migrate_vma+0xd8/0x1e0 [nouveau]
[ 1295.026796]  nouveau_dmem_migrate_vma+0x157/0x1e0 [nouveau]
[ 1295.032466]  ? nouveau_dmem_init+0x490/0x490 [nouveau]
[ 1295.037612]  ? vmacache_find+0xc2/0x110
[ 1295.041537]  nouveau_svmm_bind+0x1b4/0x210 [nouveau]
[ 1295.046583]  ? nouveau_svm_fault+0x13e0/0x13e0 [nouveau]
[ 1295.051912]  drm_ioctl_kernel+0x14d/0x1a0
[ 1295.055930]  ? drm_setversion+0x330/0x330
[ 1295.059971]  drm_ioctl+0x308/0x530
[ 1295.063384]  ? drm_version+0x150/0x150
[ 1295.067153]  ? find_held_lock+0xac/0xd0
[ 1295.070996]  ? __pm_runtime_resume+0x3f/0xa0
[ 1295.075285]  ? mark_held_locks+0x29/0xa0
[ 1295.079230]  ? _raw_spin_unlock_irqrestore+0x3c/0x50
[ 1295.084232]  ? lockdep_hardirqs_on+0x17d/0x250
[ 1295.088768]  nouveau_drm_ioctl+0x9a/0x100 [nouveau]
[ 1295.093661]  do_vfs_ioctl+0x137/0x9a0
[ 1295.097341]  ? ioctl_preallocate+0x140/0x140
[ 1295.101623]  ? match_held_lock+0x1b/0x230
[ 1295.105646]  ? match_held_lock+0x1b/0x230
[ 1295.109660]  ? find_held_lock+0xac/0xd0
[ 1295.113512]  ? __do_page_fault+0x324/0x630
[ 1295.117617]  ? lock_downgrade+0x2d0/0x2d0
[ 1295.121648]  ? mark_held_locks+0x79/0xa0
[ 1295.125583]  ? handle_mm_fault+0x352/0x430
[ 1295.129687]  ksys_ioctl+0x60/0x90
[ 1295.133020]  ? mark_held_locks+0x29/0xa0
[ 1295.136964]  __x64_sys_ioctl+0x3d/0x50
[ 1295.140726]  do_syscall_64+0x68/0x250
[ 1295.144400]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1295.149465] RIP: 0033:0x7f1a3495809b
[ 1295.153053] Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48
[ 1295.171850] RSP: 002b:00007ffef7ed1358 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1295.179451] RAX: ffffffffffffffda RBX: 00007ffef7ed1628 RCX: 00007f1a3495809b
[ 1295.186601] RDX: 00007ffef7ed13b0 RSI: 0000000040406449 RDI: 0000000000000004
[ 1295.193759] RBP: 00007ffef7ed13b0 R08: 0000000000000000 R09: 000000000157e770
[ 1295.200917] R10: 000000000151c010 R11: 0000000000000246 R12: 0000000040406449
[ 1295.208083] R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000

Reacquire the lock before continuing to the next page.
Signed-off-by: NRalph Campbell <rcampbell@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d304654b
    • K
      drm/nouveau/hwmon: return EINVAL if the GPU is powered down for sensors reads · 68bf8b57
      由 Karol Herbst 提交于 
      fixes bogus values userspace gets from hwmon while the GPU is powered down
Signed-off-by: NKarol Herbst <kherbst@redhat.com>
Reviewed-by: NRhys Kidd <rhyskidd@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      68bf8b57
    • B
      drm/nouveau: fix bogus GPL-2 license header · b0f84a84
      由 Ben Skeggs 提交于 
      The bulk SPDX addition made all these files into GPL-2.0 licensed files.
However the remainder of the project is MIT-licensed, these files
were simply missing the boiler plate and got caught up in the global update.

Fixes: 96ac6d43 (treewide: Add SPDX license identifier - Kbuild)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      b0f84a84
    • I
      drm/nouveau: fix bogus GPL-2 license header · b7019ac5
      由 Ilia Mirkin 提交于 
      The bulk SPDX addition made all these files into GPL-2.0 licensed files.
However the remainder of the project is MIT-licensed, these files
(primarily header files) were simply missing the boiler plate and got
caught up in the global update.

Fixes: b2441318 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license)
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NKarol Herbst <kherbst@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      b7019ac5
    • L
      drm/nouveau/i2c: Enable i2c pads & busses during preinit · 7cb95eee
      由 Lyude Paul 提交于 
      It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:

commit 342406e4 ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")

We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs, as apparently said scripts can actually use the i2c
bus. Since these scripts are executed before initializing any
subdevices, we end up failing to acquire access to the i2c bus which has
left a number of cards with their fan controllers uninitialized. Luckily
this doesn't break hardware - it just means the fan gets stuck at 100%.

This also means that we've always been using our i2c busses before
initializing them during the init scripts for older GPUs, we just didn't
notice it until we started preventing them from being used until init.
It's pretty impressive this never caused us any issues before!

So, fix this by initializing our i2c pad and busses during subdev
pre-init. We skip initializing aux busses during pre-init, as those are
guaranteed to only ever be used by nouveau for DP aux transactions.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Tested-by: NMarc Meledandri <m.meledandri@gmail.com>
Fixes: 342406e4 ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      7cb95eee
    • B
      drm/nouveau/disp/tu102-: wire up scdc parameter setter · 3485b7b5
      由 Ben Skeggs 提交于 
      Regs seem valid here still, and tested on TU116.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      3485b7b5
    • B
      drm/nouveau/core: recognise TU116 chipset · 75dec321
      由 Ben Skeggs 提交于 
      Modesetting only, still waiting on ACR/GR firmware from NVIDIA for Turing
graphics/compute bring-up.

Each subsystem was compared with traces, along with various tests to check
that things generally work as they should, and appears compatible enough
with the current TU117 code to enable support.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      75dec321
    • B
      drm/nouveau/kms: disallow dual-link harder if hdmi connection detected · d1084184
      由 Ben Skeggs 提交于 
      The fallthrough cases (pre-Fermi) would accidentally allow dual-link pixel
clocks even where they shouldn't be.  This leads to a high resolution HDMI
displays, connected via a DVI->HDMI adapter, to fail on the original NV50.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d1084184
    • I
      drm/nouveau/disp/nv50-: fix center/aspect-corrected scaling · 533f4752
      由 Ilia Mirkin 提交于 
      Previously center scaling would get scaling applied to it (when it was
only supposed to center the image), and aspect-corrected scaling did not
always correctly pick whether to reduce width or height for a particular
combination of inputs/outputs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      533f4752
    • I
      drm/nouveau/disp/nv50-: force scaler for any non-default LVDS/eDP modes · f8d6211a
      由 Ilia Mirkin 提交于 
      Higher layers tend to add a lot of modes not actually in the EDID, such
as the standard DMT modes. Changing this would be extremely intrusive to
everyone, so just force the scaler more often. There are no practical
cases we're aware of where a LVDS/eDP panel has multiple resolutions
exposed, and i915 already does it this way.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      f8d6211a
    • T
      drm/nouveau/mcp89/mmu: Use mcp77_mmu_new instead of g84_mmu_new on MCP89. · bb2b4074
      由 Timo Wiren 提交于 
      Fix a crash or broken depth testing in all OpenGL applications that use the
depth buffer on MCP89 (GeForce 320M) seen on a MacBook Pro Late 2010.

The bug is tracked in https://bugs.freedesktop.org/show_bug.cgi?id=108500Signed-off-by: NTimo Wiren <timo.wiren@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      bb2b4074
    • M
      proc/sysctl: add shared variables for range check · eec4844f
      由 Matteo Croce 提交于 
      In the sysctl code the proc_dointvec_minmax() function is often used to
validate the user supplied value between an allowed range.  This
function uses the extra1 and extra2 members from struct ctl_table as
minimum and maximum allowed value.

On sysctl handler declaration, in every source file there are some
readonly variables containing just an integer which address is assigned
to the extra1 and extra2 members, so the sysctl range is enforced.

The special values 0, 1 and INT_MAX are very often used as range
boundary, leading duplication of variables like zero=0, one=1,
int_max=INT_MAX in different source files:

    $ git grep -E '\.extra[12].*&(zero|one|int_max)' |wc -l
    248

Add a const int array containing the most commonly used values, some
macros to refer more easily to the correct array member, and use them
instead of creating a local one for every object file.

This is the bloat-o-meter output comparing the old and new binary
compiled with the default Fedora config:

    # scripts/bloat-o-meter -d vmlinux.o.old vmlinux.o
    add/remove: 2/2 grow/shrink: 0/2 up/down: 24/-188 (-164)
    Data                                         old     new   delta
    sysctl_vals                                    -      12     +12
    __kstrtab_sysctl_vals                          -      12     +12
    max                                           14      10      -4
    int_max                                       16       -     -16
    one                                           68       -     -68
    zero                                         128      28    -100
    Total: Before=20583249, After=20583085, chg -0.00%

[mcroce@redhat.com: tipc: remove two unused variables]
  Link: http://lkml.kernel.org/r/20190530091952.4108-1-mcroce@redhat.com
[akpm@linux-foundation.org: fix net/ipv6/sysctl_net_ipv6.c]
[arnd@arndb.de: proc/sysctl: make firmware loader table conditional]
  Link: http://lkml.kernel.org/r/20190617130014.1713870-1-arnd@arndb.de
[akpm@linux-foundation.org: fix fs/eventpoll.c]
Link: http://lkml.kernel.org/r/20190430180111.10688-1-mcroce@redhat.comSigned-off-by: NMatteo Croce <mcroce@redhat.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NAaron Tomlin <atomlin@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eec4844f
    • H
      drm/amd/display: init res_pool dccg_ref, dchub_ref with xtalin_freq · 41a5a2a8
      由 hersen wu 提交于 
      [WHY] dc sw clock implementation of navi10 and raven are not exact the
same. dcccg, dchub reference clock initialization is done after dc calls
vbios dispcontroller_init table. for raven family, before
dispcontroller_init is called by dc, the ref clk values are referred
by sw clock implementation and program asic register using wrong
values. this causes dchub pstate error. This need provide valid ref
clk values. for navi10, since dispcontroller_init is not called,
dchubbub_global_timer_enable = 0, hubbub2_get_dchub_ref_freq will
hit aeert. this need remove hubbub2_get_dchub_ref_freq from this
location and move to dcn20_init_hw.

[HOW] for all asic, initialize dccg, dchub ref clk with data from
vbios firmware table by default. for raven asic family, use these data
from vbios, for asic which support sw dccg component, like navi10,
read ref clk by sw dccg functions and update the ref clk.
Signed-off-by: Nhersen wu <hersenxs.wu@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      41a5a2a8
    • A
      drm/amdgpu/pm: remove check for pp funcs in freq sysfs handlers · 8a5b5d42
      由 Alex Deucher 提交于 
      The dpm sensor function already does this for us.  This fixes
the freq*_input files with the new SMU implementation.
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      8a5b5d42
    • N
      drm/amd/display: Force uclk to max for every state · 02316e96
      由 Nicholas Kazlauskas 提交于 
      Workaround for now to avoid underflow.

The uclk switch time should really be bumped up to 404, but doing so
would expose p-state hang issues for higher bandwidth display
configurations.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      02316e96
  5. 18 7月, 2019 10 次提交
  7. 17 7月, 2019 10 次提交