aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-06-07drm/nouveau/secboot: enable loading of versioned LS PMU/SEC2 ACR msgqueue FWBen Skeggs1-14/+14
Some chipsets will be switching to updated SEC2 LS firmware, so we need to plumb that through. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-06-07drm/nouveau/secboot: split out FW version-specific LS function pointersBen Skeggs6-41/+141
It's not enough to have per-falcon structures anymore, we have multiple versions of some firmware now that have interface differences. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-06-07drm/nouveau/secboot: pass max supported FW version to LS load funcsBen Skeggs6-21/+32
Will be passed to the FW loader function as an upper bound on the supported FW version to attempt to load. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-06-07drm/nouveau/core: support versioned firmware loadingBen Skeggs2-6/+31
We have a need for this now with updated SEC2 LS FW images that have an incompatible interface from the previous version. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-06-07drm/nouveau/core: pass subdev into nvkm_firmware_get, rather than deviceBen Skeggs6-18/+14
It'd be nice to have FW loading debug messages to appear for the relevant subsystem, when enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau: fix duplication of nv50_head_atom structPeteris Rudzusiks1-0/+1
nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom struct. This patch adds copying of struct member named "or", which previously was left uninitialized in the duplicated structure. Due to this bug, incorrect nhsync and nvsync values were sometimes used. In my particular case, that lead to a mismatch between the output resolution of the graphics device (GeForce GT 630 OEM) and the reported input signal resolution on the display. xrandr reported 1680x1050, but the display reported 1280x1024. As a result of this mismatch, the output on the display looked like it was cropped (only part of the output was actually visible on the display). git bisect pointed to commit 2ca7fb5c1cc6 ("drm/nouveau/kms/nv50: handle SetControlOutputResource from head"), which added the member "or" to nv50_head_atom structure, but forgot to copy it in nv50_head_atomic_duplicate_state(). Fixes: 2ca7fb5c1cc6 ("drm/nouveau/kms/nv50: handle SetControlOutputResource from head") Signed-off-by: Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/disp/dp: respect sink limits when selecting failsafe link configurationBen Skeggs1-2/+9
Where possible, we want the failsafe link configuration (one which won't hang the OR during modeset because of not enough bandwidth for the mode) to also be supported by the sink. This prevents "link rate unsupported by sink" messages when link training fails. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/core: initial support for boards with TU117 chipsetBen Skeggs1-0/+36
Modesetting only, still waiting on ACR/GR firmware from NVIDIA for Turing graphics/compute bring-up. Each subsystem was compared with traces, along with various tests to check that things generally work as they should, and appears compatible enough with the current TU106 code to enable support. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/core: allow detected chipset to be overriddenBen Skeggs2-3/+24
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd when encoders changeBen Skeggs1-1/+1
HW has error checks in place which check that pixel depth is explicitly provided on DP, while HDMI has a "default" setting that we use. In multi-display configurations with identical modelines, but different protocols (HDMI + DP, in this case), it was possible for the DP head to get swapped to the head which previously drove the HDMI output, without updating HeadSetControlOutputResource(), triggering the error check and hanging the core update. Reported-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/kms/nv50-: fix bug preventing non-vsync'd page flipsBen Skeggs1-1/+1
Accidentally introduced during Volta bring-up. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-14drm/nouveau/kms/gv100-: fix spurious window immediate interlocksBen Skeggs3-1/+3
Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances. Fixes suspend/resume on (at least) Quadro RTX4000 (TU104). Reported-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/nouveau: forward error generated while resuming objects treeTobias Klausmann1-1/+11
On a failed resume we may experience unrecoverable errors. Plumb the error code through to actually let the driver fail. On a reverse-prime setup this helps the drm subsystem to at least recover the integrated gpu. This can especially happen with secboot timing out, leaving the hardware in a non-functioning state. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully"Colin Ian King1-1/+1
There is a spelling mistake in a nvkm_debug message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/i2c: Disable i2c bus access after ->fini()Lyude Paul6-2/+65
For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime suspend, the MMIO region that the i2c bus is on isn't accessible. On x86, the standard behavior for accessing an unavailable MMIO region is to just return ~0. Except, that turned out to be a lie. While computers with a clean concious will return ~0 in this scenario, some machines will actually completely hang a CPU on certian bad MMIO accesses. This was witnessed with someone's Lenovo ThinkPad P50, where sensors-detect attempting to access the i2c bus while the GPU was suspended would result in a CPU hang: CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017 RIP: 0010:ioread32+0x2b/0x30 Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48 RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13 RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186 RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4 RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7 R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000 R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000 FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: g94_i2c_aux_xfer+0x326/0x850 [nouveau] nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau] __i2c_transfer+0x14b/0x620 i2c_smbus_xfer_emulated+0x159/0x680 ? _raw_spin_unlock_irqrestore+0x1/0x60 ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0 ? __lock_is_held+0x59/0xa0 __i2c_smbus_xfer+0x138/0x5a0 i2c_smbus_xfer+0x4f/0x80 i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev] i2cdev_ioctl+0x1db/0x2c0 [i2c_dev] do_vfs_ioctl+0x408/0x750 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f25317f546b Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is going to only be useful while there's at least one display enabled on the GPU anyway, and the GPU never sleeps while there's displays running. Since teaching the i2c bus to wake up the GPU on userspace accesses is a good deal more difficult than it might seem, mostly due to the fact that we have to use the i2c bus during runtime resume of the GPU, we instead opt for the easiest solution: don't let userspace access i2c busses on the GPU at all while it's in runtime suspend. Changes since v1: * Also disable i2c busses that run over DP AUX Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definitionBjorn Helgaas1-9/+0
Commit 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE") added a definition of ACPI_VIDEO_NOTIFY_PROBE because <acpi/video.h> didn't supply one. Later, commit eff4a751cce5 ("ACPI / video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACPI_VIDEO_NOTIFY_PROBE and other definitions to <acpi/video.h>, so the copy in nouveau_display.c is now unnecessary. Remove the unnecessary definition from nouveau_display.c. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/mmu: qualify vmm during dtorJon Derrick1-1/+1
If the BAR initialization failed it may leave the vmm structure in an unitialized state, leading to a null-pointer-dereference when the vmm is dereferenced during teardown. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/bar/gf100: ensure BAR is mappedJon Derrick1-0/+2
If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/bar/nv50: ensure BAR is mappedJon Derrick1-3/+9
If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-05-01drm/nouveau/bar/nv50: check bar1 vmm return valueJon Derrick1-0/+2
Check bar1's new vmm creation return value for errors. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-04-24drm/fb-helper: Fix drm_fb_helper_firmware_config() NULL pointer derefNoralf Trønnes1-0/+3
Non-atomic drivers like ast doesn't have connector->state set resulting in a NULL pointer deref: [ 29.609593] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 29.609619] Call Trace: [ 29.609630] ? drm_helper_probe_single_connector_modes+0x27f/0x680 [ 29.609640] drm_setup_crtcs+0x431/0xd80 [drm_kms_helper] [ 29.753065] __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0 [ 29.753160] ? drm_modeset_unlock_all+0x31/0x50 [drm] [ 29.765758] ast_fbdev_init+0xa8/0xc0 [ast] [ 29.765762] ast_driver_load.cold.7+0x2b3/0xe11 [ast] [ 29.765775] drm_dev_register+0x111/0x150 [drm] Fix by bailing out if the driver does not support atomic modesetting. Fixes: 09ded8af57bc ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper") Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190423145353.30158-1-noralf@tronnes.org
2019-04-24drm/atomic: -EACCESS for lease-denied crtc lookupDaniel Vetter1-0/+4
With the previous patch drm_crtc_find will return NULL when the crtc isn't in our lease, which will then disable the plane/connector. No longer an issue since the lessor can't escape their lease terms anymore, but not quite great semantics yet either. Catch this and return -EACCES, so that at least evil test cases have a better chance of making sure the kernel works correctly. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-8-daniel.vetter@ffwll.ch
2019-04-24drm/atomic: Wire file_priv through for property changesDaniel Vetter3-15/+23
We need this to make sure lessees can only connect their plane/connectors to crtc objects they own. And note that this is irrespective of whether the lessor is atomic or not, lessor cannot prevent lessees from enabling atomic. Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-7-daniel.vetter@ffwll.ch
2019-04-24drm/lease: Make sure implicit planes are leasedDaniel Vetter2-0/+12
If userspace doesn't enable universal planes, then we automatically add the primary and cursor planes. But for universal userspace there's no such check (and maybe we only want to give the lessee one plane, maybe not even the primary one), hence we need to check for the implied plane. v2: don't forget setcrtc ioctl. v3: Still allow disabling of the crtc in SETCRTC. Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-6-daniel.vetter@ffwll.ch
2019-04-24drm/lease: Check for lessor outside of locksDaniel Vetter1-3/+3
The lessor is invariant over a lifetime of a lease, we don't have to grab any locks for that. Speeds up the common case of not being a lease. Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-5-daniel.vetter@ffwll.ch
2019-04-24drm/leases: Don't init to 0 in drm_master_createDaniel Vetter1-2/+0
We kzalloc. Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-4-daniel.vetter@ffwll.ch
2019-04-24drm/lease: Drop recursive leads checksDaniel Vetter1-2/+0
We disallow subleasing, so no point checking whether the master holds all the leases - it will. Spotted while typing exhaustive igt coverage for all these corner cases. Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-3-daniel.vetter@ffwll.ch
2019-04-24drm/leases: Drop object_id validation for negative idsDaniel Vetter1-5/+0
Not exactly sure what's the aim here, but the canonical nil object has id == 0, we don't use negative object ids for anything. Plus all object_id are valided by the object_idr, there's nothing we need to do on top of that ENOENT check a bit further down. Spotted while typing exhaustive igt coverage for all these corner-cases. Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-2-daniel.vetter@ffwll.ch
2019-04-24drm/fb: revert the i915 Actually configure untiled displays from masterDave Airlie1-7/+5
This code moved in here in master, so revert it the same way. This is the same revert as 9fa246256e09 ("Revert "drm/i915/fbdev: Actually configure untiled displays"") in drm-fixes. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/i915/icl: Fix MG_DP_MODE() register programmingImre Deak1-10/+8
Fix the order of lane, port parameters passed to the register macro. Note that this was already partly fixed by commit 37fc7845df7b6 ("drm/i915: Call MG_DP_MODE() macro with the right parameters order") While at it simplify things by using the macro directly instead of an unnecessary redirection via an array. v2: - Add a note the commit message about simplifying things. (José) Fixes: 58106b7d816e1 ("drm/i915: Make MG PHY macros semantically consistent") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419071026.32370-1-imre.deak@intel.com (cherry picked from commit 9c11b12184bb01d8ba2c48e655509b184f02c769) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-04-24drm/i915: Avoid use-after-free in reporting create.sizeChris Wilson1-1/+1
We have to avoid chasing after a userspace race! <3>[ 473.114328] BUG: KASAN: use-after-free in i915_gem_create+0x1d2/0x1f0 [i915] <3>[ 473.114389] Read of size 8 at addr ffff88815bf1d840 by task gem_flink_race/1541 <4>[ 473.114464] CPU: 1 PID: 1541 Comm: gem_flink_race Tainted: G U 5.1.0-rc4-g7d07e025e786-kasan_88+ #1 <4>[ 473.114469] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016 <4>[ 473.114474] Call Trace: <4>[ 473.114488] dump_stack+0x7c/0xbb <4>[ 473.114612] ? i915_gem_create+0x1d2/0x1f0 [i915] <4>[ 473.114621] print_address_description+0x65/0x270 <4>[ 473.114728] ? i915_gem_create+0x1d2/0x1f0 [i915] <4>[ 473.114839] ? i915_gem_create+0x1d2/0x1f0 [i915] <4>[ 473.114848] kasan_report+0x149/0x18d <4>[ 473.114962] ? i915_gem_create+0x1d2/0x1f0 [i915] <4>[ 473.115069] i915_gem_create+0x1d2/0x1f0 [i915] <4>[ 473.115176] ? i915_gem_object_create.part.28+0x4b0/0x4b0 [i915] <4>[ 473.115289] ? i915_gem_dumb_create+0x1a0/0x1a0 [i915] <4>[ 473.115297] drm_ioctl_kernel+0x192/0x260 <4>[ 473.115306] ? drm_ioctl_permit+0x280/0x280 <4>[ 473.115326] drm_ioctl+0x67c/0x960 <4>[ 473.115438] ? i915_gem_dumb_create+0x1a0/0x1a0 [i915] <4>[ 473.115448] ? drm_getstats+0x20/0x20 <4>[ 473.115459] ? __lock_acquire+0xa66/0x3fe0 <4>[ 473.115474] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4>[ 473.115485] ? debug_object_active_state+0x2ea/0x4e0 <4>[ 473.115496] ? debug_show_all_locks+0x2d0/0x2d0 <4>[ 473.115513] do_vfs_ioctl+0x18d/0xfa0 <4>[ 473.115522] ? check_flags.part.27+0x440/0x440 <4>[ 473.115532] ? ioctl_preallocate+0x1a0/0x1a0 <4>[ 473.115547] ? __fget+0x2ac/0x410 <4>[ 473.115561] ? __ia32_sys_dup3+0xb0/0xb0 <4>[ 473.115569] ? rwlock_bug.part.0+0x90/0x90 <4>[ 473.115590] ksys_ioctl+0x35/0x70 <4>[ 473.115597] ? lockdep_hardirqs_off+0x1cb/0x2b0 <4>[ 473.115608] __x64_sys_ioctl+0x6a/0xb0 <4>[ 473.115614] ? lockdep_hardirqs_on+0x342/0x590 <4>[ 473.115623] do_syscall_64+0x97/0x400 <4>[ 473.115633] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 473.115641] RIP: 0033:0x7fce590d55d7 <4>[ 473.115649] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48 <4>[ 473.115655] RSP: 002b:00007fce4d525ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 <4>[ 473.115662] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fce590d55d7 <4>[ 473.115667] RDX: 00007fce4d525c10 RSI: 00000000c010645b RDI: 0000000000000007 <4>[ 473.115672] RBP: 00007fce4d525c10 R08: 00007fce4d526700 R09: 00007fce4d526700 <4>[ 473.115677] R10: 0000000000000054 R11: 0000000000000246 R12: 00000000c010645b <4>[ 473.115682] R13: 0000000000000007 R14: 0000000000000000 R15: 00007ffe0e4a7450 <3>[ 473.115731] Allocated by task 1541: <4>[ 473.115766] kmem_cache_alloc+0xce/0x290 <4>[ 473.115895] i915_gem_object_create.part.28+0x1c/0x4b0 [i915] <4>[ 473.116000] i915_gem_create+0xe3/0x1f0 [i915] <4>[ 473.116008] drm_ioctl_kernel+0x192/0x260 <4>[ 473.116013] drm_ioctl+0x67c/0x960 <4>[ 473.116020] do_vfs_ioctl+0x18d/0xfa0 <4>[ 473.116026] ksys_ioctl+0x35/0x70 <4>[ 473.116032] __x64_sys_ioctl+0x6a/0xb0 <4>[ 473.116038] do_syscall_64+0x97/0x400 <4>[ 473.116044] entry_SYSCALL_64_after_hwframe+0x49/0xbe <3>[ 473.116071] Freed by task 1542: <4>[ 473.116101] kmem_cache_free+0xb7/0x2f0 <4>[ 473.116205] __i915_gem_free_objects+0x7d4/0xe10 [i915] <4>[ 473.116311] i915_gem_create_ioctl+0xaa/0xd0 [i915] <4>[ 473.116318] drm_ioctl_kernel+0x192/0x260 <4>[ 473.116323] drm_ioctl+0x67c/0x960 <4>[ 473.116330] do_vfs_ioctl+0x18d/0xfa0 <4>[ 473.116335] ksys_ioctl+0x35/0x70 <4>[ 473.116341] __x64_sys_ioctl+0x6a/0xb0 <4>[ 473.116347] do_syscall_64+0x97/0x400 <4>[ 473.116354] entry_SYSCALL_64_after_hwframe+0x49/0xbe Testcase: igt/gem_flink_race/flink_close Fixes: e163484afa8d ("drm/i915: Update size upon return from GEM_CREATE") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190417132507.27133-1-chris@chris-wilson.co.uk (cherry picked from commit 99534023490686ce4453c45e5cb813535b9bff95) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-04-24drm/udl: move to embedding drm device inside udl device.Dave Airlie4-37/+53
This should help with some of the lifetime issues, and move us away from load/unload. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-4-airlied@gmail.com
2019-04-24drm/udl: introduce a macro to convert dev to udl.Dave Airlie4-12/+14
This just makes it easier to later embed drm into udl. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-3-airlied@gmail.com
2019-04-24drm/legacy: remove some legacy lock struct membersDave Airlie6-5/+19
This removes these unless legacy is enabled. The lock count init is unneeded anyways since it's kzalloc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: place all drm legacy members under DRM_LEGACY.Dave Airlie2-1/+11
This places a bunch of the legacy members of drm_device into only being there when legacy is enabled. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm: allow removal of legacy codepaths (v4.1)Dave Airlie8-33/+105
If you don't want the legacy drivers, then lets get rid of all the legacy codepaths from the core module. This drop the size of drm.ko for me by about 10%. 380515 7422 4192 392129 5fbc1 ../../drm-next-build/drivers/gpu/drm/drm.ko 351736 7298 4192 363226 58ada ../../drm-next-build/drivers/gpu/drm/drm.ko v2: drop drm_lock as well, fix some DMA->DRM typos v3: avoid ifdefs in mainline code v4: rework ioctl defs v4.1: fix nouveau Kconfig Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: don't include any of ati_pcigart in legacy. (v2)Dave Airlie2-1/+5
This could probably be done with Kconfig somehow, but I failed in my first 2 minute attempt. v2: use Kconfig better. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move legacy dev reinit into legacy miscDave Airlie3-24/+25
This moves the legacy dev reinit into the legacy misc file. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move init/destroy of struct members into legacy fileDave Airlie4-8/+59
This introduces drm_legacy_misc.c as a place for some misc legacy code, eventually I want to give the option to remove this from the build. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move map_hash create/destroy into inlinesDave Airlie2-3/+13
This allows them to be removed later. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move lock cleanup for master into lock file (v2)Dave Airlie3-15/+21
This makes it easier to remove legacy code later. v2: move check into lock file as well. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/radeon: drop unused ati pcigart include.Dave Airlie1-1/+0
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move map cleanups into drm_bufs.cDave Airlie3-4/+10
This makes it easier to clean this up later. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/legacy: move drm_legacy_master_rmmaps to non-driver legacy header.Dave Airlie2-2/+3
This isn't used by drivers, and won't be in the future. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)Dave Airlie2-3/+17
There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is. Full context of the story: commit 0e975980d435d58df2d430d688b8c18778b42218 Author: Peter Antoine <peter.antoine@intel.com> Date: Tue Jun 23 08:18:49 2015 +0100 drm: Turn off Legacy Context Functions The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm. The previous attempt was commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:21 2013 +0200 drm: mark context support as a legacy subsystem but this had to be reverted commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 Author: Dave Airlie <airlied@redhat.com> Date: Fri Sep 20 08:32:59 2013 +1000 Revert "drm: mark context support as a legacy subsystem" v2: remove returns from void function, and formatting (Daniel Vetter) v3: - s/Nova/nouveau/ in the commit message, and add references to the previous attempts - drop the part touching the drm hw lock, that should be a separate patch. Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by: Peter Antoine <peter.antoine@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> v2: move DRM_VM dependency into legacy config. v3: fix missing dep (kbuild robot) Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-24drm/ipp: clean up debug messagesInki Dae6-37/+40
Print out debug messages with correct device name. As for this, this patch adds device pointer to exynos_drm_ipp structure, and in case of exynos_drm_ipp_task structure, replace drm_device pointer with device one. This will make each ipp driver to print out debug messages with correct device name. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2019-04-24drm/vidi: replace platform_device pointer with device oneInki Dae1-16/+17
Add device pointer to vidi_context and remove platform_device pointer. It doesn't need for vidi_context to contain platform_device object. Instead, this patch makes this driver more simply by replacing platform_device pointer with device one. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2019-04-24drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macroInki Dae13-148/+191
Use DRM_DEV_DEBUG* instead of DRM_DEBUG macro to print out debug messages. This patch just cleans up the use of debug log macro, which changes the log macro to DRM_DEV_DEBUG*. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2019-04-24drm/exynos: use DRM_DEV_ERROR to print out error messageInki Dae18-120/+179
This patch just cleans up the use of error log macro, which changes the log macro to DRM_DEV_ERROR. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2019-04-24drm/exynos: remove unnecessary messagesInki Dae3-6/+0
This patch removes unnecessary messages from fimd_clear_channels and decon_clear_channels functions which print out just function name. Signed-off-by: Inki Dae <inki.dae@samsung.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.