- 07 Oct, 2017 13 commits
-
-
Matthew Auld authored
Before we can fully enable 64K pages, we need to first support a 64K scratch page if we intend to support the case where we have object sizes < 2M, since any scratch PTE must also point to a 64K region. Without this our 64K usage is limited to objects which completely fill the page-table, and therefore don't need any scratch. v2: add reminder about why 48b PPGTT Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
Support inserting 2M gtt pages into the 48b PPGTT. v2: sanity check sg->length against page_size v3: don't recalculate rem on each loop whitespace breakup Signed-off-by: -
Matthew Auld authored
When SW enables the use of 2M/1G pages, it must disable the GTT cache. v2: don't disable for Cherryview which doesn't even support 48b PPGTT! v3: explicitly check that the system does support 2M/1G pages v4: split WA and decision logic Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171006145041.21673-12-matthew.auld@intel.comSigned-off-by:
-
Matthew Auld authored
Before we can enable 64K pages through the IPS bit, we must first enable it through MMIO, otherwise the page-walker will simply ignore it. v2: add comment mentioning that 64K is BDW+ v3: move to more suitable home Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Matthew Auld authored
We can't mix 64K and 4K pte's in the same page-table, so for now we align 64K objects to 2M to avoid any potential mixing. This is potentially wasteful but in reality shouldn't be too bad since this only applies to the virtual address space of a 48b PPGTT. v2: don't separate logically connected ops Suggested-by:
-
Matthew Auld authored
For the 48b PPGTT try to align the vma start address to the required page size boundary to guarantee we use said page size in the gtt. If we are dealing with multiple page sizes, we can't guarantee anything and just align to the largest. For soft pinning and objects which need to be tightly packed into the lower 32bits we don't force any alignment. v2: various improvements suggested by Chris v3: use set_pages and better placement of page_sizes v4: prefer upper_32_bits() v5: assign vma->page_sizes = vma->obj->page_sizes directly prefer sizeof(vma->page_sizes) v6: fixup checking of end to exclude GGTT (which are assumed to be limited to 4G). Signed-off-by: -
Matthew Auld authored
Move the setting/clearing of the vma->pages to a vm operation. Doing so neatens things up a little, but more importantly gives us a sane place to also set/clear the vma->pages_sizes, which we introduce later in preparation for supporting huge-pages. v2: remove redundant vma->pages check v3: GEM_BUG_ON(vma->pages) following i915_vma_remove Suggested-by:
-
Matthew Auld authored
In preparation for supporting huge gtt pages for the ppgtt, we introduce page size members for gem objects. We fill in the page sizes by scanning the sg table. v2: pass the sg_mask to set_pages v3: calculate the sg_mask inline with populating the sg_table where possible, and pass to set_pages along with the pages. v4: bunch of improvements from Joonas v5: fix num_pages blunder introduce i915_sg_page_sizes helper v6: prefer GEM_BUG_ON(sizes == 0) Signed-off-by: -
Matthew Auld authored
Each backend is now responsible for calling __i915_gem_object_set_pages upon successfully gathering its backing storage. This eliminates the inconsistency between the async and sync paths, which stands out even more when we start throwing around an sg_mask in a later patch. Suggested-by:
-
Matthew Auld authored
In preparation for huge gtt pages expose page_sizes as part of the device info, to indicate the page sizes supported by the HW. Currently only 4K is supported. v2: s/page_size_mask/page_sizes/ v3: introduce I915_GTT_MAX_PAGE_SIZE Signed-off-by:
-
Matthew Auld authored
Enable transparent-huge-pages through gemfs by mounting with huge=within_size. v2: sprinkle within_size comment Signed-off-by:
-
Matthew Auld authored
Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so moves us away from the shmemfs shm_mnt, and gives us the much needed flexibility to do things like set our own mount options, namely huge= which should allow us to enable the use of transparent-huge-pages for our shmem backed objects. v2: various improvements suggested by Joonas v3: move gemfs instance to i915.mm and simplify now that we have file_setup_with_mnt v4: fallback to tmpfs shm_mnt upon failure to setup gemfs v5: make tmpfs fallback kinder v5: better gemfs failure message flags variable Signed-off-by: -
Matthew Auld authored
We are planning to use our own tmpfs mnt in i915 in place of the shm_mnt, such that we can control the mount options, in particular huge=, which we require to support huge-gtt-pages. So rather than roll our own version of __shmem_file_setup, it would be preferred if we could just give shmem our mnt, and let it do the rest. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
-
- 06 Oct, 2017 19 commits
-
-
Chris Wilson authored
Michel Thierry noticed that we were applying WaDisableCtxRestoreArbitration even to gen9, which does not require the w/a. The rationale is that we need to enable MI arbitration for execlists to work, and to be safe we do that before every batch (in addition to every context switch into the batch). Since this is not clear from the single line comment suggesting the MI_ARB_ENABLE is solely for the w/a, add a little more detail. Signed-off-by:
Michel Thierry <michel.thierry@intel.com>
-
Chris Wilson authored
If two nop's (requests in-flight following a wedged device) complete at the same time, the global_seqno value written to the HWSP is undefined as the two threads are not serialized. v2: Use irqsafe spinlock. We expect the callback may be called from inside another irq spinlock, so we can't unconditionally restore irqs. Fixes: ce1135c7 ("drm/i915: Complete requests in nop_submit_request") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171006115617.18432-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Not all compilers are able to determine that pg is guarded by wait_fuses and so may think that pg is used uninitialized. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b2891eb2 ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Chris Wilson authored
If a worker requeues itself, it may switch to a different kworker pool, which flush_work() considers as complete. To be strict, we then need to keep flushing the work until it is no longer pending. References: https://bugs.freedesktop.org/show_bug.cgi?id=102456Signed-off-by:
-
Michal Wajdeczko authored
Commit faf65486 ("drm/i915: Unify uC variable types to avoid flooding checkpatch.pl") breaks 32-bit kernel builds. Lets use cast helper to make compiler happy. v2: introduce ptr_to_u64 (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171006130844.49012-1-michal.wajdeczko@intel.comReviewed-by:
-
Michal Wajdeczko authored
Fix includes order and make sure we only include required headers. While here, make intel_huc.h header self-contained. Signed-off-by:
-
Joonas Lahtinen authored
With the code motion mostly done, convert all the uC code away from uint??_t at once (only a couple dozen variables), so that reading the checkpatch.pl output should actually pinpoint if a new uint??_t was accidentally introduced. v2: - Include intel_uc_fw.h too (Sagar) Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
-
Joonas Lahtinen authored
Lets not introduce BIT() macro requirement for UAPI for now. Fixes: 3fd3a6ff ("drm/i915: Simplify i915_reg_read_ioctl") Signed-off-by:
-
Maarten Lankhorst authored
crtc_state_is_legacy_gamma also checks for CTM, which was missing from intel_color_check. By using the same condition for commit and check we reduce the chance of mismatches. This was spotted by KASAN while trying to rework kms_color igt test. [ 72.008660] ================================================================== [ 72.009326] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.3+0x15c/0x360 [i915] [ 72.009519] Read of size 2 at addr ffff880220216e50 by task kms_color/1158 [ 72.009900] CPU: 2 PID: 1158 Comm: kms_color Tainted: G U W 4.14.0-rc3-patser+ #5281 [ 72.009921] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 72.009941] Call Trace: [ 72.009968] dump_stack+0xc5/0x151 [ 72.009996] ? _atomic_dec_and_lock+0x10f/0x10f [ 72.010024] ? show_regs_print_info+0x3c/0x3c [ 72.010072] print_address_description+0x7f/0x240 [ 72.010108] kasan_report+0x216/0x370 [ 72.010308] ? bdw_load_gamma_lut.isra.3+0x15c/0x360 [i915] [ 72.010349] __asan_load2+0x74/0x80 [ 72.010552] bdw_load_gamma_lut.isra.3+0x15c/0x360 [i915] [ 72.010772] broadwell_load_luts+0x1f0/0x300 [i915] [ 72.010997] intel_color_load_luts+0x36/0x40 [i915] [ 72.011205] intel_begin_crtc_commit+0xa1/0x310 [i915] [ 72.011283] drm_atomic_helper_commit_planes_on_crtc+0xa6/0x320 [drm_kms_helper] [ 72.011316] ? wait_for_completion_io+0x460/0x460 [ 72.011524] intel_update_crtc+0xe3/0x100 [i915] [ 72.011720] skl_update_crtcs+0x360/0x3f0 [i915] [ 72.011945] ? intel_update_crtcs+0xf0/0xf0 [i915] [ 72.012010] ? drm_atomic_helper_wait_for_dependencies+0x3d9/0x400 [drm_kms_helper] [ 72.012231] intel_atomic_commit_tail+0x8db/0x1500 [i915] [ 72.012273] ? __lock_is_held+0x9c/0xc0 [ 72.012494] ? skl_update_crtcs+0x3f0/0x3f0 [i915] [ 72.012518] ? find_next_bit+0xb/0x10 [ 72.012544] ? cpumask_next+0x1a/0x20 [ 72.012745] ? i915_sw_fence_complete+0x9d/0xe0 [i915] [ 72.012938] ? __i915_sw_fence_complete+0x5d0/0x5d0 [i915] [ 72.013176] intel_atomic_commit+0x528/0x570 [i915] [ 72.013280] ? drm_atomic_get_property+0xc00/0xc00 [drm] [ 72.013466] ? intel_atomic_commit_tail+0x1500/0x1500 [i915] [ 72.013496] ? kmem_cache_alloc_trace+0x266/0x280 [ 72.013714] ? intel_atomic_commit_tail+0x1500/0x1500 [i915] [ 72.013812] drm_atomic_commit+0x77/0x80 [drm] [ 72.013911] set_property_atomic+0x14a/0x210 [drm] [ 72.014015] ? drm_object_property_get_value+0x70/0x70 [drm] [ 72.014080] ? mutex_unlock+0xd/0x10 [ 72.014292] ? intel_atomic_commit_tail+0x1500/0x1500 [i915] [ 72.014379] drm_mode_obj_set_property_ioctl+0x1cf/0x310 [drm] [ 72.014481] ? drm_mode_obj_find_prop_id+0xa0/0xa0 [drm] [ 72.014510] ? lock_release+0x6c0/0x6c0 [ 72.014602] ? drm_is_current_master+0x46/0x60 [drm] [ 72.014706] drm_ioctl_kernel+0x148/0x1d0 [drm] [ 72.014799] ? drm_mode_obj_find_prop_id+0xa0/0xa0 [drm] [ 72.014898] ? drm_ioctl_permit+0x100/0x100 [drm] [ 72.014936] ? kasan_check_write+0x14/0x20 [ 72.015039] drm_ioctl+0x441/0x660 [drm] [ 72.015129] ? drm_mode_obj_find_prop_id+0xa0/0xa0 [drm] [ 72.015235] ? drm_getstats+0x20/0x20 [drm] [ 72.015287] ? ___might_sleep+0x159/0x340 [ 72.015311] ? find_held_lock+0xcf/0xf0 [ 72.015341] ? __schedule_bug+0x110/0x110 [ 72.015405] do_vfs_ioctl+0xa88/0xb10 [ 72.015449] ? ioctl_preallocate+0x1a0/0x1a0 [ 72.015487] ? selinux_capable+0x20/0x20 [ 72.015525] ? rcu_dynticks_momentary_idle+0x40/0x40 [ 72.015607] SyS_ioctl+0x4e/0x80 [ 72.015647] entry_SYSCALL_64_fastpath+0x18/0xad [ 72.015670] RIP: 0033:0x7ff74a3d04d7 [ 72.015691] RSP: 002b:00007ffc594bec08 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 72.015734] RAX: ffffffffffffffda RBX: ffffffff8718f54a RCX: 00007ff74a3d04d7 [ 72.015756] RDX: 00007ffc594bec40 RSI: 00000000c01864ba RDI: 0000000000000003 [ 72.015777] RBP: ffff880211c0ff98 R08: 0000000000000086 R09: 0000000000000000 [ 72.015799] R10: 00007ff74a691b58 R11: 0000000000000246 R12: 0000000000000355 [ 72.015821] R13: 00000000ff00eb00 R14: 0000000000000a00 R15: 00007ff746082000 [ 72.015857] ? trace_hardirqs_off_caller+0xfa/0x110 Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171005141520.23990-1-maarten.lankhorst@linux.intel.com [mlankhorst: s/crtc_state_is_legacy/&_gamma/ (danvet)] Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 82cf435b ("drm/i915: Implement color management on bdw/skl/bxt/kbl") Cc: <stable@vger.kernel.org> # v4.7+
-
Jani Nikula authored
Only assign the hooks once instead of overwriting for DDI. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/796b631d018fdd5aa2a3608c6a9b9fa196a50f76.1507200657.git.jani.nikula@intel.com
-
Jani Nikula authored
Reduce encoder specific checks from CRTC code. Reviewed-by:
-
Jani Nikula authored
Simplify CRTC enable. v2: Don't forget DSI (Daniel) Reviewed-by:
-
Jani Nikula authored
CRT being the only PCH encoder, we can simplify the crtc disable by pushing the PCH encoder specific parts to CRT encoder. v2: add hsw_disable_crt (Daniel), rebase Reviewed-by:
-
Jani Nikula authored
CRT being the only PCH encoder, we can simplify the crtc enable by pushing the PCH encoder specific parts to CRT encoder. v2: add separate hsw_enable_crt (Daniel), rebase Reviewed-by:
-
Michal Wajdeczko authored
Unify initialization of the uC firmware helper as we want to maximize code reuse. Signed-off-by:
-
Michal Wajdeczko authored
Fix includes order and make sure we only include required headers. Suggested-by:
-
Michal Wajdeczko authored
Move GuC core definitions into dedicated files as we want to keep GuC specific code in separated files. v2: move all functions in single patch (Joonas) fix old checkpatch issues (Sagar) v3: rebased Signed-off-by: -
Michal Wajdeczko authored
Move GuC submission declarations into dedicated header as we want to keep uC specific code in separate files. v2: fix include (Chris) update commit message (Joonas) Signed-off-by: -
Michal Wajdeczko authored
Move GuC log declarations into dedicated header as we want to keep component specific code in separate files. v2: fix includes (Chris) update commit message (Joonas) Suggested-by:
-
- 05 Oct, 2017 7 commits
-
-
Oscar Mateo authored
BSpec indicates exactly 16752 DWORDs (17 pages), plus one page for PPHWSP. Please notice that, when looking at the BSpec context image table, the right filter has to be applied (e.g. "CNL") as some rows are excluded for specific GENs. BSpec: 1383 v2: Update count and add BSpec tag (Joonas) v3: Warning about filters in the commit message (Joonas) Suggested-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Arnd Bergmann authored
One of the recent changes introduced a warning about undefined behavior in the sanity checking: drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_hdmi_level': drivers/gpu/drm/i915/intel_ddi.c:654:6: error: 'n_hdmi_entries' may be used uninitialized in this function [-Werror=maybe-uninitialized] It seems that the new cnl specific get_buf_trans functions can return uninitialized data if the voltage level is set to an unexpected value. This changes the code to always return '1' in that error case, which seems like the safest choice as we use one less than the number as an array index later on. Fixes: cc9cabfd ("drm/i915/cnl: Move voltage check into ddi buf trans functions.") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> [danvet: shut up gcc comment added.] Signed-off-by:
-
Arnd Bergmann authored
An earlier bugfix tried to work around this build failure: drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device': drivers/gpu/drm/i915/selftests/mock_gem_device.c:151:20: error: 'struct dev_archdata' has no member named 'iommu' Checking for CONFIG_IOMMU_API is not sufficient as a compile-time test since that may be enabled in configurations that have neither INTEL_IOMMU not AMD_IOMMU enabled. This changes the check to INTEL_IOMMU instead, as this is the only case we actually care about. Fixes: f46f156e ("drm/i915/selftests: Only touch archdata.iommu when it exists") Signed-off-by:
-
Chris Wilson authored
For the fake device we have our own set of mock contexts that need to match the real contexts we normally create. Currently this requires us to manually instantiate them for the selftests, which I forgot. Reported-by:
Matthew Auld <matthew.william.auld@gmail.com> Fixes: e7af3116 ("drm/i915: Introduce a preempt context") Signed-off-by:
-
Manasi Navare authored
For this specific PCI device, the eDP panel requires a higher panel power cycle delay of 1300ms where the minimum spec requirement of panel power cycle delay is 500ms. This fix in combination with correct timestamp at which we get the panel power off time fixes the dP AUX CH timeouts seen on various IGT tests. Fixes: c99a259b ("drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Acked-by:
-
Manasi Navare authored
Kernel stores the time in jiffies at which the eDP panel is turned off. This should be obtained after the panel is off (after the wait_panel_off). When we next attempt to turn the panel on, we use the difference between the timestamp at which we want to turn the panel on and timestamp at which panel was turned off to ensure that this is equal to panel power cycle delay and if not we wait for the remaining time. Not waiting for the panel power cycle delay can cause the panel to not turn on giving rise to AUX timeouts for the attempted AUX transactions. v2: * Separate lines for bugzilla (Jani Nikula) * Suggested by tag (Daniel Vetter) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions to set power states for downstream sinks. Apart from giving us the ability to set power state for individual sinks, this fixes the below test for me. $ xrandr --display :0 --output DP-2-2-8 --off $ xrandr --display :0 --output DP-2-2-1 --off $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen $ xrandr --display :0 --output DP-2-2-1 --auto v2: Modify and document the dpms and port disable order (Ville) Add comment explaining is_mst = !crtc_state equivalence(Ville, Maarten) v3 by Jani: rebase References: https://bugs.freedesktop.org/show_bug.cgi?id=90963 References: https://bugs.freedesktop.org/show_bug.cgi?id=88124 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:Lyude Paul <lyude@redhat.com> Acked-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
- 04 Oct, 2017 1 commit
-
-
Chris Wilson authored
Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive values being higher priority (they will be serviced earlier, after their dependencies have been resolved). Any prerequisite work for an execbuf will have its priority raised to match the new request as required. Normal users can specify any value in the range of -1023 to 0 [default], i.e. they can reduce the priority of their workloads (and temporarily boost it back to normal if so desired). Privileged users can specify any value in the range of -1023 to 1023, [default is 0], i.e. they can raise their priority above all overs and so potentially starve the system. Note that the existing schedulers are not fair, nor load balancing, the execution is strictly by priority on a first-come, first-served basis, and the driver may choose to boost some requests above the range available to users. This priority was originally based around nice(2), but evolved to allow clients to adjust their priority within a small range, and allow for a privileged high priority range. For example, this can be used to implement EGL_IMG_context_priority https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of the context to be created. This attribute is a hint, as an implementation may not support multiple contexts at some priority levels and system policy may limit access to high priority contexts to appropriate system privilege level. The default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is EGL_CONTEXT_PRIORITY_MEDIUM_IMG." so we can map PRIORITY_HIGH -> 1023 [privileged, will failback to 0] PRIORITY_MED -> 0 [default] PRIORITY_LOW -> -1023 They also map onto the priorities used by VkQueue (and a VkQueue is essentially a timeline, our i915_gem_context under full-ppgtt). v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/ v3: Report min/max user priorities as defines in the uapi, and rebase internal priorities on the exposed values. Testcase: igt/gem_exec_schedule Signed-off-by:
-
