summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau
AgeCommit message (Collapse)AuthorFilesLines
2020-11-30drm/prime: split array import functions v4Christian König1-3/+2
Mapping the imported pages of a DMA-buf into an userspace process doesn't work as expected. But we have reoccurring requests on this approach, so split the functions for this and document that dma_buf_mmap() needs to be used instead. v2: split it into two functions v3: rebased on latest changes v4: update commit message a bit Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/403838/
2020-11-30drm/nouveau: stop using pages with drm_prime_sg_to_page_addr_arrays v2Christian König2-4/+4
This is deprecated, also drop the comment about faults. v2: also use ttm_sg_tt_init to avoid allocating the page array. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/403835/
2020-11-27Merge tag 'drm-misc-fixes-2020-11-26' of ↵Dave Airlie1-3/+5
ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes A bunch of fixes for vc4 fixing some coexistence issue between wifi and HDMI, unsupported modes, and vblank timeouts, a fix for ast to reload the gamma LUT after changing the plane format and a double-free fix for nouveau Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201126085450.r3i7wvj7pizsa4l6@gilmour
2020-11-27Merge tag 'drm-misc-next-2020-11-18' of ↵Dave Airlie1-4/+5
ssh://git.freedesktop.org/git/drm/drm-misc into drm-next drm-misc-next for 5.11: UAPI Changes: * media: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA format Cross-subsystem Changes: * console: Remove unused functions; Store characters-per-font in font- descriptor structure instead of hard-coding * DT: Add vendor prefix for ShenZhen Asia Better Technology Ltd. (ABT) Core Changes: * Fix build warnings * Update debug logging to new interfaces, plus fixes * Add error messages for ioctls; * Fix kernel docs * doc: Fix kernel docs * fbcon: Remove accelerated scrolling * selftests: Fix build warnings * ttm: Fix missing NULL check in new page pool; Fix build warnings * video: Fix kernel docs Driver Changes: * armada: Fix build warnings * atmel-hlcdc: Fix build warnings * exynos: Fix build warnings * gma500: Remove 2d framebuffer acceleration * lima: Fix build warnings; Cleanups * mediatek: Fix build warnings * meson: Module removal fixes; Fix build warnings * nouveau: Fix build warnings * omap: Fix return values * panel: Fix build warnings; Add support and DT bindings for OnePlus 6/T; Add support and DT bindings for ABT Y030XX067A * panel/s6e63m0: Add/improve SPi reading/writing; Support 3WIRE protocol; Set connector display info; Add more comments * panfrost: Move GPU reset into separate worker, avoid race conditions * pl111: Fix build warnings * qxl: Cleanup fbcon acceleration * rockchip: Fix build warnings * savage: Fix build warnings * sti: Fix build warnings * udl: Fix missing error code in udl_handle_damage() * v3d: Fix build warnings * vc4: Fix build warnings * via: Fix build warnings * virtio: Make dma-buf ops static Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201118123221.GA19755@linux-uq9g
2020-11-26drm/nouveau: make sure ret is initialized in nouveau_ttm_io_mem_reserveChristian König1-1/+1
This wasn't initialized for pre NV50 hardware. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-and-Tested-by: Mark Hounschell <markh@compro.net> Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/series/84298/
2020-11-26drm/nouveau: fix relocations applying logic and a double-freeMatti Hamalainen1-3/+5
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included a logic-bug which results in the relocations not actually getting applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is never reached. This causes a regression with graphical corruption, triggered when relocations need to be done (for example after a suspend/resume cycle.) Fix by setting *apply_relocs value only if there were more than 0 relocations. Additionally, the never reached code had a leftover u_free() call, which, after fixing the logic, now got called and resulted in a double-free. Fix by removing one u_free(), moving the other and adding check for errors. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matti Hamalainen <ccr@tnsp.org> Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") References: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201120152338.1203257-1-ccr@tnsp.org
2020-11-20drm: Pass the full state to connectors atomic functionsMaxime Ripard1-1/+4
The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Now that the CRTCs have been converted, let's move forward with the connectors to provide a consistent interface. The conversion was done using the coccinelle script below, and built tested on all the drivers. @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... struct drm_encoder* (*atomic_best_encoder)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... void (*atomic_commit)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier f; @@ f(..., struct drm_atomic_state *state, ...) { <+... - FUNCS->atomic_commit(connector, connector_state); + FUNCS->atomic_commit(connector, state); ...+> } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier var, f; @@ f(struct drm_atomic_state *state, ...) { <+... - var = FUNCS->atomic_best_encoder(connector, connector_state); + var = FUNCS->atomic_best_encoder(connector, state); ...+> } @ connector_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_connector_helper_funcs helpers = { ..., .atomic_best_encoder = func, ..., }; | static struct drm_connector_helper_funcs helpers = { ..., .atomic_commit = func, ..., }; ) @@ identifier connector_atomic_func.func; identifier connector; symbol state; @@ func(struct drm_connector *connector, - struct drm_connector_state *state + struct drm_connector_state *connector_state ) { ... - state + connector_state ... } @ ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { ... when != connector_state } @ adds_state depends on connector_atomic_func && !ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { + struct drm_connector_state *connector_state = drm_atomic_get_new_connector_state(state, connector); ... } @ depends on connector_atomic_func @ identifier connector_atomic_func.func; identifier connector_state; identifier connector; @@ func(struct drm_connector *connector, - struct drm_connector_state *connector_state + struct drm_atomic_state *state ) { ... } @ include depends on adds_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118094758.506730-1-maxime@cerno.tech
2020-11-17drm/nouveau/nvkm/core/firmware: Fix formatting, provide missing param ↵Lee Jones1-4/+5
description ... and demote non-conformant kernel-doc header. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter or member 'subdev' not described in 'nvkm_firmware_get' drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter or member 'fwname' not described in 'nvkm_firmware_get' drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter or member 'ver' not described in 'nvkm_firmware_get' drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter or member 'fw' not described in 'nvkm_firmware_get' drivers/gpu/drm/nouveau/nvkm/core/firmware.c:106: warning: Function parameter or member 'fw' not described in 'nvkm_firmware_put' Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-22-lee.jones@linaro.org
2020-11-16Merge branch 'linux-5.11' of git://github.com/skeggsb/linux into drm-nextDave Airlie1-5/+1
-next fix for type stuff. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5vuM54oU1Yp8sX5ZVmJAv+-oQRQj-AeaKFb3qs1EtP-g@mail.gmail.com
2020-11-14drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50Ben Skeggs1-2/+1
Pre-NV50 chipsets don't currently use the MMU subsystem that later chipsets use, and type_vram is negative here, leading to an OOB memory access. This was previously guarded by a chipset check, restore that. Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5839172f0980 ("drm/nouveau: explicitly specify caching to use") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2020-11-14drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhereLyude Paul1-15/+14
It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-11-14drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50Ben Skeggs1-2/+1
Pre-NV50 chipsets don't currently use the MMU subsystem that later chipsets use, and type_vram is negative here, leading to an OOB memory access. This was previously guarded by a chipset check, restore that. Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5839172f0980 ("drm/nouveau: explicitly specify caching to use") Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-11-14drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depthAlexander Kapshuk1-5/+9
This oops manifests itself on the following hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] (rev a1) Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x0000) - not-present page Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0 Oct 09 14:17:46 lp-sasha kernel: Oops: 0000 [#1] SMP PTI Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not tainted 5.9.0-rc8-next-20201009 #38 Oct 09 14:17:46 lp-sasha kernel: Hardware name: Hewlett-Packard Compaq Presario CQ61 Notebook PC/306A, BIOS F.03 03/23/2009 Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 Oct 09 14:17:46 lp-sasha kernel: Call Trace: Oct 09 14:17:46 lp-sasha kernel: nouveau_connector_get_modes+0x1e6/0x240 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? kfree+0xb9/0x240 Oct 09 14:17:46 lp-sasha kernel: ? drm_connector_list_iter_next+0x7c/0xa0 Oct 09 14:17:46 lp-sasha kernel: drm_helper_probe_single_connector_modes+0x1ba/0x7c0 Oct 09 14:17:46 lp-sasha kernel: drm_client_modeset_probe+0x27e/0x1360 Oct 09 14:17:46 lp-sasha kernel: ? nvif_object_sclass_put+0xc/0x20 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? nouveau_cli_init+0x3cc/0x440 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? ktime_get_mono_fast_ns+0x49/0xa0 Oct 09 14:17:46 lp-sasha kernel: ? nouveau_drm_open+0x4e/0x180 [nouveau] Oct 09 14:17:46 lp-sasha kernel: __drm_fb_helper_initial_config_and_unlock+0x3f/0x4a0 Oct 09 14:17:46 lp-sasha kernel: ? drm_file_alloc+0x18f/0x260 Oct 09 14:17:46 lp-sasha kernel: ? mutex_lock+0x9/0x40 Oct 09 14:17:46 lp-sasha kernel: ? drm_client_init+0x110/0x160 Oct 09 14:17:46 lp-sasha kernel: nouveau_fbcon_init+0x14d/0x1c0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_device_init+0x1c0/0x880 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_probe+0x11a/0x1e0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: pci_device_probe+0xcd/0x140 Oct 09 14:17:46 lp-sasha kernel: really_probe+0xd8/0x400 Oct 09 14:17:46 lp-sasha kernel: driver_probe_device+0x4a/0xa0 Oct 09 14:17:46 lp-sasha kernel: device_driver_attach+0x9c/0xc0 Oct 09 14:17:46 lp-sasha kernel: __driver_attach+0x6f/0x100 Oct 09 14:17:46 lp-sasha kernel: ? device_driver_attach+0xc0/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_for_each_dev+0x75/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_add_driver+0x106/0x1c0 Oct 09 14:17:46 lp-sasha kernel: driver_register+0x86/0xe0 Oct 09 14:17:46 lp-sasha kernel: ? 0xffffffffa044e000 Oct 09 14:17:46 lp-sasha kernel: do_one_initcall+0x48/0x1e0 Oct 09 14:17:46 lp-sasha kernel: ? _cond_resched+0x11/0x60 Oct 09 14:17:46 lp-sasha kernel: ? kmem_cache_alloc_trace+0x19c/0x1e0 Oct 09 14:17:46 lp-sasha kernel: do_init_module+0x57/0x220 Oct 09 14:17:46 lp-sasha kernel: __do_sys_finit_module+0xa0/0xe0 Oct 09 14:17:46 lp-sasha kernel: do_syscall_64+0x33/0x40 Oct 09 14:17:46 lp-sasha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 09 14:17:46 lp-sasha kernel: RIP: 0033:0x7fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: 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 e3 70 0c 00 f7 d8 64 89 01 48 Oct 09 14:17:46 lp-sasha kernel: RSP: 002b:00007ffc8ad38a98 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 Oct 09 14:17:46 lp-sasha kernel: RAX: ffffffffffffffda RBX: 0000563f6e7fd530 RCX: 00007fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000000 RSI: 00007fd01a19f95d RDI: 000000000000000f Oct 09 14:17:46 lp-sasha kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007 Oct 09 14:17:46 lp-sasha kernel: R10: 000000000000000f R11: 0000000000000246 R12: 00007fd01a19f95d Oct 09 14:17:46 lp-sasha kernel: R13: 0000000000000000 R14: 0000563f6e7fbc10 R15: 0000563f6e7fd530 Oct 09 14:17:46 lp-sasha kernel: Modules linked in: nouveau(+) ttm xt_string xt_mark xt_LOG vgem v4l2_dv_timings uvcvideo ulpi udf ts_kmp ts_fsm ts_bm snd_aloop sil164 qat_dh895xccvf nf_nat_sip nf_nat_irc nf_nat_ftp nf_nat nf_log_ipv6 nf_log_ipv4 nf_log_common ltc2990 lcd intel_qat input_leds i2c_mux gspca_main videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc drivetemp cuse fuse crc_itu_t coretemp ch7006 ath5k ath algif_hash Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: ---[ end trace 0ddafe218ad30017 ]--- Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 The disassembly: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 All code ======== 0: 0a 00 or (%rax),%al 2: 00 48 8b add %cl,-0x75(%rax) 5: 49 rex.WB 6: 48 c7 87 b8 00 00 00 movq $0x6,0xb8(%rdi) d: 06 00 00 00 11: 80 b9 4d 0a 00 00 00 cmpb $0x0,0xa4d(%rcx) 18: 75 1e jne 0x38 1a: 83 fa 41 cmp $0x41,%edx 1d: 75 05 jne 0x24 1f: 48 85 c0 test %rax,%rax 22: 75 29 jne 0x4d 24: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax 2a:* 39 06 cmp %eax,(%rsi) <-- trapping instruction 2c: 7c 25 jl 0x53 2e: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) 35: 75 b7 jne 0xffffffffffffffee 37: c3 retq 38: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 3f: 75 .byte 0x75 Code starting with the faulting instruction =========================================== 0: 39 06 cmp %eax,(%rsi) 2: 7c 25 jl 0x29 4: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) b: 75 b7 jne 0xffffffffffffffc4 d: c3 retq e: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 15: 75 .byte 0x75 objdump -SF --disassemble=nouveau_connector_detect_depth [...] if (nv_connector->edid && c85e1: 83 fa 41 cmp $0x41,%edx c85e4: 75 05 jne c85eb <nouveau_connector_detect_depth+0x6b> (File Offset: 0xc866b) c85e6: 48 85 c0 test %rax,%rax c85e9: 75 29 jne c8614 <nouveau_connector_detect_depth+0x94> (File Offset: 0xc8694) nv_connector->type == DCB_CONNECTOR_LVDS_SPWG) duallink = ((u8 *)nv_connector->edid)[121] == 2; else duallink = mode->clock >= bios->fp.duallink_transition_clk; if ((!duallink && (bios->fp.strapless_is_24bit & 1)) || c85eb: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax c85f1: 39 06 cmp %eax,(%rsi) c85f3: 7c 25 jl c861a <nouveau_connector_detect_depth+0x9a> (File Offset: 0xc869a) ( duallink && (bios->fp.strapless_is_24bit & 2))) c85f5: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) c85fc: 75 b7 jne c85b5 <nouveau_connector_detect_depth+0x35> (File Offset: 0xc8635) connector->display_info.bpc = 8; [...] % scripts/faddr2line /lib/modules/5.9.0-rc8-next-20201009/kernel/drivers/gpu/drm/nouveau/nouveau.ko nouveau_connector_detect_depth+0x71/0xc0 nouveau_connector_detect_depth+0x71/0xc0: nouveau_connector_detect_depth at /home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_connector.c:891 It is actually line 889. See the disassembly below. 889 duallink = mode->clock >= bios->fp.duallink_transition_clk; The NULL pointer being dereferenced is mode. Git bisect has identified the following commit as bad: f28e32d3906e drm/nouveau/kms: Don't change EDID when it hasn't actually changed Here is the chain of events that causes the oops. On entry to nouveau_connector_detect_lvds, edid is set to NULL. The call to nouveau_connector_detect sets nv_connector->edid to valid memory, with status set to connector_status_connected and the flow of execution branching to the out label. The subsequent call to nouveau_connector_set_edid erronously clears nv_connector->edid, via the local edid pointer which remains set to NULL. Fix this by setting edid to the value of the just acquired nv_connector->edid and executing the body of nouveau_connector_set_edid only if nv_connector->edid and edid point to different memory addresses thus preventing nv_connector->edid from being turned into a dangling pointer. Fixes: f28e32d3906e ("drm/nouveau/kms: Don't change EDID when it hasn't actually changed") Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-11-11drm/nouveau: Fix out-of-bounds access when deferencing MMU typeThomas Zimmermann1-1/+4
The value of struct drm_device.ttm.type_vram can become -1 for unknown types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds error when accessing struct nvif_mmu.type[]: [ 18.304116] ================================================================== [ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.320415] Read of size 1 at addr ffff88810ffac1fe by task systemd-udevd/342 [ 18.327681] [ 18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: G E 5.10.0-rc2-1-default+ #581 [ 18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 10/24/2018 [ 18.346032] Call Trace: [ 18.348536] dump_stack+0xae/0xe5 [ 18.351919] print_address_description.constprop.0+0x17/0xf0 [ 18.357787] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.363818] __kasan_report.cold+0x20/0x38 [ 18.368099] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.374133] kasan_report+0x3a/0x50 [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] <...> [ 18.767690] Allocated by task 342: [ 18.773087] kasan_save_stack+0x1b/0x40 [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0 [ 18.785646] __kmalloc_track_caller+0x1be/0x390 [ 18.792165] kstrdup_const+0x46/0x70 [ 18.797686] kobject_set_name_vargs+0x2f/0xb0 [ 18.803992] kobject_init_and_add+0x9d/0xf0 [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm] [ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm] [ 18.823420] ttm_bo_device_init+0x39/0x220 [ttm] [ 18.830046] nouveau_ttm_init+0x2c3/0x830 [nouveau] [ 18.836929] nouveau_drm_device_init+0x1b4/0x3f0 [nouveau] <...> [ 19.105336] ================================================================== Fix this error, by not using type_vram as an index if it's negative. Assume default values instead. The error was seen on Nvidia G72 hardware. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement") Cc: Christian König <christian.koenig@amd.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> 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: Ben Skeggs <bskeggs@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Roland Scheidegger <sroland@vmware.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Likun Gao <Likun.Gao@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20201110133655.13174-1-tzimmermann@suse.de
2020-11-11drm/nouveau/ttm: use multihopDave Airlie1-99/+13
This removes the code to move resources directly between SYSTEM and VRAM in favour of using the core ttm mulithop code. Signed-off-by: Dave Airlie <airlied@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201109005432.861936-4-airlied@gmail.com
2020-11-11drm/ttm: add multihop infrastrucutre (v3)Dave Airlie1-1/+2
Currently drivers get called to move a buffer, but if they have to move it temporarily through another space (SYSTEM->VRAM via TT) then they can end up with a lot of ttm->driver->ttm call stacks, if the temprorary space moves requires eviction. Instead of letting the driver do all the placement/space for the temporary, allow it to report back (-EMULTIHOP) and a placement (hop) to the move code, which will then do the temporary move, and the correct placement move afterwards. This removes a lot of code from drivers, at the expense of adding some midlayering. I've some further ideas on how to turn it inside out, but I think this is a good solution to the call stack problems. v2: separate out the driver patches, add WARN for getting MULTHOP in paths we shouldn't (Daniel) v3: use memset (Christian) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: hristian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201109005432.861936-2-airlied@gmail.com
2020-11-09drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backendsThomas Zimmermann5-26/+5
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
2020-11-08drm: remove unneeded breakTom Rix4-6/+0
A break is not needed if it is preceded by a return or break Signed-off-by: Tom Rix <trix@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201019163115.25814-1-trix@redhat.com
2020-11-03drm/nouveau/kms/nv50-: Use state helper instead of crtc pointerMaxime Ripard1-1/+3
dispnv50 references the crtc->state pointer in order to get the current CRTC state in its atomic_check hook, which would be the old CRTC state in the global atomic state. Use the drm_atomic_get_old_crtc_state helper to get that state to make it more obvious. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201102133834.1176740-1-maxime@cerno.tech
2020-11-02drm/atomic: Pass the full state to CRTC atomic_checkMaxime Ripard1-2/+5
The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Let's start convert all the remaining helpers to provide a consistent interface, starting with the CRTC's atomic_check. The conversion was done using the coccinelle script below, built tested on all the drivers and actually tested on vc4. virtual report @@ struct drm_crtc_helper_funcs *FUNCS; struct drm_crtc *crtc; struct drm_crtc_state *crtc_state; identifier dev, state; identifier ret, f; @@ f(struct drm_device *dev, struct drm_atomic_state *state) { <... - ret = FUNCS->atomic_check(crtc, crtc_state); + ret = FUNCS->atomic_check(crtc, state); ...> } @@ identifier crtc, new_state; @@ struct drm_crtc_helper_funcs { ... - int (*atomic_check)(struct drm_crtc *crtc, struct drm_crtc_state *new_state); + int (*atomic_check)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ static struct drm_crtc_helper_funcs helpers = { ..., .atomic_check = func, ..., }; @ ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { ... when != new_state } @ adds_new_state depends on crtc_atomic_func && !ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; expression E; type T; @@ int func(...) { ... - T state = E; + T crtc_state = E; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; type T; @@ int func(...) { ... - T state; + T crtc_state; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; identifier new_state; identifier crtc; @@ int func(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ); @ include depends on adds_new_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_new_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201028123222.1732139-1-maxime@cerno.tech
2020-11-02drm/nouveau/ttm: Add limits.hMaxime Ripard1-0/+1
It seems that a recent commit broke the nouveau compilation when swiotlb is disabled (which is the case on our ARM defconfig for example). Daniel says """ Since the proper fix is maybe stuck in the usual "drm abuses swiotlb internals" bikeshed, maybe best if we push a fix to including limits.h in nouveau and call it done? """ So let's go down the simplest path to fix our build, and goes back to it later if needed. Link: https://patchwork.freedesktop.org/patch/397835/ Fixes: 4dbafbd30aef ("drm/nouveu: fix swiotlb include") Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard14-77/+157
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-11-02drm/nouveu: fix swiotlb includeChristian König2-1/+3
The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move the include as well. This blows up only when merged with linux-next, not sure why drm-misc-next works stand alone. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/397835/
2020-10-30drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()Lyude Paul1-10/+11
While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max data rate supported by the DP encoder. So, limiting it to the output of ds_clock (which refers to the maximum dotclock of the downstream DP device) doesn't make any sense. Additionally, since we're using the connector's bpc as the canonical BPC we should use this in mode_valid until we support dynamically setting the bpp based on bandwidth constraints. https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html For more info. So, let's rewrite this using Ville's advice. v2: * Ville pointed out I mixed up the dotclock and the link rate. So fix that... * ...and also rename all the variables in this function to be more appropriately labeled so I stop mixing them up. * Reuse the bpp from the connector for now until we have dynamic bpp selection. * Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we should also have been doing from the start Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()Lyude Paul2-31/+21
Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: d6a9efece724 ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/device: fix changing endianess code to work on older GPUsKarol Herbst1-13/+26
With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") Signed-off-by: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst1-1/+2
we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/kms/nv50-: Program notifier offset before requesting disp capsLyude Paul6-5/+85
Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier offset programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix this by doing that, and also perform an update afterwards to prevent racing with the GPU when reading capabilities. v2: * Don't just program the DMA notifier offset, make sure to actually perform an update v3: * Don't call UPDATE() * Actually read the correct notifier fields, as apparently the CAPABILITIES_DONE field lives in a different location than the main NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different CAPABILITIES_DONE field then pre-907d cards. v4: * Don't forget to check the return value of core507d_read_caps() v5: * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY * Disable notifier after calling GetCapabilities() Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support") Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell1-11/+3
The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-29drm/nouveau: switch to new allocatorChristian König2-29/+2
It should be able to handle all cases now. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com> Tested-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/397082/?series=83051&rev=1
2020-10-29drm/ttm: wire up the new pool as default one v2Christian König1-5/+9
Provide the necessary parameters by all drivers and use the new pool alloc when no driver specific function is provided. v2: fix the GEM VRAM helpers Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com> Tested-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/397081/?series=83051&rev=1
2020-10-26drm/ttm: merge ttm_dma_tt back into ttm_ttChristian König4-14/+16
It makes no difference to kmalloc if the structure is 48 or 64 bytes in size. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/396950/
2020-10-26drm/ttm: make num_pages uint32_tChristian König1-1/+1
We can still allocate 16TiB with that. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/396946/
2020-10-26drm/ttm: nuke ttm_tt_set_(un)populated againChristian König1-1/+0
Neither page allocation backend nor the driver should mess with that. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com> Link: https://patchwork.freedesktop.org/patch/396948/
2020-10-22drm/ttm: replace last move_notify with delete_mem_notifyDave Airlie1-1/+7
The move notify callback is only used in one place, this should be removed in the future, but for now just rename it to the use case which is to notify the driver that the GPU memory is to be deleted. Drivers can be cleaned up after this separately. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021044031.1752624-2-airlied@gmail.com
2020-10-21drm/ttm: move last binding into the drivers.Dave Airlie1-1/+6
This moves the call to tt binding into the driver move, and drops the driver callback. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020010319.1692445-8-airlied@gmail.com
2020-10-21drm/ttm: drop move notify around move.Dave Airlie1-3/+9
The drivers now do this in the move callback. move_notify is still needed in the destroy path. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020010319.1692445-7-airlied@gmail.com
2020-10-21drm/ttm: drop unbind callback.Dave Airlie1-1/+0
The drivers now control this, so drop unbinding. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020010319.1692445-5-airlied@gmail.com
2020-10-21drm/ttm: add move to system into driversDave Airlie1-4/+6
This moves the to system move into the drivers, and moves all the unbinds in the move path under driver control Note: radeon/nouveau already wait so don't duplicate it. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020010319.1692445-4-airlied@gmail.com
2020-10-21drm/ttm: move some move binds into the driversDave Airlie1-3/+7
This just gives the driver control over some of the bind paths. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020010319.1692445-2-airlied@gmail.com
2020-10-19drm/ttm: add move old to system to drivers.Dave Airlie1-2/+9
Uninline ttm_bo_move_ttm. Eventually want to unhook the unbind out. Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019071314.1671485-5-airlied@gmail.com
2020-10-19drm/ttm: use new move interface for known system->ttm movesDave Airlie1-1/+2
In all 3 drivers there is a case where the driver knows the bo is in SYSTEM so don't call the api that checks that. Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019071314.1671485-4-airlied@gmail.com
2020-10-16Merge tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds1-2/+1
Pull dma-mapping updates from Christoph Hellwig: - rework the non-coherent DMA allocator - move private definitions out of <linux/dma-mapping.h> - lower CMA_ALIGNMENT (Paul Cercueil) - remove the omap1 dma address translation in favor of the common code - make dma-direct aware of multiple dma offset ranges (Jim Quinlan) - support per-node DMA CMA areas (Barry Song) - increase the default seg boundary limit (Nicolin Chen) - misc fixes (Robin Murphy, Thomas Tai, Xu Wang) - various cleanups * tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits) ARM/ixp4xx: add a missing include of dma-map-ops.h dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling dma-direct: factor out a dma_direct_alloc_from_pool helper dma-direct check for highmem pages in dma_direct_alloc_pages dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h> dma-mapping: move large parts of <linux/dma-direct.h> to kernel/dma dma-mapping: move dma-debug.h to kernel/dma/ dma-mapping: remove <asm/dma-contiguous.h> dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h> dma-contiguous: remove dma_contiguous_set_default dma-contiguous: remove dev_set_cma_area dma-contiguous: remove dma_declare_contiguous dma-mapping: split <linux/dma-mapping.h> cma: decrease CMA_ALIGNMENT lower limit to 2 firewire-ohci: use dma_alloc_pages dma-iommu: implement ->alloc_noncoherent dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods dma-mapping: add a new dma_alloc_pages API dma-mapping: remove dma_cache_sync 53c700: convert to dma_alloc_noncoherent ...
2020-10-15Merge tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drmLinus Torvalds41-665/+1046
Pull drm updates from Dave Airlie: "Not a major amount of change, the i915 trees got split into display and gt trees to better facilitate higher level review, and there's a major refactoring of i915 GEM locking to use more core kernel concepts (like ww-mutexes). msm gets per-process pagetables, older AMD SI cards get DC support, nouveau got a bump in displayport support with common code extraction from i915. Outside of drm this contains a couple of patches for hexint moduleparams which you've acked, and a virtio common code tree that you should also get via it's regular path. New driver: - Cadence MHDP8546 DisplayPort bridge driver core: - cross-driver scatterlist cleanups - devm_drm conversions - remove drm_dev_init - devm_drm_dev_alloc conversion ttm: - lots of refactoring and cleanups bridges: - chained bridge support in more drivers panel: - misc new panels scheduler: - cleanup priority levels displayport: - refactor i915 code into helpers for nouveau i915: - split into display and GT trees - WW locking refactoring in GEM - execbuf2 extension mechanism - syncobj timeline support - GEN 12 HOBL display powersaving - Rocket Lake display additions - Disable FBC on Tigerlake - Tigerlake Type-C + DP improvements - Hotplug interrupt refactoring amdgpu: - Sienna Cichlid updates - Navy Flounder updates - DCE6 (SI) support for DC - Plane rotation enabled - TMZ state info ioctl - PCIe DPC recovery support - DC interrupt handling refactor - OLED panel fixes amdkfd: - add SMI events for thermal throttling - SMI interface events ioctl update - process eviction counters radeon: - move to dma_ for allocations - expose sclk via sysfs msm: - DSI support for sm8150/sm8250 - per-process GPU pagetable support - Displayport support mediatek: - move HDMI phy driver to PHY - convert mtk-dpi to bridge API - disable mt2701 tmds tegra: - bridge support exynos: - misc cleanups vc4: - dual display cleanups ast: - cleanups gma500: - conversion to GPIOd API hisilicon: - misc reworks ingenic: - clock handling and format improvements mcde: - DSI support mgag200: - desktop g200 support mxsfb: - i.MX7 + i.MX8M - alpha plane support panfrost: - devfreq support - amlogic SoC support ps8640: - EDID from eDP retrieval tidss: - AM65xx YUV workaround virtio: - virtio-gpu exported resources rcar-du: - R8A7742, R8A774E1 and R8A77961 support - YUV planar format fixes - non-visible plane handling - VSP device reference count fix - Kconfig fix to avoid displaying disabled options in .config" * tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drm: (1494 commits) drm/ingenic: Fix bad revert drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init drm/amdgpu: Remove warning for virtual_display drm/amdgpu: kfd_initialized can be static drm/amd/pm: setup APU dpm clock table in SMU HW initialization drm/amdgpu: prevent spurious warning drm/amdgpu/swsmu: fix ARC build errors drm/amd/display: Fix OPTC_DATA_FORMAT programming drm/amd/display: Don't allow pstate if no support in blank drm/panfrost: increase readl_relaxed_poll_timeout values MAINTAINERS: Update entry for st7703 driver after the rename Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached" drm/amd/display: HDMI remote sink need mode validation for Linux drm/amd/display: Change to correct unit on audio rate drm/amd/display: Avoid set zero in the requested clk drm/amdgpu: align frag_end to covered address space drm/amdgpu: fix NULL pointer dereference for Renoir drm/vmwgfx: fix regression in thp code due to ttm init refactor. drm/amdgpu/swsmu: add interrupt work handler for smu11 parts drm/amdgpu/swsmu: add interrupt work function ...
2020-10-15drm/ttm: nuke caching placement flagsChristian König1-27/+9
Changing the caching on the fly never really worked flawlessly. So stop this completely and just let drivers specific the desired caching in the tt or bus object. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/394256/
2020-10-15drm/ttm: add caching state to ttm_bus_placementChristian König1-0/+11
And implement setting it up correctly in the drivers. This allows getting rid of the placement flags for this. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/394254/
2020-10-15drm/ttm: set the tt caching state at creation timeChristian König1-1/+12
All drivers can determine the tt caching state at creation time, no need to do this on the fly during every validation. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/394253/
2020-10-14mm/memremap_pages: support multiple ranges per invocationDan Williams1-0/+1
In support of device-dax growing the ability to front physically dis-contiguous ranges of memory, update devm_memremap_pages() to track multiple ranges with a single reference counter and devm instance. Convert all [devm_]memremap_pages() users to specify the number of ranges they are mapping in their 'struct dev_pagemap' instance. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Paul Mackerras <paulus@ozlabs.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: "Jérôme Glisse" <jglisse@redhat.co Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brice Goglin <Brice.Goglin@inria.fr> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hulk Robot <hulkci@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Jason Yan <yanaijie@huawei.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Jia He <justin.he@arm.com> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: kernel test robot <lkp@intel.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/159643103789.4062302.18426128170217903785.stgit@dwillia2-desk3.amr.corp.intel.com Link: https://lkml.kernel.org/r/160106116293.30709.13350662794915396198.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-14mm/memremap_pages: convert to 'struct range'Dan Williams1-7/+7
The 'struct resource' in 'struct dev_pagemap' is only used for holding resource span information. The other fields, 'name', 'flags', 'desc', 'parent', 'sibling', and 'child' are all unused wasted space. This is in preparation for introducing a multi-range extension of devm_memremap_pages(). The bulk of this change is unwinding all the places internal to libnvdimm that used 'struct resource' unnecessarily, and replacing instances of 'struct dev_pagemap'.res with 'struct dev_pagemap'.range. P2PDMA had a minor usage of the resource flags field, but only to report failures with "%pR". That is replaced with an open coded print of the range. [dan.carpenter@oracle.com: mm/hmm/test: use after free in dmirror_allocate_chunk()] Link: https://lkml.kernel.org/r/20200926121402.GA7467@kadam Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> [xen] Cc: Paul Mackerras <paulus@ozlabs.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brice Goglin <Brice.Goglin@inria.fr> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hulk Robot <hulkci@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Jason Yan <yanaijie@huawei.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Jia He <justin.he@arm.com> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: kernel test robot <lkp@intel.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/159643103173.4062302.768998885691711532.stgit@dwillia2-desk3.amr.corp.intel.com Link: https://lkml.kernel.org/r/160106115761.30709.13539840236873663620.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-07drm/ttm: nuke ttm_bo_evict_mm and rename mgr function v3Christian König2-3/+6
Make it more clear what the resource manager function does and nuke the wrapper function. v2: nuke the wrapper v3: fix typo in radeon, rebased Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2) Link: https://patchwork.freedesktop.org/patch/393914/
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-16 00:56:35 +0300