- 21 May, 2020 12 commits
-
-
Stanislav Lisovskiy authored
No need to bump up CDCLK now, as it is now correctly calculated, accounting for DBuf BW as BSpec says. Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
According to BSpec max BW per slice is calculated using formula Max BW = CDCLK * 64. Currently when calculating min CDCLK we account only per plane requirements, however in order to avoid FIFO underruns we need to estimate accumulated BW consumed by all planes(ddb entries basically) residing on that particular DBuf slice. This will allow us to put CDCLK lower and save power when we don't need that much bandwidth or gain additional performance once plane consumption grows. v2: - Fix long line warning - Limited new DBuf bw checks to only gens >= 11 v3: - Lets track used Dbuf bw per slice and per crtc in bw state (or may be in DBuf state in future), that way we don't need to have all crtcs in state and those only if we detect if are actually going to change cdclk, just same way as we do with other stuff, i.e intel_atomic_serialize_global_state and co. Just as per Ville's paradigm. - Made dbuf bw calculation procedure look nicer by introducing for_each_dbuf_slice_in_mask - we often will now need to iterate slices using mask. - According to experimental results CDCLK * 64 accounts for overall bandwidth across all dbufs, not per dbuf. v4: - Fixed missing const(Ville) - Removed spurious whitespaces(Ville) - Fixed local variable init(reduced scope where not needed) - Added some comments about data rate for planar formats - Changed struct intel_crtc_bw to intel_dbuf_bw - Moved dbuf bw calculation to intel_compute_min_cdclk(Ville) v5: - Removed unneeded macro v6: - Prevent too frequent CDCLK switching back and forth: Always switch to higher CDCLK when needed to prevent bandwidth issues, however don't switch to lower CDCLK earlier than once in 30 minutes in order to prevent constant modeset blinking. We could of course not switch back at all, however this is bad from power consumption point of view. v7: - Fixed to track cdclk using bw_state, modeset will be now triggered only when CDCLK change is really needed. v8: - Lock global state if bw_state->min_cdclk is changed. - Try getting bw_state only if there are crtcs in the commit (need to have read-locked global state) v9: - Do not do Dbuf bw check for gens < 9 - triggers WARN as ddb_size is 0. v10: - Lock global state for older gens as well. v11: - Define new bw_calc_min_cdclk hook, instead of using a condition(Manasi Navare) v12: - Fixed rebase conflict v13: - Added spaces after declarations to make checkpatch happy. Signed-off-by: -
Stanislav Lisovskiy authored
We quite often need now to iterate only particular dbuf slices in mask, whether they are active or related to particular crtc. v2: - Minor code refactoring v3: - Use enum for max slices instead of macro Let's make our life a bit easier and use a macro for that. Reviewed-by:
-
Stanislav Lisovskiy authored
So lets support it. v2: - Fixed "from" field which got corrupted for some weird reason Reviewed-by:
-
Stanislav Lisovskiy authored
Checking with hweight8 if plane configuration had changed seems to be wrong as different plane configs can result in a same hamming weight. So lets check the bitmask itself. v2: Fixed "from" field which got corrupted for some weird reason Reviewed-by:
-
Stanislav Lisovskiy authored
In Gen11+ whenever we might exceed DBuf bandwidth we might need to recalculate CDCLK which DBuf bandwidth is scaled with. Total Dbuf bw used might change based on particular plane needs. Thus to calculate if cdclk needs to be changed it is not enough anymore to check plane configuration and plane min cdclk, per DBuf bw can be calculated only after wm/ddb calculation is done and all required planes are added into the state. In order to keep all min_cdclk related checks in one place let's extract it into separate function, checking and modifying any_ms. Reviewed-by:
-
Stanislav Lisovskiy authored
We need to calculate cdclk after watermarks/ddb has been calculated as with recent hw CDCLK needs to be adjusted accordingly to DBuf requirements, which is not possible with current code organization. Setting CDCLK according to DBuf BW requirements and not just rejecting if it doesn't satisfy BW requirements, will allow us to save power when it is possible and gain additional bandwidth when it's needed - i.e boosting both our power management and perfomance capabilities. This patch is preparation for that, first we now extract modeset calculation from modeset checks, in order to call it after wm/ddb has been calculated. v2: - Extract only intel_modeset_calc_cdclk from intel_modeset_checks (Ville Syrjälä) v3: - Clear plls after intel_modeset_calc_cdclk v4: - Added r-b from previous revision to commit message Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
As we no longer use PIN_UPDATE (since commit 7d0aa0db ("drm/i915/gem: Unbind all current vma on changing cache-level")) we can remove PIN_UPDATE itself. The benefit is just in simplifing the vma bind. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200521144949.25357-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order to be valid to dereference during the i915_fence_release, after retiring the fence and releasing its refererences, we assume that rq->engine can only be a real engine (that stay intact until the device is shutdown after all fences have been flushed). However, due to a quirk of preempt-to-busy, we may retire a request that still belongs to a virtual engine and so eventually free it with rq->engine being invalid. To avoid dereferencing that invalid engine, we look at the execution_mask which if it indicates it may be executed on more than one engine, we know it originated on a virtual engine and may still be on one. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906 Fixes: 43acd651 ("drm/i915: Keep a per-engine request pool") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200521140617.30015-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the removal of the no-semaphore boosting, we rely on timeslicing to reorder passed inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not universally enable timeslicing, even when it would correctly preempt our own inter-engine semaphores. Since timeslicing and semaphore priority deboosting is now disabled on Broadwell/Braswell, we have to follow suite and not use semaphores. Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw Fixes: 18e4af04 ("drm/i915: Drop no-semaphore boosting") Signed-off-by:
-
Chris Wilson authored
Use intel_engine_flush_submission() when we want to ensure that the tasklet is run. tasklet_kill(), while it may ensure that an ongoing tasklet is completed, also prevents the tasklet from running if it's already scheduled and hasn't yet been run. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1874Signed-off-by:
-
Chris Wilson authored
Count the number of CS_TIMESTAMP ticks and check that it matches our expectations. Signed-off-by:
-
- 20 May, 2020 11 commits
-
-
Matt Atwood authored
Reflect recent Bspec changes. Bspec: 33451 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519162534.10035-1-matthew.s.atwood@intel.com
-
Matt Roper authored
Since the number of platforms with this restriction are growing, let's separate out the platform logic into a has_phy_misc() function. Bspec: 50107 Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504225227.464666-11-matthew.d.roper@intel.com
-
Matt Roper authored
RKL power wells are similar to TGL power wells, but have some important differences: * PG1 now has pipe A's VDSC (rather than sticking it in PG2) * PG2 no longer exists * DDI-C (aka TC-1) moves from PG1 -> PG3 * PG5 no longer exists due to the lack of a fourth pipe Also note that what we refer to as 'DDI-C' and 'DDI-D' need to actually be programmed as TC-1 and TC-2 even though this platform doesn't have TC outputs. Bspec: 49234 Cc: Imre Deak <imre.deak@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Matt Roper authored
RKL only has five universal planes, plus a cursor. Since the bottom-most universal plane is considered the primary plane, set the number of sprites available on this platform to 4. In general, the plane capabilities of the remaining planes stay the same as TGL. However the NV12 Y-plane support moves down to the new top two planes and now only the bottom three planes can be used for NV12 UV. Bspec: 49181 Bspec: 49251 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Matt Roper authored
The RKL platform has different memory characteristics from past platforms. Update the values used by our memory bandwidth calculations accordingly. Bspec: 53998 Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Matt Roper authored
RKL re-uses the same stolen memory registers as TGL and ICL. Bspec: 52055 Bspec: 49589 Bspec: 49636 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Chris Wilson authored
This assertion was removed in commit b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning"), but accidentally restored by a cherry-pick into drm-next and now has percolated back to drm-intel-next-queued. Fixes: 2e46a2a0 ("drm/i915: Use explicit flag to mark unreachable intel_context") Fixes: 2b703bbd ("Merge drm/drm-next into drm-intel-next-queued") References: b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200520073048.2394034-1-chris@chris-wilson.co.uk
-
Matt Roper authored
Rocket Lake can pair with either TGP or CMP. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
RKL uses the same GuC and HuC as TGL and should load the same firmwares. Bspec: 50668 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Introduce the basic platform definition, macros, and PCI IDs. Bspec: 44501 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
Caz Yokoyama <caz.yokoyama@intel.com> Reviewed-by:
-
- 19 May, 2020 17 commits
-
-
Chris Wilson authored
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual request from the priority decision, we would not timeslice the current engine if there was an available virtual request. Testcase: igt/gem_exec_balancer/sliced Fixes: 3df2deed ("drm/i915/execlists: Enable timeslice on partial virtual engine dequeue") Signed-off-by:
-
Chris Wilson authored
If we decide to timeslice out the current virtual request, we will unsubmit it while it is still busy (ve->context.inflight == sibling[0]). If the virtual tasklet and then the other sibling tasklets run before we completely schedule out the active virtual request for the preemption, those other tasklets will see that the virtul request is still inflight on sibling[0] and leave it be. Therefore when we finally schedule-out the virtual request and if we see that we have passed it back to the virtual engine, reschedule the virtual tasklet so that it may be resubmitted on any of the siblings. Signed-off-by:
-
Chris Wilson authored
Make sure that we can execute a virtual request on an already busy engine, and conversely that we can execute a normal request if the engines are already fully occupied by virtual requests. Signed-off-by:
-
Chris Wilson authored
When we look at i915_request_is_started() we must be careful in case we are using a request that does not have the initial-breadcrumb and instead the is-started is being compared against the end of the previous request. This will make wait_for_submit() declare that a request has been already submitted too early. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519063123.20673-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since we temporarily disable the heartbeat and restore back to the default value, we can use the stored defaults on the engine and avoid using a local. Signed-off-by:
-
Chris Wilson authored
Check for integer overflow in the priority chain, rather than against a type-constricted max-priority check. Signed-off-by:
-
Chris Wilson authored
We recorded the execlists->queue_priority_hint update for the inflight request without kicking the tasklet. The next submitted request then failed to be scheduled as it had a lower priority than the hint, leaving the HW running with only the inflight request. Fixes: 6cebcf74 ("drm/i915: Tweak scheduler's kick_submission()") Signed-off-by:
-
Chris Wilson authored
A useful metric of the system's health is how fast we can tell the GPU to do various actions, so measure our latency. v2: Refactor all the instruction building into emitters. v3: Mark the error handling if not perfect, at least consistent. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN*. Conversion is done with below semantic patch: @@ identifier func, T; @@ func(struct intel_runtime_pm *T,...) { + struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, runtime_pm); <+... ( -WARN( +drm_WARN(&i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } Signed-off-by:Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-10-pankaj.laxminarayan.bharadiya@intel.com
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Conversion is done with below sementic patch: @@ identifier func, T; @@ func(...) { ... struct intel_crtc *T = ...; +struct drm_i915_private *dev_priv = to_i915(T->base.dev); <+... -WARN_ON( +drm_WARN_ON(&dev_priv->drm, ...) ...+> } @@ identifier func, T; @@ func(struct intel_crtc_state *T,...) { +struct drm_i915_private *dev_priv = to_i915(T->uapi.crtc->dev); <+... -WARN_ON( +drm_WARN_ON(&dev_priv->drm, ...) ...+> } changes since v1: - Added dev_priv local variable and used it in drm_WARN_ON calls (Jani) Signed-off-by: -
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. changes since v1: - Add parentheses around the dev_priv macro argument (Jani) Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* at places where struct drm_device pointer can be extracted. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Conversion is done with below sementic patch: @@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... -WARN_ON( +drm_WARN_ON(&T->drm, ...) ...+> } @@ identifier func, T; @@ func(struct intel_digital_port *T,...) { +struct drm_i915_private *i915 = to_i915(T->base.base.dev); <+... -WARN_ON( +drm_WARN_ON(&i915->drm, ...) ...+> } changes since v1: - Add i915 local variable and use it in drm_WARN_ON (Jani) Signed-off-by: -
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* calls. changes since v1: - Added dev_priv local variable and used it in drm_WARN* calls (Jani) Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* at places where struct intel_dp or struct drm_i915_private pointer is available. Conversion is done with below sementic patch: @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule3@ identifier func, T; @@ func(struct intel_dp *T,...) { + struct drm_i915_private *i915 = dp_to_i915(T); <+... ( -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(...) { ... struct intel_dp *T = ...; + struct drm_i915_private *i915 = dp_to_i915(T); <+... ( -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } Signed-off-by: -
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains struct is available. Conversion is done with below sementic patch: @@ identifier func, T; @@ func(struct i915_power_domains *T,...) { + struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, power_domains); <+... -WARN_ON( +drm_WARN_ON(&i915->drm, ...) ...+> } changes since v1: - Fix commit subject (Jani) Signed-off-by:
-
