- 08 Mar, 2019 9 commits
-
-
Chris Wilson authored
For use in the next patch, if we track which engines have been used by the HW, we can reduce the work required to flush our state off the HW to those engines. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308132522.21573-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Set pp_div field of struct pps_registers to INVALID_MMIO_REG when the register isn't there, and use i915_mmio_reg_valid() instead of repeating the condition all over the place. Use INVALID_MMIO_REG explicitly for documentation purposes, even if the value is unchanged from 0. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305135215.29862-2-jani.nikula@intel.com
-
Jani Nikula authored
PPS locking is a thing on pre-DDI, up to and including CPT and PPT. The PPS divisor register exists up to gen 9 BC, replaced by a field in the control register starting from gen 9 LP, i.e. BXT, GLK, and CNP on. Commit b0a08bec ("drm/i915/bxt: eDP Panel Power sequencing") stopped using the divisor register, but inadvertently conflated the PPS unlock in the change. No longer doing the unlocking was the right thing to do, however we should've stopped already at LPT (or DDI platforms). Deconflate the two. Arguably this could be moved away from here altogether, but this is the minimally intrusive change for now. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
We can no longer assume execution ordering, and in particular we cannot assume which context will execute last. One side-effect of this is that we cannot determine if the kernel-context is resident on the GPU, so remove the routines that claimed to do so. Signed-off-by:
-
Chris Wilson authored
Currently we assume that we know the order in which requests run and so can determine if we need to reissue a switch-to-kernel-context prior to idling. That assumption does not hold for the future, so instead of tracking which barriers have been used, simply determine if we have ever switched away from the kernel context by using the engine and before idling ensure that all engines that have been used since the last idle are synchronously switched back to the kernel context for safety (and else of shrinking memory while idle). v2: Use intel_engine_mask_t and ALL_ENGINES Signed-off-by:
-
Chris Wilson authored
We load a context (the kernel context) on both module load and resume in order to initialise some logical state onto the GPU. We can use the same routine for both operations, which will become more useful as we refactor rc6/rps enabling. Signed-off-by:
-
Chris Wilson authored
When the system idles, we switch to the kernel context as a defensive measure (no users are harmed if the kernel context is lost). Currently, we issue a switch to kernel context and then come back later to see if the kernel context is still current and the system is idle. However, if we are no longer privy to the runqueue ordering, then we have to relax our assumptions about the logical state of the GPU and the only way to ensure that the kernel context is currently loaded is by issuing a request to run after all others, and wait for it to complete all while preventing anyone else from issuing their own requests. v2: Pull wedging into switch_to_kernel_context_sync() but only after waiting (though only for the same short delay) for the active context to finish. Signed-off-by:
-
Chris Wilson authored
Check that we have setup on preemption for the engine before testing, instead warn if it is not enabled on supported HW. Signed-off-by:
-
Imre Deak authored
Pretend that we have only 1 DBuf slice and that 1 slice is always enabled, until we have a proper way for on-demand toggling of the second slice. Currently we'll try to incorrectly enable DBuf even when all pipes are disabled and we are already runtime suspended (as the computed number of DBuf slices will be 1 in that case). This also means we'll leave the second slice enabled redundantly (except when suspended), but that's an acceptable tradeoff until we have a proper solution. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108756 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 07 Mar, 2019 16 commits
-
-
Chris Wilson authored
We can reduce the switch-to-kernel-context selftest to operate as a loop and so trivially test another state transition (that of idle->busy). Signed-off-by:
-
Ville Syrjälä authored
We'll need to know the memory type in the system for some bandwidth limitations and whatnot. Let's read that out on gen9+. v2: Rebase v3: Fix the copy paste fail in the BXT bit definitions (Jani) Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190306203551.24592-13-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
We'll need information about the memory configuration on cnl+ too. Extend the code to parse the slightly changed register layout. v2: Document what cnl_get_dimm_size() returns (Jani) Reviewed-by:
-
Ville Syrjälä authored
Remove the pointless zero initialization of bunch of things (the thing is kzalloc()ed). Also throw out the mostly useless on-stack string. I think it'll be clear enough from the logs that 0 means unknown. Reviewed-by:
-
Ville Syrjälä authored
Rename the dimm info structs for clarity. Reviewed-by:
-
Ville Syrjälä authored
Decouple intel_is_dram_symmetric() from the raw register values by comparing just the dram_channel_info structs. Reviewed-by:
-
Ville Syrjälä authored
Reduce the code duplication a bit by sharing the same code for parsing both DIMMs on a channel. v2: s/%d/%u/ all over (Jani) Reviewed-by:
-
Ville Syrjälä authored
The BXT code for parsing DIMM info works for GLK too. Let's dig it out even if we might not need it immediately. Reviewed-by:
-
Ville Syrjälä authored
The BXT DUNIT register tells us the size of each DRAM device in Gb. We want to report the size of the whole DIMM in GB, so that it matches how we report it for non-LP platforms. v2: Deobfuscate the math (Chris) s/GB/GBIT/ in the register bit definitions (Jani) Reviewed-by: -
Ville Syrjälä authored
Polish the bxt DIMM parsing by extracting a few small helpers. v2: Use struct dram_dimm_info v3: Document what bxt_get_dimm_size() returns (Jani) Reviewed-by:
-
Ville Syrjälä authored
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each value separately. And let's replace the hardcoded set of values with some simple arithmetic. Also fix the byte vs. bit inconsistency in the debug message, and polish the wording otherwise as well. v2: Deobfuscate the math (Chris) Reviewed-by:
-
Ville Syrjälä authored
Make the code less repetitive by extracting a few small helpers. v2: Squash in the switch removal for skl_get_dimm_ranks() (it got misplaced in a rebase accident) Document what skl_get_dimm_size() returns (Jani) Reviewed-by: -
Ville Syrjälä authored
Life will be easier later if we have the ranks stored as a bare number. v2: s/%d/%u/ all over (Jani) Reviewed-by:
-
José Roberto de Souza authored
Now with the watermarks fixes merged, Icelake is stable enough to have the alpha support protection flag removed. We have a few ICL machines in our CI and it is mostly green with failures in tests that will not impact future linux installations. Also there is no warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a dual monitor setup. As a reminder i915.alpha_support was created to protect future linux installation's iso images that might contain a kernel from the enabling time of the new platform. Without this protection most of linux installation was recommending nomodeset option during installation that was getting stick there after installation. Specifically, alpha support says nothing about the development state of the hardware, and everything about the state of the driver in a kernel release. This is semantically no different from the old preliminary_hw_support flag, but the old one was all too often interpreted as (preliminary hw) support instead of the intended (preliminary) hw support, and it was misleading for everyone. Hence the rename. Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-y.html Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-iclb.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Chris Wilson authored
To facilitate the next patch to allow preemptible kernels not to incur the wrath of hangcheck, we need to ensure that we can still suspend and shutdown. That is we will not be able to rely on hangcheck to terminate a blocking kernel and instead must manually do so ourselves. The advantage is that we can apply more pressure! As we now perform a GPU reset to clean up any residual kernels, we leave the GPU in an unknown state and in particular can not talk to the GuC before we reinitialise it following resume. For example, we no longer need to tell the GuC to suspend itself, as it is already reset. Signed-off-by:
-
Chris Wilson authored
Currently we use HZ/5 for detecting a dead gpu on startup, and we will wish to reuse this value for detecting a dead gpu on suspend, so convert it into a macro for later convenience. Signed-off-by:
-
- 06 Mar, 2019 8 commits
-
-
Ville Syrjälä authored
At some point people have started to assume that pipe_offsets[] & co. are only populated for pipes and whatnot that actually exist. That is in fact not currently true, but we can easily make it so. Signed-off-by:
-
Ville Syrjälä authored
Let's just always enable the DVO 2x clock on i830. This way we don't have to track if DVO is being used or not. The spec does suggest we should disable the clock when it isn't needed, but this does appear to work just fine. This removes another crtc->config usage. v2: Split the DPLL enable sequence change to a separate patch Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by:
-
Ville Syrjälä authored
The current code clears the DPLL register entirely when re-enabling VGA mode temporarily during the DPLL enable sequence. On i830 we want to keep the DPLLs on all the time, so let's not do this temporary disabling. The current code does work, so this doesn't seem super important. But I prefer that we make the behaviour 100% consistent. v2: Split this change the DVO 2x clocking patch Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by:
-
Tvrtko Ursulin authored
Legacy behaviour was to allow non-page-aligned mmap requests, as does the linux mmap(2) implementation by virtue of automatically rounding up for the caller. To avoid breaking legacy userspace relax the newly introduced fix. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Cc: Adam Zabrocki <adamza@microsoft.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.0+ Cc: Akash Goel <akash.goel@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by:
-
Michał Winiarski authored
We're using pr_debug for things that we don't really want to see in the CI log, but we may find useful during test development. Let's upgrade the test name printer - we do want to see those in CI log. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
MI_STORE_DWORD_IMM wants to write into a dword-aligned (4B) address, we mistakenly cleared bit2 and not bits 0 and 1. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190306082447.21563-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Instead of passing the gem_context and engine to find the instance of the intel_context to use, pass around the intel_context instead. This is useful for the next few patches, where the intel_context is no longer a direct lookup. Signed-off-by:
-
Chris Wilson authored
Rather than manually add every new global into each hook, use i915_global_register() function and keep a list of registered globals to invoke instead. However, I haven't found a way for random drivers to add an .init table to avoid having to manually add ourselves to i915_globals_init() each time. Signed-off-by:
-
- 05 Mar, 2019 7 commits
-
-
Michał Winiarski authored
We assumed that the default preemption granularity is fine for ICL. Unfortunately, it turns out that some drivers don't support mid-thread preemption for compute workloads. If a workload that doesn't support mid-thread preemption gets mid-thread preempted, we're going to observe a GPU hang. While I'm here, let's also update the "workaround" naming. Signed-off-by:
Anuj Phogat <anuj.phogat@intel.com> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
-
Chris Wilson authored
To find the active request, we need only search along the individual engine for the right request. This does not require touching any global GEM state, so move it into the engine compartment. Signed-off-by:
-
Chris Wilson authored
Small simplification to set all bits in the dirty mask rather than lookup the exact mask of populated engines. The bits for the engines that do not exist are unused and so can safely set and then ignored. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305180332.30900-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
In the next patch, we are introducing a broad virtual engine to encompass multiple physical engines, losing the 1:1 nature of BIT(engine->id). To reflect the broader set of engines implied by the virtual instance, lets store the full bitmask. v2: Use intel_engine_mask_t (s/ring_mask/engine_mask/) v3: Tvrtko voted for moah churn so teach everyone to not mention ring and use $class$instance throughout. v4: Comment upon the disparity in bspec for using VCS1,VCS2 in gen8 and VCS[0-4] in later gen. We opt to keep the code consistent and use 0-index naming throughout. Signed-off-by:
-
Chris Wilson authored
As we allow per-context engine allows the legacy concept of I915_EXEC_RING no longer applies universally. We are still exposing the unrelated exec-id in GEM_BUSY, so transition this ioctl (once more slightly changing its ABI, but no one cares) over to only reporting the uabi-class (not instance as we can not foreseeably fit those into the small bitmask). The only user of the extended ring information from GEM_BUSY is ddx/sna, which tries to use the non-rcs business information to guide which engine to use for subsequent operations on foreign bo. All that matters for it is the decision between rcs and !rcs, so it is unaffected by the change in higher bits. Signed-off-by:
-
Chris Wilson authored
We no longer use the semaphore sync registers on gen6/7, so including them in the GPU error state is mere noise. References: 6faf5916 ("drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation") Signed-off-by:
-
Chris Wilson authored
As we don't unmask and enable the vebox interrupts if the engine is not being used, we will never generate the vebox interrupts as part of the IIR and so can unconditionally check IIR without fear of chasing into the vebox. Signed-off-by:
-
