- 11 Sep, 2019 21 commits
-
-
Jani Nikula authored
Abstract away direct access to ->num_pipes to allow further refactoring. No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911092608.13009-1-jani.nikula@intel.com
-
Chris Wilson authored
There's no easy way of checking whether iommu is enabled for the GPU (you can grep dmesg if you know the device, or you can grep i915_gpu_info if that's available). We do have a central i915_capabilities with the intent of listing such pertinent information, so add the iommu status. Suggested-by:
Martin Peres <martin.peres@linux.intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Martin Peres <martin.peres@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by:
-
Chris Wilson authored
The same read-only affliction as befell Icelake is affecting Tigerlake. Disable the read-only support as clearly it was not fixed. Testcase: igt/i915_selftests/live_gem_context References: 3936867d ("drm/i915: Disable read only ppgtt support for gen11") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911125717.28997-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
i915 doesn't use the crtc_state->plane_changed flag for anything, so setting it is pointless. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
system_unbound_wq can't keep up sometimes and we get dropped frames. Switch to a high priority variant. Reported-by:
Heinrich Fink <heinrich.fink@daqri.com> Tested-by:
-
Chris Wilson authored
Commit 736da811 ("drm/i915: Use literal representation of cdclk tables") pushed the cdclk logic into tables, adding glk_cdclk_table but not using yet: drivers/gpu/drm/i915/display/intel_cdclk.c:1173:38: error: ‘glk_cdclk_table’ defined but not used [-Werror=unused-const-variable=] Fixes: 736da811 ("drm/i915: Use literal representation of cdclk tables") Signed-off-by:
-
Chris Wilson authored
In preparation for reducing struct_mutex stranglehold around the vm, make the vma.flags atomic so that we can acquire a pin on the vma atomically before deciding if we need to take the mutex. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911090243.16786-1-chris@chris-wilson.co.uk
-
Kenneth Graunke authored
This allows userspace to use "legacy" mode for push constants, where they are committed at 3DPRIMITIVE or flush time, rather than being committed at 3DSTATE_BINDING_TABLE_POINTERS_XS time. Gen6-8 and Gen11 both use the "legacy" behavior - only Gen9 works in the "new" way. Conflating push constants with binding tables is painful for userspace, we would like to be able to avoid doing so. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: stable@vger.kernel.org Reviewed-by:
-
Chris Wilson authored
Add an atomic counter and always take the spinlock around the pin/unpin events, so that we can perform the list manipulation concurrently. Signed-off-by:
-
Tvrtko Ursulin authored
These notifications operate on intel_gt so make the code take what it needs. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
Both in the container_of and getting to gt->awake there is no need to go via i915 since both the wakeref and awake are members of gt. Signed-off-by:
-
Tvrtko Ursulin authored
Timelines live in struct intel_gt so make wait_for_timelines take exactly what it needs. Signed-off-by:
-
Tvrtko Ursulin authored
Code in i915_gem_init_hw is all about GT init so move it to intel_gt.c renaming to intel_gt_init_hw. Existing intel_gt_init_hw is renamed to intel_gt_init_hw_early since it is currently called from driver probe. Signed-off-by:
-
Matt Roper authored
The BXT and CNL functions were already basically identical, whereas ICL's function tried to do its own sanitization rather than calling bxt_sanitize_cdclk. This should actually fix a bug in our ICL initialization where it would consider the /2 CD2X divider invalid and force an unnecessary sanitization (we now have valid clock frequencies that use this divider). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
When reading out the BIOS-programmed cdclk state, let's make sure that the cdclk value is on the valid list for the platform, ensure that the VCO matches the cdclk, and ensure that the CD2X divider was set properly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
With all of the cdclk function consolidation, we can cut down on a lot of platform if/else logic by creating a vfunc that's initialized at startup. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
The uninitialize flow is the same on all of these platforms, aside from calculating a different frequency level. v2: Reverse platform conditional order for consistency. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
The CNL variant of this function is identical to the BXT variant aside from not needing to handle SSA precharge. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
We'd previously combined ICL/TGL logic into the cnl_set_cdclk function, but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into the bxt function; the only things we really need to handle separately are punit notification and calling different functions to enable/disable the cdclk PLL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X dividers in an easy-to-read table for most recent platforms. We've been translating the data from that table into platform-specific code logic, but it's easy to overlook an area we need to update when adding new cdclk values or enabling new platforms. Let's just add a form of the bspec table to the code and then adjust our functions to pull what they need directly out of the table. v2: Fix comparison when finding best cdclk. v3: Another logic fix for calc_cdclk. v4: - Use named initializers for cdclk tables. (Ville) - Include refclk as a field in the table instead of adding all three ratios for each entry. (Ville) - Terminate tables with an empty entry to avoid needing to store the table size. (Ville) - Don't try so hard to return reasonable values from our lookup functions if we get impossible inputs; just WARN and return 0. (Ville) - Keep a bxt_ prefix on the lookup functions since they're still only used on bxt+ for now. We can rename them later if we extend this table-based approach back to older platforms. (Ville) v5: - Fix cnl table's ratios for 24mhz refclk. (Ville) - Don't miss the named initializers on the cnl table. (Ville) - Represent refclk in table as u16 rather than u32. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Aside from a few minor register changes and some different clock values, cdclk design hasn't changed much since gen9lp. Let's consolidate the handlers for bxt, cnl, and icl to keep the codeflow consistent. Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since "update" makes me think we should be writing to hardware rather than reading from it. v2: - Fix icl_calc_voltage_level() limits. (Ville) - Use CNL_CDCLK_PLL_RATIO_MASK rather than BXT_DE_PLL_RATIO_MASK on gen10+ to avoid confusion. (Ville) v3: - Also fix ehl_calc_voltage_level() limits. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
-
- 10 Sep, 2019 10 commits
-
-
Chris Wilson authored
Empirical evidence from CI tells us that our rc6 setup for Tigerlake is off. Disable rc6 on tgl temporary so that we gain CI coverage as we prepare a fix. It also appears that the BIOS on our tgl leaves rc6 enabled, so we have to explicitly disable it on init. References: https://bugs.freedesktop.org/show_bug.cgi?id=111593Signed-off-by:
-
Chris Wilson authored
Currently, if there is time remaining before the start of the loop, we do one full iteration over many possible different chunks within the object. A full loop may take 50+s (depending on speed of indirect GTT mmapings) and we try separately with LINEAR, X and Y -- at which point igt times out. If we check more frequently, we will interrupt the loop upon our timeout -- it is hard to argue for as this significantly reduces the test coverage as we dramatically reduce the runtime. In practical terms, the coverage we should prioritise is in using different fence setups, forcing verification of the tile row computations over the current preference of checking extracting chunks. Though the exhaustive search is great given an infinite timeout, to improve our current coverage, we also add a randomised smoketest of partial mmaps. So let's do both, add a randomised smoketest of partial tiling chunks and the exhaustive (though time limited) search for failures. Even in adding another subtest, we should shave 100s off BAT! (With, hopefully, no loss in coverage, at least over multiple runs.) Signed-off-by:
-
Chris Wilson authored
Being a "low-level" test, we opt to bypass the normal bind/unbind hooks for the lower level insert_entries/clear_range. For ggtt, the bind/unbind hooks provide the runtime wakeref and so we must also handle this in exercising the low level hooks. <4> [538.151672] RPM raw-wakeref not held <4> [538.151825] WARNING: CPU: 0 PID: 11 at ./drivers/gpu/drm/i915/intel_runtime_pm.h:107 fwtable_read32+0x1be/0x300 [i915] <4> [538.151830] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp btusb btrtl btbcm x86_pkg_temp_thermal coretemp btintel crct10dif_pclmul bluetooth crc32_pclmul snd_intel_nhlt snd_hda_codec ecdh_generic ghash_clmulni_intel ecc snd_hwdep snd_hda_core lpc_ich r8169 realtek snd_pcm mei_me mei prime_numbers pinctrl_broxton pinctrl_intel [last unloaded: i915] <4> [538.151861] CPU: 0 PID: 11 Comm: migration/0 Tainted: G U 5.3.0-rc7-CI-Trybot_4938+ #1 <4> [538.151864] Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS AYAPLCEL.86A.0056.2018.0926.1100 09/26/2018 <4> [538.151960] RIP: 0010:fwtable_read32+0x1be/0x300 [i915] <4> [538.151965] Code: e8 e7 f9 5f e0 e9 0b ff ff ff 80 3d d5 8d 26 00 00 0f 85 81 fe ff ff 48 c7 c7 ef 01 bd a0 c6 05 c1 8d 26 00 01 e8 b2 e4 6a e0 <0f> 0b e9 67 fe ff ff 80 3d ad 8d 26 00 00 0f 85 65 fe ff ff 48 c7 <4> [538.151969] RSP: 0018:ffffc9000007be10 EFLAGS: 00010086 <4> [538.151972] RAX: 0000000000000000 RBX: ffff88826be10d50 RCX: 0000000000000002 <4> [538.151975] RDX: 0000000080000002 RSI: 0000000000000000 RDI: 00000000ffffffff <4> [538.151978] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 <4> [538.151981] R10: 0000000000000000 R11: ffffc9000007bcb0 R12: 0000000000101008 <4> [538.151984] R13: 0000000000000000 R14: ffffc9000036f638 R15: 0000000000000002 <4> [538.151987] FS: 0000000000000000(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 <4> [538.151990] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [538.151993] CR2: 00007fd48e7052f8 CR3: 0000000005210000 CR4: 00000000003406f0 <4> [538.151995] Call Trace: <4> [538.152106] bxt_vtd_ggtt_clear_range__cb+0x38/0x40 [i915] Signed-off-by:
-
Chris Wilson authored
As soon as we re-enable the various functions within the HW, they may go off and read data via a GGTT offset. Hence, if we have not yet restored the GGTT PTE before then, they may read and even *write* random locations in memory. Detected by DMAR faults during resume. Signed-off-by:
-
Chris Wilson authored
Be paranoid and make sure we flush any and all writes out of the WCB before performing the UC mmio to update the RING_TAIL. (An UC write should itself be enough to do the flush, hence the paranoia here.) Quite infrequently, we see problems where the GPU seems to overshoot the RING_TAIL and so executes garbage, hence the speculation. References: https://bugs.freedesktop.org/show_bug.cgi?id=111598 References: https://bugs.freedesktop.org/show_bug.cgi?id=111417 References: https://bugs.freedesktop.org/show_bug.cgi?id=111034Signed-off-by:
-
Chris Wilson authored
Icelake hit an issue where it missed reporting a completion event and instead jumped straight to a idle->active event (skipping over the active->idle and not even hitting the lite-restore preemption). 661497511us : process_csb: rcs0 cs-irq head=11, tail=0 661497512us : process_csb: rcs0 csb[0]: status=0x10008002:0x00000020 [lite-restore] 661497512us : trace_ports: rcs0: preempted { 28cc8:11052, 0:0 } 661497513us : trace_ports: rcs0: promote { 28cc8:11054, 0:0 } 661497514us : __i915_request_submit: rcs0 fence 28cc8:11056, current 11052 661497514us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes 661497515us : trace_ports: rcs0: submit { 28cc8:11056, 0:0 } 661497530us : process_csb: rcs0 cs-irq head=0, tail=1 661497530us : process_csb: rcs0 csb[1]: status=0x10008002:0x00000020 [lite-restore] 661497531us : trace_ports: rcs0: preempted { 28cc8:11054!, 0:0 } 661497535us : trace_ports: rcs0: promote { 28cc8:11056, 0:0 } 661497540us : __i915_request_submit: rcs0 fence 28cc8:11058, current 11054 661497544us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes 661497545us : trace_ports: rcs0: submit { 28cc8:11058, 0:0 } 661497553us : process_csb: rcs0 cs-irq head=1, tail=2 661497553us : process_csb: rcs0 csb[2]: status=0x10000001:0x00000000 [idle->active] 661497574us : process_csb: process_csb:1538 GEM_BUG_ON(*execlists->active) Signed-off-by: -
Swati Sharma authored
For cherryview, add hw read out to create hw blob of gamma lut values. Review comments from previous series: https://patchwork.freedesktop.org/patch/328252 v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed function cherryview_get_color_config() to chv_read_luts() -Renamed cherryview_get_gamma_config() to chv_read_cgm_gamma_lut() [Ville] v9: -80 character limit [Uma] -Made read func para as const [Ville, Uma] -Renamed chv_read_cgm_gamma_lut() to chv_read_cgm_gamma_lut() [Ville, Uma] Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
-
Swati Sharma authored
For i965, add hw read out to create hw blob of gamma lut values. Review comments from old series: https://patchwork.freedesktop.org/series/58039/ v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed i965_get_color_config() to i965_read_lut() [Ville] -Renamed i965_get_gamma_config_10p6() to i965_read_gamma_lut_10p6() [Ville] v9: -Typo and 80 character limit [Uma] -Made read func para as const [Ville, Uma] -Renamed i965_read_gamma_lut_10p6() to i965_read_lut_10p6() [Ville, Uma] v10: -Swapped ldw and udw while creating hw blob [Jani] -Added last index rgb lut value from PIPEGCMAX to h/w blob [Jani] Signed-off-by:
-
Swati Sharma authored
intel_color_get_gamma_bit_precision() is extended for cherryview by adding chv_gamma_precision(), i965 will use existing i9xx_gamma_precision() func only. Signed-off-by:
-
Chris Wilson authored
During reset, we try to ensure no forward progress of the CS prior to the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this register is context saved and do we end up in the odd situation where we save the STOP_RING bit and so try to stop the engine again immediately upon resume. This is quite unexpected and causes us to complain about an early CS completion event! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111514Signed-off-by:
-
- 09 Sep, 2019 6 commits
-
-
Matthew Auld authored
It might prove useful in the future to know if the vma is utilising huge-GTT-pages. Related to this is the GTT cache, where there is some HW "quirkiness" where it must be disabled if using 2M pages, so include that for good measure. Suggested-by:
-
Matthew Auld authored
Try to tidy up the cache-coloring such that we rid the code of any mm.color_adjust assumptions, this should hopefully make it more obvious in the code when we need to actually use the cache-level as the color, and as a bonus should make adding a different color-scheme simpler. Signed-off-by:
-
Matthew Auld authored
Make it clear that the color adjust callback applies to the ggtt. Signed-off-by:
-
Matthew Auld authored
Export color_differs so that we can use it elsewhere. Signed-off-by:
-
Chris Wilson authored
As we may unwind incomplete requests (for preemption) prior to processing the CSB and the schedule-out events, we may update rq->engine (resetting it to point back to the parent virtual engine) prior to calling execlists_schedule_out(), invalidating the assertion that the request still points to the inflight engine. (The likelihood of this is increased if the CSB interrupt processing is pushed to the ksoftirqd for being too slow and direct submission overtakes it.) Tvrtko summarised it as: "So unwind from direct submission resets rq->engine and races with process_csb from the tasklet which notices request has actually completed." Reported-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by:
-
Matthew Auld authored
We are meant to register the kmem cache at init, such the supplied exit and shrink hooks can be called. Signed-off-by:
-
- 06 Sep, 2019 3 commits
-
-
Andi Shyti authored
Refactor the GT power management interface to work through the GT now that it is under the control of gt/ Based on a patch by Chris Wilson. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michel Thierry authored
Gen12 has subtle changes in the reg state context offsets (some fields are gone, some are in a different location), compared to previous Gens. The simplest approach seems to be keeping Gen12 (and future platform) changes apart from the previous gens, while keeping the registers that are contiguous in functions we can reuse. v2: alias, virtual engine, rpcs, prune unused regs v3: use engine base (Daniele), take ctx_bb for all Bspec: 46255 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Tested-by:
-
Mika Kuoppala authored
Daniele pointed out that relative mmio works differently in on context restore. Instead of adding the engine mmio base to offset, it masks out the base and adds bits [12:2] to current engine base. This should allow us to construct context register state to be applicable to all instances, including virtual. And avoid the trouble of updating the registers on virtual instances when submitting work. v2: only enable for gen12 for now (Mika) v3: make enabling readable (Chris) Bspec: 20206 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Suggested-by:
-
