- 09 Sep, 2016 12 commits
-
-
Chris Wilson authored
Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for an extra second waiting for the mutex to be released (no one touching the GPU is allowed the struct_mutex whilst the I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset, this allows us to clean up the reset worker faster. v2: Remember to call wake_up_bit() after changing (for the faster wakeup as promised) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-12-chris@chris-wilson.co.uk
-
Chris Wilson authored
If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as useless (and has in the past proven dangerous). The remaining WARN_ON(i915_wait_request) serve as a valuable reminder that handling errors from an indefinite wait are tricky. We can keep the current semantic that knowing after a reset is complete, so is the request, by performing the reset ourselves if we hold the mutex. uevent emission is still handled by the reset worker, so it may appear slightly out of order with respect to the actual reset (and concurrent use of the device). Signed-off-by:
-
Chris Wilson authored
In the next patch we want to handle reset directly by a locked waiter in order to avoid issues with returning before the reset is handled. To handle the reset, we must first know whether we hold the struct_mutex. If we do not hold the struct_mtuex we can not perform the reset, but we do not block the reset worker either (and so we can just continue to wait for request completion) - otherwise we must relinquish the mutex. Signed-off-by:
-
Chris Wilson authored
We need finer control over wakeup behaviour during i915_wait_request(), so expand the current bool interruptible to a bitmask. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-9-chris@chris-wilson.co.uk
-
Chris Wilson authored
Access to intel_init_emon() is strictly ordered by gt_powersave, using struct_mutex around it is overkill (and will conflict with the caller holding struct_mutex themselves). Signed-off-by:
-
Chris Wilson authored
In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a waiter waking up after the reset knows the request is complete. For pending flips, we still rely on the increment of the global reset epoch (as well as the reset-in-progress flag) to signify when the hardware was reset. The advantage, now that we do not inspect the reset state during reset itself i.e. we no longer emit requests during reset, is that we can use the atomic updates of the state flags to ensure that only one reset worker is active. v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup into a waiter wakeup. Signed-off-by:
-
Chris Wilson authored
Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by decoupling elsp queue management. This will become more clear in the next patch. In the engine reset case we want to resume where we left-off after skipping the incomplete batch which requires checking the elsp queue, removing element and fixing elsp_submitted counts in some cases. Instead of directly manipulating the elsp queue from reset path we can examine these ports, fix up ringbuffer pointers using the incomplete request and restart submissions again after reset. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Just rearrange the code to reduce churn in the next patch. Signed-off-by:
-
Chris Wilson authored
Similar to the issue with reading from the context status buffer, see commit 26720ab9 ("drm/i915: Move CSB MMIO reads out of the execlists lock"), we frequently write to the ELSP register (4 writes per interrupt) and know we hold the required spinlock and forcewake throughout. We can further reduce the cost of writing these registers beyond the I915_WRITE_FW() by precomputing the address of the ELSP register. We also note that the subsequent read serves no purpose here, and are happy to see it go. v2: Address I915_WRITE mistakes in changelog text data bss dec hex filename 1259784 4581 576 1264941 134d2d drivers/gpu/drm/i915/i915.ko 1259720 4581 576 1264877 134ced drivers/gpu/drm/i915/i915.ko Saves 64 bytes of address recomputation. Signed-off-by:
-
Chris Wilson authored
Rather than blindly assuming we need to advance the tail for resubmitting the request via the ELSP, record the position. Signed-off-by:
-
Chris Wilson authored
Leave the more complicated request dequeueing to the tasklet and instead just kick start the tasklet if we detect we are adding the first request. v2: Play around with list operators until we agree upon something Signed-off-by:
-
Chris Wilson authored
This is really a core kernel struct in disguise until we can finally place it in kernel/. There is an immediate need for a fence collection mechanism that is more flexible than fence-array, in particular being able to easily drive request submission via events (and not just interrupt driven). The same mechanism would be useful for handling nonblocking and asynchronous atomic modesets, parallel execution and more, but for the time being just create a local sw fence for execbuf. Signed-off-by:
-
- 07 Sep, 2016 28 commits
-
-
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by:Carlos Santa <carlos.santa@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Carlos Santa authored
Make the .hws_needs_physical the exception by switching the flag on earlier platforms since they are fewer to support. Remove the flag on later GPUs hardware since they all use GTT hws by default. Switch the logic as well in the driver to reflect this change Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN2_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for 830, 845g, i85x, i865g. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Introducing a GEN3_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Introducing a GEN4_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i965g, i965gm, g45 and gm45. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN5_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for ilk. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
No need for HAS_CORE_RING_FREQ as that flag is actually the same as .has_llc. Feedback from V. Syrjala. Signed-off-by:
-
Carlos Santa authored
Remove runtime PM support for SNB as it breaks hotplug support. Feedback from V. Syrjala. Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN6_FEAUTRES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for snb. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
As recommended by Ville Syrjala removing .is_mobile field from the platform struct definition for vlv and hsw+ GPUs as there's no need to make the distinction in later hardware anymore. Keep it for older GPUs as it is still needed for ilk-ivb. Signed-off-by:
-
Carlos Santa authored
[patch series] Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definition Signed-off-by:
-
Manasi Navare authored
Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Reviewed-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Jim Bride authored
Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code does not directly depend on crtc state, so that the code can be used for upfront link training. Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Signed-off-by:
-
Durgadoss R authored
Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. v2: * Refactored code so that bxt_clk_div need not be exported (Durga) v1: * Rebased on top of intel_dpll_mgr.c (Durga) * Initial version from Ander on top of intel_ddi.c Reviewed-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Manasi Navare authored
Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link training. v3: * Rebased onto latest kernel (Manasi) v2: * Rebased onto kernel v4.7 (Jim) Reviewed-by:
-
Ander Conselvan de Oliveira authored
The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by:
-
Ander Conselvan de Oliveira authored
Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. v2: * Rebased on atomic state changes (Manasi) Reviewed-by:
-
