aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2022-01-24drm/i915: Clean up pre-skl primary plane registersVille Syrjälä6-116/+128
Use REG_BIT() & co. for the pre-skl primary plane registers. Also give everything a consistent namespace. v2: s/DSP/DISP/ to avoid confusion (José) Use DISP_WIDTH rather than DISP_POS_X for DSPSIZE (José) Deal with gvt Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121113036.23240-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2022-01-23Merge tag 'bitmap-5.17-rc1' of git://github.com/norov/linuxLinus Torvalds1-2/+2
Pull bitmap updates from Yury Norov: - introduce for_each_set_bitrange() - use find_first_*_bit() instead of find_next_*_bit() where possible - unify for_each_bit() macros * tag 'bitmap-5.17-rc1' of git://github.com/norov/linux: vsprintf: rework bitmap_list_string lib: bitmap: add performance test for bitmap_print_to_pagebuf bitmap: unify find_bit operations mm/percpu: micro-optimize pcpu_is_populated() Replace for_each_*_bit_from() with for_each_*_bit() where appropriate find: micro-optimize for_each_{set,clear}_bit() include/linux: move for_each_bit() macros from bitops.h to find.h cpumask: replace cpumask_next_* with cpumask_first_* where appropriate tools: sync tools/bitmap with mother linux all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate cpumask: use find_first_and_bit() lib: add find_first_and_bit() arch: remove GENERIC_FIND_FIRST_BIT entirely include: move find.h from asm_generic to linux bitops: move find_bit_*_le functions from le.h to find.h bitops: protect find_first_{,zero}_bit properly
2022-01-22lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()Vlastimil Babka4-0/+17
Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated from memblock, even if stack depot ends up not actually used. The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit. This is fine for use-cases such as KASAN which is also a config option and has overhead on its own. But it's an issue for functionality that has to be actually enabled on boot (page_owner) or depends on hardware (GPU drivers) and thus the memory might be wasted. This was raised as an issue [1] when attempting to add stackdepot support for SLUB's debug object tracking functionality. It's common to build kernels with CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or create only specific kmem caches with debugging for testing purposes. It would thus be more efficient if stackdepot's table was allocated only when actually going to be used. This patch thus makes the allocation (and whole stack_depot_init() call) optional: - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN select this flag. - Other users have to call stack_depot_init() as part of their own init when it's determined that stack depot will actually be used. This may depend on both config and runtime conditions. Convert current users which are page_owner and several in the DRM subsystem. Same will be done for SLUB later. - Because the init might now be called after the boot-time memblock allocation has given all memory to the buddy allocator, change stack_depot_init() to allocate stack_table with kvmalloc() when memblock is no longer available. Also handle allocation failure by disabling stackdepot (could have theoretically happened even with memblock allocation previously), and don't unnecessarily align the memblock allocation to its own size anymore. [1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/ Link: https://lkml.kernel.org/r/20211013073005.11351-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Marco Elver <elver@google.com> # stackdepot Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> From: Colin Ian King <colin.king@canonical.com> Subject: lib/stackdepot: fix spelling mistake and grammar in pr_err message There is a spelling mistake of the work allocation so fix this and re-phrase the message to make it easier to read. Link: https://lkml.kernel.org/r/20211015104159.11282-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Vlastimil Babka <vbabka@suse.cz> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup On FLATMEM, we call page_ext_init_flatmem_late() just before kmem_cache_init() which means stack_depot_init() (called by page owner init) will not recognize properly it should use kvmalloc() and not memblock_alloc(). memblock_alloc() will also not issue a warning and return a block memory that can be invalid and cause kernel page fault when saving stacks, as reported by the kernel test robot [1]. Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() so that slab_is_available() is true during stack_depot_init(). SPARSEMEM doesn't have this issue, as it doesn't do page_ext_init_flatmem_late(), but a different page_ext_init() even later in the boot process. Thanks to Mike Rapoport for pointing out the FLATMEM init ordering issue. While at it, also actually resolve a checkpatch warning in stack_depot_init() from DRM CI, which was supposed to be in the original patch already. [1] https://lore.kernel.org/all/20211014085450.GC18719@xsang-OptiPlex-9020/ Link: https://lkml.kernel.org/r/6abd9213-19a9-6d58-cedc-2414386d2d81@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: kernel test robot <oliver.sang@intel.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup3 Due to cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") landing recently to -next adding a new stack depot user in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriate call to stack_depot_init() there as well. Link: https://lkml.kernel.org/r/2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup4 Due to 4e66934eaadc ("lib: add reference counting tracking infrastructure") landing recently to net-next adding a new stack depot user in lib/ref_tracker.c we need to add an appropriate call to stack_depot_init() there as well. Link: https://lkml.kernel.org/r/45c1b738-1a2f-5b5f-2f6d-86fab206d01c@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Eric Dumazet <edumazet@google.com> Cc: Jiri Slab <jirislaby@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-22i915: simplify subdirectory registration with register_sysctl()Luis Chamberlain1-21/+1
There is no need to user boiler plate code to specify a set of base directories we're going to stuff sysctls under. Simplify this by using register_sysctl() and specifying the directory path directly. // pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH @c1@ expression E1; identifier subdir, sysctls; @@ static struct ctl_table subdir[] = { { .procname = E1, .maxlen = 0, .mode = 0555, .child = sysctls, }, { } }; @c2@ identifier c1.subdir; expression E2; identifier base; @@ static struct ctl_table base[] = { { .procname = E2, .maxlen = 0, .mode = 0555, .child = subdir, }, { } }; @c3@ identifier c2.base; identifier header; @@ header = register_sysctl_table(base); @r1 depends on c1 && c2 && c3@ expression c1.E1; identifier c1.subdir, c1.sysctls; @@ -static struct ctl_table subdir[] = { - { - .procname = E1, - .maxlen = 0, - .mode = 0555, - .child = sysctls, - }, - { } -}; @r2 depends on c1 && c2 && c3@ identifier c1.subdir; expression c2.E2; identifier c2.base; @@ -static struct ctl_table base[] = { - { - .procname = E2, - .maxlen = 0, - .mode = 0555, - .child = subdir, - }, - { } -}; @initialize:python@ @@ def make_my_fresh_expression(s1, s2): return '"' + s1.strip('"') + "/" + s2.strip('"') + '"' @r3 depends on c1 && c2 && c3@ expression c1.E1; identifier c1.sysctls; expression c2.E2; identifier c2.base; identifier c3.header; fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) }; @@ header = -register_sysctl_table(base); +register_sysctl(E3, sysctls); Generated-by: Coccinelle SmPL Link: https://lkml.kernel.org/r/20211123202422.819032-3-mcgrof@kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Amir Goldstein <amir73il@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Antti Palosaari <crope@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: David Airlie <airlied@linux.ie> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Iurii Zaikin <yzaikin@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Joel Becker <jlbec@evilplan.org> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Julia Lawall <julia.lawall@inria.fr> Cc: Kees Cook <keescook@chromium.org> Cc: Lukas Middendorf <kernel@tuxforce.de> Cc: Mark Fasheh <mark@fasheh.com> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Phillip Potter <phil@philpotter.co.uk> Cc: Qing Wang <wangqing@vivo.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Stephen Kitt <steve@sk2.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Xiaoming Ni <nixiaoming@huawei.com> Cc: Douglas Gilbert <dgilbert@interlog.com> Cc: James E.J. Bottomley <jejb@linux.ibm.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-21drm/i915: Lock timeline mutex directly in error path of eb_pin_timelineMatthew Brost1-2/+7
Don't use the interruptable version of the timeline mutex lock in the error path of eb_pin_timeline as the cleanup must always happen. v2: (John Harrison) - Don't check for interrupt during mutex lock v3: (Tvrtko) - A comment explaining why lock helper isn't used Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220111163929.14017-1-matthew.brost@intel.com
2022-01-21drm/i915/guc: Flush G2H handler during a GT resetMatthew Brost1-17/+1
Now that the error capture is fully decoupled from fence signalling (request retirement to free memory, which in turn depends on resets) we can safely flush the G2H handler during a GT reset. This eliminates corner cases where GuC generated G2H (e.g. engine resets) race with a GT reset. v2: (John Harrison) - Fix typo in commit message (s/is/in) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121043118.24886-4-matthew.brost@intel.com
2022-01-21drm/i915/guc: Add work queue to trigger a GT resetMatthew Brost2-4/+42
The G2H handler needs to be flushed during a GT reset but a G2H indicating engine reset failure can trigger a GT reset. Add a worker to trigger the GT rest when an engine reset failure is received to break this circular dependency. v2: (John Harrison) - Store engine reset mask - Fix typo in commit message v3: (John Harrison) - Fix another typo in commit message - s/reset_*/reset_fail_*/ Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121043118.24886-3-matthew.brost@intel.com
2022-01-21drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAILMatthew Brost1-1/+1
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than GFP_KERNEL to fully decouple the error capture from fence signalling. v2: (John Harrison) - Fix typo in commit message (s/do/to) Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121043118.24886-2-matthew.brost@intel.com
2022-01-21drm/amdgpu: fix the page fault caused by uninitialized variablesXiaojian Du1-3/+3
This patch will fix the page fault caused by uninitialized variables. Error Log: ...... [ 130.246323] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 131.963112] [drm] PCIE GART of 512M enabled (table at 0x0000008000000000). [ 131.963130] BUG: unable to handle page fault for address: 000000000002db80 [ 131.963181] #PF: supervisor write access in kernel mode [ 131.963210] #PF: error_code(0x0002) - not-present page [ 131.963233] PGD 0 P4D 0 [ 131.963253] Oops: 0002 [#1] SMP NOPTI [ 131.963273] CPU: 3 PID: 1411 Comm: modprobe Not tainted 5.13.0+ #1 [ 131.963338] RIP: 0010:osq_lock+0x4d/0x120 [ 131.963381] Code: 10 00 00 00 00 48 c7 02 00 00 00 00 89 42 14 87 07 85 c0 0f 84 d0 00 00 00 83 e8 01 48 98 48 03 0c c5 00 d9 ea 9c 48 89 4a 08 <48> 89 11 44 8b 42 10 45 85 c0 0f 85 af 00 00 00 55 48 89 fe 65 4c [ 131.963460] RSP: 0018:ffffa40481717768 EFLAGS: 00010202 [ 131.963483] RAX: fffffffffffffffe RBX: ffffa40481717920 RCX: 000000000002db80 [ 131.963520] RDX: ffff9256fecedb80 RSI: ffff9256cbed2e80 RDI: ffffa40481717ac4 [ 131.963547] RBP: ffffa40481717808 R08: ffffa40481717920 R09: 00000000ffffffff [ 131.963582] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 [ 131.963609] R13: ffffa40481717ac4 R14: ffffa40481717ab8 R15: ffff9256c9480000 [ 131.963646] FS: 00007f23d9b9c540(0000) GS:ffff9256fecc0000(0000) knlGS:0000000000000000 [ 131.963687] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 131.963721] CR2: 000000000002db80 CR3: 0000000008444000 CR4: 00000000000506e0 [ 131.963758] Call Trace: [ 131.963772] ? __ww_mutex_lock.isra.0+0x3a2/0x760 [ 131.963810] ? prb_read_valid+0x1c/0x20 [ 131.963830] ? console_unlock+0x2fe/0x4f0 [ 131.963849] __ww_mutex_lock_interruptible_slowpath+0x16/0x20 [ 131.963882] ww_mutex_lock_interruptible+0x83/0x90 [ 131.963908] amdgpu_bo_create_reserved+0xf0/0x1e0 [amdgpu] [ 131.964237] amdgpu_bo_create_kernel+0x17/0x80 [amdgpu] [ 131.964509] amdgpu_gmc_vram_checking+0x41/0xf0 [amdgpu] [ 131.964807] gmc_v10_0_hw_init+0x105/0x120 [amdgpu] [ 131.965108] amdgpu_device_init.cold+0x1aa4/0x1e3e [amdgpu] ...... Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-21drm/amdgpu: fix convert bad page retiremtStanley.Yang1-12/+14
Pmfw read ecc info registers and store values in eccinfo_table in the following order umc0 ch_inst 0, 1, 2 ... 7 umc1 ch_inst 0, 1, 2 ... 7 ... umc3 ch_inst 0, 1, 2 ... 7 Driver should convert eccinfo_table_idx to channel_index according to channel_idx_tbl. Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-21drm/i915/mst: only ack the ESI we actually handledJani Nikula1-8/+12
Seems odd that we clear all event status indicators if we've only handled some. Only clear the ones we've handled. v2: ack DOWN_REP and UP_REQ only if they were set in esi (Ville) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120110102.3116218-1-jani.nikula@intel.com
2022-01-21drm/i915/mst: ack sink irq ESI for link status changesJani Nikula1-0/+1
Only specific event status indicators caused the link status to be acked. Be sure to ack the link status change event. Arguably we should track which bits to actually clear in ESI instead of the wholesale approach. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-6-jani.nikula@intel.com
2022-01-21drm/i915/mst: read link status only when requested by sink in ESIJani Nikula1-23/+18
The link service irq vector in DPCD 0x2005 contains the link status changed bit to indicate the status should be checked. Only read and check the link status when requested by the sink. This also reduces the confusion around the buffer size for the combined ESI and link status. Alas, we still need to take into account that all link status helpers expect a buffer of DP_LINK_STATUS_SIZE (6) while the link status in ESI only has 4 bytes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-5-jani.nikula@intel.com
2022-01-21drm/i915/mst: abstract handling of link status in DP MSTJani Nikula1-5/+18
We'll want to expand on this, so abstract it to a separate function first. Improve debug logging while at it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-4-jani.nikula@intel.com
2022-01-21drm/i915/mst: debug log 4 bytes of ESI right after readingJani Nikula1-2/+2
For whatever reason, the ESI link service irq vector was missing from the debug output. Add the missing byte, clean up the debug message, and do the logging right after reading the data. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-3-jani.nikula@intel.com
2022-01-21drm/i915/mst: abstract intel_dp_ack_sink_irq_esi()Jani Nikula1-10/+15
Smaller functions make the thing easier to read. Debug log failures to ack. Note: Looks like we have the retry loop simply because of hysterical raisins, dating back to the original DP MST enabling. Keep it, though I have no idea why we have it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-2-jani.nikula@intel.com
2022-01-21drm/i915/mst: fix intel_dp_mst_hpd_irq() indentationJani Nikula1-5/+5
Remove extra indentation. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112110319.1172110-1-jani.nikula@intel.com
2022-01-21drm/i915: split out i915_reg_read_ioctl() to i915_ioctl.[ch]Jani Nikula6-74/+111
Add new files i915_ioctl.[ch] to hold small ioctls that are out of place everywhere else, and not big enough to warrant a file of their own. For starters, it's just for i915_reg_read_ioctl() that's a bit high level for a low level implementation that intel_uncore.[ch] is. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120113346.3214745-1-jani.nikula@intel.com
2022-01-21Merge tag 'drm-next-2022-01-21' of git://anongit.freedesktop.org/drm/drmLinus Torvalds18-146/+108
Pull drm fixes from Dave Airlie: "Thanks to Daniel for taking care of things while I was out, just a set of merge window fixes that came in this week, two i915 display fixes and a bunch of misc amdgpu, along with a radeon regression fix. amdgpu: - SR-IOV fix - VCN harvest fix - Suspend/resume fixes - Tahiti fix - Enable GPU recovery on yellow carp radeon: - Fix error handling regression in radeon_driver_open_kms i915: - Update EHL display voltage swing table - Fix programming the ADL-P display TC voltage swing" * tag 'drm-next-2022-01-21' of git://anongit.freedesktop.org/drm/drm: drm/radeon: fix error handling in radeon_driver_open_kms drm/amd/amdgpu: fixing read wrong pf2vf data in SRIOV drm/amdgpu: apply vcn harvest quirk drm/i915/display/adlp: Implement new step in the TC voltage swing prog sequence drm/i915/display/ehl: Update voltage swing table drm/amd/display: Revert W/A for hard hangs on DCN20/DCN21 drm/amdgpu: drop flags check for CHIP_IP_DISCOVERY drm/amdgpu: Fix rejecting Tahiti GPUs drm/amdgpu: don't do resets on APUs which don't support it drm/amdgpu: invert the logic in amdgpu_device_should_recover_gpu() drm/amdgpu: Enable recovery on yellow carp
2022-01-21Merge tag 'amd-drm-fixes-5.17-2022-01-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie15-139/+75
amd-drm-fixes-5.17-2022-01-19: amdgpu: - SR-IOV fix - VCN harvest fix - Suspend/resume fixes - Tahiti fix - Enable GPU recovery on yellow carp radeon: - Fix error handling regression in radeon_driver_open_kms Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120013547.5649-1-alexander.deucher@amd.com
2022-01-21Merge tag 'drm-intel-next-fixes-2022-01-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie3-7/+33
- Latest updates for the EHL display voltage swing table (José Roberto de Souza) - Additional step is required when programming the ADL-P display TC voltage swing (José Roberto de Souza) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yek1zdsnRPiBVvFF@tursulin-mobl2
2022-01-20drm/i915/dmc: Eliminate remnant GEN<n> referencesMadhumitha Tolakanahalli Pradeep1-7/+7
Replace GEN<n> with DISPLAY_VER<n>, in line with the naming convention followed in the i915 driver code. Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217034141.198033-1-madhumitha.tolakanahalli.pradeep@intel.com
2022-01-20drm/i915: Clean up vlv/chv sprite plane registersVille Syrjälä2-42/+70
Use REG_BIT() & co. to polish the vlv/chv sprite plane registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2022-01-19drm/amd/display: change FIFO reset condition to embedded display onlyZhan Liu1-1/+1
[Why] FIFO reset is only necessary for fast boot sequence, where otg is disabled and dig fe is enabled when changing dispclk. Fast boot is only enabled on embedded displays. [How] Change FIFO reset condition to "embedded display only". Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amd/display: Correct MPC split policy for DCN301Zhan Liu1-1/+1
[Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdkfd: enable heavy-weight TLB flush on ArcturusEric Huang2-8/+8
SDMA FW fixes the hang issue for adding heavy-weight TLB flush on Arcturus, so we can enable it. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: fix broken debug sdma vram access functionJonathan Kim1-7/+8
Debug VRAM access through SDMA has several broken parts resulting in silent MMIO fallback. BO kernel creation takes the location of the cpu addr pointer, not the pointer itself for address kmap. drm_dev_enter return true on success so change access check. The source BO is reserved but not pinned so find the address using the cursor offset relative to its memory domain start. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove gart.ready flagChristian König11-137/+52
That's just a leftover from old radeon days and was preventing CS and GART bindings before the hardware was initialized. But nowdays that is perfectly valid. The only thing we need to warn about are GART binding before the table is even allocated. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove unused variable warningStanley.Yang2-29/+0
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove unused variablemziya1-4/+0
Remove set but unused variable. warning: variable 'umc_reg_offset' set but not used Signed-off-by: mziya <Mohammadzafar.ziya@amd.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: Remove repeated callsyipechai1-3/+1
Remove repeated calls. Signed-off-by: yipechai <YiPeng.Chai@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: modify a pair of functions for the pcie port wreg/rregXiaojian Du3-32/+39
This patch will modify a pair of functions for pcie port wreg/rreg. AMD GPU have had an independent NBIO block from SOC15 arch. If the dirver wants to read/write the address space of the pcie devices, it has to go through the NBIO block. This patch will move the pcie port wreg/rreg functions to "amdgpu_device.c", so that to reuse the functions on the future GPU ASICs. Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: add vram check function for GMCXiaojian Du7-5/+74
This patch will add vram check function for GMC block. It will write pattern data to the vram and then read back from the vram, so that to verify the work status of vram. This patch will cover gmc v6/7/8/9/10. Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-20drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI portsVille Syrjälä1-0/+8
Lots of machines these days seem to have a crappy type1 DP dual mode adaptor chip slapped onto the motherboard. Based on the DP dual mode spec we currently limit those to 165MHz max TMDS clock. Windows OTOH ignores DP dual mode adaptors when the VBT indicates that the port is not actually DP++, so we can perhaps assume that the vendors did intend that the 165MHz clock limit doesn't apply here. Though it would be much nicer if they actually declared an explicit limit through VBT, but that doesn't seem to be happening either. So in order to match Windows behaviour let's ignore the DP dual mode adaptor's TMDS clock limit for ports that don't look like DP++ in VBT. Unfortunately many older VBTs misdelcare their DP++ ports as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB Lenovo ThinkPad X220). So we can't really do this universally without risking black screens. I suppose a sensible cutoff is HSW+ since that's when 4k became a thing and one might assume that the machines have been tested to work with higher TMDS clock rates. v2: s/IS_BROADWELL/IS_HASWELL/ Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222161738.12478-1-ville.syrjala@linux.intel.com
2022-01-20drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITSVille Syrjälä2-15/+6
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just a DP+HDMI check. The rest of the bits shouldn't really matter anyway. The slight change in behaviour here is that now we do look at the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via intel_bios_encoder_supports_hdmi()) when we previously ignored it. The one platform we know that has problems with that bit is VLV. But IIRC the problem was always that buggy VBTs basically never set that bit. So that should be OK since all it would do is make all DVI ports look like HDMI ports instead. Also can't imagine there are many VLV machines with actual DVI ports in existence. We still keep the rest of the dvo_port/aux_ch checks as we can't trust that DP+HDMI device type equals DP++ due to buggy VBTs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-20drm/i915/bios: Throw out the !has_ddi_port_info() codepathsVille Syrjälä2-105/+9
Now that we parse the DDI port info from the VBT on all g4x+ platforms we can throw out all the old codepaths in intel_bios_is_port_present(), intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None of these should be called on pre-g4x platforms. For good measure throw in a WARN into intel_bios_is_port_present() should someone get the urge to call it on older platforms. The other two functions are specific to HDMI and DP so should not need any protection as those encoder types don't even exist on older platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-20drm/i915/bios: Use i915->vbt.ports[] for all g4x+Ville Syrjälä1-4/+1
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need to drop the version check as some elk/ctg machines may have VBTs older than that. The oldest I know is an elk with version 142. But the child device stuff has had the correct size since at least version 125 (observed on my sdg), so from that angle this should be totally safe. This does couple of things: - Start using the aux_ch/ddc_pin from VBT instead of just the hardcoded defaults. Hopefully there are no VBTs with entirely bogus information here. - Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode(). Should be fine as the logic doesn't actually change. - Start using i915->vbt.ports[] for intel_bios_is_port_edp(). The old codepath only looks at the DP DVO ports, the new codepath looks at both DP and HDMI DVO ports. In principle that should not matter. We also stop looking at some of the other device type bits (eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that it sets up totally conflicting device type bits (eg. LVDS+eDP at the same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't be hard to re-introduce that into eg. sanitize_device_type() if needed). Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each) with both DP and HDMI (DP++). Everything still worked as it should. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/i915/bios: Use i915->vbt.ports[] on CHVVille Syrjälä1-2/+2
CHV is currently straddling the divide by using parse_ddi_ports() stuff for aux_ch/ddc_pin but going through all old codepaths for the rest (intel_bios_is_port_present(), intel_bios_is_port_edp(), intel_bios_is_port_dp_dual_mode()). Let's switch over full and use i915->vbt.ports[] for the rest of the stuff. dvo_port_to_port() doesn't know about DSI so we won't get into any kind of "is port B HDMI or DSI or both?" conundrum, which could otherwise happen on VLV/CHV due to DSI ports living in a separate world from the other digital ports. Including Jani's detailed analysis here for posterity: "We stop checking for port A for CHV in intel_bios_is_port_present(), but it's a warn and I don't recall any bug reports, so probably fine. We could add a check in parse_ddi_port(), but meh. Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a warn. The eDP check in intel_bios_is_port_edp() becomes slightly more relaxed. Both the old and new check require these to be set: - DEVICE_TYPE_DISPLAYPORT_OUTPUT - DEVICE_TYPE_INTERNAL_CONNECTOR. The old code also required these to be unset: - DEVICE_TYPE_MIPI_OUTPUT - DEVICE_TYPE_COMPOSITE_OUTPUT - DEVICE_TYPE_DUAL_CHANNEL - DEVICE_TYPE_LVDS_SIGNALING - DEVICE_TYPE_TMDS_DVI_SIGNALING - DEVICE_TYPE_VIDEO_SIGNALING - DEVICE_TYPE_ANALOG_OUTPUT It's possible we've added these just as a sanity check for broken VBTs more than anything. I guess I'd see if actual problems arise. Bottom line, I think the functional changes matter only for VBTs with bogus data." I agree that it should work assuming the VBT isn't totally insane. Modern windows drivers also don't seem to check any of those additional device type bits, which may or may not matter for older devices (no idea what some old driver versions are checking). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/i915/bios: Introduce has_ddi_port_info()Ville Syrjälä1-3/+8
Pull the "do we want to use i915->vbt.ports[]?" check into a central place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/malidp: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-11-javierm@redhat.com
2022-01-19drm/arm/hdlcd: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-10-javierm@redhat.com
2022-01-19drm/komeda: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-9-javierm@redhat.com
2022-01-19drm/imx/dcss: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-8-javierm@redhat.com
2022-01-19drm/hisilicon/hibmc: Replace module initialization with DRM helpersThomas Zimmermann1-1/+2
Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-6-javierm@redhat.com
2022-01-19drm/cirrus: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-15/+2
Remove custom cirrus_init() and cirrus_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-5-javierm@redhat.com
2022-01-19drm/bochs: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-18/+2
Remove custom bochs_init() and bochs_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-4-javierm@redhat.com
2022-01-19drm/ast: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-16/+2
Remove custom ast_init() and ast_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-3-javierm@redhat.com
2022-01-19drm/i915: Remove zombie async flip vt-d w/aVille Syrjälä1-12/+0
This async flip vt-d w/a was moved to a different place in commit 7d396cacaea6 ("drm/i195: Make the async flip VT-d workaround dynamic") but the drm-intel-fixes cherry-pick commit b2d73debfdc1 ("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected the original code as well. So now we have this w/a in two places. Remove the resurrected zombie code. Not done as a revert to hopefully prevent any kind of automagic stable backport. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211208150050.17230-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayerRaymond Jay Golo1-0/+12
The 1Netbook OneXPlayer uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Raymond Jay Golo <rjgolo@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjgolo@gmail.com
2022-01-19drm/selftests/test-drm_dp_mst_helper: Fix memory leak in sideband_msg_req_encode_decodeJosé Expósito1-1/+3
Avoid leaking the "out" variable if it is not possible to allocate the "txmsg" variable. Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move 'sideband_msg_req_encode_decode' onto the heap") Addresses-Coverity-ID: 1475685 ("Resource leak") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220108165812.46797-1-jose.exposito89@gmail.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.