- 08 Mar, 2019 21 commits
-
-
José Roberto de Souza authored
When PSR2 is active aka after the number of frames programmed in PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC interrupts causing IGT tests to fail due timeout. This same behavior don't happen with PSR1, as soon as pipe CRC is enabled it blocks PSR1 activation so CRC calculation continues to happens normaly. This patch also set mode_changed as true when PSR is available to force atomic check functions to compute new PSR state, otherwise PSR2 would not be disabled. v4: Only setting mode_changed if has_psr is set(Dhinakaran) v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting mode_changed if it can do PSR. v2: Changed commit description to describe that PSR2 inhibit CRC calculations. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-6-jose.souza@intel.com
-
José Roberto de Souza authored
Other features like PSR2 also needs to be disabled while getting CRC so lets rename ips_force_disable to crc_enabled, drop all this checks for pipe A and HSW and BDW and make it generic and hsw_compute_ips_config() will take care of all the checks removed from here. v2: Renaming and parameter changes to the functions that prepares the commit (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
If has_psr is set it means that CRTC has a EDP panel attached so the EDP check is redundant and can be dropped. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
In any commit, intel_modeset_pipe_config() will initialilly clear and then recalculate most of the pipe states but it leave intel specific color features states in reset state. If after intel_pipe_config_compare() is detected that a fastset is possible it will mark update_pipe as true and unsed mode_changed, causing the color features state to be kept in reset state and then latter being committed to hardware disabling the color features. This issue can be reproduced by any code patch that duplicates the actual(with color features already enabled) state and only mark mode_changed as true. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Forcing a specific CRTC to the eDP connector was causing the intel_psr_fastset_force() to mark mode_chaged in the wrong and disabled CRTC causing no update in the PSR state. Looks like our internal state track do not clear output_types and has_psr in the disabled CRTCs, not sure if this is the expected behavior or not but in the mean time this fix the issue. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Now we are checking sink capabilities when probing PSR DPCD register and then dynamically checking in if new state is compatible with PSR in, so this FIXME can be dropped. Reviewed-by:
-
Chris Wilson authored
Introduce a mutex to start locking the HW contexts independently of struct_mutex, with a view to reducing the coarse struct_mutex. The intel_context.pin_mutex is used to guard the transition to and from being pinned on the gpu, and so is required before starting to build any request. The intel_context will then remain pinned until the request completes, but the mutex can be released immediately unpin completion of pinning the context. A slight variant of the above is used by per-context sseu that wants to inspect the pinned status of the context, and requires that it remains stable (either !pinned or pinned) across its operation. By using the pin_mutex to serialise operations while pin_count==0, we can take that pin_mutex for stabilise the boolean pin status. v2: for Tvrtko! * Improved commit message. * Dropped _gpu suffix from gen8_modify_rpcs_gpu. v3: Repair the locking for sseu selftests Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308132522.21573-7-chris@chris-wilson.co.uk
-
Chris Wilson authored
Each engine acquires a pin on the kernel contexts (normal and preempt) so that the logical state is always available on demand. Keep track of each engines pin by storing the returned pointer on the engine for quick access. Signed-off-by:
-
Chris Wilson authored
Push the intel_context pin callback down from intel_engine_cs onto the context itself by virtue of having a central caller for intel_context_pin() being able to lookup the intel_context itself. Signed-off-by:
-
Chris Wilson authored
In preparation for an ever growing number of engines and so ever increasing static array of HW contexts within the GEM context, move the array over to an rbtree, allocated upon first use. Unfortunately, this imposes an rbtree lookup at a few frequent callsites, but we should be able to mitigate those by moving over to using the HW context as our primary type and so only incur the lookup on the boundary with the user GEM context and engines. v2: Check for no HW context in guc_stage_desc_init Signed-off-by:
-
Chris Wilson authored
If we place a pointer to the engine specific intel_context_ops in the engine itself, we can assign the ops pointer on initialising the context, and then rely on it being set. This simplifies the code in later patches. Signed-off-by:
-
Chris Wilson authored
This complex struct pulling in half the driver deserves its own isolation in preparation for intel_context becoming an outright complicated class of its own. In order to split this beast into its own header also requests splitting several of its dependent types and their dependencies into their own headers as well. v2: Add standalone compilation tests Signed-off-by:
-
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:
-
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:
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ä 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:
-
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 3 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:
-
