summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2017-08-04drm/i915: fix backlight invert for non-zero minimum brightnessJani Nikula
When we started following the backlight minimum brightness in 6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness") we overlooked the brightness invert quirk. Even if we invert the brightness, we need to take the min limit into account. We probably missed this because the invert has only been required on gen4 for proper operation. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101127 Fixes: 6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170531083355.7898-1-jani.nikula@intel.com
2017-08-04drm/i915/shrinker: Wrap need_resched() inside preempt-disableChris Wilson
In order for us to successfully detect the end of a timeslice, preemption must be disabled. Otherwise, inside the loop we may be preempted many times without our noticing, and each time our timeslice will be reset, invalidating need_resched() Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Fixes: 290271de34f6 ("drm/i915: Spin for struct_mutex inside shrinker") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+ Link: https://patchwork.freedesktop.org/patch/msgid/20170804104135.26805-1-chris@chris-wilson.co.uk Tested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-08-04drm/i915/perf: Initialise the dynamic sysfs attrChris Wilson
Use sysfs_attr_init() to dynamically initialise the oa_config->sysfs_metric_id.attr as it has the important side-effect of setting the lockdep key. [ 4.971513] [drm] Initialized i915 1.6.0 20170731 for 0000:00:02.0 on minor 0 [ 4.973489] BUG: key ffff88026f6e7bb0 not in .data! [ 4.973506] DEBUG_LOCKS_WARN_ON(1) [ 4.973518] ------------[ cut here ]------------ [ 4.973547] WARNING: CPU: 1 PID: 258 at kernel/locking/lockdep.c:3156 lockdep_init_map+0x1b2/0x1c0 [ 4.973567] Modules linked in: i915(+) x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii mei lpc_ich prime_numbers i2c_hid pinctrl_broxton pinctrl_intel [ 4.973645] CPU: 1 PID: 258 Comm: systemd-udevd Not tainted 4.13.0-rc3-CI-CI_DRM_2915+ #1 [ 4.973664] 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.973686] task: ffff8802704c2740 task.stack: ffffc90000224000 [ 4.973700] RIP: 0010:lockdep_init_map+0x1b2/0x1c0 [ 4.973712] RSP: 0018:ffffc90000227a10 EFLAGS: 00010282 [ 4.973726] RAX: 0000000000000016 RBX: ffff880262aac010 RCX: 0000000000000000 [ 4.973741] RDX: 0000000080000001 RSI: 0000000000000001 RDI: ffffffff810ed1ab [ 4.973757] RBP: ffffc90000227a30 R08: 0000000000000001 R09: 0000000000000000 [ 4.973774] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88026f6e7bb0 [ 4.973789] R13: 0000000000000000 R14: ffff88026f6e7b98 R15: ffffffff81a24da0 [ 4.973805] FS: 00007f588d7f58c0(0000) GS:ffff88027fc80000(0000) knlGS:0000000000000000 [ 4.973823] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.973837] CR2: 00000082482e32a0 CR3: 0000000270531000 CR4: 00000000003406e0 [ 4.973852] Call Trace: [ 4.973864] __kernfs_create_file+0x71/0xe0 [ 4.973876] sysfs_add_file_mode_ns+0x85/0x1a0 [ 4.973890] internal_create_group+0xe5/0x2b0 [ 4.973903] sysfs_create_group+0xe/0x10 [ 4.973985] i915_perf_register+0xd9/0x220 [i915] [ 4.974044] i915_driver_load+0xa72/0x16b0 [i915] [ 4.974124] i915_pci_probe+0x32/0x90 [i915] Annoyingly detected by CI, but not reported due to it occurring during boot and disabling lockdep for later runs. Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG interface") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Andrzej Datczuk <andrzej.datczuk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803223700.10329-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
2017-08-04drm/i915/gvt: Initialize MMIO Block with HW stateTina Zhang
MMIO block with tracked mmio, is introduced for the sake of performance of searching tracked mmio. All the tracked mmio needs to get the initial value from the HW state during vGPU being created. This patch is to initialize the tracked registers in MMIO block with the HW state. v2: Add "Fixes:" line for this patch (Zhenyu) Fixes: 65f9f6febf12 ("drm/i915/gvt: Optimize MMIO register handling for some large MMIO blocks") Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-04drm: i915: remove dead code and pointless local lut storagePeter Rosin
The driver stores lut values from the fbdev interface, and is able to give them back, but does not appear to do anything with these lut values. The generic fb helpers have replaced this function, and may even have made the driver work for the C8 mode from the fbdev interface. But that is untested. Since the fb helpers .gamma_set and .gamma_get are obsolete, remove the dead code. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-10-peda@axentia.se
2017-08-03drm/i915: enable WaDisableDopClkGating for sklPraveen Paneri
This WA is required when decoupled frequencies for slice and unslice are enabled. This disables DOP clock gating for skl. v2: enable the WA for all gen9 platforms (not just for SKL GT4 where the hang issue is originally reported) to avoid rare hangs (David) v3: as per WaDatabase, enable it only for SKL (Rodrigo) Cc: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by: Praveen Paneri <praveen.paneri@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1501781530-8186-1-git-send-email-praveen.paneri@intel.com
2017-08-03drm/i915: Fix PCH names for KBP and CNP.Rodrigo Vivi
No functional change. KBP was based on SPT and spec wasn't clear about the full name. There was the initial point of the "Point" confusion. Later the split with Coffee Lake and Cannon Lake both using CNP and also some uncertainty from the specs we had at that time made us to propagated the mistake along. So, let's fix this now and avoid propagating these wrong "points". Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170731185220.758-1-rodrigo.vivi@intel.com
2017-08-03drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG interfaceLionel Landwerlin
The motivation behind this new interface is expose at runtime the creation of new OA configs which can be used as part of the i915 perf open interface. This will enable the kernel to learn new configs which may be experimental, or otherwise not part of the core set currently available through the i915 perf interface. v2: Drop DRM_ERROR for userspace errors (Matthew) Add padding to userspace structure (Matthew) s/guid/uuid/ (Matthew) v3: Use u32 instead of int to iterate through registers (Matthew) v4: Lock access to dynamic config list (Lionel) v5: by Matthew: Fix uninitialized error values Fix incorrect unwiding when opening perf stream Use kmalloc_array() to store register Use uuid_is_valid() to valid config uuids Declare ioctls as write only Check padding members are set to 0 by Lionel: Return ENOENT rather than EINVAL when trying to remove non existing config v6: by Chris: Use ref counts for OA configs Store UUID in drm_i915_perf_oa_config rather then using pointer Shuffle fields of drm_i915_perf_oa_config to avoid padding v7: by Chris Rename uapi pointers fields to end with '_ptr' v8: by Andrzej, Marek, Sebastian Update register whitelisting by Lionel Add more register names for documentation Allow configuration programming in non-paranoid mode Add support for value filter for a couple of registers already programmed in other part of the kernel v9: Documentation fix (Lionel) Allow writing WAIT_FOR_RC6_EXIT only on Gen8+ (Andrzej) v10: Perform read access_ok() on register pointers (Lionel) Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Andrzej Datczuk <andrzej.datczuk@intel.com> Reviewed-by: Andrzej Datczuk <andrzej.datczuk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-2-lionel.g.landwerlin@intel.com
2017-08-03drm/i915: reorder NOA register definition to follow addressesLionel Landwerlin
It makes things easier to read when implementing whitelisting in the following patches. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-6-lionel.g.landwerlin@intel.com
2017-08-03drm/i915/perf: disable NOA logic when not usedLionel Landwerlin
We already do it on Haswell and the documentation says it saves power. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-5-lionel.g.landwerlin@intel.com
2017-08-03drm/i915/perf: leave GDT_CHICKEN_BITS programming in configsLionel Landwerlin
There will be a need for userspaces configurations to set this register. We can apply the same model inside the kernel for test configs. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-4-lionel.g.landwerlin@intel.com
2017-08-03drm/i915/perf: prune OA configsLionel Landwerlin
In the following commit we'll introduce loadable userspace configs. This change reworks how configurations are handled in the perf driver and retains only the test configurations in kernel space. We now store the test config in dev_priv and resolve the id only once when opening the perf stream. The OA config is then handled through a pointer to the structure holding the configuration details. v2: Rework how test configs are handled (Lionel) v3: Use u32 to hold number of register (Matthew) v4: Removed unused dev_priv->perf.oa.current_config variable (Matthew) v5: Lock device when accessing exclusive_stream (Lionel) v6: Ensure OACTXCONTROL is always reprogrammed (Lionel) v7: Switch a couple of index variable from int to u32 (Matthew) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-3-lionel.g.landwerlin@intel.com
2017-08-03drm/i915/perf: fix flex eu registers programmingLionel Landwerlin
We were reserving fewer dwords in the ring than necessary. Indeed we're always writing all registers once, so discard the actual number of registers given by the user and just program the whitelisted ones once. Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+") Reported-by: Matthew Auld <matthew.william.auld@gmail.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20170803165812.2373-6-lionel.g.landwerlin@intel.com
2017-08-03drm/i915: add const to bin_attributeBhumika Goyal
Add const to bin_attribute structures as they are only passed to the functions sysfs_{remove/create}_bin_file or device_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structures to be const. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501694447-14356-1-git-send-email-bhumirks@gmail.com
2017-08-02drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lutMaarten Lankhorst
bdw_load_gamma_lut is writing beyond the array to the maximum value. The intend of the function is to clamp values > 1 to 1, so write the intended color to the max register. This fixes the following KASAN warning: [ 197.020857] [IGT] kms_pipe_color: executing [ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0 [ 197.078989] ================================================================== [ 197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839 [ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U 4.13.0-rc1-patser+ #5211 [ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 [ 197.079220] Call Trace: [ 197.079230] dump_stack+0x68/0x9e [ 197.079239] print_address_description+0x6f/0x250 [ 197.079251] kasan_report+0x216/0x370 [ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915] [ 197.079460] __asan_report_load2_noabort+0x14/0x20 [ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079612] broadwell_load_luts+0x1df/0x550 [i915] [ 197.079690] intel_color_load_luts+0x7b/0x80 [i915] [ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915] [ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper] [ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915] [ 197.079937] intel_update_crtc+0x238/0x330 [i915] [ 197.080016] intel_update_crtcs+0x10f/0x210 [i915] [ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915] [ 197.080101] ? _raw_spin_unlock+0x3c/0x40 [ 197.080110] ? __queue_work+0xb40/0xbf0 [ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915] [ 197.080195] ? trace_hardirqs_on+0xd/0x10 [ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915] [ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915] [ 197.080336] ? debug_object_activate+0x39e/0x580 [ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915] [ 197.080409] ? __might_sleep+0x15b/0x180 [ 197.080483] intel_atomic_commit+0x944/0xa70 [i915] [ 197.080490] ? refcount_dec_and_test+0x11/0x20 [ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm] [ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm] [ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper] [ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm] [ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm] [ 197.080783] ? __might_fault+0x104/0x180 [ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm] [ 197.080885] drm_ioctl+0x624/0x8f0 [drm] [ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080934] ? drm_getunique+0x210/0x210 [drm] [ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0 [ 197.080949] ? lock_downgrade+0x610/0x610 [ 197.080957] ? __lru_cache_add+0x15a/0x180 [ 197.080967] do_vfs_ioctl+0xd92/0xe40 [ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0 [ 197.080982] ? selinux_capable+0x20/0x20 [ 197.080991] ? __do_page_fault+0x7b7/0x9a0 [ 197.080997] ? lock_downgrade+0x5bb/0x610 [ 197.081007] ? security_file_ioctl+0x57/0x90 [ 197.081016] SyS_ioctl+0x4e/0x80 [ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad [ 197.081030] RIP: 0033:0x7f61f287a987 [ 197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987 [ 197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003 [ 197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000 [ 197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58 [ 197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Martin Peres <martin.peres@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Kiran S Kumar <kiran.s.kumar@intel.com> Cc: Kausal Malladi <kausalmalladi@gmail.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.com Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
2017-08-02drm/i915/gvt: clean workload queue if error happenedChuanxiao Dong
If a workload caused a HW GPU hang or it is in the middle of vGPU reset, the workload queue should be cleaned up to emulate the hang state of the GPU. v2: - use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu) Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-02drm/i915/gvt: change resetting to resetting_engChuanxiao Dong
Use resetting_eng to identify which engine is resetting so the rest ones' workload won't be impacted v2: - use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu) Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-01drm: Plumb modifiers through plane initBen Widawsky
This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM drivers to initialize their list of supported modifiers upon initializing the plane. v2: A minor addition from Daniel v3: * Updated commit message * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu) * Remove some excess newlines (Liviu) * Update comment for > 64 modifiers (Liviu) v4: Minor comment adjustments (Liviu) v5: Some new platforms added due to rebase v6: Add some missed plane inits (or maybe they're new - who knows at this point) (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (v2) Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-07-31drm/i915: Update DRIVER_DATE to 20170731Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-28drm/i915: Remove unused i915_err_print_instdoneTvrtko Ursulin
Just a simple code cleanup, below commit forgot to remove a function which it made unused: commit eaa14c24864ecfc60fb591f3b20747af7c67d446 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 19 13:52:03 2016 +0100 drm/i915: Stop reporting error details in dmesg as well as the error-state As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). v2: Chris Wilson dag out the relevant commit. Commit msg updated. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170727110113.16942-1-tvrtko.ursulin@linux.intel.com
2017-07-28drm/i915: Include mbox details for pcode read/write failuresChris Wilson
If we fail at punit communication, include both the mbox address and the value we tried to write so that we can identify the invalid sequence. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170728085022.1586-1-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27Merge tag 'gvt-fixes-2017-07-26' of https://github.com/01org/gvt-linux into ↵Daniel Vetter
drm-intel-fixes gvt-fixes-2017-07-26 - Turn on KBL support for more SKUs (Jianjun) - Fix vblank timer close bug (Fred) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170726075621.hrauvik62gi2jecj@zhen-hp.sh.intel.com
2017-07-27drm/i915: Fix bad comparison in skl_compute_plane_wm.Maarten Lankhorst
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler warning: drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than 0 or 1. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d555cb5827d6 ("drm/i915/skl+: use linetime latency if ddb size is not available") Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com> Reported-by: David Binderman <dcb314@hotmail.com> Cc: David Binderman <dcb314@hotmail.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+ Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> (cherry picked from commit 54d20ed1fff23c7d2633f01fc788111bf9c51c5d) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170717111355.4523-1-maarten.lankhorst@linux.intel.com Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-07-27drm/i915: Force CPU synchronisation even if userspace requests ASYNCChris Wilson
The goal here was to minimise doing any thing or any check inside the kernel that was not strictly required. For a userspace that assumes complete control over the cache domains, the kernel is usually using outdated information and may trigger clflushes where none were required. However, swapping is a situation where userspace has no knowledge of the domain transfer, and will leave the object in the CPU cache. The kernel must flush this out to the backing storage prior to use with the GPU. As we use an asynchronous task tracked by an implicit fence for this, we also need to cancel the ASYNC flag on the object so that the object will wait for the clflush to complete before being executed. This also absolves userspace of the responsibility imposed by commit 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") that its needed to ensure that the object was out of the CPU cache prior to use on the GPU. Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-5-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 0f46daa1a273779a0b73d768a788ca3f04238f9c) Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Only skip updating execobject.offset after errorChris Wilson
I was being overly paranoid in not updating the execobject.offset after performing the fallback copy where we set reloc.presumed_offset to -1. The thinking was to ensure that a subsequent NORELOC execbuf would be forced to process the invalid relocations. However this is overkill so long as we *only* update the execobject.offset following a successful update of the relocation value witin the batch. If we have to repeat the execbuf due to a later interruption, then we may skip the relocations on the second pass (honouring NORELOC) since the execobject.offset match the actual offsets (even though reloc.presumed_offset is garbage). Subsequent calls to execbuf with NORELOC should themselves ensure that the reloc.presumed_offset have been corrected in case of future migration. Reporting back the actual execobject.offset, even when reloc.presumed_offset is garbage, ensures that reuse of those objects use the latest information to avoid relocations. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-4-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 1f727d9e725a408ef58d159c20fb2e51818ff153) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Only mark the execobject as pinned on successChris Wilson
If we fail to acquire a fence (for old school fenced GPU access) then we unwind the vma reservation, including its pin. However, we were making the execobject as holding the pin before erring out, leading to a double unpin: [ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287! [ 3193.998131] invalid opcode: 0000 [#1] PREEMPT SMP [ 3194.002816] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me e1000e mei prime_numbers ptp pps_core [last unloaded: i915] [ 3194.022841] CPU: 0 PID: 8123 Comm: kms_flip Tainted: G U 4.13.0-rc1-CI-CI_DRM_471+ #1 [ 3194.031765] Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A04 11/05/2007 [ 3194.040343] task: ffff8800785d4c40 task.stack: ffffc90001768000 [ 3194.046339] RIP: 0010:eb_release_vmas.isra.6+0x119/0x180 [i915] [ 3194.052234] RSP: 0018:ffffc9000176ba80 EFLAGS: 00010246 [ 3194.057439] RAX: 00000000000003c0 RBX: ffff8800710fc2d8 RCX: ffff8800588e4f48 [ 3194.064546] RDX: ffffffff1fffffff RSI: 00000000ffffffff RDI: ffff8800588e00d0 [ 3194.071654] RBP: ffffc9000176bab0 R08: 0000000000000000 R09: 0000000000000000 [ 3194.078761] R10: 0000000000000040 R11: 0000000000000001 R12: ffff880060822f00 [ 3194.085867] R13: 0000000000000310 R14: 00000000000003b8 R15: ffffc9000176bbb0 [ 3194.092975] FS: 00007fd2b94aba40(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000 [ 3194.101033] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3194.106754] CR2: 00007ffbec3ff000 CR3: 0000000074e67000 CR4: 00000000000006f0 [ 3194.113861] Call Trace: [ 3194.116321] eb_relocate_slow+0x67/0x4e0 [i915] [ 3194.120861] i915_gem_do_execbuffer+0x429/0x1260 [i915] [ 3194.126070] ? lock_acquire+0xb5/0x210 [ 3194.129803] ? __might_fault+0x39/0x90 [ 3194.133563] i915_gem_execbuffer2+0x9b/0x1b0 [i915] [ 3194.138447] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915] [ 3194.143478] drm_ioctl_kernel+0x64/0xb0 [ 3194.147298] drm_ioctl+0x2cd/0x390 [ 3194.150710] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915] [ 3194.155741] ? finish_task_switch+0xa5/0x210 [ 3194.159993] ? finish_task_switch+0x6a/0x210 [ 3194.164247] do_vfs_ioctl+0x90/0x670 [ 3194.167806] ? entry_SYSCALL_64_fastpath+0x5/0xb1 [ 3194.172492] ? __this_cpu_preempt_check+0x13/0x20 [ 3194.177176] ? trace_hardirqs_on_caller+0xe7/0x1c0 [ 3194.181946] SyS_ioctl+0x3c/0x70 [ 3194.185159] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 3194.189756] RIP: 0033:0x7fd2b76a8587 [ 3194.193314] RSP: 002b:00007fff074845b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 3194.200855] RAX: ffffffffffffffda RBX: ffffffff8146da43 RCX: 00007fd2b76a8587 [ 3194.207962] RDX: 00007fff074846e0 RSI: 0000000040406469 RDI: 0000000000000003 [ 3194.215068] RBP: ffffc9000176bf88 R08: 0000000000000000 R09: 0000000000000003 [ 3194.222175] R10: 00007fd2b796bb58 R11: 0000000000000246 R12: 00007fff07484880 [ 3194.229280] R13: 0000000000000003 R14: 0000000040406469 R15: 0000000000000000 [ 3194.236386] ? __this_cpu_preempt_check+0x13/0x20 [ 3194.241070] Code: 24 b0 00 00 00 48 85 c9 0f 84 6c ff ff ff 8b 41 20 85 c0 7e 73 83 e8 01 89 41 20 41 8b 84 24 e8 00 00 00 a8 0f 0f 85 5f ff ff ff <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d f3 c3 49 8b 84 [ 3194.259943] RIP: eb_release_vmas.isra.6+0x119/0x180 [i915] RSP: ffffc9000176ba80 [ 3194.268047] ---[ end trace 1d7348c6575d8800 ]--- [ 3673.658819] softdog: Initiating panic [ 3673.662471] Kernel panic - not syncing: Software Watchdog Timer expired [ 3673.669066] Kernel Offset: disabled [ 3673.672541] Rebooting in 1 seconds.. Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-3-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 1da7b54c46bcfe5484af0b27d8c9003b238031b0) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Remove assertion from raw __i915_vma_unpin()Chris Wilson
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to cleanup. However, on an overflow the pin_count bitfield will be zero, triggering an assertion, even though we the intention is to merely warn and report the error back to the user (as historically the culprit has be a leak in the display code). Fixes: 20dfbde463c8 ("drm/i915: Wrap vma->pin_count accessors with small inline helpers") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-2-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 67fddd902b8e37b15a905c287ce4e40f52a564af) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/cnl: Fix loadgen select programming on ddi vswing sequenceNavare, Manasi D
The condition for setting the Loadgen Select bit of PORT_TX_DW4 register during DDI Vswing Sequence should be Bit rate <=6 GHz whereas the existing code checks only Bit Rate < 6GHz. This patch fixes this condition. While at it also remove the redundant paranthesis. Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1500329122-32662-1-git-send-email-manasi.d.navare@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit a8e45a1c42d11597e975f3e5f2fe182f90cdaa7f) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Fix scaler init during CRTC HW state readoutImre Deak
The scaler allocation code depends on a non-zero default value for the crtc scaler_id, so make sure we initialize the scaler state accordingly even if the crtc is off. This fixes at least an initial YUV420 modeset (added in a follow-up patchset by Shashank) when booting with the screen off: after the initial HW readout and modeset which enables the scaler a subsequent modeset will disable the scaler which isn't properly allocated. This results in a funky HW state where the pipe scaler HW registers can't be modified and the normally black screen is grey and shifted to the right or jitters. The problem was revealed by Shashank's YUV420 patchset and first reported by Ville. v2: - In the stable tag also include versions which need backporting (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: <stable@vger.kernel.org> # 4.2.x Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 5fb9dadf336f3590c799e8cbde348215dccc2aa2) Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'Christophe JAILLET
Goto the right label in case of error, otherwise there is a leak. This has been introduced by c5cf9a9147ff. In this patch a goto has not been updated. Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20170719223503.30580-1-christophe.jaillet@wanadoo.fr Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit a5ec7fe81a6ec38cb8b8a798d0552cbcadce7aa9) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Unbreak gpu reset vs. modeset lockingDaniel Vetter
Taking the modeset locks unconditionally isn't the greatest idea, because atm that part is still broken and times out (and then atomic keels over). And there's really no reason to do so, the old code didn't do that either. To make the patch a bit simpler let's also nuke 2 cases that are only around for the old mmioflip paths. Atomic nonblocking workers will not die (minus bugs) when a gpu reset happens. And of course this doesn't fix any of the gpu reset vs. modeset deadlock fun, but it at least stop modern CI machines from keeling over all over the place for no reason at all. And we still have the explicit testcases to run the fake gpu reset, so coverage isn't that much worse. v2: Split out additional changes on top, restrict this to purely reducing the critical section of modeset locks. v2: Review from Maarten - update comments - don't oops when state is NULL in intel_finish_reset, but try to at least still drop locks properly. The hw is going to be toast anyway. Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch (cherry picked from commit ce87ea15ebc60a9f8f156b2549f7b2cf7fe48d04) Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Fix cursor updates on some platformsVille Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor on some platforms. My 830 works just fine, but eg. 945 and PNV don't. On those platforms we need to arm even the CURPOS update with a CURBASE write. Even worse, a write to any of the cursor register apart from CURBASE will cancel an already pending cursor update. So if we have armed a CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank would cancel that armed update. Thus we're left with a cursor that doesn't appear to move, or even change shape. Fix the problem by always performing the CURBASE write after a CURPOS write. Bspec is somewhat unclear which platforms actually require this CURBASE write and which don't. So to keep it simple and to make sure we really fix the problem across all supported devices, let's just perform the CURBASE write unconditionally. Cc: Paul Menzel <pmenzel@molgen.mpg.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790 Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com (cherry picked from commit 8753d2bc5e49daad301ce65f5dada57ed924fad6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Fix user ptr check size in eb_relocate_vma()Imre Deak
Fix the sizeof(ptr) vs. sizeof(*ptr) typo. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com (cherry picked from commit edd9003f7f9dddd28fdd768e6e7569d996c769cb) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/sdvo: Shut up state checker with hdmi cards on gen3Daniel Vetter
The hdmi bits simply don't exist, so nerf them. I think audio doesn't work on gen3 at all, and for the limited color range we should probably use the colorimetry sdvo paramater instead of the bit in the port. But fixing sdvo isn't my goal, I just want to get the backtrace out of the way, and this takes care of that. Still, while at it fix the missing read-out of the gen4 audio bit, maybe that part even works ... v2: Instead of trying to plug the damage in ->compute_config() make sure we never set intel_sdvo->is_hdmi, which stops the bad state at the source. Suggested by Chris Wilson. Also make sure we don't break this by accident by putting a WARN_ON in place. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170726193251.25393-1-daniel.vetter@ffwll.ch
2017-07-27drm/i915: Rework sdvo proxy i2c lockingDaniel Vetter
lockdep complaints about a locking recursion for the i2c bus lock because both the sdvo ddc proxy bus and the gmbus nested within use the same locking class. It's not really a deadlock since we never nest the other way round, but it's annoying. Fix it by pulling the gmbus locking into the i2c lock_ops for both i2c_adapater and making sure that the ddc_proxy_xfer function is entirely lockless. Re-layouting the extracted function resulted in some whitespace cleanups, I figured we might as well keep them. v2: Review from Chris: - s/locked/unlocked/ since I got the naming backwards - Use the vfuncs of the proxied adatper instead of re-rolling copies. That's more consistent with the other proxying we're doing. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170726132647.31833-1-daniel.vetter@ffwll.ch
2017-07-27drm/i915: Call the unlocked version of i915_gem_object_get_pages()Chris Wilson
When we hold for the lock for swapping out the shmem pages for the physically contiguous pages, we have to call the unlocked version of get_pages! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101934 Fixes: 35d23516946e ("drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more appropriately") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170726181602.23527-2-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Move i915_gem_object_phys_attach()Chris Wilson
Prevent a forward declaration in the next patch. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170726181602.23527-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Pin the pages before acquiring struct_mutex for displayChris Wilson
Since we don't need the struct_mutex to acquire the object's pages, call i915_gem_object_pin_pages() before we bind the object into the GGTT. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170726160038.29487-3-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more appropriatelyChris Wilson
Actually transferring from shmemfs to the physically contiguous set of pages should be wholly guarded by its obj->mm.lock! v2: Remember to free the old pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170726160038.29487-2-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Trim struct_mutex usage for kmsChris Wilson
Reduce acquisition of struct_mutex to the critical regions that must hold it; for KMS, we need struct_mutex currently only for the purpose of pinning/unpinning the framebuffer's VMA into the global GTT. This allows us to avoid taking the struct_mutex when disabling the CRTC (i.e. NULL framebuffer objects) before a reset. (Not yet achieving the full goal of avoiding the strut_mutex nesting, but good enough to break the first half of the reset deadlock.) v2: Keep pages pinning inside struct_mutex for the moment. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170726160038.29487-1-chris@chris-wilson.co.uk [danvet: Drop another case of grabbing dev->struct_mutex around cleanup_planes, which popped up because I had to redo the drm-next backmerge for entirely different reasons. Acked by Chris on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Handle msr read failure gracefullyGabriel Krisman Bertazi
When reading the i915_energy_uJ debugfs file, it tries to fetch MSR_RAPL_POWER_UNIT, which might not be available, like in a vm environment, causing the exception shown below. We can easily prevent it by doing a rdmsrl_safe read instead, which will handle the exception, allowing us to abort the debugfs file read. This was caught by the new igt@debugfs_test@read_all_entries testcase in the CI. unchecked MSR access error: RDMSR from 0x606 at rIP:0xffffffffa0078f66 (i915_energy_uJ+0x36/0xb0 [i915]) Call Trace: seq_read+0xdc/0x3a0 full_proxy_read+0x4f/0x70 __vfs_read+0x23/0x120 ? putname+0x4f/0x60 ? rcu_read_lock_sched_held+0x75/0x80 ? entry_SYSCALL_64_fastpath+0x5/0xb1 vfs_read+0xa0/0x150 SyS_read+0x44/0xb0 entry_SYSCALL_64_fastpath+0x1c/0xb1 RIP: 0033:0x7f1f5e9f4500 RSP: 002b:00007ffc77e65cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: ffffffff8146e003 RCX: 00007f1f5e9f4500 RDX: 0000000000000200 RSI: 00007ffc77e65d10 RDI: 0000000000000006 RBP: ffffc900007abf88 R08: 0000000001eaff20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 0000000000000005 R15: 0000000001eb94db ? __this_cpu_preempt_check+0x13/0x20 v2: - Drop unsigned long long cast and improve calculation (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101901 Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/87o9s7zrx3.fsf@dilma.collabora.co.uk Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Force CPU synchronisation even if userspace requests ASYNCChris Wilson
The goal here was to minimise doing any thing or any check inside the kernel that was not strictly required. For a userspace that assumes complete control over the cache domains, the kernel is usually using outdated information and may trigger clflushes where none were required. However, swapping is a situation where userspace has no knowledge of the domain transfer, and will leave the object in the CPU cache. The kernel must flush this out to the backing storage prior to use with the GPU. As we use an asynchronous task tracked by an implicit fence for this, we also need to cancel the ASYNC flag on the object so that the object will wait for the clflush to complete before being executed. This also absolves userspace of the responsibility imposed by commit 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") that its needed to ensure that the object was out of the CPU cache prior to use on the GPU. Fixes: 77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-5-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Only skip updating execobject.offset after errorChris Wilson
I was being overly paranoid in not updating the execobject.offset after performing the fallback copy where we set reloc.presumed_offset to -1. The thinking was to ensure that a subsequent NORELOC execbuf would be forced to process the invalid relocations. However this is overkill so long as we *only* update the execobject.offset following a successful update of the relocation value witin the batch. If we have to repeat the execbuf due to a later interruption, then we may skip the relocations on the second pass (honouring NORELOC) since the execobject.offset match the actual offsets (even though reloc.presumed_offset is garbage). Subsequent calls to execbuf with NORELOC should themselves ensure that the reloc.presumed_offset have been corrected in case of future migration. Reporting back the actual execobject.offset, even when reloc.presumed_offset is garbage, ensures that reuse of those objects use the latest information to avoid relocations. Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-4-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Only mark the execobject as pinned on successChris Wilson
If we fail to acquire a fence (for old school fenced GPU access) then we unwind the vma reservation, including its pin. However, we were making the execobject as holding the pin before erring out, leading to a double unpin: [ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287! [ 3193.998131] invalid opcode: 0000 [#1] PREEMPT SMP [ 3194.002816] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me e1000e mei prime_numbers ptp pps_core [last unloaded: i915] [ 3194.022841] CPU: 0 PID: 8123 Comm: kms_flip Tainted: G U 4.13.0-rc1-CI-CI_DRM_471+ #1 [ 3194.031765] Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A04 11/05/2007 [ 3194.040343] task: ffff8800785d4c40 task.stack: ffffc90001768000 [ 3194.046339] RIP: 0010:eb_release_vmas.isra.6+0x119/0x180 [i915] [ 3194.052234] RSP: 0018:ffffc9000176ba80 EFLAGS: 00010246 [ 3194.057439] RAX: 00000000000003c0 RBX: ffff8800710fc2d8 RCX: ffff8800588e4f48 [ 3194.064546] RDX: ffffffff1fffffff RSI: 00000000ffffffff RDI: ffff8800588e00d0 [ 3194.071654] RBP: ffffc9000176bab0 R08: 0000000000000000 R09: 0000000000000000 [ 3194.078761] R10: 0000000000000040 R11: 0000000000000001 R12: ffff880060822f00 [ 3194.085867] R13: 0000000000000310 R14: 00000000000003b8 R15: ffffc9000176bbb0 [ 3194.092975] FS: 00007fd2b94aba40(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000 [ 3194.101033] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3194.106754] CR2: 00007ffbec3ff000 CR3: 0000000074e67000 CR4: 00000000000006f0 [ 3194.113861] Call Trace: [ 3194.116321] eb_relocate_slow+0x67/0x4e0 [i915] [ 3194.120861] i915_gem_do_execbuffer+0x429/0x1260 [i915] [ 3194.126070] ? lock_acquire+0xb5/0x210 [ 3194.129803] ? __might_fault+0x39/0x90 [ 3194.133563] i915_gem_execbuffer2+0x9b/0x1b0 [i915] [ 3194.138447] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915] [ 3194.143478] drm_ioctl_kernel+0x64/0xb0 [ 3194.147298] drm_ioctl+0x2cd/0x390 [ 3194.150710] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915] [ 3194.155741] ? finish_task_switch+0xa5/0x210 [ 3194.159993] ? finish_task_switch+0x6a/0x210 [ 3194.164247] do_vfs_ioctl+0x90/0x670 [ 3194.167806] ? entry_SYSCALL_64_fastpath+0x5/0xb1 [ 3194.172492] ? __this_cpu_preempt_check+0x13/0x20 [ 3194.177176] ? trace_hardirqs_on_caller+0xe7/0x1c0 [ 3194.181946] SyS_ioctl+0x3c/0x70 [ 3194.185159] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 3194.189756] RIP: 0033:0x7fd2b76a8587 [ 3194.193314] RSP: 002b:00007fff074845b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 3194.200855] RAX: ffffffffffffffda RBX: ffffffff8146da43 RCX: 00007fd2b76a8587 [ 3194.207962] RDX: 00007fff074846e0 RSI: 0000000040406469 RDI: 0000000000000003 [ 3194.215068] RBP: ffffc9000176bf88 R08: 0000000000000000 R09: 0000000000000003 [ 3194.222175] R10: 00007fd2b796bb58 R11: 0000000000000246 R12: 00007fff07484880 [ 3194.229280] R13: 0000000000000003 R14: 0000000040406469 R15: 0000000000000000 [ 3194.236386] ? __this_cpu_preempt_check+0x13/0x20 [ 3194.241070] Code: 24 b0 00 00 00 48 85 c9 0f 84 6c ff ff ff 8b 41 20 85 c0 7e 73 83 e8 01 89 41 20 41 8b 84 24 e8 00 00 00 a8 0f 0f 85 5f ff ff ff <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d f3 c3 49 8b 84 [ 3194.259943] RIP: eb_release_vmas.isra.6+0x119/0x180 [i915] RSP: ffffc9000176ba80 [ 3194.268047] ---[ end trace 1d7348c6575d8800 ]--- [ 3673.658819] softdog: Initiating panic [ 3673.662471] Kernel panic - not syncing: Software Watchdog Timer expired [ 3673.669066] Kernel Offset: disabled [ 3673.672541] Rebooting in 1 seconds.. Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-3-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Remove assertion from raw __i915_vma_unpin()Chris Wilson
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to cleanup. However, on an overflow the pin_count bitfield will be zero, triggering an assertion, even though we the intention is to merely warn and report the error back to the user (as historically the culprit has be a leak in the display code). Fixes: 20dfbde463c8 ("drm/i915: Wrap vma->pin_count accessors with small inline helpers") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-2-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/cnl: Fix loadgen select programming on ddi vswing sequenceNavare, Manasi D
The condition for setting the Loadgen Select bit of PORT_TX_DW4 register during DDI Vswing Sequence should be Bit rate <=6 GHz whereas the existing code checks only Bit Rate < 6GHz. This patch fixes this condition. While at it also remove the redundant paranthesis. Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1500329122-32662-1-git-send-email-manasi.d.navare@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/fbc: add comments to the FBC auxiliary structsPaulo Zanoni
I wrote this code an year and a half ago and I couldn't exactly remember the main differences of these two structures when reviewing a new FBC patch. Add some comments to help explain what's the purpose of each struct. For the record, the original commits are: b183b3f14395 ("drm/i915/fbc: introduce struct intel_fbc_reg_params") aaf78d276ba0 ("drm/i915/fbc: introduce struct intel_fbc_state_cache") Cc: Praveen Paneri <praveen.paneri@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714193822.12121-1-paulo.r.zanoni@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: cleanup the CHICKEN_MISC_2 (re)definitionsPaulo Zanoni
* Don't define it twice. * Define MSBs first, like the rest of i915_reg.h. * Add CNL_ prefix to the bit that arrived in CNL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714175228.27019-1-paulo.r.zanoni@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/selftests: Fix kbuild errorChris Wilson
After applying af2788925ae0 ("drm/i915: Squelch reset messages during selftests") out of sequence, I missed fixing up a call to i915_reset(). Reported-by: kbuild test robot <kbuild-all@01.org> Fixes: af2788925ae0 ("drm/i915: Squelch reset messages during selftests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170725125336.11969-1-chris@chris-wilson.co.uk Reviewed-by: David Weinehall <david.weinehall@linux.intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Squelch reset messages during selftestsChris Wilson
During our selftests, we try reseting the GPU tens of thousands of times, flooding the dmesg with our reset spam drowning out any potential warnings. Add an option to i915_reset()/i915_reset_engine() to specify a quiet reset for selftesting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-19-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-06 00:27:22 +0000