* [Intel-gfx] [PATCH v17 2/7] drm/i915: Introduce skl_plane_wm_level accessor.
From: Stanislav Lisovskiy @ 2020-02-20 12:07 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be changed
in next coming patches from this series.
v2: - plane_id -> plane->id(Ville Syrjälä)
- Moved wm_level var to have more local scope
(Ville Syrjälä)
- Renamed yuv to color_plane(Ville Syrjälä) in
skl_plane_wm_level
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/intel_pm.c | 120 +++++++++++++++++++++-----------
1 file changed, 81 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d6933e382657..e1d167429489 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4548,6 +4548,18 @@ icl_get_total_relative_data_rate(struct intel_crtc_state *crtc_state,
return total_data_rate;
}
+static const struct skl_wm_level *
+skl_plane_wm_level(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ int level,
+ int color_plane)
+{
+ const struct skl_plane_wm *wm =
+ &crtc_state->wm.skl.optimal.planes[plane->id];
+
+ return color_plane ? &wm->uv_wm[level] : &wm->wm[level];
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
@@ -4560,7 +4572,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
u16 total[I915_MAX_PLANES] = {};
u16 uv_total[I915_MAX_PLANES] = {};
u64 total_data_rate;
- enum plane_id plane_id;
+ struct intel_plane *plane;
int num_active;
u64 plane_data_rate[I915_MAX_PLANES] = {};
u64 uv_plane_data_rate[I915_MAX_PLANES] = {};
@@ -4612,22 +4624,28 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
*/
for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
blocks = 0;
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
- const struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
- if (plane_id == PLANE_CURSOR) {
- if (wm->wm[level].min_ddb_alloc > total[PLANE_CURSOR]) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
+
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ level, false);
+ wm_uv_level = skl_plane_wm_level(plane, crtc_state,
+ level, true);
+
+ if (plane->id == PLANE_CURSOR) {
+ if (wm_level->min_ddb_alloc > total[PLANE_CURSOR]) {
drm_WARN_ON(&dev_priv->drm,
- wm->wm[level].min_ddb_alloc != U16_MAX);
+ wm_level->min_ddb_alloc != U16_MAX);
blocks = U32_MAX;
break;
}
continue;
}
- blocks += wm->wm[level].min_ddb_alloc;
- blocks += wm->uv_wm[level].min_ddb_alloc;
+ blocks += wm_level->min_ddb_alloc;
+ blocks += wm_uv_level->min_ddb_alloc;
}
if (blocks <= alloc_size) {
@@ -4649,13 +4667,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* watermark level, plus an extra share of the leftover blocks
* proportional to its relative data rate.
*/
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
- const struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
u64 rate;
u16 extra;
- if (plane_id == PLANE_CURSOR)
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ level, false);
+ wm_uv_level = skl_plane_wm_level(plane, crtc_state,
+ level, true);
+
+ if (plane->id == PLANE_CURSOR)
continue;
/*
@@ -4665,22 +4688,22 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
if (total_data_rate == 0)
break;
- rate = plane_data_rate[plane_id];
+ rate = plane_data_rate[plane->id];
extra = min_t(u16, alloc_size,
DIV64_U64_ROUND_UP(alloc_size * rate,
total_data_rate));
- total[plane_id] = wm->wm[level].min_ddb_alloc + extra;
+ total[plane->id] = wm_level->min_ddb_alloc + extra;
alloc_size -= extra;
total_data_rate -= rate;
if (total_data_rate == 0)
break;
- rate = uv_plane_data_rate[plane_id];
+ rate = uv_plane_data_rate[plane->id];
extra = min_t(u16, alloc_size,
DIV64_U64_ROUND_UP(alloc_size * rate,
total_data_rate));
- uv_total[plane_id] = wm->uv_wm[level].min_ddb_alloc + extra;
+ uv_total[plane->id] = wm_uv_level->min_ddb_alloc + extra;
alloc_size -= extra;
total_data_rate -= rate;
}
@@ -4688,29 +4711,29 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
/* Set the actual DDB start/end points for each plane */
start = alloc->start;
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
struct skl_ddb_entry *plane_alloc =
- &crtc_state->wm.skl.plane_ddb_y[plane_id];
+ &crtc_state->wm.skl.plane_ddb_y[plane->id];
struct skl_ddb_entry *uv_plane_alloc =
- &crtc_state->wm.skl.plane_ddb_uv[plane_id];
+ &crtc_state->wm.skl.plane_ddb_uv[plane->id];
- if (plane_id == PLANE_CURSOR)
+ if (plane->id == PLANE_CURSOR)
continue;
/* Gen11+ uses a separate plane for UV watermarks */
drm_WARN_ON(&dev_priv->drm,
- INTEL_GEN(dev_priv) >= 11 && uv_total[plane_id]);
+ INTEL_GEN(dev_priv) >= 11 && uv_total[plane->id]);
/* Leave disabled planes at (0,0) */
- if (total[plane_id]) {
+ if (total[plane->id]) {
plane_alloc->start = start;
- start += total[plane_id];
+ start += total[plane->id];
plane_alloc->end = start;
}
- if (uv_total[plane_id]) {
+ if (uv_total[plane->id]) {
uv_plane_alloc->start = start;
- start += uv_total[plane_id];
+ start += uv_total[plane->id];
uv_plane_alloc->end = start;
}
}
@@ -4722,9 +4745,16 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* that aren't actually possible.
*/
for (level++; level <= ilk_wm_max_level(dev_priv); level++) {
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
+ &crtc_state->wm.skl.optimal.planes[plane->id];
+
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ level, false);
+ wm_uv_level = skl_plane_wm_level(plane, crtc_state,
+ level, true);
/*
* We only disable the watermarks for each plane if
@@ -4738,9 +4768,10 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* planes must be enabled before the level will be used."
* So this is actually safe to do.
*/
- if (wm->wm[level].min_ddb_alloc > total[plane_id] ||
- wm->uv_wm[level].min_ddb_alloc > uv_total[plane_id])
- memset(&wm->wm[level], 0, sizeof(wm->wm[level]));
+ if (wm_level->min_ddb_alloc > total[plane->id] ||
+ wm_uv_level->min_ddb_alloc > uv_total[plane->id])
+ memset(&wm->wm[level], 0,
+ sizeof(struct skl_wm_level));
/*
* Wa_1408961008:icl, ehl
@@ -4748,9 +4779,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
*/
if (IS_GEN(dev_priv, 11) &&
level == 1 && wm->wm[0].plane_en) {
- wm->wm[level].plane_res_b = wm->wm[0].plane_res_b;
- wm->wm[level].plane_res_l = wm->wm[0].plane_res_l;
- wm->wm[level].ignore_lines = wm->wm[0].ignore_lines;
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ 0, false);
+ wm->wm[level].plane_res_b =
+ wm_level->plane_res_b;
+ wm->wm[level].plane_res_l =
+ wm_level->plane_res_l;
+ wm->wm[level].ignore_lines =
+ wm_level->ignore_lines;
}
}
}
@@ -4759,11 +4795,11 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* Go back and disable the transition watermark if it turns out we
* don't have enough DDB blocks for it.
*/
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
+ &crtc_state->wm.skl.optimal.planes[plane->id];
- if (wm->trans_wm.plane_res_b >= total[plane_id])
+ if (wm->trans_wm.plane_res_b >= total[plane->id])
memset(&wm->trans_wm, 0, sizeof(wm->trans_wm));
}
@@ -5354,10 +5390,13 @@ void skl_write_plane_wm(struct intel_plane *plane,
&crtc_state->wm.skl.plane_ddb_y[plane_id];
const struct skl_ddb_entry *ddb_uv =
&crtc_state->wm.skl.plane_ddb_uv[plane_id];
+ const struct skl_wm_level *wm_level;
for (level = 0; level <= max_level; level++) {
+ wm_level = skl_plane_wm_level(plane, crtc_state, level, false);
+
skl_write_wm_level(dev_priv, PLANE_WM(pipe, plane_id, level),
- &wm->wm[level]);
+ wm_level);
}
skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
&wm->trans_wm);
@@ -5388,10 +5427,13 @@ void skl_write_cursor_wm(struct intel_plane *plane,
&crtc_state->wm.skl.optimal.planes[plane_id];
const struct skl_ddb_entry *ddb =
&crtc_state->wm.skl.plane_ddb_y[plane_id];
+ const struct skl_wm_level *wm_level;
for (level = 0; level <= max_level; level++) {
+ wm_level = skl_plane_wm_level(plane, crtc_state, level, false);
+
skl_write_wm_level(dev_priv, CUR_WM(pipe, level),
- &wm->wm[level]);
+ wm_level);
}
skl_write_wm_level(dev_priv, CUR_WM_TRANS(pipe), &wm->trans_wm);
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v17 4/7] drm/i915: Refactor intel_can_enable_sagv
From: Stanislav Lisovskiy @ 2020-02-20 12:07 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with added sagv block time latency and
check if it fits in DBuf in order to
determine if SAGV can be enabled already
at this stage, just as BSpec 49325 states.
if that fails rollback to usual Level 0
latency and disable SAGV.
- Remove unneeded tabs(James Ausmus)
v3: Rebased the patch
v4: - Added back interlaced check for Gen12 and
added separate function for TGL SAGV check
(thanks to James Ausmus for spotting)
- Removed unneeded gen check
- Extracted Gen12 SAGV decision making code
to a separate function from skl_compute_wm
v5: - Added SAGV global state to dev_priv, because
we need to track all pipes, not only those
in atomic state. Each pipe has now correspondent
bit mask reflecting, whether it can tolerate
SAGV or not(thanks to Ville Syrjala for suggestions).
- Now using active flag instead of enable in crc
usage check.
v6: - Fixed rebase conflicts
v7: - kms_cursor_legacy seems to get broken because of multiple memcpy
calls when copying level 0 water marks for enabled SAGV, to
fix this now simply using that field right away, without copying,
for that introduced a new wm_level accessor which decides which
wm_level to return based on SAGV state.
v8: - Protect crtc_sagv_mask same way as we do for other global state
changes: i.e check if changes are needed, then grab all crtc locks
to serialize the changes(Ville Syrjälä)
- Add crtc_sagv_mask caching in order to avoid needless recalculations
(Matthew Roper)
- Put back Gen12 SAGV switch in order to get it enabled in separate
patch(Matthew Roper)
- Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper)
- Check if there are no active pipes in intel_can_enable_sagv
instead of platform specific functions(Matthew Roper), same
for intel_has_sagv check.
v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä)
- crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä)
- Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask
- Extracted skl_plane_wm_level function and passing latency to
separate patches(Ville Syrjälä)
- Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm
(Ville Syrjälä)
- Now using simple assignment for sagv_wm0 as it contains only
pod types and no pointers(Ville Syrjälä)
- Fixed intel_can_enable_sagv not to do double duty, now it only
check SAGV bits by ANDing those between local and global state.
The SAGV masks are now computed after watermarks are available,
in order to be able to figure out if ddb ranges are fitting nicely.
(Ville Syrjälä)
- Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic
when using skl_plane_wm_level accessor, as we had previously for Gen11+
color plane and regular wm levels, so probably both has to be recalculated
with additional SAGV block time for Level 0.
v10: - Starting to use new global state for storing pipe_sagv_mask
v11: - Fixed rebase conflict with recent drm-tip
- Check if we really need to recalculate SAGV mask, otherwise
bail out without making any changes.
- Use cached SAGV result, instead of recalculating it everytime,
if bw_state hasn't changed.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
---
drivers/gpu/drm/i915/display/intel_bw.h | 18 +
drivers/gpu/drm/i915/display/intel_display.c | 22 +-
.../drm/i915/display/intel_display_types.h | 2 +
.../gpu/drm/i915/display/intel_global_state.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 449 ++++++++++++++++--
drivers/gpu/drm/i915/intel_pm.h | 4 +-
6 files changed, 454 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
index ac004d6f4276..fb1760125f9d 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -18,6 +18,24 @@ struct intel_crtc_state;
struct intel_bw_state {
struct intel_global_state base;
+ /*
+ * Contains a bit mask, used to determine, whether correspondent
+ * pipe allows SAGV or not.
+ */
+ u8 pipe_sagv_mask;
+
+ /*
+ * Used to determine if we already had calculated
+ * SAGV mask for this state once.
+ */
+ bool sagv_calculated;
+
+ /*
+ * Contains final SAGV decision based on current mask,
+ * to prevent doing the same job over and over again.
+ */
+ bool can_sagv;
+
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
};
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 48fe3d2e0fa3..6a4d88e4d41a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13977,7 +13977,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(&hw_plane_wm->wm[level],
- &sw_plane_wm->wm[level]))
+ &sw_plane_wm->wm[level]) ||
+ (skl_wm_level_equals(&hw_plane_wm->wm[level],
+ &sw_plane_wm->sagv_wm0) &&
+ (level == 0)))
continue;
drm_err(&dev_priv->drm,
@@ -14032,7 +14035,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
/* Watermarks */
for (level = 0; level <= max_level; level++) {
if (skl_wm_level_equals(&hw_plane_wm->wm[level],
- &sw_plane_wm->wm[level]))
+ &sw_plane_wm->wm[level]) ||
+ (skl_wm_level_equals(&hw_plane_wm->wm[level],
+ &sw_plane_wm->sagv_wm0) &&
+ (level == 0)))
continue;
drm_err(&dev_priv->drm,
@@ -15509,8 +15515,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
* SKL workaround: bspec recommends we disable the SAGV when we
* have more then one pipe enabled
*/
- if (!intel_can_enable_sagv(state))
- intel_disable_sagv(dev_priv);
+ if (INTEL_GEN(dev_priv) < 11)
+ if (!intel_can_enable_sagv(dev_priv))
+ intel_disable_sagv(dev_priv);
intel_modeset_verify_disabled(dev_priv, state);
}
@@ -15610,8 +15617,10 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
if (state->modeset)
intel_verify_planes(state);
- if (state->modeset && intel_can_enable_sagv(state))
- intel_enable_sagv(dev_priv);
+ if (INTEL_GEN(dev_priv) < 11) {
+ if (state->modeset && intel_can_enable_sagv(dev_priv))
+ intel_enable_sagv(dev_priv);
+ }
drm_atomic_helper_commit_hw_done(&state->base);
@@ -15763,7 +15772,6 @@ static int intel_atomic_commit(struct drm_device *dev,
if (state->global_state_changed) {
assert_global_state_locked(dev_priv);
-
dev_priv->active_pipes = state->active_pipes;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0d8a64305464..407892aa93bf 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -654,6 +654,8 @@ struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
+ struct skl_wm_level sagv_wm0;
+ struct skl_wm_level uv_sagv_wm0;
bool is_planar;
};
diff --git a/drivers/gpu/drm/i915/display/intel_global_state.h b/drivers/gpu/drm/i915/display/intel_global_state.h
index e6163a469029..481bf5ea90a3 100644
--- a/drivers/gpu/drm/i915/display/intel_global_state.h
+++ b/drivers/gpu/drm/i915/display/intel_global_state.h
@@ -84,4 +84,5 @@ void intel_atomic_clear_global_state(struct intel_atomic_state *state);
int intel_atomic_lock_global_state(struct intel_global_state *obj_state);
int intel_atomic_serialize_global_state(struct intel_global_state *obj_state);
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e1d167429489..2aafd2b07e4a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_trace.h"
+#include "display/intel_bw.h"
#include "intel_pm.h"
#include "intel_sideband.h"
#include "../../../platform/x86/intel_ips.h"
@@ -3620,7 +3621,7 @@ static bool skl_needs_memory_bw_wa(struct drm_i915_private *dev_priv)
return IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv);
}
-static bool
+bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
/* HACK! */
@@ -3743,39 +3744,24 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
return 0;
}
-bool intel_can_enable_sagv(struct intel_atomic_state *state)
+static bool skl_can_enable_sagv_on_pipe(struct intel_atomic_state *state,
+ enum pipe pipe)
{
struct drm_device *dev = state->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc;
struct intel_plane *plane;
struct intel_crtc_state *crtc_state;
- enum pipe pipe;
int level, latency;
- if (!intel_has_sagv(dev_priv))
- return false;
-
- /*
- * If there are no active CRTCs, no additional checks need be performed
- */
- if (hweight8(state->active_pipes) == 0)
- return true;
-
- /*
- * SKL+ workaround: bspec recommends we disable SAGV when we have
- * more then one pipe enabled
- */
- if (hweight8(state->active_pipes) > 1)
- return false;
-
- /* Since we're now guaranteed to only have one active CRTC... */
- pipe = ffs(state->active_pipes) - 1;
crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
crtc_state = to_intel_crtc_state(crtc->base.state);
- if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
+ if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE) {
+ DRM_DEBUG_KMS("No SAGV for interlaced mode on pipe %c\n",
+ pipe_name(pipe));
return false;
+ }
for_each_intel_plane_on_crtc(dev, crtc, plane) {
struct skl_plane_wm *wm =
@@ -3802,13 +3788,174 @@ bool intel_can_enable_sagv(struct intel_atomic_state *state)
* incur memory latencies higher than sagv_block_time_us we
* can't enable SAGV.
*/
- if (latency < dev_priv->sagv_block_time_us)
+ if (latency < dev_priv->sagv_block_time_us) {
+ DRM_DEBUG_KMS("Latency %d < sagv block time %d, no SAGV for pipe %c\n",
+ latency, dev_priv->sagv_block_time_us, pipe_name(pipe));
return false;
+ }
}
return true;
}
+static void skl_compute_sagv_mask(struct intel_atomic_state *state)
+{
+ struct intel_crtc *crtc;
+ enum pipe pipe;
+ struct intel_bw_state *new_bw_state = intel_atomic_get_bw_state(state);
+
+ if (IS_ERR(new_bw_state)) {
+ WARN(1, "Could not get bw_state\n");
+ return;
+ }
+
+
+ if (state->active_pipes != 1) {
+ new_bw_state->pipe_sagv_mask = 0;
+ DRM_DEBUG_KMS("No SAGV for multiple pipes on Gen 9\n");
+ return;
+ }
+
+ /* Since we're now guaranteed to only have one active CRTC... */
+ pipe = ffs(state->active_pipes) - 1;
+
+ if (skl_can_enable_sagv_on_pipe(state, pipe))
+ new_bw_state->pipe_sagv_mask |= BIT(crtc->pipe);
+ else
+ new_bw_state->pipe_sagv_mask &= ~BIT(crtc->pipe);
+}
+
+static void tgl_compute_sagv_mask(struct intel_atomic_state *state);
+
+static void icl_compute_sagv_mask(struct intel_atomic_state *state)
+{
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *new_crtc_state;
+ int i;
+ struct intel_bw_state *new_bw_state = intel_atomic_get_bw_state(state);
+
+ if (IS_ERR(new_bw_state)) {
+ WARN(1, "Could not get bw_state\n");
+ return;
+ }
+
+ for_each_new_intel_crtc_in_state(state, crtc,
+ new_crtc_state, i) {
+ if (skl_can_enable_sagv_on_pipe(state, crtc->pipe))
+ new_bw_state->pipe_sagv_mask |= BIT(crtc->pipe);
+ else
+ new_bw_state->pipe_sagv_mask &= ~BIT(crtc->pipe);
+ }
+}
+
+void intel_compute_sagv_mask(struct intel_atomic_state *state, int total_affected_planes)
+{
+ int ret;
+ struct drm_device *dev = state->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_bw_state *new_bw_state = intel_atomic_get_bw_state(state);
+ struct intel_bw_state *old_bw_state = intel_atomic_get_old_bw_state(state);
+
+ if (IS_ERR(new_bw_state) || IS_ERR(old_bw_state)) {
+ WARN(1, "Could not get bw_state\n");
+ return;
+ }
+
+ new_bw_state->sagv_calculated = false;
+
+ /*
+ * If active_pipes had changed, means we have added/removed crtc,
+ * if total_affected_planes had changed - means we have changed wm/ddb.
+ * Both require SAGV recalculation - otherwise just return and SAGV mask
+ * will stay the same.
+ * Also we will have crtc locks grabbed only in mentioned above cases.
+ */
+ if ((state->active_pipes == dev_priv->active_pipes) &&
+ (total_affected_planes == 0)) {
+ new_bw_state->sagv_calculated = true;
+ return;
+ }
+
+ /*
+ * Now once we got wm levels calculated,
+ * check if we can have SAGV.
+ */
+ if (INTEL_GEN(dev_priv) >= 12)
+ tgl_compute_sagv_mask(state);
+ else if (INTEL_GEN(dev_priv) == 11)
+ icl_compute_sagv_mask(state);
+ else
+ skl_compute_sagv_mask(state);
+
+ /*
+ * For SAGV we need to account all the pipes,
+ * not only the ones which are in state currently.
+ * Grab all locks if we detect that we are actually
+ * going to do something.
+ */
+ if (new_bw_state->pipe_sagv_mask != old_bw_state->pipe_sagv_mask) {
+ ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+ if (ret) {
+ DRM_DEBUG_KMS("Could not serialize global state\n");
+ return;
+ }
+ }
+}
+
+bool intel_calculate_sagv_result(struct drm_i915_private *dev_priv,
+ struct intel_bw_state *bw_state)
+{
+ bool sagv_result = true;
+ enum pipe pipe;
+
+ for_each_pipe(dev_priv, pipe) {
+ /*
+ * TODO: We are depending on active_pipes here,
+ * probably it should be part of some other global state
+ * obj, like modeset_state or smth, which we should depend on.
+ * Don't want to clone it here, really.
+ */
+ int active_pipe_bit = dev_priv->active_pipes & BIT(pipe);
+ if (active_pipe_bit) {
+ if ((bw_state->pipe_sagv_mask & BIT(pipe)) == 0) {
+ sagv_result = false;
+ break;
+ }
+ }
+ }
+
+ return sagv_result;
+}
+
+/*
+ * This function to be used before swap state
+ */
+bool intel_can_enable_sagv_for_state(struct intel_atomic_state *state)
+{
+ struct drm_device *dev = state->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_bw_state *bw_state = intel_atomic_get_bw_state(state);
+
+ if (IS_ERR(bw_state)) {
+ WARN(1, "Could not get bw_state\n");
+ return false;
+ }
+
+ if (!intel_has_sagv(dev_priv)) {
+ DRM_DEBUG_KMS("No SAGV support detected\n");
+ return false;
+ }
+
+ if (bw_state->sagv_calculated)
+ goto out;
+
+ bw_state->can_sagv = intel_calculate_sagv_result(dev_priv, bw_state);
+ bw_state->sagv_calculated = true;
+
+out:
+ return bw_state->can_sagv;
+}
+
/*
* Calculate initial DBuf slice offset, based on slice size
* and mask(i.e if slice size is 1024 and second slice is enabled
@@ -3842,6 +3989,46 @@ static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv)
return ddb_size;
}
+/*
+ * To be used after we swap state
+ */
+bool intel_can_enable_sagv(struct drm_i915_private *dev_priv)
+{
+ struct intel_global_state *global_state;
+ struct intel_bw_state *bw_state;
+
+ global_state = dev_priv->bw_obj.state;
+ if (IS_ERR(global_state)) {
+ WARN(1, "Could not get global state\n");
+ return false;
+ }
+
+ /*
+ * TODO: Should we still may be lock global state here?
+ */
+ bw_state = to_intel_bw_state(global_state);
+
+ /*
+ * Should have this calculated by that time,
+ * means something got changed or wrong in the driver
+ * currently, supposed places which call this function are:
+ * intel_atomic_commit_tail, intel_atomic_bw_check,
+ * skl_allocate_pipe_ddb, skl_write_plane_wm.
+ * All of those are supposed to be called after
+ * skl_compute_wm->intel_compute_sagv_mask is called.
+ */
+ drm_WARN_ON(&dev_priv->drm, !bw_state->sagv_calculated);
+
+ if (bw_state->sagv_calculated)
+ goto out;
+
+ bw_state->can_sagv = intel_calculate_sagv_result(dev_priv, bw_state);
+ bw_state->sagv_calculated = true;
+
+out:
+ return bw_state->can_sagv;
+}
+
static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
u32 active_pipes);
@@ -4028,6 +4215,7 @@ skl_cursor_allocation(const struct intel_crtc_state *crtc_state,
u32 latency = dev_priv->wm.skl_latency[level];
skl_compute_plane_wm(crtc_state, level, latency, &wp, &wm, &wm);
+
if (wm.min_ddb_alloc == U16_MAX)
break;
@@ -4554,12 +4742,93 @@ skl_plane_wm_level(struct intel_plane *plane,
int level,
int color_plane)
{
+ struct drm_atomic_state *state = crtc_state->uapi.state;
+ struct drm_crtc *crtc = crtc_state->uapi.crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
const struct skl_plane_wm *wm =
&crtc_state->wm.skl.optimal.planes[plane->id];
+ if (!level) {
+ bool can_sagv = false;
+
+ /*
+ * If we haven't yet swapped our state, we should use
+ * the state to determine SAGV, otherwise use global
+ * state as atomic state pointer might become stale
+ * and zeroed out.
+ */
+ if (state) {
+ struct intel_atomic_state *intel_state =
+ to_intel_atomic_state(state);
+ can_sagv = intel_can_enable_sagv_for_state(intel_state);
+ } else {
+ can_sagv = intel_can_enable_sagv(dev_priv);
+ }
+
+ if (can_sagv)
+ return color_plane ? &wm->uv_sagv_wm0 : &wm->sagv_wm0;
+ }
+
return color_plane ? &wm->uv_wm[level] : &wm->wm[level];
}
+static int
+tgl_check_pipe_fits_sagv_wm(struct intel_crtc_state *crtc_state)
+{
+ struct drm_crtc *crtc = crtc_state->uapi.crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct skl_ddb_entry *alloc = &crtc_state->wm.skl.ddb;
+ u16 alloc_size;
+ u64 total_data_rate;
+ enum plane_id plane_id;
+ int num_active;
+ u64 plane_data_rate[I915_MAX_PLANES] = {};
+ u32 blocks;
+
+ /*
+ * No need to check gen here, we call this only for gen12
+ */
+ total_data_rate =
+ icl_get_total_relative_data_rate(crtc_state,
+ plane_data_rate);
+
+ skl_ddb_get_pipe_allocation_limits(dev_priv, crtc_state,
+ total_data_rate,
+ alloc, &num_active);
+ alloc_size = skl_ddb_entry_size(alloc);
+ if (alloc_size == 0)
+ return -ENOSPC;
+
+ /*
+ * Do check if we can fit L0 + sagv_block_time and
+ * disable SAGV if we can't.
+ */
+ blocks = 0;
+ for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ /*
+ * The only place, where we can't use skl_plane_wm_level
+ * accessor, because if actually calls intel_can_enable_sagv
+ * which depends on that function.
+ */
+ const struct skl_plane_wm *wm =
+ &crtc_state->wm.skl.optimal.planes[plane_id];
+
+ blocks += wm->sagv_wm0.min_ddb_alloc;
+ blocks += wm->uv_sagv_wm0.min_ddb_alloc;
+
+ if (blocks > alloc_size) {
+ DRM_DEBUG_KMS("Not enough ddb blocks(%d<%d) for SAGV on pipe %c\n",
+ alloc_size, blocks, pipe_name(intel_crtc->pipe));
+ return -ENOSPC;
+ }
+ }
+ DRM_DEBUG_KMS("%d total blocks required for SAGV, ddb entry size %d\n",
+ blocks, alloc_size);
+ return 0;
+}
+
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
@@ -5143,11 +5412,19 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
static void
skl_compute_wm_levels(const struct intel_crtc_state *crtc_state,
const struct skl_wm_params *wm_params,
- struct skl_wm_level *levels)
+ struct skl_plane_wm *plane_wm,
+ bool yuv)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
int level, max_level = ilk_wm_max_level(dev_priv);
+ /*
+ * Check which kind of plane is it and based on that calculate
+ * correspondent WM levels.
+ */
+ struct skl_wm_level *levels = yuv ? plane_wm->uv_wm : plane_wm->wm;
struct skl_wm_level *result_prev = &levels[0];
+ struct skl_wm_level *sagv_wm = yuv ?
+ &plane_wm->uv_sagv_wm0 : &plane_wm->sagv_wm0;
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = &levels[level];
@@ -5158,6 +5435,27 @@ skl_compute_wm_levels(const struct intel_crtc_state *crtc_state,
result_prev = result;
}
+ /*
+ * For Gen12 if it is an L0 we need to also
+ * consider sagv_block_time when calculating
+ * L0 watermark - we will need that when making
+ * a decision whether enable SAGV or not.
+ * For older gens we agreed to copy L0 value for
+ * compatibility.
+ */
+ if ((INTEL_GEN(dev_priv) >= 12)) {
+ u32 latency = dev_priv->wm.skl_latency[0];
+
+ latency += dev_priv->sagv_block_time_us;
+ skl_compute_plane_wm(crtc_state, 0, latency,
+ wm_params, &levels[0],
+ sagv_wm);
+ DRM_DEBUG_KMS("%d L0 blocks required for SAGV vs %d for non-SAGV\n",
+ sagv_wm->min_ddb_alloc, levels[0].min_ddb_alloc);
+ } else {
+ /* Since all members are POD */
+ *sagv_wm = levels[0];
+ }
}
static void skl_compute_transition_wm(const struct intel_crtc_state *crtc_state,
@@ -5232,7 +5530,7 @@ static int skl_build_plane_wm_single(struct intel_crtc_state *crtc_state,
if (ret)
return ret;
- skl_compute_wm_levels(crtc_state, &wm_params, wm->wm);
+ skl_compute_wm_levels(crtc_state, &wm_params, wm, false);
skl_compute_transition_wm(crtc_state, &wm_params, wm);
return 0;
@@ -5254,7 +5552,7 @@ static int skl_build_plane_wm_uv(struct intel_crtc_state *crtc_state,
if (ret)
return ret;
- skl_compute_wm_levels(crtc_state, &wm_params, wm->uv_wm);
+ skl_compute_wm_levels(crtc_state, &wm_params, wm, true);
return 0;
}
@@ -5585,10 +5883,29 @@ skl_print_wm_changes(struct intel_atomic_state *state)
for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
enum plane_id plane_id = plane->id;
const struct skl_plane_wm *old_wm, *new_wm;
+ u16 old_plane_res_l, new_plane_res_l;
+ u8 old_plane_res_b, new_plane_res_b;
+ u16 old_min_ddb_alloc, new_min_ddb_alloc;
old_wm = &old_pipe_wm->planes[plane_id];
new_wm = &new_pipe_wm->planes[plane_id];
+ old_plane_res_l = intel_can_enable_sagv(dev_priv) ?
+ old_wm->sagv_wm0.plane_res_l : old_wm->wm[0].plane_res_l;
+ old_plane_res_b = intel_can_enable_sagv(dev_priv) ?
+ old_wm->sagv_wm0.plane_res_b : old_wm->wm[0].plane_res_b;
+
+ new_plane_res_l = intel_can_enable_sagv_for_state(state) ?
+ new_wm->sagv_wm0.plane_res_l : new_wm->wm[0].plane_res_l;
+ new_plane_res_b = intel_can_enable_sagv_for_state(state) ?
+ new_wm->sagv_wm0.plane_res_b : new_wm->wm[0].plane_res_b;
+
+ old_min_ddb_alloc = intel_can_enable_sagv(dev_priv) ?
+ old_wm->sagv_wm0.min_ddb_alloc : old_wm->wm[0].min_ddb_alloc;
+
+ new_min_ddb_alloc = intel_can_enable_sagv_for_state(state) ?
+ new_wm->sagv_wm0.min_ddb_alloc : new_wm->wm[0].min_ddb_alloc;
+
if (skl_plane_wm_equals(dev_priv, old_wm, new_wm))
continue;
@@ -5611,7 +5928,7 @@ skl_print_wm_changes(struct intel_atomic_state *state)
"[PLANE:%d:%s] lines %c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d"
" -> %c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d,%c%3d\n",
plane->base.base.id, plane->base.name,
- enast(old_wm->wm[0].ignore_lines), old_wm->wm[0].plane_res_l,
+ enast(old_wm->wm[0].ignore_lines), old_plane_res_l,
enast(old_wm->wm[1].ignore_lines), old_wm->wm[1].plane_res_l,
enast(old_wm->wm[2].ignore_lines), old_wm->wm[2].plane_res_l,
enast(old_wm->wm[3].ignore_lines), old_wm->wm[3].plane_res_l,
@@ -5621,7 +5938,7 @@ skl_print_wm_changes(struct intel_atomic_state *state)
enast(old_wm->wm[7].ignore_lines), old_wm->wm[7].plane_res_l,
enast(old_wm->trans_wm.ignore_lines), old_wm->trans_wm.plane_res_l,
- enast(new_wm->wm[0].ignore_lines), new_wm->wm[0].plane_res_l,
+ enast(new_wm->wm[0].ignore_lines), new_plane_res_l,
enast(new_wm->wm[1].ignore_lines), new_wm->wm[1].plane_res_l,
enast(new_wm->wm[2].ignore_lines), new_wm->wm[2].plane_res_l,
enast(new_wm->wm[3].ignore_lines), new_wm->wm[3].plane_res_l,
@@ -5635,12 +5952,12 @@ skl_print_wm_changes(struct intel_atomic_state *state)
"[PLANE:%d:%s] blocks %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"
" -> %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
plane->base.base.id, plane->base.name,
- old_wm->wm[0].plane_res_b, old_wm->wm[1].plane_res_b,
+ old_plane_res_b, old_wm->wm[1].plane_res_b,
old_wm->wm[2].plane_res_b, old_wm->wm[3].plane_res_b,
old_wm->wm[4].plane_res_b, old_wm->wm[5].plane_res_b,
old_wm->wm[6].plane_res_b, old_wm->wm[7].plane_res_b,
old_wm->trans_wm.plane_res_b,
- new_wm->wm[0].plane_res_b, new_wm->wm[1].plane_res_b,
+ new_plane_res_b, new_wm->wm[1].plane_res_b,
new_wm->wm[2].plane_res_b, new_wm->wm[3].plane_res_b,
new_wm->wm[4].plane_res_b, new_wm->wm[5].plane_res_b,
new_wm->wm[6].plane_res_b, new_wm->wm[7].plane_res_b,
@@ -5650,12 +5967,12 @@ skl_print_wm_changes(struct intel_atomic_state *state)
"[PLANE:%d:%s] min_ddb %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d"
" -> %4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d,%4d\n",
plane->base.base.id, plane->base.name,
- old_wm->wm[0].min_ddb_alloc, old_wm->wm[1].min_ddb_alloc,
+ old_min_ddb_alloc, old_wm->wm[1].min_ddb_alloc,
old_wm->wm[2].min_ddb_alloc, old_wm->wm[3].min_ddb_alloc,
old_wm->wm[4].min_ddb_alloc, old_wm->wm[5].min_ddb_alloc,
old_wm->wm[6].min_ddb_alloc, old_wm->wm[7].min_ddb_alloc,
old_wm->trans_wm.min_ddb_alloc,
- new_wm->wm[0].min_ddb_alloc, new_wm->wm[1].min_ddb_alloc,
+ new_min_ddb_alloc, new_wm->wm[1].min_ddb_alloc,
new_wm->wm[2].min_ddb_alloc, new_wm->wm[3].min_ddb_alloc,
new_wm->wm[4].min_ddb_alloc, new_wm->wm[5].min_ddb_alloc,
new_wm->wm[6].min_ddb_alloc, new_wm->wm[7].min_ddb_alloc,
@@ -5755,7 +6072,8 @@ skl_ddb_add_affected_pipes(struct intel_atomic_state *state)
* default value of the watermarks registers is not zero.
*/
static int skl_wm_add_affected_planes(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+ struct intel_crtc *crtc,
+ int *num_affected_planes)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct intel_crtc_state *old_crtc_state =
@@ -5764,6 +6082,8 @@ static int skl_wm_add_affected_planes(struct intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_plane *plane;
+ *num_affected_planes = 0;
+
for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
struct intel_plane_state *plane_state;
enum plane_id plane_id = plane->id;
@@ -5787,11 +6107,64 @@ static int skl_wm_add_affected_planes(struct intel_atomic_state *state,
return PTR_ERR(plane_state);
new_crtc_state->update_planes |= BIT(plane_id);
+ *num_affected_planes += 1;
}
return 0;
}
+static void tgl_compute_sagv_mask(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc_state *old_crtc_state;
+ int ret;
+ int i;
+ struct intel_plane *plane;
+ struct intel_bw_state *new_bw_state = intel_atomic_get_bw_state(state);
+
+ if (IS_ERR(new_bw_state)) {
+ WARN(1, "Could not get bw_state\n");
+ return;
+ }
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ int pipe_bit = BIT(crtc->pipe);
+ bool skip = true;
+
+ /*
+ * If we had set this mast already once for this state,
+ * no need to waste CPU cycles for doing this again.
+ */
+ for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ enum plane_id plane_id = plane->id;
+
+ if (!skl_plane_wm_equals(dev_priv,
+ &old_crtc_state->wm.skl.optimal.planes[plane_id],
+ &new_crtc_state->wm.skl.optimal.planes[plane_id])) {
+ skip = false;
+ break;
+ }
+ }
+
+ /*
+ * Check if wm levels are actually the same as for previous
+ * state, which means we can just skip doing this long check
+ * and just copy correspondent bit from previous state.
+ */
+ if (skip)
+ continue;
+
+ ret = tgl_check_pipe_fits_sagv_wm(new_crtc_state);
+ if (!ret)
+ new_bw_state->pipe_sagv_mask |= pipe_bit;
+ else
+ new_bw_state->pipe_sagv_mask &= ~pipe_bit;
+ }
+}
+
static int
skl_compute_wm(struct intel_atomic_state *state)
{
@@ -5799,6 +6172,7 @@ skl_compute_wm(struct intel_atomic_state *state)
struct intel_crtc_state *new_crtc_state;
struct intel_crtc_state *old_crtc_state;
int ret, i;
+ int affected_planes; int total_affected_planes = 0;
ret = skl_ddb_add_affected_pipes(state);
if (ret)
@@ -5815,11 +6189,15 @@ skl_compute_wm(struct intel_atomic_state *state)
if (ret)
return ret;
- ret = skl_wm_add_affected_planes(state, crtc);
+ ret = skl_wm_add_affected_planes(state, crtc, &affected_planes);
if (ret)
return ret;
+
+ total_affected_planes += affected_planes;
}
+ intel_compute_sagv_mask(state, total_affected_planes);
+
ret = skl_compute_ddb(state);
if (ret)
return ret;
@@ -5939,6 +6317,9 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
val = I915_READ(CUR_WM(pipe, level));
skl_wm_level_from_reg_val(val, &wm->wm[level]);
+ if (level == 0)
+ memcpy(&wm->sagv_wm0, &wm->wm[level],
+ sizeof(struct skl_wm_level));
}
if (plane_id != PLANE_CURSOR)
diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
index d60a85421c5a..561a17a5d4e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.h
+++ b/drivers/gpu/drm/i915/intel_pm.h
@@ -41,7 +41,9 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
struct skl_pipe_wm *out);
void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
-bool intel_can_enable_sagv(struct intel_atomic_state *state);
+bool intel_can_enable_sagv(struct drm_i915_private *dev_priv);
+bool intel_can_enable_sagv_for_state(struct intel_atomic_state *state);
+bool intel_has_sagv(struct drm_i915_private *dev_priv);
int intel_enable_sagv(struct drm_i915_private *dev_priv);
int intel_disable_sagv(struct drm_i915_private *dev_priv);
bool skl_wm_level_equals(const struct skl_wm_level *l1,
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v17 5/7] drm/i915: Added required new PCode commands
From: Stanislav Lisovskiy @ 2020-02-20 12:07 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++++
drivers/gpu/drm/i915/intel_sideband.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..b3924e9d25bc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8997,6 +8997,7 @@ enum {
#define GEN7_PCODE_ILLEGAL_DATA 0x3
#define GEN11_PCODE_ILLEGAL_SUBCOMMAND 0x4
#define GEN11_PCODE_LOCKED 0x6
+#define GEN11_PCODE_REJECTED 0x11
#define GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE 0x10
#define GEN6_PCODE_WRITE_RC6VIDS 0x4
#define GEN6_PCODE_READ_RC6VIDS 0x5
@@ -9018,6 +9019,7 @@ enum {
#define ICL_PCODE_MEM_SUBSYSYSTEM_INFO 0xd
#define ICL_PCODE_MEM_SS_READ_GLOBAL_INFO (0x0 << 8)
#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point) (((point) << 16) | (0x1 << 8))
+#define ICL_PCODE_SAGV_DE_MEM_SS_CONFIG 0xe
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
@@ -9030,6 +9032,8 @@ enum {
#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US 0x23
+#define GEN11_PCODE_POINTS_RESTRICTED 0x0
+#define GEN11_PCODE_POINTS_RESTRICTED_MASK 0x1
#define GEN6_PCODE_DATA _MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_sideband.c b/drivers/gpu/drm/i915/intel_sideband.c
index 1447e7516cb7..1e7dd6b6f103 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -370,6 +370,8 @@ static inline int gen7_check_mailbox_status(u32 mbox)
return -ENXIO;
case GEN11_PCODE_LOCKED:
return -EBUSY;
+ case GEN11_PCODE_REJECTED:
+ return -EACCES;
case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
return -EOVERFLOW;
default:
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v17 6/7] drm/i915: Restrict qgv points which don't have enough bandwidth.
From: Stanislav Lisovskiy @ 2020-02-20 12:07 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid simultaneous legacy SAGV PCode requests and
restricting qgv points. Put the actual restriction
to commit function, added serialization(thanks to Ville)
to prevent commit being applied out of order in case of
nonblocking and/or nomodeset commits.
v4:
- Minor code refactoring, fixed few typos(thanks to James Ausmus)
- Change the naming of qgv point
masking/unmasking functions(James Ausmus).
- Simplify the masking/unmasking operation itself,
as we don't need to mask only single point per request(James Ausmus)
- Reject and stick to highest bandwidth point if SAGV
can't be enabled(BSpec)
v5:
- Add new mailbox reply codes, which seems to happen during boot
time for TGL and indicate that QGV setting is not yet available.
v6:
- Increase number of supported QGV points to be in sync with BSpec.
v7: - Rebased and resolved conflict to fix build failure.
- Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus)
v8: - Don't report an error if we can't restrict qgv points, as SAGV
can be disabled by BIOS, which is completely legal. So don't
make CI panic. Instead if we detect that there is only 1 QGV
point accessible just analyze if we can fit the required bandwidth
requirements, but no need in restricting.
v9: - Fix wrong QGV transition if we have 0 planes and no SAGV
simultaneously.
v10: - Fix CDCLK corruption, because of global state getting serialized
without modeset, which caused copying of non-calculated cdclk
to be copied to dev_priv(thanks to Ville for the hint).
v11: - Remove unneeded headers and spaces(Matthew Roper)
- Remove unneeded intel_qgv_info qi struct from bw check and zero
out the needed one(Matthew Roper)
- Changed QGV error message to have more clear meaning(Matthew Roper)
- Use state->modeset_set instead of any_ms(Matthew Roper)
- Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used
- Keep using crtc_state->hw.active instead of .enable(Matthew Roper)
- Moved unrelated changes to other patch(using latency as parameter
for plane wm calculation, moved to SAGV refactoring patch)
v12: - Fix rebase conflict with own temporary SAGV/QGV fix.
- Remove unnecessary mask being zero check when unmasking
qgv points as this is completely legal(Matt Roper)
- Check if we are setting the same mask as already being set
in hardware to prevent error from PCode.
- Fix error message when restricting/unrestricting qgv points
to "mask/unmask" which sounds more accurate(Matt Roper)
- Move sagv status setting to icl_get_bw_info from atomic check
as this should be calculated only once.(Matt Roper)
- Edited comments for the case when we can't enable SAGV and
use only 1 QGV point with highest bandwidth to be more
understandable.(Matt Roper)
v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä)
- Changed comment for zero new_mask in qgv points masking function
to better reflect reality(Ville Syrjälä)
- Simplified bit mask operation in qgv points masking function
(Ville Syrjälä)
- Moved intel_qgv_points_mask closer to gen11 SAGV disabling,
however this still can't be under modeset condition(Ville Syrjälä)
- Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask
(Ville Syrjälä)
- Extracted PCode changes to separate patch.(Ville Syrjälä)
- Now treat num_planes 0 same as 1 to avoid confusion and
returning max_bw as 0, which would prevent choosing QGV
point having max bandwidth in case if SAGV is not allowed,
as per BSpec(Ville Syrjälä)
- Do the actual qgv_points_mask swap in the same place as
all other global state parts like cdclk are swapped.
In the next patch, this all will be moved to bw state as
global state, once new global state patch series from Ville
lands
v14: - Now using global state to serialize access to qgv points
- Added global state locking back, otherwise we seem to read
bw state in a wrong way.
v15: - Added TODO comment for near atomic global state locking in
bw code.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
---
drivers/gpu/drm/i915/display/intel_bw.c | 177 ++++++++++++++-----
drivers/gpu/drm/i915/display/intel_bw.h | 9 +
drivers/gpu/drm/i915/display/intel_display.c | 109 ++++++++++++
drivers/gpu/drm/i915/i915_drv.h | 3 +
4 files changed, 249 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
index ff57277e8880..6b7894ef7ea6 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -8,6 +8,9 @@
#include "intel_bw.h"
#include "intel_display_types.h"
#include "intel_sideband.h"
+#include "intel_atomic.h"
+#include "intel_pm.h"
+
/* Parameters for Qclk Geyserville (QGV) */
struct intel_qgv_point {
@@ -113,6 +116,26 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
return 0;
}
+int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
+ u32 points_mask)
+{
+ int ret;
+
+ /* bspec says to keep retrying for at least 1 ms */
+ ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
+ points_mask,
+ GEN11_PCODE_POINTS_RESTRICTED_MASK,
+ GEN11_PCODE_POINTS_RESTRICTED,
+ 1);
+
+ if (ret < 0) {
+ DRM_ERROR("Failed to disable qgv points (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
struct intel_qgv_info *qi)
{
@@ -240,6 +263,16 @@ static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct intel
break;
}
+ /*
+ * In case if SAGV is disabled in BIOS, we always get 1
+ * SAGV point, but we can't send PCode commands to restrict it
+ * as it will fail and pointless anyway.
+ */
+ if (qi.num_points == 1)
+ dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
+ else
+ dev_priv->sagv_status = I915_SAGV_ENABLED;
+
return 0;
}
@@ -259,7 +292,7 @@ static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
if (qgv_point >= bi->num_qgv_points)
return UINT_MAX;
- if (num_planes >= bi->num_planes)
+ if (num_planes >= bi->num_planes || !num_planes)
return bi->deratedbw[qgv_point];
}
@@ -277,34 +310,6 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
icl_get_bw_info(dev_priv, &icl_sa_info);
}
-static unsigned int intel_max_data_rate(struct drm_i915_private *dev_priv,
- int num_planes)
-{
- if (INTEL_GEN(dev_priv) >= 11) {
- /*
- * Any bw group has same amount of QGV points
- */
- const struct intel_bw_info *bi =
- &dev_priv->max_bw[0];
- unsigned int min_bw = UINT_MAX;
- int i;
-
- /*
- * FIXME with SAGV disabled maybe we can assume
- * point 1 will always be used? Seems to match
- * the behaviour observed in the wild.
- */
- for (i = 0; i < bi->num_qgv_points; i++) {
- unsigned int bw = icl_max_bw(dev_priv, num_planes, i);
-
- min_bw = min(bw, min_bw);
- }
- return min_bw;
- } else {
- return UINT_MAX;
- }
-}
-
static unsigned int intel_bw_crtc_num_active_planes(const struct intel_crtc_state *crtc_state)
{
/*
@@ -417,11 +422,16 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
- struct intel_bw_state *bw_state = NULL;
- unsigned int data_rate, max_data_rate;
+ struct intel_bw_state *new_bw_state = NULL;
+ struct intel_bw_state *old_bw_state = NULL;
+ unsigned int data_rate;
unsigned int num_active_planes;
struct intel_crtc *crtc;
int i, ret;
+ u32 allowed_points = 0;
+ unsigned int max_bw_point = 0, max_bw = 0;
+ unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
+ u32 mask = (1 << num_qgv_points) - 1;
/* FIXME earlier gens need some checks too */
if (INTEL_GEN(dev_priv) < 11)
@@ -446,41 +456,110 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
old_active_planes == new_active_planes)
continue;
- bw_state = intel_atomic_get_bw_state(state);
- if (IS_ERR(bw_state))
- return PTR_ERR(bw_state);
+ new_bw_state = intel_atomic_get_bw_state(state);
+ if (IS_ERR(new_bw_state))
+ return PTR_ERR(new_bw_state);
- bw_state->data_rate[crtc->pipe] = new_data_rate;
- bw_state->num_active_planes[crtc->pipe] = new_active_planes;
+ new_bw_state->data_rate[crtc->pipe] = new_data_rate;
+ new_bw_state->num_active_planes[crtc->pipe] = new_active_planes;
drm_dbg_kms(&dev_priv->drm,
"pipe %c data rate %u num active planes %u\n",
pipe_name(crtc->pipe),
- bw_state->data_rate[crtc->pipe],
- bw_state->num_active_planes[crtc->pipe]);
+ new_bw_state->data_rate[crtc->pipe],
+ new_bw_state->num_active_planes[crtc->pipe]);
}
- if (!bw_state)
+ if (!new_bw_state)
return 0;
- ret = intel_atomic_lock_global_state(&bw_state->base);
- if (ret)
+ /*
+ * TODO: Should we just call intel_atomic_serialize_global_state here?
+ * we anyway already have different data rates and this call is
+ * is almost similar, except that it doesn't call duplicate_state
+ * hook.
+ */
+ ret = intel_atomic_lock_global_state(&new_bw_state->base);
+ if (ret) {
+ DRM_DEBUG_KMS("Could not lock global state\n");
return ret;
+ }
- data_rate = intel_bw_data_rate(dev_priv, bw_state);
- num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
-
- max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
+ data_rate = intel_bw_data_rate(dev_priv, new_bw_state);
+ num_active_planes = intel_bw_num_active_planes(dev_priv, new_bw_state);
data_rate = DIV_ROUND_UP(data_rate, 1000);
- if (data_rate > max_data_rate) {
- drm_dbg_kms(&dev_priv->drm,
- "Bandwidth %u MB/s exceeds max available %d MB/s (%d active planes)\n",
- data_rate, max_data_rate, num_active_planes);
+ for (i = 0; i < num_qgv_points; i++) {
+ unsigned int max_data_rate;
+
+ max_data_rate = icl_max_bw(dev_priv, num_active_planes, i);
+ /*
+ * We need to know which qgv point gives us
+ * maximum bandwidth in order to disable SAGV
+ * if we find that we exceed SAGV block time
+ * with watermarks. By that moment we already
+ * have those, as it is calculated earlier in
+ * intel_atomic_check,
+ */
+ if (max_data_rate > max_bw) {
+ max_bw_point = i;
+ max_bw = max_data_rate;
+ }
+ if (max_data_rate >= data_rate)
+ allowed_points |= BIT(i);
+ DRM_DEBUG_KMS("QGV point %d: max bw %d required %d\n",
+ i, max_data_rate, data_rate);
+ }
+
+ /*
+ * BSpec states that we always should have at least one allowed point
+ * left, so if we couldn't - simply reject the configuration for obvious
+ * reasons.
+ */
+ if (allowed_points == 0) {
+ DRM_DEBUG_KMS("No QGV points provide sufficient memory"
+ " bandwidth for display configuration.\n");
return -EINVAL;
}
+ /*
+ * Leave only single point with highest bandwidth, if
+ * we can't enable SAGV due to the increased memory latency it may
+ * cause.
+ */
+ if (!intel_can_enable_sagv_for_state(state)) {
+ allowed_points = 1 << max_bw_point;
+ DRM_DEBUG_KMS("No SAGV, using single QGV point %d\n",
+ max_bw_point);
+ }
+ /*
+ * We store the ones which need to be masked as that is what PCode
+ * actually accepts as a parameter.
+ */
+ new_bw_state->qgv_points_mask = (~allowed_points) & mask;
+
+ DRM_DEBUG_KMS("New state %p qgv mask %x\n",
+ state, new_bw_state->qgv_points_mask);
+
+ old_bw_state = intel_atomic_get_old_bw_state(state);
+ if (IS_ERR(old_bw_state)) {
+ DRM_DEBUG_KMS("Could not get old bw state!\n");
+ return PTR_ERR(old_bw_state);
+ }
+
+ /*
+ * If the actual mask had changed we need to make sure that
+ * the commits are serialized(in case this is a nomodeset, nonblocking)
+ */
+ if (new_bw_state->qgv_points_mask != old_bw_state->qgv_points_mask) {
+ ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+ if (ret) {
+ DRM_DEBUG_KMS("Could not serialize global state\n");
+ return ret;
+ }
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
index fb1760125f9d..071deae3a427 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -36,6 +36,13 @@ struct intel_bw_state {
*/
bool can_sagv;
+ /*
+ * Current QGV points mask, which restricts
+ * some particular SAGV states, not to confuse
+ * with pipe_sagv_mask.
+ */
+ u8 qgv_points_mask;
+
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
};
@@ -56,5 +63,7 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
void intel_bw_crtc_update(struct intel_bw_state *bw_state,
const struct intel_crtc_state *crtc_state);
+int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
+ u32 points_mask);
#endif /* __INTEL_BW_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 6a4d88e4d41a..cd248bd69794 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15473,6 +15473,105 @@ static void intel_atomic_cleanup_work(struct work_struct *work)
intel_atomic_helper_free_state(i915);
}
+static void intel_qgv_points_mask(struct intel_atomic_state *state)
+{
+ struct drm_device *dev = state->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ int ret;
+ struct intel_bw_state *new_bw_state = NULL;
+ struct intel_bw_state *old_bw_state = NULL;
+ u32 new_mask = 0;
+ unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
+ unsigned int mask = (1 << num_qgv_points) - 1;
+
+ new_bw_state = intel_atomic_get_bw_state(state);
+ if (IS_ERR(new_bw_state)) {
+ WARN(1, "Could not get new bw_state!\n");
+ return;
+ }
+
+ old_bw_state = intel_atomic_get_old_bw_state(state);
+ if (IS_ERR(old_bw_state)) {
+ WARN(1, "Could not get old bw_state!\n");
+ return;
+ }
+
+ new_mask = old_bw_state->qgv_points_mask | new_bw_state->qgv_points_mask;
+
+ /*
+ * If new mask is zero - means there is nothing to mask,
+ * we can only unmask, which should be done in unmask.
+ */
+ if (!new_mask)
+ return;
+
+ WARN_ON(new_mask == mask);
+
+ /*
+ * Just return if we can't control SAGV or don't have it.
+ */
+ if (!intel_has_sagv(dev_priv))
+ return;
+
+ /*
+ * Restrict required qgv points before updating the configuration.
+ * According to BSpec we can't mask and unmask qgv points at the same
+ * time. Also masking should be done before updating the configuration
+ * and unmasking afterwards.
+ */
+ ret = icl_pcode_restrict_qgv_points(dev_priv, new_mask);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Could not mask required qgv points(%d)\n",
+ ret);
+}
+
+static void intel_qgv_points_unmask(struct intel_atomic_state *state)
+{
+ struct drm_device *dev = state->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ int ret;
+ struct intel_bw_state *new_bw_state = NULL;
+ struct intel_bw_state *old_bw_state = NULL;
+ u32 new_mask = 0;
+
+ new_bw_state = intel_atomic_get_bw_state(state);
+ if (IS_ERR(new_bw_state)) {
+ WARN(1, "Could not get new bw_state!\n");
+ return;
+ }
+
+ old_bw_state = intel_atomic_get_old_bw_state(state);
+ if (IS_ERR(old_bw_state)) {
+ WARN(1, "Could not get new bw_state!\n");
+ return;
+ }
+
+ new_mask = new_bw_state->qgv_points_mask;
+
+ /*
+ * Just return if we can't control SAGV or don't have it.
+ */
+ if (!intel_has_sagv(dev_priv))
+ return;
+
+ /*
+ * Nothing to unmask
+ */
+ if (new_mask == old_bw_state->qgv_points_mask)
+ return;
+
+ /*
+ * Allow required qgv points after updating the configuration.
+ * According to BSpec we can't mask and unmask qgv points at the same
+ * time. Also masking should be done before updating the configuration
+ * and unmasking afterwards.
+ */
+ ret = icl_pcode_restrict_qgv_points(dev_priv, new_mask);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Could not unmask required qgv points(%d)\n",
+ ret);
+}
+
static void intel_atomic_commit_tail(struct intel_atomic_state *state)
{
struct drm_device *dev = state->base.dev;
@@ -15506,6 +15605,14 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
crtc->config = new_crtc_state;
+ /*
+ * Now we need to check if SAGV needs to be disabled(i.e QGV points
+ * modified even, when no modeset is done(for example plane updates
+ * can now trigger that).
+ */
+ if ((INTEL_GEN(dev_priv) >= 11))
+ intel_qgv_points_mask(state);
+
if (state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(dev, &state->base);
@@ -15620,6 +15727,8 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
if (INTEL_GEN(dev_priv) < 11) {
if (state->modeset && intel_can_enable_sagv(dev_priv))
intel_enable_sagv(dev_priv);
+ } else {
+ intel_qgv_points_unmask(state);
}
drm_atomic_helper_commit_hw_done(&state->base);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9928d00ea0b1..1143f67bba0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -841,6 +841,9 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
};
+/* BSpec precisely defines this */
+#define NUM_SAGV_POINTS 8
+
#define INTEL_PIPE_CRC_ENTRIES_NR 128
struct intel_pipe_crc {
spinlock_t lock;
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH v17 7/7] drm/i915: Enable SAGV support for Gen12
From: Stanislav Lisovskiy @ 2020-02-20 12:07 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/intel_pm.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2aafd2b07e4a..6d4240f260a9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3624,10 +3624,6 @@ static bool skl_needs_memory_bw_wa(struct drm_i915_private *dev_priv)
bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
- /* HACK! */
- if (IS_GEN(dev_priv, 12))
- return false;
-
return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
}
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v6] x86: introduce a new set of APIs to manage Xen page tables
From: Jan Beulich @ 2020-02-20 12:10 UTC (permalink / raw)
To: Wei Liu, Hongyan Xia
Cc: xen-devel, jgrall, Roger Pau Monné, Andrew Cooper
In-Reply-To: <20200128142133.eqvyj52xdu5lzbdw@debian>
On 28.01.2020 15:21, Wei Liu wrote:
> On Tue, Jan 28, 2020 at 01:50:05PM +0000, Hongyan Xia wrote:
>> From: Wei Liu <wei.liu2@citrix.com>
>>
>> We are going to switch to using domheap page for page tables.
>> A new set of APIs is introduced to allocate and free pages of page
>> tables based on mfn instead of the xenheap direct map address. The
>> allocation and deallocation work on mfn_t but not page_info, because
>> they are required to work even before frame table is set up.
>>
>> Implement the old functions with the new ones. We will rewrite, site
>> by site, other mm functions that manipulate page tables to use the new
>> APIs.
>>
>> After the allocation, one needs to map and unmap via map_domain_page to
>> access the PTEs. This does not break xen half way, since the new APIs
>> still use xenheap pages underneath, and map_domain_page will just use
>> the directmap for mappings. They will be switched to use domheap and
>> dynamic mappings when usage of old APIs is eliminated.
>>
>> No functional change intended in this patch.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
>> Reviewed-by: Julien Grall <jgrall@amazon.com>
>
> Reviewed-by: Wei Liu <wl@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
I'm sorry for the delay.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Set MIPS status to Odd Fixes
From: YunQiang Su @ 2020-02-20 12:11 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Paul Burton, linux-mips, linux-kernel, wayne.sun, chris.wang,
Yunqiang Su
In-Reply-To: <20200220112330.GA3053@alpha.franken.de>
CC people from NeoCore and CIP United, and my Wave Computing's mail address.
Thomas Bogendoerfer <tsbogend@alpha.franken.de> 于2020年2月20日周四 下午7:23写道：
>
> On Wed, Feb 19, 2020 at 11:17:30AM -0800, Paul Burton wrote:
> > My time with MIPS the company has reached its end, and so at best I'll
> > have little time spend on maintaining arch/mips/. Reflect that in
> > MAINTAINERS by changing status to Odd Fixes. Hopefully this might spur
> > the involvement of someone with more time, but even if not it should
> > help serve to avoid unrealistic expectations.
>
> I'd like to jump in as MIPS maintainer. I'm doing Linux MIPS kernel
It is a great news that you are willing to act as maintainer as Linux-MIPS.
> development since ages (started with an Olivetti M700 and kernel version
> 2.x) and right now time for doing the jobs isn't issue:-)
>
I noticed that you are mainly working some old machines.
And recently years, there are some new machines from Ingenic, Loongson, MTK etc.
MIPS Inc also have some MIPSr6 IPs.
I think that you need some of these machines.
In the last years, we see that the single maintainer is not enough as people may
quite busy.
Do you think that we need co-maintainers?
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
--
YunQiang Su
^ permalink raw reply
* Re: [PATCH v3 0/3] Dump QCOW2 metadata
From: Vladimir Sementsov-Ogievskiy @ 2020-02-20 12:10 UTC (permalink / raw)
To: Max Reitz, Andrey Shinkevich, qemu-block; +Cc: kwolf, den, qemu-devel, armbru
In-Reply-To: <fb4eb1a7-25f7-86ce-4c27-06bca430e97a@redhat.com>
20.02.2020 14:58, Max Reitz wrote:
> On 14.01.20 09:22, Andrey Shinkevich wrote:
>> The information about QCOW2 metadata allocations in an image ELF-file is
>> helpful for finding issues with the image data integrity.
>
> Sorry that I’m replying only so late – but I don’t know why we need this
> in qemu, and this cover letter doesn’t provide a justification. I mean,
> it isn’t too complex (from the diffstat), but wouldn’t it be better to
> just have a script for this?
>
> I suppose one reason to put it in qemu/qemu-img is that a script
> wouldn’t be packaged by distributions. So if a user has a corrupted
> image, with this series we could tell them to run qemu-img check -M and
> put the output somewhere. With a script, we’d first have to tell them
> to download the script. But then again, downloading a script (that
> should be part of the qemu repository) doesn’t seem too much trouble to
> me either.
>
> So I’m curious as to whether you had a specific reason in mind when you
> decided to implement this as part of qemu itself?
>
> (I suppose the additional complexity is fully limited to the check
> infrastructure, so it wouldn’t interfere with the rest of the qcow2
> driver. Hm. Fair enough.)
>
Just not to parse qcow2 from scratch. Qemu already can read qcow2, and
it looks through all its structures during check, why not
to add an ability to represent these structures as a qobject?
--
Best regards,
Vladimir
^ permalink raw reply
* Re: [PATCH v3 03/22] x86: Replace ist_enter() with nmi_enter()
From: Peter Zijlstra @ 2020-02-20 12:11 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-arch, rostedt, mingo, joel, gregkh, gustavo,
tglx, paulmck, josh, mathieu.desnoyers, jiangshanlai, luto,
tony.luck, frederic, dan.carpenter, mhiramat
In-Reply-To: <20200220105439.GA507@zn.tnic>
On Thu, Feb 20, 2020 at 11:54:39AM +0100, Borislav Petkov wrote:
> On Wed, Feb 19, 2020 at 03:47:27PM +0100, Peter Zijlstra wrote:
> > @@ -1220,7 +1220,7 @@ static void mce_kill_me_maybe(struct cal
> > * MCE broadcast. However some CPUs might be broken beyond repair,
> > * so be always careful when synchronizing with others.
> > */
> > -void do_machine_check(struct pt_regs *regs, long error_code)
> > +notrace void do_machine_check(struct pt_regs *regs, long error_code)
>
> Is there a convention where the notrace marker should come in the
> function signature? I see all possible combinations while grepping...
Same place as inline I think.
> > {
> > DECLARE_BITMAP(valid_banks, MAX_NR_BANKS);
> > DECLARE_BITMAP(toclear, MAX_NR_BANKS);
> > @@ -1254,10 +1254,10 @@ void do_machine_check(struct pt_regs *re
> > */
> > int lmce = 1;
> >
> > - if (__mc_check_crashing_cpu(cpu))
> > - return;
> > + nmi_enter();
> >
> > - ist_enter(regs);
> > + if (__mc_check_crashing_cpu(cpu))
> > + goto out;
> >
> > this_cpu_inc(mce_exception_count);
> >
>
> Should that __mc_check_crashing_cpu() happen before nmi_enter? The
> function is doing only a bunch of checks and clearing MSRs for bystander
> CPUs...
You'll note the lack of notrace on that function, and we must not call
into tracers before nmi_enter().
AFAICT there really is no benefit to trying to lift it before
nmi_enter().
^ permalink raw reply
* RE: obmc-console design for multi host support
From: Kumar Thangavel @ 2020-02-20 12:13 UTC (permalink / raw)
To: Andrew Jeffery, openbmc@lists.ozlabs.org
Cc: Jeremy Kerr, Joel Stanley, Velumani T-ERS,HCLTech
In-Reply-To: <f136d4ad-65e6-4e74-8f53-2ca3edaf9288@www.fastmail.com>
Hi Andrew,
Thanks for your response and information.
Please find my response inline below.
Thanks,
Kumar.
-----Original Message-----
From: Andrew Jeffery <andrew@aj.id.au>
Sent: Thursday, February 20, 2020 5:38 AM
To: Kumar Thangavel <thangavel.k@hcl.com>; openbmc@lists.ozlabs.org
Cc: Jeremy Kerr <jk@ozlabs.org>; Joel Stanley <joel@jms.id.au>; Velumani T-ERS,HCLTech <velumanit@hcl.com>
Subject: Re: obmc-console design for multi host support
[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]
Hi Kumar,
On Wed, 19 Feb 2020, at 18:24, Kumar Thangavel wrote:
>
> Hi All,
>
>
> Obmc-console application current design may not support multi host or
> multiple console. So, we proposed the design to handle multi
> host/multiple console in obmc-console client and server applications.
Thanks for writing a proposal.
>
> Please find the attached design document.
>
>
> Could you please review and provide your comments on this.
Interesting timing, because I've actually just solved this problem. Please review this series in Gerrit:
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fq%2Ftopic%3A%2522concurrent-servers%2522%2B(status%3Aopen%2520OR%2520status%3Amerged&data=02%7C01%7Cthangavel.k%40hcl.com%7Cc3bc8632eb5b4b538a3508d7b59904ba%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637177541130921053&sdata=HIYcn2Cd6tgCrAJCUwTaT5AqUkXfrB25HR0ncpsejdg%3D&reserved=0)
Regarding the proposal, I have a few thoughts:
1. Please try to keep it to plain-text
2. If you have code it's best to post it straight away (rather than lead with a proposal and no code)
Kumar : Sure. Will Keep plain text for posting proposals/code.
On point 1, this is an open-source community and sending documents in formats like docx might mean that some people can't access them. Plain- text always works, especially as emails are generally composed that way, which means you can put your proposal directly in an email and people can respond to it with ease.
On point 2, it seems that you've included screenshots of code changes that you have made locally - a few sub-points there:
a. Code is text - you can include snippets of it in your document directly, which removes the need for rich media formats, which removes the need for something like docx.
b. If you've got code, push it to github or gerrit and we can look at it directly!
Kumar : Sure, Will keep code snippets in the plain text or will push it to github or gerrit.
On point b, given that this proposal largely deals with implementation details, it's much more effective if you lead with code and then drive a discussion on the list if necessary. At least this way we have something concrete to point at and argue about, or in the happy case we can just merge it and you've avoided the effort of driving redundant discussion.
Finally, these thoughts are about helping you help us help you to get your code merged with the least amount of effort/friction. Hopefully they are useful to you :)
Kumar : I looked at your patches and this is really good information and very helpful. Will look more in detail and get back to you.
Cheers,
Andrew
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
^ permalink raw reply
* [Buildroot] [git commit] package/audiofile: annotate _IGNORE_CVES for the included security patches
From: Peter Korsgaard @ 2020-02-20 12:13 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=ab7f5a8d39ab5060994728df3c52206e054d8a9b
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
package/audiofile/audiofile.mk | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/package/audiofile/audiofile.mk b/package/audiofile/audiofile.mk
index 2f2e8902e9..bb46436d85 100644
--- a/package/audiofile/audiofile.mk
+++ b/package/audiofile/audiofile.mk
@@ -15,6 +15,22 @@ AUDIOFILE_AUTORECONF = YES
AUDIOFILE_LICENSE = GPL-2.0+, LGPL-2.1+
AUDIOFILE_LICENSE_FILES = COPYING COPYING.GPL
+# 0003-Always-check-the-number-of-coefficients.patch
+AUDIOFILE_IGNORE_CVES += \
+ CVE-2017-6827 CVE-2017-6828 CVE-2017-6832 \
+ CVE-2017-6833 CVE-2017-6835 CVE-2017-6837
+# 0004-clamp-index-values-to-fix-index-overflow-in-IMA.cpp.patch
+AUDIOFILE_IGNORE_CVES += CVE-2017-6829
+# 0005-Check-for-multiplication-overflow-in-sfconvert.patch
+AUDIOFILE_IGNORE_CVES += \
+ CVE-2017-6830 CVE-2017-6834 CVE-2017-6836 CVE-2017-6838
+# 0006-Actually-fail-when-error-occurs-in-parseFormat.patch
+AUDIOFILE_IGNORE_CVES += CVE-2017-6831
+# 0007-Check-for-multiplication-overflow-in-MSADPCM-decodeS.patch
+AUDIOFILE_IGNORE_CVES += CVE-2017-6839
+# 0008-CVE-2015-7747.patch
+AUDIOFILE_IGNORE_CVES += CVE-2015-7747
+
ifeq ($(BR2_PACKAGE_FLAC),y)
AUDIOFILE_DEPENDENCIES += flac
AUDIOFILE_CONF_OPTS += --enable-flac
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH 0/2] net/mlx5: copy the item flags from prefix flow
From: Raslan Darawsheh @ 2020-02-20 12:13 UTC (permalink / raw)
To: Suanming Mou, Slava Ovsiienko, Matan Azrad; +Cc: dev@dpdk.org
In-Reply-To: <1582122664-54731-1-git-send-email-suanmingm@mellanox.com>
Hi,
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Wednesday, February 19, 2020 4:31 PM
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Matan Azrad
> <matan@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>
> Subject: [PATCH 0/2] net/mlx5: copy the item flags from prefix flow
>
> For flow split to several subflows, the match items maybe in the prefix
> flow, and the actions are split to the suffix flow.
>
> In this case, for the actions need the user defined match item will not
> create correctly.
>
> Copy the item layers flags to the suffix flow from prefix flow to fix
> the issue.
>
> This patch series should be applied after:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D8613&data=0
> 2%7C01%7Crasland%40mellanox.com%7C18e60c79e62d40313b6008d7b5485c
> df%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6371771947191293
> 09&sdata=QE%2FeFbc3rp1m5KgmtmR%2Bfu5%2B2v%2BeBANO1u80R2
> PdS9A%3D&reserved=0
>
> Suanming Mou (2):
> net/mlx5: fix layer flags missing in metadata
> net/mlx5: fix lack of match information in meter
>
> drivers/net/mlx5/mlx5_flow.c | 41 +++++++++++++++++++-------
> drivers/net/mlx5/mlx5_flow_dv.c | 64
> +++++++++++++++++++++++++++++++----------
> 2 files changed, 79 insertions(+), 26 deletions(-)
>
> --
> 1.8.3.1
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply
* Re: [PATCH 1/2] tty: serial: samsung_tty: build it for any platform
From: Bartlomiej Zolnierkiewicz @ 2020-02-20 12:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-serial, Kukjin Kim, Donghoon Yu, Hyunki Koo, HYUN-KI KOO,
Shinbeom Choi, Krzysztof Kozlowski, Jiri Slaby, linux-arm-kernel,
linux-samsung-soc, linux-kernel
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
Hi Greg,
On 2/20/20 11:26 AM, Greg Kroah-Hartman wrote:
> There is no need to tie this driver to only a specific SoC, or compile
> test, so remove that dependancy from the Kconfig rules.
samsung_tty driver is hardware specific driver so why should we
build it for any platform?
This change seems to defeat the whole purpose behind COMPILE_TEST
config option (which allows us to build hardware-specific drivers
without needlessly presenting the user with tons of non-relevant
config options).
Please explain this change some more, are you planing to remove
COMPILE_TEST config option?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 52eaac21ff9f..a310bd22f1e2 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -237,7 +237,6 @@ config SERIAL_CLPS711X_CONSOLE
>
> config SERIAL_SAMSUNG
> tristate "Samsung SoC serial support"
> - depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
>
> base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
^ permalink raw reply
* Re: [PATCH 1/2] tty: serial: samsung_tty: build it for any platform
From: Bartlomiej Zolnierkiewicz @ 2020-02-20 12:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Donghoon Yu, linux-samsung-soc, linux-kernel, Krzysztof Kozlowski,
Shinbeom Choi, Hyunki Koo, Kukjin Kim, linux-arm-kernel,
linux-serial, Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
Hi Greg,
On 2/20/20 11:26 AM, Greg Kroah-Hartman wrote:
> There is no need to tie this driver to only a specific SoC, or compile
> test, so remove that dependancy from the Kconfig rules.
samsung_tty driver is hardware specific driver so why should we
build it for any platform?
This change seems to defeat the whole purpose behind COMPILE_TEST
config option (which allows us to build hardware-specific drivers
without needlessly presenting the user with tons of non-relevant
config options).
Please explain this change some more, are you planing to remove
COMPILE_TEST config option?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 52eaac21ff9f..a310bd22f1e2 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -237,7 +237,6 @@ config SERIAL_CLPS711X_CONSOLE
>
> config SERIAL_SAMSUNG
> tristate "Samsung SoC serial support"
> - depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
> select SERIAL_CORE
> help
> Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
>
> base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: FAILED: patch "[PATCH] KVM: VMX: Add non-canonical check on writes to RTIT address" failed to apply to 4.19-stable tree
From: Sasha Levin @ 2020-02-20 12:14 UTC (permalink / raw)
To: Ben Hutchings; +Cc: gregkh, sean.j.christopherson, pbonzini, stable
In-Reply-To: <fc00f38ef8db90d982dad4de41e97918b565d321.camel@codethink.co.uk>
On Thu, Feb 20, 2020 at 09:16:51AM +0000, Ben Hutchings wrote:
>On Sun, 2020-02-09 at 15:12 -0500, Sasha Levin wrote:
>> On Sun, Feb 09, 2020 at 01:31:58PM +0100, gregkh@linuxfoundation.org wrote:
>> > The patch below does not apply to the 4.19-stable tree.
>> > If someone wants it applied there, or to any other stable or longterm
>> > tree, then please email the backport, including the original git commit
>> > id to <stable@vger.kernel.org>.
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>> > ------------------ original commit in Linus's tree ------------------
>> >
>> > From fe6ed369fca98e99df55c932b85782a5687526b5 Mon Sep 17 00:00:00 2001
>> > From: Sean Christopherson <sean.j.christopherson@intel.com>
>> > Date: Tue, 10 Dec 2019 15:24:32 -0800
>> > Subject: [PATCH] KVM: VMX: Add non-canonical check on writes to RTIT address
>> > MSRs
>> >
>> > Reject writes to RTIT address MSRs if the data being written is a
>> > non-canonical address as the MSRs are subject to canonical checks, e.g.
>> > KVM will trigger an unchecked #GP when loading the values to hardware
>> > during pt_guest_enter().
>> >
>> > Cc: stable@vger.kernel.org
>> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>
>> File/code movement. Cleaned up and queued for 4.19-4.4.
>
>I don't know what happened here, but you've ended up adding the
>entirety of arch/x86/kvm/vmx/vmx.c on all those branches rather than
>applying the change to the right file.
Ugh, sorry. I think that I got confused here by 'git cherry-pick'
creating the file when it doesn't exist and it doesn't find the right
file renames.
--
Thanks,
Sasha
^ permalink raw reply
* [Buildroot] [PATCH 1/5] package/audiofile: annotate _IGNORE_CVES for the included security patches
From: Peter Korsgaard @ 2020-02-20 12:14 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200219160203.874-1-peter@korsgaard.com>
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [yocto] Bitbake returning non-zero due to sstate errors
From: Martin Jansa @ 2020-02-20 12:14 UTC (permalink / raw)
To: Paul Barker; +Cc: Yocto discussion list
In-Reply-To: <CAM9ZRVvDHTvvKr1Tdc+C1ZdTv2DSX8JJ9bYhHc0c-wre4qg5LA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]
On Thu, Feb 20, 2020 at 11:26:54AM +0000, Paul Barker wrote:
> In my new CI setup I'm using an sstate mirror which seems to have some
> occasional download issues. This results in the setscene task failing.
> For example:
>
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> file://fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a74_package_write_ipk.tgz
> anywhere. The paths that were searched were:
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: No suitable staging package found
> ERROR: Logfile of failure stored in:
> /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-r0/temp/log.do_package_write_ipk_setscene.10524
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk_setscene: Failed
> WARNING: Setscene task
> (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> failed with exit code '1' - real task will be run instead
>
> As indicated in the final warning message there the real tasks run
> since no sstate artifact is available. These tasks succeed:
>
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk: Succeeded
>
> The result is a successful build of the desired images. However, the
> build is marked as a failure due to those sstate errors:
>
> Summary: There were 11 ERROR messages shown, returning a non-zero exit code.
>
> Is this the expected behaviour? The final images are built correctly.
> I can't see any simple way to mask those setscene errors but I might
> be missing something.
>
> The full log can be seen at
> https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> I'm on the zeus branch here, I'll try to re-test on master later if I
> can.
See this previous discussion which includes patches for bitbake and
oe-core to change them to warnings:
https://marc.info/?l=openembedded-core&m=150403687120408&w=2
Because it was rejected I'm parsing the bitbake output to see if all
ERROR: messages were only about setscene tasks as mentioned in the same
thread much later:
https://marc.info/?l=openembedded-core&m=157504616302317&w=4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* [Buildroot] [git commit] package/libsndfile: annotate _IGNORE_CVES for the included security patches
From: Peter Korsgaard @ 2020-02-20 12:15 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=91126d8863927745123769ed36b3f74c79d93b7a
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Also mark CVE-2018-13419 as disputed.
[Peter: add dispute link as suggested by Thomas]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
package/libsndfile/libsndfile.mk | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/package/libsndfile/libsndfile.mk b/package/libsndfile/libsndfile.mk
index 22909ffb62..19c3184961 100644
--- a/package/libsndfile/libsndfile.mk
+++ b/package/libsndfile/libsndfile.mk
@@ -10,6 +10,17 @@ LIBSNDFILE_INSTALL_STAGING = YES
LIBSNDFILE_LICENSE = LGPL-2.1+
LIBSNDFILE_LICENSE_FILES = COPYING
+# 0001-double64_init-Check-psf-sf.channels-against-upper-bo.patch
+LIBSNDFILE_IGNORE_CVES += CVE-2017-14634
+# 0002-Check-MAX_CHANNELS-in-sndfile-deinterleave.patch
+LIBSNDFILE_IGNORE_CVES += CVE-2018-13139 CVE-2018-19432
+# 0003-a-ulaw-fix-multiple-buffer-overflows-432.patch
+LIBSNDFILE_IGNORE_CVES += \
+ CVE-2017-14245 CVE-2017-14246 CVE-2017-17456 CVE-2017-17457 \
+ CVE-2018-19661 CVE-2018-19662
+# disputed, https://github.com/erikd/libsndfile/issues/398
+LIBSNDFILE_IGNORE_CVES += CVE-2018-13419
+
LIBSNDFILE_CONF_OPTS = \
--disable-sqlite \
--disable-alsa \
^ permalink raw reply related
* Re: [PATCH v3 01/37] mm:gup/writeback: add callbacks for inaccessible pages
From: David Hildenbrand @ 2020-02-20 12:15 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank, Andrew Morton
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik, Andrea Arcangeli,
linux-mm, Will Deacon
In-Reply-To: <20200220104020.5343-2-borntraeger@de.ibm.com>
On 20.02.20 11:39, Christian Borntraeger wrote:
> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
>
> With the introduction of protected KVM guests on s390 there is now a
> concept of inaccessible pages. These pages need to be made accessible
> before the host can access them.
>
> While cpu accesses will trigger a fault that can be resolved, I/O
> accesses will just fail. We need to add a callback into architecture
> code for places that will do I/O, namely when writeback is started or
> when a page reference is taken.
>
> This is not only to enable paging, file backing etc, it is also
> necessary to protect the host against a malicious user space. For
> example a bad QEMU could simply start direct I/O on such protected
> memory. We do not want userspace to be able to trigger I/O errors and
> thus we the logic is "whenever somebody accesses that page (gup) or
> doing I/O, make sure that this page can be accessed. When the guest
> tries to access that page we will wait in the page fault handler for
> writeback to have finished and for the page_ref to be the expected
> value.
Subject: "mm: gup..."
And I'd probably add that on s390x, it's unlikely to ever return !0.
(why the WARN_ON is okay and has to be tackled once relevant)
>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Acked-by: Will Deacon <will@kernel.org>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH] sched/fair: add !se->on_rq check before dequeue entity
From: Vincent Guittot @ 2020-02-20 12:15 UTC (permalink / raw)
To: chenqiwu
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, chenqiwu
In-Reply-To: <CAKfTPtCm-Vn1YAC8j-XFLritQxQ-B7d=pqO9U6=c2vCuTNUpsg@mail.gmail.com>
On Thu, 20 Feb 2020 at 11:31, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Thu, 20 Feb 2020 at 11:09, chenqiwu <qiwuchen55@gmail.com> wrote:
> >
> > On Thu, Feb 20, 2020 at 10:38:02AM +0100, Vincent Guittot wrote:
> > > On Thu, 20 Feb 2020 at 08:29, <qiwuchen55@gmail.com> wrote:
> > > >
> > > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > >
> > > > We igonre checking for !se->on_rq condition before dequeue one
> > > > entity from cfs rq. It must be required in case the entity has
> > > > been dequeued.
> > >
> > > Do you have a use case that triggers this situation ?
> > >
> > > This is the only way to reach this situation seems to be dequeuing a
> > > task on a throttled cfs_rq
> > >
> > Sorry, I have no use case triggers this situation. It's just found by
> > reading code.
> > I agree the situation you mentioned above may have a racy with
> > dequeue_task_fair() in the following code path:
> > __schedule
> > pick_next_task_fair
> > put_prev_entity
> > check_cfs_rq_runtime
> > throttle_cfs_rq
> > dequeue_entity
> >
> > So this check is worth to be added for dequeue_task_fair().
>
> In fact the check is already done thanks to the: if (cfs_rq_throttled(cfs_rq))
> AFAICT, there is no other way to enqueue a task on a cfs_rq for which
> the group entity is not enqueued
Hmm i have been too quick in my reply. I wanted to say:
AFAICT, there is no other way to dequeue a task from a cfs_rq for
which the group entity is not enqueued
^ permalink raw reply
* Re: [PATCH v2 1/2] struct_union_enum_specifier: always initialize sym->scope
From: Luc Van Oostenryck @ 2020-02-20 12:15 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Alexey Gladkov, linux-sparse
In-Reply-To: <20200220115736.GB27143@redhat.com>
On Thu, Feb 20, 2020 at 12:57:37PM +0100, Oleg Nesterov wrote:
> On 02/20, Luc Van Oostenryck wrote:
> >
> > On Wed, Feb 19, 2020 at 05:29:11PM +0100, Oleg Nesterov wrote:
> > > Currently it is not possible to figure out the scope of the private
> > > struct/union/enum type, its ->scope is NULL because bind_symbol() is
> > > not called.
> > >
> > > Change struct_union_enum_specifier() to set sym->scope = block_scope
> > > in this case, this is what bind_symbol() does when type has a name.
> >
> > Thanks.
> > I've just changed the comment to "used by dissect"
>
> Great, thanks!
>
> > because
> > elsewhere the scope or toplevel()s only relevant for symbols.
>
> Cough... can't resist ;)
>
> Not really, see struct_union_enum_specifier()->is_outer_scope(). But
> yes sure, this is only when ->ident != NULL.
Ah yes, sorry, I wasn't clear enough here. By 'symbol' here, I
effectively meant: "a name (with its associated semantic)", not
a 'struct symbol'.
-- Luc
^ permalink raw reply
* [Buildroot] [PATCH 2/5] package/libsndfile: annotate _IGNORE_CVES for the included security patches
From: Peter Korsgaard @ 2020-02-20 12:16 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200219160203.874-2-peter@korsgaard.com>
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
> Also mark CVE-2018-13419 as disputed.
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
> ---
> package/libsndfile/libsndfile.mk | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> diff --git a/package/libsndfile/libsndfile.mk b/package/libsndfile/libsndfile.mk
> index 22909ffb62..4a375ab609 100644
> --- a/package/libsndfile/libsndfile.mk
> +++ b/package/libsndfile/libsndfile.mk
> @@ -10,6 +10,17 @@ LIBSNDFILE_INSTALL_STAGING = YES
> LIBSNDFILE_LICENSE = LGPL-2.1+
> LIBSNDFILE_LICENSE_FILES = COPYING
> +# 0001-double64_init-Check-psf-sf.channels-against-upper-bo.patch
> +LIBSNDFILE_IGNORE_CVES += CVE-2017-14634
> +# 0002-Check-MAX_CHANNELS-in-sndfile-deinterleave.patch
> +LIBSNDFILE_IGNORE_CVES += CVE-2018-13139 CVE-2018-19432
> +# 0003-a-ulaw-fix-multiple-buffer-overflows-432.patch
> +LIBSNDFILE_IGNORE_CVES += \
> + CVE-2017-14245 CVE-2017-14246 CVE-2017-17456 CVE-2017-17457 \
> + CVE-2018-19661 CVE-2018-19662
> +# disputed
Committed after adding the dispute link as suggested by Thomas, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] drm/panel: ld9040: add MODULE_DEVICE_TABLE with SPI IDs
From: Marek Szyprowski @ 2020-02-20 12:07 UTC (permalink / raw)
To: dri-devel, linux-samsung-soc
Cc: Andrzej Hajda, Sam Ravnborg, Bartlomiej Zolnierkiewicz,
Thierry Reding, Marek Szyprowski
In-Reply-To: <CGME20200220120711eucas1p1f3ac819081ece4847b17c10c005dfa42@eucas1p1.samsung.com>
Add proper MODULE_DEVICE_TABLE structure with SPI IDs to allow proper
creation of SPI modalias string and fix autoloading module for this driver.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
index 3c52f15f7a1c..9bb2e8c7934a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
@@ -373,6 +373,12 @@ static const struct of_device_id ld9040_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ld9040_of_match);
+static const struct spi_device_id ld9040_ids[] = {
+ { "ld9040", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, ld9040_ids);
+
static struct spi_driver ld9040_driver = {
.probe = ld9040_probe,
.remove = ld9040_remove,
--
2.17.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [Buildroot] [PATCH 3/5] package/libtomcrypt: annotate _IGNORE_CVES for the included security patches
From: Peter Korsgaard @ 2020-02-20 12:16 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200219160203.874-3-peter@korsgaard.com>
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/4] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver
From: Xu Zaibo @ 2020-02-20 12:16 UTC (permalink / raw)
To: John Garry, herbert, davem
Cc: qianweili, tanghui20, forest.zhouchang, linuxarm, zhangwei375,
shenyang39, yekai13, linux-crypto
In-Reply-To: <87591c1f-5c6b-64bd-5dc2-900e1481b5ca@huawei.com>
On 2020/2/20 19:07, John Garry wrote:
> On 20/02/2020 10:10, Xu Zaibo wrote:
>> Hi,
>>
>>
>> On 2020/2/20 17:50, John Garry wrote:
>>> On 20/02/2020 09:04, Zaibo Xu wrote:
>>>> From: liulongfang <liulongfang@huawei.com>
>>>>
>>>> In the scenario of SMMU translation, the SEC performance of short
>>>> messages
>>>> (<512Bytes) cannot meet our expectations. To avoid this, we reserve
>>>> the
>>>> plat buffer (PBUF) memory for small packets when creating TFM.
>>>>
>>>
>>> I haven't gone through the code here, but why not use this method
>>> also for non-translated? What are the pros and cons?
>> Because non-translated has no performance or throughput problems.
>>
>
> OK, so no problem, but I was asking could it be improved, and, if so,
> what would be the drawbacks?
>
> As for the change to check if the IOMMU is translating, it seems exact
> same as that for the hi1616 driver...
>
Currently, I find the only drawback is needing more memory :), what's
your idea?
Yes, the same as SEC V1.
Cheers,
Zaibo
.
>>
>> .
>>>
>>> The commit message is very light on details.
>>>
>>> Thanks
>>> john
>>>
>>> .
>>>
>>
>>
>> .
>
> .
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.