[Intel-gfx] [PATCH 12/23] drm/i915: Enable big joiner support in enable and disable sequences.
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough to bring up CRTC's in a big joiner configuration,
without any plane configuration on the second pipe yet.
HOWEVER, we bring up the crtc's in the wrong order. We need to make
sure that the master crtc is brought up after the slave crtc, we
don't do that yet. This is done correctly later in this series.
The next steps are to add atomic commit, and make sure we enable and
update both master and slave in the correct order.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_ddi.c | 55 ++-
drivers/gpu/drm/i915/display/intel_display.c | 402 --
.../drm/i915/display/intel_display_types.h| 17 +
drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 122 --
drivers/gpu/drm/i915/display/intel_vdsc.h | 2 +
6 files changed, 418 insertions(+), 198 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c775fd205915..a26155f90261 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1694,6 +1694,13 @@ static void intel_ddi_clock_get(struct intel_encoder
*encoder,
skl_ddi_clock_get(encoder, pipe_config);
else if (INTEL_GEN(dev_priv) <= 8)
hsw_ddi_clock_get(encoder, pipe_config);
+
+ if (pipe_config->bigjoiner) {
+ pipe_config->hw.transcoder_mode.crtc_clock =
+ pipe_config->hw.adjusted_mode.crtc_clock;
+
+ pipe_config->hw.adjusted_mode.crtc_clock /= 2;
+ }
}
void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
@@ -2176,13 +2183,6 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
intel_phy_is_tc(dev_priv, phy))
intel_display_power_get(dev_priv,
intel_ddi_main_link_aux_domain(dig_port));
-
- /*
-* VDSC power is needed when DSC is enabled
-*/
- if (crtc_state->dsc_params.compression_enable)
- intel_display_power_get(dev_priv,
- intel_dsc_power_domain(crtc_state));
}
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
@@ -3290,7 +3290,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
/* 7.l */
intel_ddi_enable_fec(encoder, crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void hsw_ddi_pre_enable_dp(struct intel_encoder *encoder,
@@ -3361,7 +3362,8 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
if (!is_mst)
intel_ddi_enable_pipe_clock(crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
@@ -3972,19 +3974,18 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
crtc_state->min_voltage_level = 2;
}
-void intel_ddi_get_config(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config)
+static void intel_ddi_read_func_ctl(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->uapi.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
u32 temp, flags = 0;
- /* XXX: DSI transcoder paranoia */
- if (WARN_ON(transcoder_is_dsi(cpu_transcoder)))
+ temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
+ if (!(temp & TRANS_DDI_FUNC_ENABLE))
return;
- temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (temp & TRANS_DDI_PHSYNC)
flags |= DRM_MODE_FLAG_PHSYNC;
else
@@ -4066,6 +4067,29 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
default:
break;
}
+}
+
+void intel_ddi_get_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+
+ /* XXX: DSI transcoder paranoia */
+ if (WARN_ON(transcoder_is_dsi(cpu_transcoder)))
+ return;
+
+ intel_ddi_read_func_ctl(encoder, pipe_config);
+ if
[Intel-gfx] [PATCH 05/23] drm/i915: Complete sw/hw split
Now that we separated everything into uapi and hw, it's
time to make the split definitive. Remove the union and
make a copy of the hw state on modeset and fastset.
Color blobs are copied in crtc atomic_check(), right
before color management is checked.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 44 +++
drivers/gpu/drm/i915/display/intel_atomic.h | 2 +
drivers/gpu/drm/i915/display/intel_display.c | 39 +---
.../drm/i915/display/intel_display_types.h| 8 ++--
4 files changed, 85 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index f4440ede95c5..fb550d3cea7f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -195,6 +195,14 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, _state->uapi);
+ /* copy color blobs */
+ if (crtc_state->hw.degamma_lut)
+ drm_property_blob_get(crtc_state->hw.degamma_lut);
+ if (crtc_state->hw.ctm)
+ drm_property_blob_get(crtc_state->hw.ctm);
+ if (crtc_state->hw.gamma_lut)
+ drm_property_blob_get(crtc_state->hw.gamma_lut);
+
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
@@ -209,6 +217,41 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
return _state->uapi;
}
+static void intel_crtc_put_color_blobs(struct intel_crtc_state *crtc_state)
+{
+ drm_property_blob_put(crtc_state->hw.degamma_lut);
+ drm_property_blob_put(crtc_state->hw.gamma_lut);
+ drm_property_blob_put(crtc_state->hw.ctm);
+}
+
+void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state)
+{
+ intel_crtc_put_color_blobs(crtc_state);
+}
+
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+{
+ intel_crtc_put_color_blobs(crtc_state);
+
+ if (crtc_state->uapi.degamma_lut)
+ crtc_state->hw.degamma_lut =
+ drm_property_blob_get(crtc_state->uapi.degamma_lut);
+ else
+ crtc_state->hw.degamma_lut = NULL;
+
+ if (crtc_state->uapi.gamma_lut)
+ crtc_state->hw.gamma_lut =
+ drm_property_blob_get(crtc_state->uapi.gamma_lut);
+ else
+ crtc_state->hw.gamma_lut = NULL;
+
+ if (crtc_state->uapi.ctm)
+ crtc_state->hw.ctm =
+ drm_property_blob_get(crtc_state->uapi.ctm);
+ else
+ crtc_state->hw.ctm = NULL;
+}
+
/**
* intel_crtc_destroy_state - destroy crtc state
* @crtc: drm crtc
@@ -224,6 +267,7 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
struct intel_crtc_state *crtc_state = to_intel_crtc_state(state);
__drm_atomic_helper_crtc_destroy_state(_state->uapi);
+ intel_crtc_free_hw_state(crtc_state);
kfree(crtc_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 58065d3161a3..42be91e0772a 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -35,6 +35,8 @@ intel_digital_connector_duplicate_state(struct drm_connector
*connector);
struct drm_crtc_state *intel_crtc_duplicate_state(struct drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
+void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 32bbb5bf48f3..e40485a1e503 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -114,6 +114,7 @@ static const u64 cursor_format_modifiers[] = {
DRM_FORMAT_MOD_INVALID
};
+static void copy_uapi_to_hw_state(struct intel_crtc_state *crtc_state);
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
static void ironlake_pch_clock_get(struct intel_crtc *crtc,
@@ -7097,6 +7098,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc,
crtc->enabled = false;
crtc->state->connector_mask = 0;
crtc->state->encoder_mask = 0;
+ copy_uapi_to_hw_state(to_intel_crtc_state(crtc->state));
for_each_encoder_on_crtc(crtc->dev, crtc, encoder)
encoder->base.crtc = NULL;
@@ -11804,6 +11806,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*_crtc,
if (mode_changed || crtc_state->update_pipe ||
[Intel-gfx] [PATCH 06/23] drm/i915: Get rid of crtc_state->fb_changed
We had this as an optimization to not do a plane update, but we killed
it off because there are so many reasons we may have to do a plane
update or fastset that it's best to just assume everything changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c| 1 -
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index fb550d3cea7f..4b4eee9c49f5 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -208,7 +208,6 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->disable_cxsr = false;
crtc_state->update_wm_pre = false;
crtc_state->update_wm_post = false;
- crtc_state->fb_changed = false;
crtc_state->fifo_changed = false;
crtc_state->wm.need_postvbl_update = false;
crtc_state->fb_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e40485a1e503..520c66071e67 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11521,7 +11521,6 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
bool was_crtc_enabled = old_crtc_state->hw.active;
bool is_crtc_enabled = crtc_state->hw.active;
bool turn_off, turn_on, visible, was_visible;
- struct drm_framebuffer *fb = plane_state->base.fb;
int ret;
if (INTEL_GEN(dev_priv) >= 9 && plane->id != PLANE_CURSOR) {
@@ -11555,18 +11554,11 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
if (!was_visible && !visible)
return 0;
- if (fb != old_plane_state->base.fb)
- crtc_state->fb_changed = true;
-
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%d:%s] with fb %i\n",
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] with [PLANE:%d:%s] visible %i -> %i, off
%i, on %i, ms %i\n",
crtc->base.base.id, crtc->base.name,
-plane->base.base.id, plane->base.name,
-fb ? fb->base.id : -1);
-
- DRM_DEBUG_ATOMIC("[PLANE:%d:%s] visible %i -> %i, off %i, on %i, ms
%i\n",
plane->base.base.id, plane->base.name,
was_visible, visible,
turn_off, turn_on, mode_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e81b785cc8f2..57dbcfc126df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -792,7 +792,6 @@ struct intel_crtc_state {
bool update_pipe; /* can a fast modeset be performed? */
bool disable_cxsr;
bool update_wm_pre, update_wm_post; /* watermarks are updated */
- bool fb_changed; /* fb on any of the planes is changed */
bool fifo_changed; /* FIFO split is changed */
/* Pipe source size (ie. panel fitter input size)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/23] drm/i915: Rename planar linked plane variables
Rename linked_plane to planar_linked_plane and slave to planar_slave,
this will make it easier to keep apart bigjoiner linking and planar plane
linking.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 7 --
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display.c | 22 +--
.../drm/i915/display/intel_display_types.h| 8 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 12 +-
6 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 4b4eee9c49f5..158594e64bb9 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -311,10 +311,13 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
*/
mode = PS_SCALER_MODE_NORMAL;
} else {
+ struct intel_plane *linked =
+ plane_state->planar_linked_plane;
+
mode = PS_SCALER_MODE_PLANAR;
- if (plane_state->linked_plane)
- mode |=
PS_PLANE_Y_SEL(plane_state->linked_plane->id);
+ if (linked)
+ mode |= PS_PLANE_Y_SEL(linked->id);
}
} else if (INTEL_GEN(dev_priv) > 9 || IS_GEMINILAKE(dev_priv)) {
mode = PS_SCALER_MODE_NORMAL;
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 1f50b15ec704..a1a34b9981cc 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -321,9 +321,9 @@ void skl_update_planes_on_crtc(struct intel_atomic_state
*state,
if (new_plane_state->base.visible) {
intel_update_plane(plane, new_crtc_state,
new_plane_state);
- } else if (new_plane_state->slave) {
+ } else if (new_plane_state->planar_slave) {
struct intel_plane *master =
- new_plane_state->linked_plane;
+ new_plane_state->planar_linked_plane;
/*
* We update the slave plane from this function because
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fd8b398733b8..ba52a70840fd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11666,7 +11666,7 @@ static int icl_add_linked_planes(struct
intel_atomic_state *state)
int i;
for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
- linked = plane_state->linked_plane;
+ linked = plane_state->planar_linked_plane;
if (!linked)
continue;
@@ -11675,8 +11675,8 @@ static int icl_add_linked_planes(struct
intel_atomic_state *state)
if (IS_ERR(linked_plane_state))
return PTR_ERR(linked_plane_state);
- WARN_ON(linked_plane_state->linked_plane != plane);
- WARN_ON(linked_plane_state->slave == plane_state->slave);
+ WARN_ON(linked_plane_state->planar_linked_plane != plane);
+ WARN_ON(linked_plane_state->planar_slave ==
plane_state->planar_slave);
}
return 0;
@@ -11699,16 +11699,16 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
* in the crtc_state->active_planes mask.
*/
for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
- if (plane->pipe != crtc->pipe || !plane_state->linked_plane)
+ if (plane->pipe != crtc->pipe ||
!plane_state->planar_linked_plane)
continue;
- plane_state->linked_plane = NULL;
- if (plane_state->slave && !plane_state->base.visible) {
+ plane_state->planar_linked_plane = NULL;
+ if (plane_state->planar_slave && !plane_state->base.visible) {
crtc_state->active_planes &= ~BIT(plane->id);
crtc_state->update_planes |= BIT(plane->id);
}
- plane_state->slave = false;
+ plane_state->planar_slave = false;
}
if (!crtc_state->nv12_planes)
@@ -11742,10 +11742,10 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
return -EINVAL;
}
- plane_state->linked_plane = linked;
+ plane_state->planar_linked_plane = linked;
- linked_state->slave = true;
-
[Intel-gfx] [PATCH 02/23] HAX drm/i915: Disable FEC entirely for now
I get a permanent FIFO underrun when enabling FEC with big joiner,
so for now disable it.
It seems that even at 1024x768 resolution without bigjoiner we don't
get a working configuration. Flag is set but vblank timing shows that
vblanks are delivered slightly faster, so the extra overhead we
calculated for data M/N goes unused.
Not-Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4dfb78dc7fa2..02242a16640b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1877,7 +1877,8 @@ static bool intel_dp_source_supports_dsc(struct intel_dp
*intel_dp,
static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
const struct intel_crtc_state *pipe_config)
{
- if (!intel_dp_is_edp(intel_dp) && !pipe_config->fec_enable)
+ /* HACK: Disable FEC until we solved FIFO underruns */
+ if (!intel_dp_is_edp(intel_dp) && !pipe_config->fec_enable && 0)
return false;
return intel_dp_source_supports_dsc(intel_dp, pipe_config) &&
@@ -2024,8 +2025,9 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
int pipe_bpp;
int ret;
+ /* HACK: Disable FEC until we solved FIFO underruns */
pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
- intel_dp_supports_fec(intel_dp, pipe_config);
+ intel_dp_supports_fec(intel_dp, pipe_config) && 0;
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/23] drm/i915: Try to make bigjoiner work in atomic check.
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so it doesn't depend at commit time on the other
crtc_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 15 +-
drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 197 +-
.../drm/i915/display/intel_display_types.h| 11 +-
drivers/gpu/drm/i915/display/intel_dp.c | 25 ++-
5 files changed, 228 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index c50e0b218bd6..0db04064c86e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -228,25 +228,26 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state *from_crtc_state)
{
intel_crtc_put_color_blobs(crtc_state);
- if (crtc_state->uapi.degamma_lut)
+ if (from_crtc_state->uapi.degamma_lut)
crtc_state->hw.degamma_lut =
- drm_property_blob_get(crtc_state->uapi.degamma_lut);
+
drm_property_blob_get(from_crtc_state->uapi.degamma_lut);
else
crtc_state->hw.degamma_lut = NULL;
- if (crtc_state->uapi.gamma_lut)
+ if (from_crtc_state->uapi.gamma_lut)
crtc_state->hw.gamma_lut =
- drm_property_blob_get(crtc_state->uapi.gamma_lut);
+ drm_property_blob_get(from_crtc_state->uapi.gamma_lut);
else
crtc_state->hw.gamma_lut = NULL;
- if (crtc_state->uapi.ctm)
+ if (from_crtc_state->uapi.ctm)
crtc_state->hw.ctm =
- drm_property_blob_get(crtc_state->uapi.ctm);
+ drm_property_blob_get(from_crtc_state->uapi.ctm);
else
crtc_state->hw.ctm = NULL;
}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 42be91e0772a..8da84d64aa04 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -36,7 +36,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ba52a70840fd..143d531c4c81 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7434,7 +7434,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *adjusted_mode =
_config->hw.adjusted_mode;
+ struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
int clock_limit = dev_priv->max_dotclk_freq;
if (INTEL_GEN(dev_priv) < 4) {
@@ -7451,6 +7451,25 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
}
}
+ /*
+* copy hw mode to transcoder mode.
+* This matters mostly for big joiner, which splits the mode in half.
+*/
+ pipe_config->hw.transcoder_mode = pipe_config->hw.adjusted_mode;
+ if (pipe_config->bigjoiner) {
+ /* Make sure the crtc config is halved horizontally */
+ adjusted_mode->crtc_clock /= 2;
+ adjusted_mode->crtc_hdisplay /= 2;
+ adjusted_mode->crtc_hblank_start /= 2;
+ adjusted_mode->crtc_hblank_end /= 2;
+ adjusted_mode->crtc_hsync_start /= 2;
+ adjusted_mode->crtc_hsync_end /= 2;
+ adjusted_mode->crtc_htotal /= 2;
+ adjusted_mode->crtc_hskew /= 2;
+
+ pipe_config->pipe_src_w /= 2;
+ }
+
if
[Intel-gfx] [PATCH 17/23] drm/i915: Add intel_update_bigjoiner handling.
Enabling is done in a special sequence and to be fair, so should
plane updates be. Ideally the end user never notices the second
pipe is used, so use the vblank evasion to cover both pipes.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
The disable sequence still needs some love, but otherwise bigjoiner
is close to ready now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 118 ---
drivers/gpu/drm/i915/display/intel_sprite.c | 22 +++-
drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
3 files changed, 123 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index acb3c5974e99..7f86c358cf45 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14230,7 +14230,7 @@ static void intel_update_crtc(struct intel_crtc *crtc,
else
i9xx_update_planes_on_crtc(state, crtc);
- intel_pipe_update_end(new_crtc_state);
+ intel_pipe_update_end(new_crtc_state, NULL);
if (new_crtc_state->update_pipe && !modeset &&
old_crtc_state->hw.mode.private_flags & I915_MODE_FLAG_INHERITED)
@@ -14312,6 +14312,56 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
}
}
+static void intel_update_bigjoiner(struct intel_crtc *crtc,
+ struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+ struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
+ struct intel_crtc_state *new_slave_crtc_state =
+ intel_atomic_get_new_crtc_state(state, slave);
+ struct intel_crtc_state *old_slave_crtc_state =
+ intel_atomic_get_old_crtc_state(state, slave);
+
+ if (modeset) {
+ /* Enable slave first */
+ update_scanline_offset(new_slave_crtc_state);
+ drm_calc_timestamping_constants(>base,
_slave_crtc_state->hw.transcoder_mode);
+ dev_priv->display.crtc_enable(new_slave_crtc_state, state);
+
+ /* Then master */
+ update_scanline_offset(new_crtc_state);
+ drm_calc_timestamping_constants(>base,
_crtc_state->hw.transcoder_mode);
+ dev_priv->display.crtc_enable(new_crtc_state, state);
+
+ /* vblanks work again, re-enable pipe CRC. */
+ intel_crtc_enable_pipe_crc(crtc);
+
+ } else {
+ intel_pre_plane_update(old_crtc_state, new_crtc_state);
+ intel_pre_plane_update(old_slave_crtc_state,
new_slave_crtc_state);
+
+ if (new_crtc_state->update_pipe)
+ intel_encoders_update_pipe(crtc, new_crtc_state, state);
+ }
+
+ /*
+* Perform vblank evasion around commit operation, and make sure to
+* commit both planes simultaneously for best results.
+*/
+ intel_pipe_update_start(new_crtc_state);
+
+ commit_pipe_config(state, old_crtc_state, new_crtc_state);
+ commit_pipe_config(state, old_slave_crtc_state, new_slave_crtc_state);
+
+ skl_update_planes_on_crtc(state, crtc);
+ icl_update_bigjoiner_planes_on_crtc(state, slave);
+
+ intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
+}
+
static void intel_commit_modeset_enables(struct intel_atomic_state *state)
{
struct intel_crtc *crtc;
@@ -14330,7 +14380,7 @@ static void intel_commit_modeset_enables(struct
intel_atomic_state *state)
static void skl_commit_modeset_enables(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct intel_crtc *crtc;
+ struct intel_crtc *crtc, *slave;
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
unsigned int updated = 0;
bool progress;
@@ -14339,11 +14389,47 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
u8 required_slices = state->wm_results.ddb.enabled_slices;
struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
+ struct skl_ddb_entry new_entries[I915_MAX_PIPES] = {};
+ const struct intel_crtc_state *slave_crtc_state;
+ u32 dirty_pipes = state->wm_results.dirty_pipes;
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ if (new_crtc_state->bigjoiner_slave) {
+ /* clear dirty bit, we're updated in master */
+ dirty_pipes &= ~drm_crtc_mask(>base);
+
[Intel-gfx] [PATCH 10/23] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
Also unexport a few functions only used internally in intel_dp.c
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_dp.c | 98 +++--
1 file changed, 75 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2fceb71f7f70..046e1662d1e3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -247,7 +247,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
}
static int
-intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
+intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, bool
allow_bigjoiner)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _dig_port->base;
@@ -257,6 +257,9 @@ intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+ if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11)
+ max_dotclk *= 2;
+
if (type != DP_DS_PORT_TYPE_VGA)
return max_dotclk;
@@ -505,8 +508,10 @@ u32 intel_dp_fec_to_mode_clock(u32 fec_clock)
100U);
}
-static u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32 lane_count,
- u32 mode_clock, u32 mode_hdisplay)
+static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *dev_priv,
+ u32 link_clock, u32 lane_count,
+ u32 mode_clock, u32 mode_hdisplay,
+ bool bigjoiner)
{
u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
@@ -523,6 +528,10 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32
lane_count,
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER /
mode_hdisplay;
+
+ if (bigjoiner)
+ max_bpp_small_joiner_ram *= 2;
+
DRM_DEBUG_KMS("Max small joiner bpp: %u\n", max_bpp_small_joiner_ram);
/*
@@ -531,6 +540,15 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32
lane_count,
*/
bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
+ if (bigjoiner) {
+ u32 max_bpp_bigjoiner =
+ dev_priv->max_cdclk_freq * 48 /
+ intel_dp_mode_to_fec_clock(mode_clock);
+
+ DRM_DEBUG_KMS("Max big joiner bpp: %u\n", max_bpp_bigjoiner);
+ bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
+ }
+
/* Error out if the max bpp is less than smallest allowed valid bpp */
if (bits_per_pixel < valid_dsc_bpp[0]) {
DRM_DEBUG_KMS("Unsupported BPP %u, min %u\n",
@@ -553,7 +571,8 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32
lane_count,
}
static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
- int mode_clock, int mode_hdisplay)
+ int mode_clock, int mode_hdisplay,
+ bool bigjoiner)
{
u8 min_slice_count, i;
int max_slice_width;
@@ -578,12 +597,20 @@ static u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
/* Find the closest match to the valid slice count values */
for (i = 0; i < ARRAY_SIZE(valid_dsc_slicecount); i++) {
- if (valid_dsc_slicecount[i] >
- drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
- false))
+ u8 test_slice_count = bigjoiner ?
+ 2 * valid_dsc_slicecount[i] :
+ valid_dsc_slicecount[i];
+
+ if (test_slice_count >
+ drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd, false))
break;
- if (min_slice_count <= valid_dsc_slicecount[i])
- return valid_dsc_slicecount[i];
+
+ /* big joiner needs small joiner to be enabled */
+ if (bigjoiner && test_slice_count < 4)
+ continue;
+
+ if (min_slice_count <= test_slice_count)
+ return test_slice_count;
}
DRM_DEBUG_KMS("Unsupported Slice Count %d\n", min_slice_count);
@@ -603,11 +630,15 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_dotclk;
u16 dsc_max_output_bpp = 0;
u8 dsc_slice_count = 0;
+ bool dsc = false, bigjoiner = false;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
- max_dotclk =
[Intel-gfx] [PATCH 15/23] drm/i915: Link planes in a bigjoiner configuration.
Make sure that when a plane is set in a bigjoiner mode, we will add
their counterpart to the atomic state as well. This will allow us to
make sure all state is available when planes are checked.
Because of the funny interactions with bigjoiner and planar YUV
formats, we may end up adding a lot of planes, so we have to keep
iterating until we no longer add any planes.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 31 +++-
.../gpu/drm/i915/display/intel_atomic_plane.h | 4 +
drivers/gpu/drm/i915/display/intel_display.c | 142 --
.../drm/i915/display/intel_display_types.h| 11 ++
4 files changed, 172 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 964db7774d10..cc088676f0a2 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -182,16 +182,36 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
old_plane_state,
new_plane_state);
}
-static struct intel_crtc *
-get_crtc_from_states(const struct intel_plane_state *old_plane_state,
-const struct intel_plane_state *new_plane_state)
-{
+struct intel_crtc *
+intel_plane_get_crtc_from_states(struct intel_atomic_state *state,
+const struct intel_plane_state
*old_plane_state,
+const struct intel_plane_state
*new_plane_state)
+ {
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane = to_intel_plane(new_plane_state->base.plane);
+
if (new_plane_state->base.crtc)
return to_intel_crtc(new_plane_state->base.crtc);
if (old_plane_state->base.crtc)
return to_intel_crtc(old_plane_state->base.crtc);
+ if (new_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *new_master_plane_state =
+ intel_atomic_get_new_plane_state(state,
new_plane_state->bigjoiner_plane);
+
+ if (new_master_plane_state->base.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
+ if (old_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *old_master_plane_state =
+ intel_atomic_get_old_plane_state(state,
old_plane_state->bigjoiner_plane);
+
+ if (old_master_plane_state->base.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
return NULL;
}
@@ -206,7 +226,8 @@ static int intel_plane_atomic_check(struct drm_plane
*_plane,
const struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
struct intel_crtc *crtc =
- get_crtc_from_states(old_plane_state, new_plane_state);
+ intel_plane_get_crtc_from_states(state, old_plane_state,
+new_plane_state);
const struct intel_crtc_state *old_crtc_state;
struct intel_crtc_state *new_crtc_state;
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 33fb85cd3909..901a50e6e2d3 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -42,5 +42,9 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
struct intel_crtc_state *crtc_state,
const struct intel_plane_state
*old_plane_state,
struct intel_plane_state *plane_state);
+struct intel_crtc *
+intel_plane_get_crtc_from_states(struct intel_atomic_state *state,
+const struct intel_plane_state
*old_plane_state,
+const struct intel_plane_state
*new_plane_state);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index df588bf47559..06ceac4f1436 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11811,24 +11811,101 @@ static bool check_single_encoder_cloning(struct
drm_atomic_state *state,
return true;
}
+static int icl_add_dependent_planes(struct intel_atomic_state *state,
+ struct intel_plane_state *plane_state)
+{
+ struct intel_plane_state *new_plane_state;
+ struct intel_plane *plane;
+ int ret = 0;
+
+ plane = plane_state->bigjoiner_plane;
+ if (plane && !intel_atomic_get_new_plane_state(state, plane)) {
+ new_plane_state =
[Intel-gfx] [PATCH 04/23] drm/i915: Handle a few more cases for hw/sw split
We are still looking at drm_crtc_state in a few places, convert those
to use intel_crtc_state instead. Look at uapi/hw where appropriate.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6818cbd00ac2..32bbb5bf48f3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16081,8 +16081,8 @@ static int intel_initial_commit(struct drm_device *dev)
{
struct drm_atomic_state *state = NULL;
struct drm_modeset_acquire_ctx ctx;
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
int ret = 0;
state = drm_atomic_state_alloc(dev);
@@ -16094,15 +16094,15 @@ static int intel_initial_commit(struct drm_device
*dev)
retry:
state->acquire_ctx =
- drm_for_each_crtc(crtc, dev) {
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ for_each_intel_crtc(dev, crtc) {
+ crtc_state = intel_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
ret = PTR_ERR(crtc_state);
goto out;
}
- if (crtc_state->active) {
- ret = drm_atomic_add_affected_planes(state, crtc);
+ if (crtc_state->hw.active) {
+ ret = drm_atomic_add_affected_planes(state,
>base);
if (ret)
goto out;
@@ -16112,7 +16112,7 @@ static int intel_initial_commit(struct drm_device *dev)
* having a proper LUT loaded. Remove once we
* have readout for pipe gamma enable.
*/
- crtc_state->color_mgmt_changed = true;
+ crtc_state->uapi.color_mgmt_changed = true;
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 76f066b1dfe5..5127ec037b7b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -187,7 +187,7 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
if (!crtc_state ||
!drm_atomic_crtc_needs_modeset(crtc_state) ||
- crtc_state->enable)
+ to_intel_crtc_state(crtc_state)->hw.enable)
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8988dbe8c19e..979e166f5639 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1068,9 +1068,9 @@ static int intel_psr_fastset_force(struct
drm_i915_private *dev_priv)
intel_crtc_state = to_intel_crtc_state(crtc_state);
- if (crtc_state->active && intel_crtc_state->has_psr) {
+ if (intel_crtc_state->hw.active && intel_crtc_state->has_psr) {
/* Mark mode as changed to trigger a pipe->update() */
- crtc_state->mode_changed = true;
+ intel_crtc_state->uapi.mode_changed = true;
break;
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/23] drm/i915: Disable FBC in bigjoiner configuration.
Is there any point in having FBC enabled on half a screen? I suppose it could still save power, but just feels wrong.. Can always be enabled later again if required. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/display/intel_fbc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c index c6cc3775f3b8..e4d678d425e4 100644 --- a/drivers/gpu/drm/i915/display/intel_fbc.c +++ b/drivers/gpu/drm/i915/display/intel_fbc.c @@ -1056,6 +1056,8 @@ void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv, continue; crtc_state = intel_atomic_get_new_crtc_state(state, crtc); + if (crtc_state->bigjoiner) + continue; crtc_state->enable_fbc = true; crtc_chosen = true; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/23] drm/i915: Do not add all planes when checking scalers on glk+
We cannot switch between HQ and normal mode on GLK+, so only
add planes on platforms where it makes sense.
We could probably restrict it even more to only add when scaler
users toggles between 1 and 2, but lets just leave it for now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 158594e64bb9..c50e0b218bd6 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -421,6 +421,11 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
*/
if (!plane) {
struct drm_plane_state *state;
+
+ /* No need to reprogram, we're not changing
scaling mode */
+ if (INTEL_GEN(dev_priv) >= 10 ||
IS_GEMINILAKE(dev_priv))
+ continue;
+
plane = drm_plane_from_index(_priv->drm, i);
state = drm_atomic_get_plane_state(drm_state,
plane);
if (IS_ERR(state)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/23] drm/i915: Remove begin/finish_crtc_commit.
This can all be done from the intel_update_crtc function. Split out the
pipe update into a separate function, just like is done for the planes.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 124 ---
1 file changed, 52 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 520c66071e67..fd8b398733b8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
-static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
-static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
static void intel_crtc_init_scalers(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state);
static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
@@ -13673,13 +13671,54 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc
*crtc)
return crtc->base.funcs->get_vblank_counter(>base);
}
+void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!IS_GEN(dev_priv, 2))
+ intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
true);
+
+ if (crtc_state->has_pch_encoder) {
+ enum pipe pch_transcoder =
+ intel_crtc_pch_transcoder(crtc);
+
+ intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
true);
+ }
+}
+
+static void commit_pipe_config(struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+
+ if (!modeset) {
+ if (new_crtc_state->uapi.color_mgmt_changed ||
+ new_crtc_state->update_pipe)
+ intel_color_commit(new_crtc_state);
+
+ if (new_crtc_state->update_pipe)
+ intel_update_pipe_config(old_crtc_state,
new_crtc_state);
+ else if (INTEL_GEN(dev_priv) >= 9)
+ skl_detach_scalers(new_crtc_state);
+
+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
+ bdw_set_pipemisc(new_crtc_state);
+ }
+
+ if (dev_priv->display.atomic_update_watermarks)
+ dev_priv->display.atomic_update_watermarks(state,
+ new_crtc_state);
+}
+
static void intel_update_crtc(struct intel_crtc *crtc,
struct intel_atomic_state *state,
struct intel_crtc_state *old_crtc_state,
struct intel_crtc_state *new_crtc_state)
{
- struct drm_device *dev = state->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
bool modeset = needs_modeset(new_crtc_state);
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state,
@@ -13703,14 +13742,21 @@ static void intel_update_crtc(struct intel_crtc *crtc,
else if (new_plane_state)
intel_fbc_enable(crtc, new_crtc_state, new_plane_state);
- intel_begin_crtc_commit(state, crtc);
+ /* Perform vblank evasion around commit operation */
+ intel_pipe_update_start(new_crtc_state);
+
+ commit_pipe_config(state, old_crtc_state, new_crtc_state);
if (INTEL_GEN(dev_priv) >= 9)
skl_update_planes_on_crtc(state, crtc);
else
i9xx_update_planes_on_crtc(state, crtc);
- intel_finish_crtc_commit(state, crtc);
+ intel_pipe_update_end(new_crtc_state);
+
+ if (new_crtc_state->update_pipe && !modeset &&
+ old_crtc_state->hw.mode.private_flags & I915_MODE_FLAG_INHERITED)
+ intel_crtc_arm_fifo_underrun(crtc, new_crtc_state);
}
static void intel_old_crtc_state_disables(struct intel_atomic_state *state,
@@ -14507,72 +14553,6 @@ skl_max_scale(const struct intel_crtc_state
*crtc_state,
return max_scale;
}
-static void intel_begin_crtc_commit(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state
[Intel-gfx] [PATCH 21/23] drm/i915: Make sure watermarks work correctly with bigjoiner as well.
For bigjoiner, we cannot do drm_atomic_crtc_state_for_each_plane_state()
on the crtc, because planes don't match the drm core state.
We need a separate master_plane_state for all the properties,
and a slave_plane_state for the rectangles/visibility etc.
This is similar to how we handle the Y plane, because it won't be
directly calculated either. Instead it's calculated from the master
crtc.
Add a intel_atomic_crtc_state_for_each_plane_state macro, which
iterates over master_plane_state and obtains slave_plane_state
as well. This cleans up code slightly as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
drivers/gpu/drm/i915/display/intel_display.h | 20 +-
drivers/gpu/drm/i915/intel_pm.c | 201 ++
4 files changed, 134 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index a8f34254cd2a..add77e33e54e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -297,7 +297,7 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
return;
/* set scaler mode */
- if (plane_state && (plane_state->linked_plane ||
+ if (plane_state && (plane_state->planar_linked_plane ||
(!plane_state->bigjoiner_slave && plane_state->base.fb &&
plane_state->base.fb->format->is_yuv &&
plane_state->base.fb->format->num_planes > 1))) {
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 9fca9e90af58..f471bb30c20a 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -414,14 +414,14 @@ void icl_update_bigjoiner_planes_on_crtc(struct
intel_atomic_state *state,
intel_update_slave(plane, new_crtc_state,
master_plane_state, new_plane_state);
- } else if (new_plane_state->slave) {
+ } else if (new_plane_state->planar_slave) {
/*
* bigjoiner slave + planar slave.
* The correct sequence is to get from the planar slave
to planar master,
* then to the master plane state for the
master_plane_state.
*/
- struct intel_plane *linked =
new_plane_state->linked_plane;
+ struct intel_plane *linked =
new_plane_state->planar_linked_plane;
const struct intel_plane_state *uv_plane_state =
intel_atomic_get_new_plane_state(state, linked);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index a8b2198fcef1..14717a59e677 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -350,7 +350,7 @@ enum phy_fia {
&(dev)->mode_config.plane_list, \
base.head) \
for_each_if((plane_mask) & \
- drm_plane_mask(_plane->base)))
+ drm_plane_mask(_plane->base))
#define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
list_for_each_entry(intel_plane,\
@@ -440,6 +440,24 @@ enum phy_fia {
(__i)--) \
for_each_if(crtc)
+#define intel_atomic_crtc_state_for_each_plane_state( \
+ plane, master_plane_state, plane_state, \
+ crtc_state) \
+ for_each_intel_plane_mask(((crtc_state)->uapi.state->dev), (plane), \
+ (((crtc_state)->bigjoiner_slave ? \
+ intel_atomic_get_new_crtc_state( \
+
to_intel_atomic_state((crtc_state)->uapi.state), \
+ (crtc_state)->bigjoiner_linked_crtc) : \
+ (crtc_state))->uapi.plane_mask)) \
+ for_each_if master_plane_state) = \
+
to_intel_plane_state(__drm_atomic_get_current_plane_state((crtc_state)->uapi.state,
>base))), \
+ ((plane) = (master_plane_state)->bigjoiner_slave
? \
+(master_plane_state)->bigjoiner_plane
: \
+(plane)), \
+ ((plane_state) =
(master_plane_state)->bigjoiner_slave ? \
+
to_intel_plane_state(__drm_atomic_get_current_plane_state((crtc_state)->uapi.state,
>base)) : \
+ (master_plane_state
+
[Intel-gfx] [PATCH 13/23] drm/i915: Make hardware readout work on i915.
Unfortunately I have no way to test this, but it should be correct
if the bios sets up bigjoiner in a sane way.
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace, and double the mode on bigjoiner
master.
And last, disable bigjoiner slave from primary if reconstruction fails.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 65 +++-
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8c08c4914c9b..0424a378eb51 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3177,6 +3177,8 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(intel_crtc->base.state);
struct drm_framebuffer *fb;
if (!plane_config->fb)
@@ -3199,7 +3201,7 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
if (c == _crtc->base)
continue;
- if (!to_intel_crtc(c)->active)
+ if (!to_intel_crtc_state(c->state)->uapi.active)
continue;
state = to_intel_plane_state(c->primary->state);
@@ -3221,6 +3223,12 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
* pretend the BIOS never had it enabled.
*/
intel_plane_disable_noatomic(intel_crtc, intel_plane);
+ if (crtc_state->bigjoiner) {
+ struct intel_crtc *slave =
+ crtc_state->bigjoiner_linked_crtc;
+
+ intel_plane_disable_noatomic(slave,
to_intel_plane(slave->base.primary));
+ }
return;
@@ -9918,6 +9926,7 @@ static void
skylake_get_initial_plane_config(struct intel_crtc *crtc,
struct intel_initial_plane_config
*plane_config)
{
+ struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *plane = to_intel_plane(crtc->base.primary);
@@ -10021,6 +10030,18 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
fb->height = ((val >> 16) & 0x) + 1;
fb->width = ((val >> 0) & 0x) + 1;
+ /* add bigjoiner slave as well, if the fb stretches both */
+ if (crtc_state->bigjoiner) {
+ enum pipe bigjoiner_pipe =
crtc_state->bigjoiner_linked_crtc->pipe;
+
+ if (fb->width == crtc_state->pipe_src_w &&
+ (I915_READ(PLANE_SURF(bigjoiner_pipe, plane_id)) &
0xf000) == plane_config->base) {
+ val =
I915_READ(PLANE_SIZE(crtc_state->bigjoiner_linked_crtc->pipe, plane_id));
+ fb->height += ((val >> 16) & 0xfff) + 1;
+ fb->width += ((val >> 0) & 0x1fff) + 1;
+ }
+ }
+
val = I915_READ(PLANE_STRIDE(pipe, plane_id));
stride_mult = skl_plane_stride_mult(fb, 0, DRM_MODE_ROTATE_0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
@@ -16814,7 +16835,8 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
- if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc))
+ if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc) &&
+ !crtc_state->bigjoiner_slave)
intel_crtc_disable_noatomic(>base, ctx);
if (crtc_state->hw.active || HAS_GMCH(dev_priv)) {
@@ -17136,6 +17158,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
struct intel_plane *plane;
int min_cdclk = 0;
+ if (crtc_state->bigjoiner_slave)
+ continue;
+
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->hw.active) {
intel_mode_from_pipe_config(>base.mode,
crtc_state);
@@ -17144,7 +17169,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
intel_mode_from_pipe_config(_state->hw.adjusted_mode,
crtc_state);
crtc_state->hw.mode = crtc->base.mode;
- WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
>base.mode));
+ if (!crtc_state->bigjoiner_slave)
+
Re: [Intel-gfx] [PATCH 2/9] drm/print: add drm_debug_enabled()
On Monday, 2019-09-16 16:23:13 +0300, Jani Nikula wrote:
> On Mon, 16 Sep 2019, Eric Engestrom wrote:
> > On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
> >> On Fri, 13 Sep 2019, Eric Engestrom wrote:
> >> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
> >> >> Add helper to check if a drm debug category is enabled. Convert drm core
> >> >> to use it. No functional changes.
> >> >>
> >> >> Signed-off-by: Jani Nikula
> >> >> ---
> >> >> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> >> >> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> >> >> drivers/gpu/drm/drm_edid.c| 2 +-
> >> >> drivers/gpu/drm/drm_edid_load.c | 2 +-
> >> >> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
> >> >> drivers/gpu/drm/drm_print.c | 4 ++--
> >> >> drivers/gpu/drm/drm_vblank.c | 6 +++---
> >> >> include/drm/drm_print.h | 5 +
> >> >> 8 files changed, 18 insertions(+), 13 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> index 5a5b42db6f2a..6576cd997cbd 100644
> >> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >> >> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> >> >> ret = drm_atomic_nonblocking_commit(state);
> >> >> } else {
> >> >> - if (unlikely(drm_debug & DRM_UT_STATE))
> >> >> + if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
> >> >> drm_atomic_print_state(state);
> >> >>
> >> >> ret = drm_atomic_commit(state);
> >> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> >> index 97216099a718..f47c5b6b51f7 100644
> >> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> >> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> >> >> drm_dp_mst_branch *mstb,
> >> >> }
> >> >> }
> >> >> out:
> >> >> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
> >> >> + if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
> >> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >> >>
> >> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> >> >> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
> >> >> drm_dp_mst_topology_mgr *mgr,
> >> >> idx += tosend + 1;
> >> >>
> >> >> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> >> >> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> >> >> + if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
> >> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >> >>
> >> >> drm_printf(, "sideband msg failed to send\n");
> >> >> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
> >> >> drm_dp_mst_topology_mgr *mgr,
> >> >> mutex_lock(>qlock);
> >> >> list_add_tail(>next, >tx_msg_downq);
> >> >>
> >> >> - if (unlikely(drm_debug & DRM_UT_DP)) {
> >> >> + if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
> >> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >> >>
> >> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> >> index 12c783f4d956..58dad4d24cd4 100644
> >> >> --- a/drivers/gpu/drm/drm_edid.c
> >> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> >> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct
> >> >> drm_connector *connector,
> >> >> {
> >> >> int i;
> >> >>
> >> >> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> >> >> + if (connector->bad_edid_counter++ &&
> >> >> !drm_debug_enabled(DRM_UT_KMS))
> >> >> return;
> >> >>
> >> >> dev_warn(connector->dev->dev,
> >> >> diff --git a/drivers/gpu/drm/drm_edid_load.c
> >> >> b/drivers/gpu/drm/drm_edid_load.c
> >> >> index d38b3b255926..37d8ba3ddb46 100644
> >> >> --- a/drivers/gpu/drm/drm_edid_load.c
> >> >> +++ b/drivers/gpu/drm/drm_edid_load.c
> >> >> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector
> >> >> *connector, const char *name,
> >> >> u8 *edid;
> >> >> int fwsize, builtin;
> >> >> int i, valid_extensions = 0;
> >> >> - bool print_bad_edid = !connector->bad_edid_counter ||
> >> >> (drm_debug & DRM_UT_KMS);
> >> >> + bool print_bad_edid = !connector->bad_edid_counter ||
> >> >> drm_debug_enabled(DRM_UT_KMS);
> >> >>
> >> >> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
> >> >> if (builtin >= 0) {
> >> >> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
> >> >> b/drivers/gpu/drm/drm_mipi_dbi.c
> >> >> index f8154316a3b0..ccfb5b33c5e3 100644
>
Re: [Intel-gfx] [v3][PATCH 1/3] drm/i915/color: Fix formatting issues
On Thu, 19 Sep 2019, Swati Sharma wrote:
> Fixed few formatting issues in multi-segmented load_lut().
>
> v3: -style nitting [Jani]
> -balanced parentheses moved from patch 2 to 1 [Jani]
> -subject prefix change [Jani]
> -added commit message [Jani]
>
> Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 34
> ++
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 318308d..765482d 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -807,11 +807,11 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut
> *color)
> u32 i;
>
> /*
> - * Every entry in the multi-segment LUT is corresponding to a superfine
> - * segment step which is 1/(8 * 128 * 256).
> + * Program Super Fine segment (let's call it seg1)...
>*
> - * Superfine segment has 9 entries, corresponding to values
> - * 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 * 256).
> + * Super Fine segment's step is 1/(8 * 128 * 256) and it has
> + * 9 entries, corresponding to values 0, 1/(8 * 128 * 256),
> + * 2/(8 * 128 * 256) ... 8/(8 * 128 * 256).
>*/
> I915_WRITE(PREC_PAL_MULTI_SEG_INDEX(pipe), PAL_PREC_AUTO_INCREMENT);
>
> @@ -837,17 +837,17 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut
> *color)
> u32 i;
>
> /*
> - *
>* Program Fine segment (let's call it seg2)...
>*
> - * Fine segment's step is 1/(128 * 256) ie 1/(128 * 256), 2/(128*256)
> - * ... 256/(128*256). So in order to program fine segment of LUT we
> - * need to pick every 8'th entry in LUT, and program 256 indexes.
> + * Fine segment's step is 1/(128 * 256) i.e. 1/(128 * 256), 2/(128 *
> 256)
> + * ... 256/(128 * 256). So in order to program fine segment of LUT we
> + * need to pick every 8th entry in the LUT, and program 256 indexes.
>*
>* PAL_PREC_INDEX[0] and PAL_PREC_INDEX[1] map to seg2[1],
> - * with seg2[0] being unused by the hardware.
> + * seg2[0] being unused by the hardware.
>*/
> I915_WRITE(PREC_PAL_INDEX(pipe), PAL_PREC_AUTO_INCREMENT);
> +
> for (i = 1; i < 257; i++) {
> entry = [i * 8];
> I915_WRITE(PREC_PAL_DATA(pipe), ilk_lut_12p4_ldw(entry));
> @@ -857,8 +857,8 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut
> *color)
> /*
>* Program Coarse segment (let's call it seg3)...
>*
> - * Coarse segment's starts from index 0 and it's step is 1/256 ie 0,
> - * 1/256, 2/256 ...256/256. As per the description of each entry in LUT
> + * Coarse segment starts from index 0 and it's step is 1/256 ie 0,
> + * 1/256, 2/256 ... 256/256. As per the description of each entry in LUT
>* above, we need to pick every (8 * 128)th entry in LUT, and
>* program 256 of those.
>*
> @@ -890,12 +890,10 @@ static void icl_load_luts(const struct intel_crtc_state
> *crtc_state)
> case GAMMA_MODE_MODE_8BIT:
> i9xx_load_luts(crtc_state);
> break;
> -
> case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
> icl_program_gamma_superfine_segment(crtc_state);
> icl_program_gamma_multi_segment(crtc_state);
> break;
> -
> default:
> bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
> ivb_load_lut_ext_max(crtc);
> @@ -1788,16 +1786,16 @@ void intel_color_init(struct intel_crtc *crtc)
> else
> dev_priv->display.color_commit = ilk_color_commit;
>
> - if (INTEL_GEN(dev_priv) >= 11)
> + if (INTEL_GEN(dev_priv) >= 11) {
> dev_priv->display.load_luts = icl_load_luts;
> - else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> + } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> dev_priv->display.load_luts = glk_load_luts;
> dev_priv->display.read_luts = glk_read_luts;
> - } else if (INTEL_GEN(dev_priv) >= 8)
> + } else if (INTEL_GEN(dev_priv) >= 8) {
> dev_priv->display.load_luts = bdw_load_luts;
> - else if (INTEL_GEN(dev_priv) >= 7)
> + } else if (INTEL_GEN(dev_priv) >= 7) {
> dev_priv->display.load_luts = ivb_load_luts;
> - else {
> + } else {
> dev_priv->display.load_luts = ilk_load_luts;
> dev_priv->display.read_luts = ilk_read_luts;
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Move the SAMPLER_MODE setup into the context
== Series Details == Series: drm/i915/tgl: Move the SAMPLER_MODE setup into the context URL : https://patchwork.freedesktop.org/series/66954/ State : success == Summary == CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14465_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14465_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-apl2/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-apl8/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb4/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +20 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb8/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb1/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html * igt@i915_selftest@mock_fence: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb2/igt@i915_selftest@mock_fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb7/igt@i915_selftest@mock_fence.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#103375]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-kbl1/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-kbl1/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb2/igt@kms_psr2_su@page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb5/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-iclb8/igt@kms_psr@psr2_cursor_blt.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#104108]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl10/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14465/shard-skl3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html * igt@kms_vblank@pipe-c-wait-forked-busy-hang: - shard-hsw:
Re: [Intel-gfx] [v3][PATCH 2/3] drm/i915/color: Extract icl_read_luts()
On Thu, 19 Sep 2019, Swati Sharma wrote:
> For icl+, have hw read out to create hw blob of gamma
> lut values. icl+ platforms supports multi segmented gamma
> mode by default, add hw lut creation for this mode.
>
> This will be used to validate gamma programming using dsb
> (display state buffer) which is a tgl specific feature.
>
> Following are the main changes done in this patch:
> 1. gamma_enable checks made specific to platform func()
>since icl doeesn't support that and enable gamma through mode
> 2. lut[0] and lut[8] enteries should be same superfine and coarse;
>superfine and fine segments respectively, checked twice-no harm
> 3. Removed temporary lut
> 4. Coarse segment interpolated gamma values loop start from 2
>instead of 0, since actual h/w values started getting overrided.
>
> v2: -readout code for multisegmented gamma has to come
> up with some intermediate entries that aren't preserved
> in hardware (Jani N)
> -linear interpolation (Ville)
> -moved common code to check gamma_enable to specific funcs,
> since icl doesn't support that
> v3: -use u16 instead of __u16 [Jani N]
> -used single lut [Jani N]
> -improved and more readable for loops [Jani N]
> -read values directly to actual locations and then fill gaps [Jani N]
> -moved cleaning to patch 1 [Jani N]
> -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to
> make it similar to icl_load_luts()
> -renamed icl_compute_interpolated_gamma_blob() to
> icl_compute_interpolated_gamma_lut_values() more sensible, I guess
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 216
> +++--
> drivers/gpu/drm/i915/i915_reg.h| 7 +
> 2 files changed, 208 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 765482d..ad548ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1371,6 +1371,9 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
>
> static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)
> {
> + if (!crtc_state->gamma_enable)
> + return 0;
> +
> switch (crtc_state->gamma_mode) {
> case GAMMA_MODE_MODE_8BIT:
> return 8;
> @@ -1384,6 +1387,9 @@ static int i9xx_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>
> static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)
> {
> + if (!crtc_state->gamma_enable)
> + return 0;
> +
> if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
> return 0;
>
> @@ -1400,6 +1406,9 @@ static int ilk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>
> static int chv_gamma_precision(const struct intel_crtc_state *crtc_state)
> {
> + if (!crtc_state->gamma_enable)
> + return 0;
> +
> if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
> return 10;
> else
> @@ -1408,6 +1417,9 @@ static int chv_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>
> static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)
> {
> + if (!crtc_state->gamma_enable)
> + return 0;
> +
> switch (crtc_state->gamma_mode) {
> case GAMMA_MODE_MODE_8BIT:
> return 8;
> @@ -1419,21 +1431,39 @@ static int glk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> }
> }
>
> +static int icl_gamma_precision(const struct intel_crtc_state *crtc_state)
> +{
> + if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> + return 0;
> +
> + switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> + case GAMMA_MODE_MODE_8BIT:
> + return 8;
> + case GAMMA_MODE_MODE_10BIT:
> + return 10;
> + case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
> + return 16;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + return 0;
> + }
> +
> +}
> +
> int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
> *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
> if (HAS_GMCH(dev_priv)) {
> if (IS_CHERRYVIEW(dev_priv))
> return chv_gamma_precision(crtc_state);
> else
> return i9xx_gamma_precision(crtc_state);
> } else {
> - if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 11)
> + return icl_gamma_precision(crtc_state);
> + else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
>
[Intel-gfx] [PATCH v9 01/10] drm/i915/dsb: feature flag added for display state buffer.
Display State Buffer(DSB) is a new hardware capability, introduced
in GEN12 display. DSB allows a driver to batch-program display HW
registers.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4faec2f94e19..84b9b138d7ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1863,6 +1863,8 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(n)) + \
INTEL_INFO(dev_priv)->gen == (n))
+#define HAS_DSB(dev_priv) (INTEL_INFO(dev_priv)->display.has_dsb)
+
/*
* Return true if revision is in range [since,until] inclusive.
*
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index d4c288860aed..0cdc2465534b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -135,6 +135,7 @@ enum intel_ppgtt_type {
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
+ func(has_dsb); \
func(has_fbc); \
func(has_gmch); \
func(has_hotplug); \
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 00/10] DSB enablement.
Display State Buffer (DSB) is hardware capability which allows driver to batch submit HW programming. As part of initial enablement common api created which currently used to program gamma lut proramming. Going forwad DSB support can be added for HDR and flip related operation. HSDES: 1209978241 BSpec: 32020 v1: Initial version. v2: Move intel_dsb files under display folder and fixed an issue. v3: As per review comments from Chris and Jani, - removed some unwanted code. (Chris) - Used i915_gem_object_create_internal instead of _shmem. (Chris) - cmd_buf_tail removed and can be derived through vma object. (Chris) - Simplified and optimized code few places. (Chris) - Called dsb-api directly in callsites instead going via I915_WRITE. (Jani) v4: Addressed review commnets from Shashank. v5: Addressed review commnets from Shashank and Jani. v6: Addressed review commnets from Shashank. v7: Addressed review commnets from Shashank and Jani. v8: Addressed review commnets from Shashank and Jani. v9: Addressed review commnets from Jani. Animesh Manna (10): drm/i915/dsb: feature flag added for display state buffer. drm/i915/dsb: DSB context creation. drm/i915/dsb: single register write function for DSB. drm/i915/dsb: Indexed register write function for DSB. drm/i915/dsb: Check DSB engine status. drm/i915/dsb: functions to enable/disable DSB engine. drm/i915/dsb: function to trigger workload execution of DSB. drm/i915/dsb: Enable gamma lut programming using DSB. drm/i915/dsb: Enable DSB for gen12. drm/i915/dsb: Documentation for DSB. Documentation/gpu/i915.rst| 9 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_color.c| 63 ++-- .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dsb.c | 337 ++ drivers/gpu/drm/i915/display/intel_dsb.h | 50 +++ drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 10 + drivers/gpu/drm/i915/intel_device_info.h | 1 + 10 files changed, 457 insertions(+), 23 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 02/10] drm/i915/dsb: DSB context creation.
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some unwanted code. (Chris)
- Used i915_gem_object_create_internal instead of _shmem. (Chris)
- cmd_buf_tail removed and can be derived through vma object. (Chris)
v3: vma realeased if i915_gem_object_pin_map() failed. (Shashank)
v4: for simplification and based on current usage added single dsb
object in intel_crtc. (Shashank)
v5: seting NULL to cmd_buf moved outside of mutex in dsb-put(). (Shashank)
v6:
- refcount machanism added.
- Used atomic_add_return and atomic_dec_and_test instead of
atomic_inc and atomic_dec. (Jani)
Cc: Imre Deak
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dsb.c | 80 +++
drivers/gpu/drm/i915/display/intel_dsb.h | 31 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
5 files changed, 116 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 658b930d34a8..6313e7b4bd78 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -172,6 +172,7 @@ i915-y += \
display/intel_display_power.o \
display/intel_dpio_phy.o \
display/intel_dpll_mgr.o \
+ display/intel_dsb.o \
display/intel_fbc.o \
display/intel_fifo_underrun.o \
display/intel_frontbuffer.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d5cc4b810d9e..49c902b00484 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1033,6 +1033,9 @@ struct intel_crtc {
/* scalers available on this crtc */
int num_scalers;
+
+ /* per pipe DSB related info */
+ struct intel_dsb dsb;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
new file mode 100644
index ..2ed277670f15
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ */
+
+#include "i915_drv.h"
+#include "intel_display_types.h"
+
+#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+
+struct intel_dsb *
+intel_dsb_get(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct intel_dsb *dsb = >dsb;
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ intel_wakeref_t wakeref;
+
+ if (!HAS_DSB(i915))
+ return dsb;
+
+ if (atomic_add_return(1, >refcount) != 1)
+ return dsb;
+
+ dsb->id = DSB1;
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
+ if (IS_ERR(obj)) {
+ DRM_ERROR("Gem object creation failed\n");
+ goto err;
+ }
+
+ mutex_lock(>drm.struct_mutex);
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(vma)) {
+ DRM_ERROR("Vma creation failed\n");
+ i915_gem_object_put(obj);
+ atomic_dec(>refcount);
+ goto err;
+ }
+
+ dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+ if (IS_ERR(dsb->cmd_buf)) {
+ DRM_ERROR("Command buffer creation failed\n");
+ i915_vma_unpin_and_release(, 0);
+ dsb->cmd_buf = NULL;
+ atomic_dec(>refcount);
+ goto err;
+ }
+ dsb->vma = vma;
+
+err:
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ return dsb;
+}
+
+void intel_dsb_put(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ if (!HAS_DSB(i915))
+ return;
+
+ if (WARN_ON(atomic_read(>refcount) == 0))
+ return;
+
+ if (atomic_dec_and_test(>refcount)) {
+ mutex_lock(>drm.struct_mutex);
+ i915_gem_object_unpin_map(dsb->vma->obj);
+ i915_vma_unpin_and_release(>vma, 0);
+ mutex_unlock(>drm.struct_mutex);
+ dsb->cmd_buf = NULL;
+ }
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
new file mode 100644
index
[Intel-gfx] [PATCH v9 08/10] drm/i915/dsb: Enable gamma lut programming using DSB.
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
Currently enabled for 12-bit gamma LUT which is enabled by
default and later 8-bit/10-bit will be enabled in future
based on need.
v1: Initial version.
v2: Directly call dsb-api at callsites. (Jani)
v3:
- modified the code as per single dsb instance per crtc. (Shashank)
- Added dsb get/put call in platform specific load_lut hook. (Jani)
- removed dsb pointer from dev_priv. (Jani)
v4: simplified code by dropping ref-count implementation. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_color.c | 63 ++
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 318308dc136c..40af3fe2c3c9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -611,12 +611,13 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_dsb *dsb = intel_dsb_get(crtc);
enum pipe pipe = crtc->pipe;
/* Program the max register to clamp values > 1.0. */
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
/*
* Program the gc max 2 register to clamp values > 1.0.
@@ -624,10 +625,15 @@ static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
* from 3.0 to 7.0
*/
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 0),
+ 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 1),
+ 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 2),
+ 1 << 16);
}
+
+ intel_dsb_put(dsb);
}
static void ivb_load_luts(const struct intel_crtc_state *crtc_state)
@@ -787,22 +793,23 @@ icl_load_gcmax(const struct intel_crtc_state *crtc_state,
const struct drm_color_lut *color)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_dsb *dsb = intel_dsb_get(crtc);
enum pipe pipe = crtc->pipe;
/* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 0), color->red);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 1), color->green);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 2), color->blue);
+ intel_dsb_put(dsb);
}
static void
icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
const struct drm_color_lut *lut = blob->data;
+ struct intel_dsb *dsb = intel_dsb_get(crtc);
enum pipe pipe = crtc->pipe;
u32 i;
@@ -813,26 +820,29 @@ icl_program_gamma_superfine_segment(const struct
intel_crtc_state *crtc_state)
* Superfine segment has 9 entries, corresponding to values
* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 * 256).
*/
- I915_WRITE(PREC_PAL_MULTI_SEG_INDEX(pipe), PAL_PREC_AUTO_INCREMENT);
+ intel_dsb_reg_write(dsb, PREC_PAL_MULTI_SEG_INDEX(pipe),
+ PAL_PREC_AUTO_INCREMENT);
for (i = 0; i < 9; i++) {
const struct drm_color_lut *entry = [i];
- I915_WRITE(PREC_PAL_MULTI_SEG_DATA(pipe),
- ilk_lut_12p4_ldw(entry));
- I915_WRITE(PREC_PAL_MULTI_SEG_DATA(pipe),
- ilk_lut_12p4_udw(entry));
+ intel_dsb_indexed_reg_write(dsb, PREC_PAL_MULTI_SEG_DATA(pipe),
+
[Intel-gfx] [PATCH v9 05/10] drm/i915/dsb: Check DSB engine status.
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index faa853b08458..650b18a6 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -17,6 +17,15 @@
#define DSB_BYTE_EN_SHIFT 20
#define DSB_REG_VALUE_MASK 0xf
+static inline bool is_dsb_busy(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f8f52ae6cc6f..01952fae5348 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11684,4 +11684,11 @@ enum skl_power_gate {
#define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port) (1 << (tc_port))
+/* This register controls the Display State Buffer (DSB) engines. */
+#define _DSBSL_INSTANCE_BASE 0x70B00
+#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
+(pipe) * 0x1000 + (id) * 100)
+#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_STATUS (1 << 0)
+
#endif /* _I915_REG_H_ */
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 07/10] drm/i915/dsb: function to trigger workload execution of DSB.
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
v4: reset ins_start_offset after commit. (Jani)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 43
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 6fb4529689f1..f4c0b37683a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -224,3 +224,46 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ dsb->ins_start_offset = 0;
+ intel_dsb_disable_engine(dsb);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 2ae22f7309a7..c77ce76fd226 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -45,5 +45,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0ef2f3be5d30..22e3e610c649 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11688,6 +11688,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE 0x70B00
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 10/10] drm/i915/dsb: Documentation for DSB.
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
Documentation/gpu/i915.rst | 9
drivers/gpu/drm/i915/display/intel_dsb.c | 68
2 files changed, 77 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index e249ea7b0ec7..465779670fd4 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -246,6 +246,15 @@ Display PLLs
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h
:internal:
+Display State Buffer
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :doc: DSB
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :internal:
+
Memory Management and Command Submission
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index f4c0b37683a5..0a0a1536ac96 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,23 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/**
+ * DOC: DSB
+ *
+ * A DSB (Display State Buffer) is a queue of MMIO instructions in the memory
+ * which can be offloaded to DSB HW in Display Controller. DSB HW is a DMA
+ * engine that can be programmed to download the DSB from memory.
+ * It allows driver to batch submit display HW programming. This helps to
+ * reduce loading time and CPU activity, thereby making the context switch
+ * faster. DSB Support added from Gen12 Intel graphics based platform.
+ *
+ * DSB's can access only the pipe, plane, and transcoder Data Island Packet
+ * registers.
+ *
+ * DSB HW can support only register writes (both indexed and direct MMIO
+ * writes). There are no registers reads possible with DSB HW engine.
+ */
+
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
@@ -66,6 +83,17 @@ static inline bool intel_dsb_disable_engine(struct intel_dsb
*dsb)
return true;
}
+/**
+ * intel_dsb_get() - Allocate DSB context and return a DSB instance.
+ * @crtc: intel_crtc structure to get pipe info.
+ *
+ * This function provides handle of a DSB instance, for the further DSB
+ * operations.
+ *
+ * Returns: address of Intel_dsb instance requested for.
+ * Failure: Returns the same DSB instance, but without a command buffer.
+ */
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -116,6 +144,14 @@ intel_dsb_get(struct intel_crtc *crtc)
return dsb;
}
+/**
+ * intel_dsb_put() - To destroy DSB context.
+ * @dsb: intel_dsb structure.
+ *
+ * This function destroys the DSB context allocated by a dsb_get(), by
+ * unpinning and releasing the VMA object associated with it.
+ */
+
void intel_dsb_put(struct intel_dsb *dsb)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -138,6 +174,19 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+/**
+ * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
+ * increment register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for writing register-value pair in command
+ * buffer of DSB for auto-increment register. During command buffer overflow,
+ * a warning is thrown and rest all erroneous condition register programming
+ * is done through mmio write.
+ */
+
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val)
{
@@ -202,6 +251,18 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
i915_reg_t reg,
buf[dsb->free_pos] = 0;
}
+/**
+ * intel_dsb_reg_write() -Write to the DSB context for normal
+ * register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for writing register-value pair in command
+ * buffer of DSB. During command buffer overflow, a warning is thrown
+ * and rest all erroneous condition register programming is done
+ * through mmio write.
+ */
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -225,6 +286,13 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
i915_mmio_reg_offset(reg);
}
+/**
+ * intel_dsb_commit() - Trigger workload execution of DSB.
+ * @dsb: intel_dsb structure.
+ *
+ * This function is used to do actual write to hardware using DSB.
+ * On errors, fall back to MMIO. Also this function help to reset the context.
+ */
void intel_dsb_commit(struct intel_dsb *dsb)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
--
2.22.0
[Intel-gfx] [PATCH v9 09/10] drm/i915/dsb: Enable DSB for gen12.
Enabling DSB by setting 1 to has_dsb flag for gen12.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fe6941c8fc99..c2faa679658c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -787,7 +787,8 @@ static const struct intel_device_info
intel_elkhartlake_info = {
[TRANSCODER_DSI_0] = TRANSCODER_DSI0_OFFSET, \
[TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET, \
}, \
- .has_global_mocs = 1
+ .has_global_mocs = 1, \
+ .display.has_dsb = 1
static const struct intel_device_info intel_tigerlake_12_info = {
GEN12_FEATURES,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 06/10] drm/i915/dsb: functions to enable/disable DSB engine.
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
v2: POSTING_READ added after writing control register. (Shashank)
v3: cosmetic changes done. (Shashank)
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 40
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 650b18a6..6fb4529689f1 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -26,6 +26,46 @@ static inline bool is_dsb_busy(struct intel_dsb *dsb)
return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
}
+static inline bool intel_dsb_enable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl |= DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
+static inline bool intel_dsb_disable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl &= ~DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 01952fae5348..0ef2f3be5d30 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11689,6 +11689,7 @@ enum skl_power_gate {
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
#endif /* _I915_REG_H_ */
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 04/10] drm/i915/dsb: Indexed register write function for DSB.
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
v4: cosmetic changes done. (Shashank)
v5: reset ins_start_offset. (Jani)
v6: update ins_start_offset in inel_dsb_reg_write.
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 68
drivers/gpu/drm/i915/display/intel_dsb.h | 9
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index f94cd6dc98b6..faa853b08458 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -12,8 +12,10 @@
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -83,9 +85,74 @@ void intel_dsb_put(struct intel_dsb *dsb)
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
dsb->free_pos = 0;
+ dsb->ins_start_offset = 0;
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array. If
+* we are writing odd no of dwords, Zeros will be added in the end for
+* padding.
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -102,6 +169,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
return;
}
+ dsb->ins_start_offset = dsb->free_pos;
buf[dsb->free_pos++] = val;
buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 0686d67b34d5..2ae22f7309a7 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -30,11 +30,20 @@ struct intel_dsb {
* and help in calculating tail of command buffer.
*/
int free_pos;
+
+ /*
+* ins_start_offset will help to store start address of
[Intel-gfx] [PATCH v9 03/10] drm/i915/dsb: single register write function for DSB.
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
v3: set free_pos to zero in dsb-put() instead dsb-get() and
a cosmetic change. (Shashank)
v4: macro of indexed-write is moved. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 29
drivers/gpu/drm/i915/display/intel_dsb.h | 9
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2ed277670f15..f94cd6dc98b6 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,12 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_BYTE_EN0xF
+#define DSB_BYTE_EN_SHIFT 20
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -76,5 +82,28 @@ void intel_dsb_put(struct intel_dsb *dsb)
i915_vma_unpin_and_release(>vma, 0);
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
+ dsb->free_pos = 0;
+ }
+}
+
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
}
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
+ (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+ i915_mmio_reg_offset(reg);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 2c0f60c5f66c..0686d67b34d5 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -22,10 +24,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+* free_pos will point the first free entry position
+* and help in calculating tail of command buffer.
+*/
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
#endif
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support
== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/66989/ State : warning == Summary == $ dim checkpatch origin/drm-tip 32afcef2acff mdev: class id support 8efae9b60a78 mdev: introduce device specific ops -:309: ERROR:CODE_INDENT: code indent should use tabs where possible #309: FILE: include/linux/mdev.h:111: + const struct mdev_parent_ops *ops);$ -:309: WARNING:LEADING_SPACE: please, no spaces at the start of a line #309: FILE: include/linux/mdev.h:111: + const struct mdev_parent_ops *ops);$ -:314: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #314: new file mode 100644 total: 1 errors, 2 warnings, 0 checks, 410 lines checked 7bbada3ad14d mdev: introduce virtio device and its device ops -:50: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #50: new file mode 100644 -:55: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #55: FILE: include/linux/virtio_mdev.h:1: +/* -:70: WARNING:FUNCTION_ARGUMENTS: function definition argument 'void *' should also have an identifier name #70: FILE: include/linux/virtio_mdev.h:16: + irqreturn_t (*callback)(void *); -:175: ERROR:CODE_INDENT: code indent should use tabs where possible #175: FILE: include/linux/virtio_mdev.h:121: +/* Device ops */$ -:186: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #186: FILE: include/linux/virtio_mdev.h:132: + void (*get_config)(struct mdev_device *mdev, unsigned offset, -:187: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #187: FILE: include/linux/virtio_mdev.h:133: + void *buf, unsigned len); -:188: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #188: FILE: include/linux/virtio_mdev.h:134: + void (*set_config)(struct mdev_device *mdev, unsigned offset, -:189: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #189: FILE: include/linux/virtio_mdev.h:135: + const void *buf, unsigned len); total: 1 errors, 7 warnings, 0 checks, 168 lines checked 61e824bf250a virtio: introudce a mdev based transport -:44: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #44: new file mode 100644 -:84: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #84: FILE: drivers/vfio/mdev/virtio_mdev.c:36: + spinlock_t lock; -:111: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #111: FILE: drivers/vfio/mdev/virtio_mdev.c:63: +static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset, -:112: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #112: FILE: drivers/vfio/mdev/virtio_mdev.c:64: + void *buf, unsigned len) -:120: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #120: FILE: drivers/vfio/mdev/virtio_mdev.c:72: +static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset, -:121: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #121: FILE: drivers/vfio/mdev/virtio_mdev.c:73: + const void *buf, unsigned len) -:189: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #189: FILE: drivers/vfio/mdev/virtio_mdev.c:141: +virtio_mdev_setup_vq(struct virtio_device *vdev, unsigned index, -:268: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #268: FILE: drivers/vfio/mdev/virtio_mdev.c:220: + +} -:294: WARNING:RETURN_VOID: void function return statements are not generally useful #294: FILE: drivers/vfio/mdev/virtio_mdev.c:246: + return; +} -:296: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #296: FILE: drivers/vfio/mdev/virtio_mdev.c:248: +static int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs, -:308: WARNING:LINE_SPACING: Missing a blank line after declarations #308: FILE: drivers/vfio/mdev/virtio_mdev.c:260: + int i, err, queue_idx = 0; + vm_dev->vqs = kmalloc_array(queue_idx, sizeof(*vm_dev->vqs), -:429: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #429: FILE: drivers/vfio/mdev/virtio_mdev.c:381: + +} total: 0 errors, 9 warnings, 3 checks, 432 lines checked 17f868b5d9a4 vringh: fix copy direction of vringh_iov_push_kern() 822c68b1ca18 docs: Sample driver to demonstrate how to implement virtio-mdev framework -:26: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the config symbol fully #26: FILE: samples/Kconfig:134: +config SAMPLE_VIRTIO_MDEV_NET -:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #46: new file mode 100644 -:118: WARNING:FUNCTION_ARGUMENTS: function definition
[Intel-gfx] [PATCH] drm/i915: Mark contents as dirty on a write fault
Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
Flush pages on acquisition"), we no longer mark the contents as dirty on
a write fault. This has the issue of us then not marking the pages as
dirty on releasing the buffer, which means the contents are not written
out to the swap device (should we ever pick that buffer as a victim).
Notably, this is visible in the dumb buffer interface used for cursors.
Having updated the cursor contents via mmap, and swapped away, if the
shrinker should evict the old cursor, upon next reuse, the cursor would
be invisible.
E.g. echo 80 > /proc/sys/kernel/sysrq ; echo f > /proc/sysrq-trigger
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111541
Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Ville Syrjälä
Cc: # v5.2+
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 1748e63156a2..860b751c51f1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -319,7 +319,11 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
intel_wakeref_auto(>ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
- i915_vma_set_ggtt_write(vma);
+ if (write) {
+ GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ i915_vma_set_ggtt_write(vma);
+ obj->mm.dirty = true;
+ }
err_fence:
i915_vma_unpin_fence(vma);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Set up ILK/SNB csc unit properly for YCbCr output
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare the pipe csc for YCbCr output on ilk/snb. The main difference
> to IVB+ is the lack of explicit post offsets, and instead we must
> configure the CSC info RGB->YUV mode (which takes care of offsetting
> Cb/Cr properly) and enable the "black screen offset" bit to add the
> required offset to Y.
>
> And while at it throw some comments around the bit defines to
> document which platforms have which bits.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 25 +---
> --
> drivers/gpu/drm/i915/i915_reg.h| 10 -
> 2 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 736c42720daf..a902f7809840 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1213,6 +1213,21 @@ static u32 ilk_gamma_mode(const struct
> intel_crtc_state *crtc_state)
> return GAMMA_MODE_MODE_10BIT;
> }
>
> +static u32 ilk_csc_mode(const struct intel_crtc_state *crtc_state)
> +{
> + /*
> + * CSC comes after the LUT in RGB->YCbCr mode.
> + * RGB->YCbCr needs the limited range offsets added to
> + * the output. RGB limited range output is handled by
> + * the hw automagically elsewhere.
> + */
> + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
> + return CSC_BLACK_SCREEN_OFFSET;
> +
> + return CSC_MODE_YUV_TO_RGB |
> + CSC_POSITION_BEFORE_GAMMA;
> +}
> +
> static int ilk_color_check(struct intel_crtc_state *crtc_state)
> {
> int ret;
> @@ -1226,15 +1241,15 @@ static int ilk_color_check(struct
> intel_crtc_state *crtc_state)
> !crtc_state->c8_planes;
>
> /*
> - * We don't expose the ctm on ilk/snb currently,
> - * nor do we enable YCbCr output. Also RGB limited
> - * range output is handled by the hw automagically.
> + * We don't expose the ctm on ilk/snb currently, also RGB
> + * limited range output is handled by the hw automagically.
>*/
> - crtc_state->csc_enable = false;
> + crtc_state->csc_enable =
> + crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB;
>
> crtc_state->gamma_mode = ilk_gamma_mode(crtc_state);
>
> - crtc_state->csc_mode = 0;
> + crtc_state->csc_mode = ilk_csc_mode(crtc_state);
>
> ret = intel_color_add_affected_planes(crtc_state);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 58471312b8b2..33d535ae0944 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10106,11 +10106,11 @@ enum skl_power_gate {
> #define _PIPE_A_CSC_COEFF_BV 0x49024
>
> #define _PIPE_A_CSC_MODE 0x49028
> -#define ICL_CSC_ENABLE (1 << 31)
> -#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
> -#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
> -#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
> -#define CSC_MODE_YUV_TO_RGB (1 << 0)
> +#define ICL_CSC_ENABLE (1 << 31) /* icl+ */
> +#define ICL_OUTPUT_CSC_ENABLE (1 << 30) /* icl+ */
> +#define CSC_BLACK_SCREEN_OFFSET (1 << 2) /* ilk/snb */
> +#define CSC_POSITION_BEFORE_GAMMA (1 << 1) /* pre-glk */
> +#define CSC_MODE_YUV_TO_RGB (1 << 0) /* ilk/snb */
>
> #define _PIPE_A_CSC_PREOFF_HI0x49030
> #define _PIPE_A_CSC_PREOFF_ME0x49034
The changes look good to me.
Reviewed-by: Gwan-gyeong Mun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 04/10] drm/i915/dsb: Indexed register write function for DSB.
On Fri, 20 Sep 2019, Animesh Manna wrote:
> DSB can program large set of data through indexed register write
> (opcode 0x9) in one shot. DSB feature can be used for bulk register
> programming e.g. gamma lut programming, HDR meta data programming.
>
> v1: initial version.
> v2: simplified code by using ALIGN(). (Chris)
> v3: ascii table added as code comment. (Shashank)
> v4: cosmetic changes done. (Shashank)
> v5: reset ins_start_offset. (Jani)
> v6: update ins_start_offset in inel_dsb_reg_write.
>
> Cc: Shashank Sharma
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Reviewed-by: Shashank Sharma
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 68
> drivers/gpu/drm/i915/display/intel_dsb.h | 9
> 2 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index f94cd6dc98b6..faa853b08458 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -12,8 +12,10 @@
> /* DSB opcodes. */
> #define DSB_OPCODE_SHIFT 24
> #define DSB_OPCODE_MMIO_WRITE0x1
> +#define DSB_OPCODE_INDEXED_WRITE 0x9
> #define DSB_BYTE_EN 0xF
> #define DSB_BYTE_EN_SHIFT20
> +#define DSB_REG_VALUE_MASK 0xf
>
> struct intel_dsb *
> intel_dsb_get(struct intel_crtc *crtc)
> @@ -83,9 +85,74 @@ void intel_dsb_put(struct intel_dsb *dsb)
> mutex_unlock(>drm.struct_mutex);
> dsb->cmd_buf = NULL;
> dsb->free_pos = 0;
> + dsb->ins_start_offset = 0;
> }
> }
>
> +void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
> + u32 val)
> +{
> + struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + u32 *buf = dsb->cmd_buf;
> + u32 reg_val;
> +
> + if (!buf) {
> + I915_WRITE(reg, val);
> + return;
> + }
> +
> + if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
> + DRM_DEBUG_KMS("DSB buffer overflow\n");
> + return;
> + }
> +
> + /*
> + * For example the buffer will look like below for 3 dwords for auto
> + * increment register:
> + * ++
> + * | size = 3 | offset &| value1 | value2 | value3 | zero |
> + * | | opcode |||||
> + * ++
> + * + + +++++
> + * 0 4 812 16 20 24
> + * Byte
> + *
> + * As every instruction is 8 byte aligned the index of dsb instruction
> + * will start always from even number while dealing with u32 array. If
> + * we are writing odd no of dwords, Zeros will be added in the end for
> + * padding.
> + */
> + reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
> + if (reg_val != i915_mmio_reg_offset(reg)) {
> + /* Every instruction should be 8 byte aligned. */
> + dsb->free_pos = ALIGN(dsb->free_pos, 2);
> +
> + dsb->ins_start_offset = dsb->free_pos;
> +
> + /* Update the size. */
> + buf[dsb->free_pos++] = 1;
> +
> + /* Update the opcode and reg. */
> + buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
> + DSB_OPCODE_SHIFT) |
> + i915_mmio_reg_offset(reg);
> +
> + /* Update the value. */
> + buf[dsb->free_pos++] = val;
> + } else {
> + /* Update the new value. */
> + buf[dsb->free_pos++] = val;
> +
> + /* Update the size. */
> + buf[dsb->ins_start_offset]++;
> + }
> +
> + /* if number of data words is odd, then the last dword should be 0.*/
> + if (dsb->free_pos & 0x1)
> + buf[dsb->free_pos] = 0;
> +}
> +
> void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
> {
> struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
> @@ -102,6 +169,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
> i915_reg_t reg, u32 val)
> return;
> }
>
> + dsb->ins_start_offset = dsb->free_pos;
Okay, I'm being a pedant, but that's kind of part of the job
description, I'm afraid.
What if:
intel_dsb_get()
intel_dsb_reg_write(dsb, FOO, 0);
intel_dsb_indexed_reg_write(dsb, FOO, 0);
intel_dsb_commit()
intel_dsb_put()
BR,
Jani.
> buf[dsb->free_pos++] = val;
> buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
> (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
> diff --git
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Add PIPECONF YCbCr 4:4:4 programming for ILK-IVB
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:05 +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On ILK-IVB the pipe colorspace is configured via PIPECONF
> > (as opposed to PIPEMISC in BDW+). Let's configure+readout
> > that stuff correctly.
> >
> > Enablling YCbCr 4:4:4 output will now be a simple matter of
> Typo: Enablling -> Enabling
> > setting crtc_state->output_format appropriately in the encoder
> > .compute_config(). However, when we do that we must be
> > aware of the fact that YCbCr DP output doesn't seem to work
> > on ILK (resulting image is totally garbled), but on SNB+
> > it works fine. However HDMI YCbCr output does work correctly
> > even on ILK.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 21
> > +++-
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index bd3ff96c1618..8e98715cd63b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -9406,9 +9406,19 @@ static void ironlake_set_pipeconf(const
> > struct
> > intel_crtc_state *crtc_state)
> > else
> > val |= PIPECONF_PROGRESSIVE;
> >
> > + /*
> > +* This would end up with an odd purple hue over
> > +* the entire display. Make sure we don't do it.
> > +*/
> > + WARN_ON(crtc_state->limited_color_range &&
> > + crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
> > +
> > if (crtc_state->limited_color_range)
> > val |= PIPECONF_COLOR_RANGE_SELECT;
> >
> > + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
> > + val |= PIPECONF_OUTPUT_COLORSPACE_YUV709;
> > +
> > val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> >
> > I915_WRITE(PIPECONF(pipe), val);
> > @@ -9945,7 +9955,6 @@ static bool ironlake_get_pipe_config(struct
> > intel_crtc *crtc,
> > if (!wakeref)
> > return false;
> >
> > - pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> > pipe_config->shared_dpll = NULL;
> >
> > @@ -9974,6 +9983,16 @@ static bool ironlake_get_pipe_config(struct
> > intel_crtc *crtc,
> > if (tmp & PIPECONF_COLOR_RANGE_SELECT)
> > pipe_config->limited_color_range = true;
> >
> > + switch (tmp & PIPECONF_OUTPUT_COLORSPACE_MASK) {
> > + case PIPECONF_OUTPUT_COLORSPACE_YUV601:
> > + case PIPECONF_OUTPUT_COLORSPACE_YUV709:
> > + pipe_config->output_format =
> > INTEL_OUTPUT_FORMAT_YCBCR444;
> > + break;
> > + default:
> > + pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > + break;
> > + }
> > +
> > pipe_config->gamma_mode = (tmp & PIPECONF_GAMMA_MODE_MASK_ILK)
> > PIPECONF_GAMMA_MODE_SHIFT;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 33d535ae0944..3d33a1e03a45 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5712,6 +5712,10 @@ enum {
> > #define PIPECONF_CXSR_DOWNCLOCK (1 << 16)
> > #define PIPECONF_EDP_RR_MODE_SWITCH_VLV (1 << 14)
> > #define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
> > +#define PIPECONF_OUTPUT_COLORSPACE_MASK (3 << 11) /* ilk-ivb */
> > +#define PIPECONF_OUTPUT_COLORSPACE_RGB (0 << 11) /* ilk-ivb */
> > +#define PIPECONF_OUTPUT_COLORSPACE_YUV601(1 << 11) /*
> > ilk-ivb */
> > +#define PIPECONF_OUTPUT_COLORSPACE_YUV709(2 << 11) /*
> > ilk-ivb */
> > #define PIPECONF_OUTPUT_COLORSPACE_YUV_HSW (1 << 11) /*
> > hsw only
> > */
> > #define PIPECONF_BPC_MASK(0x7 << 5)
> > #define PIPECONF_8BPC(0 << 5)
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: Add PIPECONF YCbCr 4:4:4 programming for HSW
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:03 +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On HSW the pipe colorspace is configured via PIPECONF
> > (as opposed to PIPEMISC in BDW+). Let's configure+readout
> > that stuff correctly.
> >
> > Enablling YCbCr 4:4:4 output will now be a simple matter of
> Typo: Enablling -> Enabling
> > setting crtc_state->output_format appropriately in the encoder
> > .compute_config().
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 13 -
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 1dd1aa29a649..bd3ff96c1618 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -9430,6 +9430,10 @@ static void haswell_set_pipeconf(const
> > struct
> > intel_crtc_state *crtc_state)
> > else
> > val |= PIPECONF_PROGRESSIVE;
> >
> > + if (IS_HASWELL(dev_priv) &&
> > + crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
> > + val |= PIPECONF_OUTPUT_COLORSPACE_YUV_HSW;
> > +
> > I915_WRITE(PIPECONF(cpu_transcoder), val);
> > POSTING_READ(PIPECONF(cpu_transcoder));
> > }
> > @@ -10423,7 +10427,14 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> >
> > intel_get_pipe_src_size(crtc, pipe_config);
> >
> > - if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
> > + if (IS_HASWELL(dev_priv)) {
> > + u32 tmp = I915_READ(PIPECONF(pipe_config-
> > > cpu_transcoder));
> > +
> > + if (tmp & PIPECONF_OUTPUT_COLORSPACE_YUV_HSW)
> > + pipe_config->output_format =
> > INTEL_OUTPUT_FORMAT_YCBCR444;
> > + else
> > + pipe_config->output_format =
> > INTEL_OUTPUT_FORMAT_RGB;
> > + } else {
> > pipe_config->output_format =
> > bdw_get_pipemisc_output_format(crtc);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 66f7f417231f..58471312b8b2 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5712,6 +5712,7 @@ enum {
> > #define PIPECONF_CXSR_DOWNCLOCK (1 << 16)
> > #define PIPECONF_EDP_RR_MODE_SWITCH_VLV (1 << 14)
> > #define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
> > +#define PIPECONF_OUTPUT_COLORSPACE_YUV_HSW (1 << 11) /*
> > hsw only
> > */
> > #define PIPECONF_BPC_MASK(0x7 << 5)
> > #define PIPECONF_8BPC(0 << 5)
> > #define PIPECONF_10BPC (1 << 5)
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark contents as dirty on a write fault
Quoting Chris Wilson (2019-09-20 13:18:21)
> Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
> Flush pages on acquisition"), we no longer mark the contents as dirty on
> a write fault. This has the issue of us then not marking the pages as
> dirty on releasing the buffer, which means the contents are not written
> out to the swap device (should we ever pick that buffer as a victim).
> Notably, this is visible in the dumb buffer interface used for cursors.
> Having updated the cursor contents via mmap, and swapped away, if the
> shrinker should evict the old cursor, upon next reuse, the cursor would
> be invisible.
Hmm, I think the dumb interface may be missing a few steps around the
place to ensure the contents are flushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
On 20/09/2019 09:36, Chris Wilson wrote:
Force bonded requests to run on distinct engines so that they cannot be
shuffled onto the same engine where timeslicing will reverse the order.
A bonded request will often wait on a semaphore signaled by its master,
creating an implicit dependency -- if we ignore that implicit dependency
and allow the bonded request to run on the same engine and before its
master, we will cause a GPU hang.
We can prevent this inversion by restricting which engines we allow
ourselves to jump to upon preemption, i.e. baking in the arrangement
established at first execution. (We should also consider capturing the
implicit dependency using i915_sched_add_dependency(), but first we need
to think about the constraints that requires on the execution/retirement
ordering.)
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a99166a2d2eb..7920649e4d87 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3755,18 +3755,21 @@ static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
+ intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
bond = virtual_find_bond(ve, to_request(signal)->engine);
- if (bond) {
- intel_engine_mask_t old, new, cmp;
+ if (!bond)
+ return;
- cmp = READ_ONCE(rq->execution_mask);
- do {
- old = cmp;
- new = cmp & bond->sibling_mask;
- } while ((cmp = cmpxchg(>execution_mask, old, new)) != old);
- }
+ /* Restrict the bonded request to run on only the slaved engines */
+ allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
Hmm.. isn't it a miss on the uapi level that we allow master to be
mentioned in the list of bonds? That's the only scenario where this line
does something I think. So should we just forbid this setup on the uapi
level?
+ exec = READ_ONCE(rq->execution_mask);
+ while (!try_cmpxchg(>execution_mask, , exec & allowed))
+ ;
+
+ /* Prevent the master from being re-run on the slaved engines */
+ to_request(signal)->execution_mask &= ~allowed;
This sounds unfortunate for future scheduling. There shouldn't be a
fundamental reason why next execution for the master couldn't be on an
engine which can also be a slave. So if we have:
master
.veng=vcs0,vcs1
slave
.veng=vcs0,vcs1
.bond(master=vcs0, mask=vcs1)
.bond(master=vcs1, mask=vcs0)
This should be allowed setup but with this change it would fix the
master to only be one of the options.
Is the real problem that after preemption for timeslicing and subsequent
re-submit we miss some hooks to re-evaluate the bonded relationship?
I guess looking would be hard to do any peeking from one submission
tasklet to another (different engines) to check if one of the pair is
already executing again and so to pick the other end correctly?
I think in practical terms for media this work since they are not
setting it up like my sketch shows. So it could be just fine in practice
for current users.
Regards,
Tvrtko
}
struct intel_context *
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent bonded requests from overtaking each other on preemption
== Series Details == Series: drm/i915: Prevent bonded requests from overtaking each other on preemption URL : https://patchwork.freedesktop.org/series/66990/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14471 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/ Known issues Here are the changes found in Patchwork_14471 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@legacy-render: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] / [fdo#111381]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_self_import@basic-with_fd_dup: - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14471 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14471: 7885378114aefe9decb3c6ea2f10b575ed807d98 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7885378114ae drm/i915: Prevent bonded requests from overtaking each other on preemption == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add memory type decoding for bandwidth checking
On Fri, Sep 20, 2019 at 03:29:06PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> > The memory type values have changed in TGL, so we need to translate them
> > differently than ICL.
> >
> > BSpec: 53998
> >
> > Cc: Ville Syrjälä
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: James Ausmus
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 59 ++---
> > 1 file changed, 43 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 688858ebe4d0..11224d9a6752 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -35,22 +35,49 @@ static int icl_pcode_read_mem_global_info(struct
> > drm_i915_private *dev_priv,
> > if (ret)
> > return ret;
> >
> > - switch (val & 0xf) {
> > - case 0:
> > - qi->dram_type = INTEL_DRAM_DDR4;
> > - break;
> > - case 1:
> > - qi->dram_type = INTEL_DRAM_DDR3;
> > - break;
> > - case 2:
> > - qi->dram_type = INTEL_DRAM_LPDDR3;
> > - break;
> > - case 3:
> > - qi->dram_type = INTEL_DRAM_LPDDR3;
>
> This should be LPDDR4 actually. Doesn't really matter but would be nice
> to fix as well.
Either my git send-email config or the ML seems to be eating my original
patch mail, and it's not hitting the list, patchwork, or CI, so will
have to send a v2 anyway and I will fix this up in that.
>
> > - break;
> > - default:
> > - MISSING_CASE(val & 0xf);
> > - break;
> > + if (IS_GEN(dev_priv, 12)) {
> > + switch (val & 0xf) {
> > + case 0:
> > + qi->dram_type = INTEL_DRAM_DDR4;
> > + break;
> > + case 3:
> > + qi->dram_type = INTEL_DRAM_LPDDR4;
> > + break;
> > + case 4:
> > + qi->dram_type = INTEL_DRAM_DDR3;
> > + break;
> > + case 5:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + case 1:
> > + case 2:
> > + /* Unimplemented */
>
> Seems pointless to list these.
Will drop in v2.
>
> The numbers match bspec. Unfortunatley I can't get tgl
> configdb to cooperate so can't double check against the
> MC register definition.
>
> Reviewed-by: Ville Syrjälä
Thanks!
-James
>
> > + /* fall through */
> > + default:
> > + MISSING_CASE(val & 0xf);
> > + break;
> > + }
> > + } else if (IS_GEN(dev_priv, 11)) {
> > + switch (val & 0xf) {
> > + case 0:
> > + qi->dram_type = INTEL_DRAM_DDR4;
> > + break;
> > + case 1:
> > + qi->dram_type = INTEL_DRAM_DDR3;
> > + break;
> > + case 2:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + case 3:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + default:
> > + MISSING_CASE(val & 0xf);
> > + break;
> > + }
> > + } else {
> > + MISSING_CASE(INTEL_GEN(dev_priv));
> > + qi->dram_type = INTEL_DRAM_LPDDR3; /* Conservative default */
> > }
> >
> > qi->num_channels = (val & 0xf0) >> 4;
> > --
> > 2.22.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
On 20/09/2019 13:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
On 20/09/2019 09:36, Chris Wilson wrote:
Force bonded requests to run on distinct engines so that they cannot be
shuffled onto the same engine where timeslicing will reverse the order.
A bonded request will often wait on a semaphore signaled by its master,
creating an implicit dependency -- if we ignore that implicit dependency
and allow the bonded request to run on the same engine and before its
master, we will cause a GPU hang.
We can prevent this inversion by restricting which engines we allow
ourselves to jump to upon preemption, i.e. baking in the arrangement
established at first execution. (We should also consider capturing the
implicit dependency using i915_sched_add_dependency(), but first we need
to think about the constraints that requires on the execution/retirement
ordering.)
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a99166a2d2eb..7920649e4d87 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3755,18 +3755,21 @@ static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
+ intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
bond = virtual_find_bond(ve, to_request(signal)->engine);
- if (bond) {
- intel_engine_mask_t old, new, cmp;
+ if (!bond)
+ return;
- cmp = READ_ONCE(rq->execution_mask);
- do {
- old = cmp;
- new = cmp & bond->sibling_mask;
- } while ((cmp = cmpxchg(>execution_mask, old, new)) != old);
- }
+ /* Restrict the bonded request to run on only the slaved engines */
+ allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
Hmm.. isn't it a miss on the uapi level that we allow master to be
mentioned in the list of bonds? That's the only scenario where this line
does something I think. So should we just forbid this setup on the uapi
level?
That's just a lot of digging!
It's simple, in set_engines__bond in the bonds loop we just do "if
(master == bond) oh_no_you_wont". Am I missing something?
+ exec = READ_ONCE(rq->execution_mask);
+ while (!try_cmpxchg(>execution_mask, , exec & allowed))
+ ;
+
+ /* Prevent the master from being re-run on the slaved engines */
+ to_request(signal)->execution_mask &= ~allowed;
This sounds unfortunate for future scheduling. There shouldn't be a
fundamental reason why next execution for the master couldn't be on an
engine which can also be a slave. So if we have:
Note though that we do not reset the execution_mask at any point :)
That's actually harder to do than it sounds, as after the bonded
execution, they are no longer linked. :|
master
.veng=vcs0,vcs1
slave
.veng=vcs0,vcs1
.bond(master=vcs0, mask=vcs1)
.bond(master=vcs1, mask=vcs0)
This should be allowed setup but with this change it would fix the
master to only be one of the options.
It would fix it to the first one it selected and executed on. It can
still pick either vcs0 or vcs1 and the slave would then be on vcs1 or
vcs0 respectively.
Is the real problem that after preemption for timeslicing and subsequent
re-submit we miss some hooks to re-evaluate the bonded relationship?
That doesn't exist, yes. But it's more than that, as we don't have the
notion of global preemption -- we don't evaluate between engines whether
or not there are cross dependencies.
I guess looking would be hard to do any peeking from one submission
tasklet to another (different engines) to check if one of the pair is
already executing again and so to pick the other end correctly?
Hard indeed. I would throw a flag onto the request that says if you
preempt me, stop the world (intel_engine_mask_t perhaps). Even that
requires some tricks we don't yet have. But we can't touch the other
engines within the tasklet unless we can come up with a lockless
strategy (hence the strategy of punting to a supreme thread with
oversight of all engines, gah.)
I think in practical terms for media this work since they are not
setting it up like my sketch shows. So it could be just fine in practice
for current users.
I think your example works better than you think -- we just end up
concreted into our first choice and can't jump around hogs in the
system. (For example, to prove the above, we can launch two such tasks,
with a spinner as both masters and the system should get stuck on both
spinners.)
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details == Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2. URL : https://patchwork.freedesktop.org/series/66998/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dp: Fix dsc bpp calculations, v2. Okay! Commit: HAX drm/i915: Disable FEC entirely for now Okay! Commit: drm/i915: Prepare to split crtc state in uapi and hw state Okay! Commit: drm/i915: Handle a few more cases for hw/sw split Okay! Commit: drm/i915: Complete sw/hw split Okay! Commit: drm/i915: Get rid of crtc_state->fb_changed Okay! Commit: drm/i915: Remove begin/finish_crtc_commit. Okay! Commit: drm/i915: Rename planar linked plane variables Okay! Commit: drm/i915: Do not add all planes when checking scalers on glk+ Okay! Commit: drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid() Okay! Commit: drm/i915: Try to make bigjoiner work in atomic check. Okay! Commit: drm/i915: Enable big joiner support in enable and disable sequences. Okay! Commit: drm/i915: Make hardware readout work on i915. Okay! Commit: drm/i915: Prepare update_slave() for bigjoiner plane updates Okay! Commit: drm/i915: Link planes in a bigjoiner configuration. Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] video/hdmi: Fix AVI bar unpack
On Thu, Sep 19, 2019 at 04:28:53PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The bar values are little endian, not big endian. The pack
> function did it right but the unpack got it wrong. Fix it.
>
> Cc: sta...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Martin Bugge
> Cc: Hans Verkuil
> Cc: Thierry Reding
> Cc: Mauro Carvalho Chehab
> Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
> InfoFrames")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details ==
Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
URL : https://patchwork.freedesktop.org/series/66998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14476
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/
Known issues
Here are the changes found in Patchwork_14476 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724] /
[fdo#111214])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 45)
--
Additional (1): fi-hsw-4770r
Missing(10): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-glk-dsi
fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14476
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14476: 4fc8d6917d9641566f066833c6cd4a367858864a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4fc8d6917d96 HAX to make it work on the icelake test system
6841b8e381a7 drm/i915: Add debugfs dumping for bigjoiner.
2f481b21d19e drm/i915: Make sure watermarks work correctly with bigjoiner as
well.
00bf77afbf1c drm/i915: Make prepare_plane_fb() work with bigjoiner planes
b38045c74b32 drm/i915: Prepare atomic plane check for bigjoiner planes
fda4e645a05a drm/i915: Disable FBC in bigjoiner configuration.
a4c555a8c16c drm/i915: Add intel_update_bigjoiner handling.
dfcb59743ad5 drm/i915: Program planes in bigjoiner mode.
5c48f75472bd drm/i915: Link planes in a bigjoiner configuration.
87f053dd9d78 drm/i915: Prepare update_slave() for bigjoiner plane updates
0334bd232823 drm/i915: Make hardware readout work on i915.
fe1d38cc6ac9 drm/i915: Enable big joiner support in enable and disable
sequences.
02ae546be7ff drm/i915: Try to make bigjoiner work in atomic check.
c5ac35a82acd drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
11b08875cb14 drm/i915: Do not add all planes when checking scalers on glk+
35e0e945926a drm/i915: Rename planar linked plane variables
1997dbaaa507 drm/i915: Remove begin/finish_crtc_commit.
89bdbc955927 drm/i915: Get rid of crtc_state->fb_changed
fb10f9c4dae1 drm/i915: Complete sw/hw split
8fa117d4a277 drm/i915: Handle a few more cases for hw/sw split
2bb73b0ec47e drm/i915: Prepare to split crtc
[Intel-gfx] ✓ Fi.CI.BAT: success for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14477 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/ Known issues Here are the changes found in Patchwork_14477 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@bad-open: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_flink_ba...@bad-open.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u3/igt@gem_flink_ba...@bad-open.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14477 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14477: 89ca6c89252aa3e8b3e3fe65ce0d39cf953e642b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 89ca6c89252a drm/i915/dsb: Documentation for DSB. 6ccd2217aa11 drm/i915/dsb: Enable DSB for gen12. dc74e0b1bce3 drm/i915/dsb: Enable gamma lut programming using DSB. f3f9d6a4f641 drm/i915/dsb: function to trigger workload execution of DSB. c6d05e53a15d drm/i915/dsb: functions to enable/disable DSB engine. 82006824a268 drm/i915/dsb: Check DSB engine status. 6cebb40b0c3d drm/i915/dsb: Indexed register write function for DSB. 32156cd99f53 drm/i915/dsb: single register write function for DSB. 5a60554c2d5d drm/i915/dsb: DSB context creation. 396d115d8cc6 drm/i915/dsb: feature flag added for display state buffer. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate
On 02/09/2019 05:02, Chris Wilson wrote:
Since we cannot allocate underneath the vm->mutex (it is used in the
direct-reclaim paths), we need to shift the allocations off into a
mutexless worker with fence recursion prevention. To know when we need
this protection, we mark up the address spaces that do allocate before
insertion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9095f017162e..56d27cf09a3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
goto err_free_pd;
}
+ ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND;
So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that
works from these call sites? Should it be called bind_alloc*s*?
bind_allocates? Or be a boolean which is converted to a trick flag in
i915_vma_bind where a comment can be put explaining the trick?
Regards,
Tvrtko
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
@@ -1947,6 +1948,7 @@ static struct i915_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
ppgtt_init(>base, >gt);
ppgtt->base.vm.top = 1;
+ ppgtt->base.vm.bind_alloc = I915_VMA_LOCAL_BIND;
ppgtt->base.vm.allocate_va_range = gen6_alloc_va_range;
ppgtt->base.vm.clear_range = gen6_ppgtt_clear_range;
ppgtt->base.vm.insert_entries = gen6_ppgtt_insert_entries;
@@ -2578,6 +2580,7 @@ static int init_aliasing_ppgtt(struct i915_ggtt *ggtt)
goto err_ppgtt;
ggtt->alias = ppgtt;
+ ggtt->vm.bind_alloc |= ppgtt->vm.bind_alloc;
GEM_BUG_ON(ggtt->vm.vma_ops.bind_vma != ggtt_bind_vma);
ggtt->vm.vma_ops.bind_vma = aliasing_gtt_bind_vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 57d27898639a..007bdaf4ba00 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -305,6 +305,8 @@ struct i915_address_space {
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
+ unsigned int bind_alloc;
+
bool closed;
struct mutex mutex; /* protects vma and our lists */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Mark contents as dirty on a write fault
== Series Details ==
Series: drm/i915: Mark contents as dirty on a write fault
URL : https://patchwork.freedesktop.org/series/67000/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14478
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14478 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14478, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14478:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
Known issues
Here are the changes found in Patchwork_14478 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u3/igt@gem_mmap_...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 46)
--
Additional (1): fi-hsw-4770r
Missing(9): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14478
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14478: 9da082235386c02590d12100f6f40eb8002b5019 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9da082235386 drm/i915: Mark contents as dirty on a write fault
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
>
> On 20/09/2019 09:36, Chris Wilson wrote:
> > Force bonded requests to run on distinct engines so that they cannot be
> > shuffled onto the same engine where timeslicing will reverse the order.
> > A bonded request will often wait on a semaphore signaled by its master,
> > creating an implicit dependency -- if we ignore that implicit dependency
> > and allow the bonded request to run on the same engine and before its
> > master, we will cause a GPU hang.
> >
> > We can prevent this inversion by restricting which engines we allow
> > ourselves to jump to upon preemption, i.e. baking in the arrangement
> > established at first execution. (We should also consider capturing the
> > implicit dependency using i915_sched_add_dependency(), but first we need
> > to think about the constraints that requires on the execution/retirement
> > ordering.)
> >
> > Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> > References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
> > 1 file changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index a99166a2d2eb..7920649e4d87 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -3755,18 +3755,21 @@ static void
> > virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> > {
> > struct virtual_engine *ve = to_virtual_engine(rq->engine);
> > + intel_engine_mask_t allowed, exec;
> > struct ve_bond *bond;
> >
> > bond = virtual_find_bond(ve, to_request(signal)->engine);
> > - if (bond) {
> > - intel_engine_mask_t old, new, cmp;
> > + if (!bond)
> > + return;
> >
> > - cmp = READ_ONCE(rq->execution_mask);
> > - do {
> > - old = cmp;
> > - new = cmp & bond->sibling_mask;
> > - } while ((cmp = cmpxchg(>execution_mask, old, new)) !=
> > old);
> > - }
> > + /* Restrict the bonded request to run on only the slaved engines */
> > + allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
>
> Hmm.. isn't it a miss on the uapi level that we allow master to be
> mentioned in the list of bonds? That's the only scenario where this line
> does something I think. So should we just forbid this setup on the uapi
> level?
That's just a lot of digging!
> > + exec = READ_ONCE(rq->execution_mask);
> > + while (!try_cmpxchg(>execution_mask, , exec & allowed))
> > + ;
> > +
> > + /* Prevent the master from being re-run on the slaved engines */
> > + to_request(signal)->execution_mask &= ~allowed;
>
> This sounds unfortunate for future scheduling. There shouldn't be a
> fundamental reason why next execution for the master couldn't be on an
> engine which can also be a slave. So if we have:
Note though that we do not reset the execution_mask at any point :)
That's actually harder to do than it sounds, as after the bonded
execution, they are no longer linked. :|
> master
>.veng=vcs0,vcs1
> slave
>.veng=vcs0,vcs1
>.bond(master=vcs0, mask=vcs1)
>.bond(master=vcs1, mask=vcs0)
>
> This should be allowed setup but with this change it would fix the
> master to only be one of the options.
It would fix it to the first one it selected and executed on. It can
still pick either vcs0 or vcs1 and the slave would then be on vcs1 or
vcs0 respectively.
> Is the real problem that after preemption for timeslicing and subsequent
> re-submit we miss some hooks to re-evaluate the bonded relationship?
That doesn't exist, yes. But it's more than that, as we don't have the
notion of global preemption -- we don't evaluate between engines whether
or not there are cross dependencies.
> I guess looking would be hard to do any peeking from one submission
> tasklet to another (different engines) to check if one of the pair is
> already executing again and so to pick the other end correctly?
Hard indeed. I would throw a flag onto the request that says if you
preempt me, stop the world (intel_engine_mask_t perhaps). Even that
requires some tricks we don't yet have. But we can't touch the other
engines within the tasklet unless we can come up with a lockless
strategy (hence the strategy of punting to a supreme thread with
oversight of all engines, gah.)
> I think in practical terms for media this work since they are not
> setting it up like my sketch shows. So it could be just fine in practice
> for current users.
I think your example works better than you think -- we just end up
concreted into our first choice and can't jump around hogs in the
system. (For example, to prove the above, we can launch two such
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC
== Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC URL : https://patchwork.freedesktop.org/series/66955/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14466_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14466_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14466_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14466_full: ### IGT changes ### Possible regressions * igt@i915_suspend@debugfs-reader: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb5/igt@i915_susp...@debugfs-reader.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb4/igt@i915_susp...@debugfs-reader.html Known issues Here are the changes found in Patchwork_14466_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb7/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-skl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl10/igt@i915_pm_rc6_reside...@rc6-accuracy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#109507]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl6/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl4/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([fdo#103540]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-hsw2/igt@kms_f...@flip-vs-suspend-interruptible.html *
Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> 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.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 58 +++--
> drivers/gpu/drm/i915/i915_reg.h | 3 ++
> 2 files changed, 58 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index cd58e47ab7b2..7653cbdb0ee4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -90,6 +90,26 @@ static int icl_pcode_read_qgv_point_info(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +static 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)
> {
> @@ -354,7 +374,9 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> unsigned int data_rate, max_data_rate;
> unsigned int num_active_planes;
> struct intel_crtc *crtc;
> - int i;
> + int i, ret;
> + struct intel_qgv_info qi = {};
> + u32 points_mask = 0;
>
> /* FIXME earlier gens need some checks too */
> if (INTEL_GEN(dev_priv) < 11)
> @@ -398,10 +420,40 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> 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 = DIV_ROUND_UP(data_rate, 1000);
>
> + ret = icl_get_qgv_points(dev_priv, );
> + if (ret < 0) {
> + goto fallback;
If we don't have that we don't have any idea about bw limits. So
probably just return 0 here.
> + }
> +
> + for (i = 0; i < qi.num_points; i++) {
> + max_data_rate = icl_max_bw(dev_priv, num_active_planes, i);
> + if (max_data_rate < data_rate) {
> + DRM_DEBUG_KMS("QGV point %d: max bw %d required %d
> restricted\n",
> + i, max_data_rate, data_rate);
> + points_mask |= 1 << i;
I think just marking the accepted levels in the mask would make things
simpler...
> + } else
> + DRM_DEBUG_KMS("QGV point %d: max bw %d required %d
> unrestricted\n",
> + i, max_data_rate, data_rate);
> + }
> +
> + if (points_mask >= ((1 << qi.num_points) - 1)) {
... eg. this can then just be 'if (points_mask == 0)'
> + DRM_DEBUG_KMS("Could not find any suitable QGV points\n");
> + return -EINVAL;
> + }
> +
> + ret = icl_pcode_restrict_qgv_points(dev_priv, points_mask);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n",
> ret);
> + goto fallback;
Seems like dead code to me.
We'll need to account for the SAGV yes/no in here as well. That is, if
SAGV is off due to watermarks we'll need to restrict things to the
highest QGV point only. Also using both the QGV point restriction
pcode command and the legacy SAGV pcode command at the same time sounds
rather risky to me. I suspect pcode might not expect that. So we need
to rework this on a slightly bigger scale.
> + }
> +
> + return 0;
> +
> +fallback:
> + max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
> +
> if (data_rate > max_data_rate) {
> DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available %d MB/s
> (%d active planes)\n",
> data_rate, max_data_rate, num_active_planes);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bf37ecebc82f..fe327fee8781 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8845,6 +8845,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)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details ==
Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
URL : https://patchwork.freedesktop.org/series/66998/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a06a0350a83 drm/i915/dp: Fix dsc bpp calculations, v2.
30142b729b5c HAX drm/i915: Disable FEC entirely for now
-:14: WARNING:BAD_SIGN_OFF: 'Not-signed-off-by:' is the preferred signature form
#14:
Not-Signed-off-by: Maarten Lankhorst
-:40: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 19 lines checked
2bb73b0ec47e drm/i915: Prepare to split crtc state in uapi and hw state
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
- crtc, *_changed flags, event, commit, state, mode_blob,
(plane/connector/encoder)_mask.
-:2112: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#2112: FILE: drivers/gpu/drm/i915/display/intel_display.c:11201:
+ crtc_state->uapi.active = crtc_state->uapi.enable = true;
-:2810: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#2810: FILE: drivers/gpu/drm/i915/display/intel_display.c:16692:
+ crtc_state->hw.active = crtc_state->hw.enable =
-:3965: ERROR:CODE_INDENT: code indent should use tabs where possible
#3965: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211:
+^I^I^I^I new_crtc_state->uapi.event);$
-:3965: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#3965: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211:
+ drm_crtc_arm_vblank_event(>base,
+ new_crtc_state->uapi.event);
total: 1 errors, 1 warnings, 3 checks, 4348 lines checked
8fa117d4a277 drm/i915: Handle a few more cases for hw/sw split
fb10f9c4dae1 drm/i915: Complete sw/hw split
89bdbc955927 drm/i915: Get rid of crtc_state->fb_changed
1997dbaaa507 drm/i915: Remove begin/finish_crtc_commit.
35e0e945926a drm/i915: Rename planar linked plane variables
11b08875cb14 drm/i915: Do not add all planes when checking scalers on glk+
c5ac35a82acd drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
02ae546be7ff drm/i915: Try to make bigjoiner work in atomic check.
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/i915/display/intel_display.c:11826:
+ intel_atomic_get_new_crtc_state(state,
+ crtc_state->bigjoiner_linked_crtc);
-:191: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#191: FILE: drivers/gpu/drm/i915/display/intel_display.c:12326:
+ crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
-:217: WARNING:LONG_LINE: line over 100 characters
#217: FILE: drivers/gpu/drm/i915/display/intel_display.c:13625:
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state,
*slave_crtc_state, *master_crtc_state;
-:280: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#280: FILE: drivers/gpu/drm/i915/display/intel_display.c:13688:
+ slave = new_crtc_state->bigjoiner_linked_crtc =
-:290: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#290: FILE: drivers/gpu/drm/i915/display/intel_display.c:13698:
+ return -EINVAL;
+ } else {
-:348: ERROR:OPEN_BRACE: that open brace { should be on the previous line
#348: FILE: drivers/gpu/drm/i915/display/intel_display.c:13930:
+ if (new_crtc_state->bigjoiner)
+ {/* Not supported yet */}
total: 1 errors, 2 warnings, 3 checks, 391 lines checked
fe1d38cc6ac9 drm/i915: Enable big joiner support in enable and disable
sequences.
-:121: WARNING:LONG_LINE_COMMENT: line over 100 characters
#121: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4087:
+/* Our own transcoder needs to be disabled when reading it in
intel_ddi_read_func_ctl() */
-:123: WARNING:LONG_LINE: line over 100 characters
#123: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4089:
+ pipe_config->cpu_transcoder = (enum
transcoder)pipe_config->bigjoiner_linked_crtc->pipe;
-:231: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#231: FILE: drivers/gpu/drm/i915/display/intel_display.c:6527:
+ I915_WRITE(PIPE_MULT(cpu_transcoder),
+ pipe_config->pixel_multiplier - 1);
-:239: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#239: FILE: drivers/gpu/drm/i915/display/intel_display.c:6531:
+ intel_cpu_transcoder_set_m_n(pipe_config,
+ _config->fdi_m_n,
NULL);
-:348: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#348: FILE: drivers/gpu/drm/i915/display/intel_display.c:8353:
+ /*
+ *
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Bloomfield, Jon (2019-09-20 16:50:57) > > -Original Message- > > From: Intel-gfx On Behalf Of > > Tvrtko > > Ursulin > > Sent: Friday, September 20, 2019 8:12 AM > > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > > overtaking each other on preemption > > > > > > On 20/09/2019 15:57, Chris Wilson wrote: > > > Quoting Chris Wilson (2019-09-20 09:36:24) > > >> Force bonded requests to run on distinct engines so that they cannot be > > >> shuffled onto the same engine where timeslicing will reverse the order. > > >> A bonded request will often wait on a semaphore signaled by its master, > > >> creating an implicit dependency -- if we ignore that implicit dependency > > >> and allow the bonded request to run on the same engine and before its > > >> master, we will cause a GPU hang. > > > > > > Thinking more, it should not directly cause a GPU hang, as the stuck > > > request > > > should be timesliced away, and each preemption should be enough to keep > > > hangcheck at bay (though we have evidence it may not). So at best it runs > > > at half-speed, at worst a third (if my model is correct). > > > > But I think it is still correct to do since we don't have the coupling > > information on re-submit. Hm.. but don't we need to prevent slave from > > changing engines as well? > > Unless I'm missing something, the proposal here is to set the engines in > stone at first submission, and never change them? For submission here, think execution (submission to actual HW). (We have 2 separate phases that all like to be called submit()!) > If so, that does sound overly restrictive, and will prevent any kind of > rebalancing as workloads (of varying slave counts) come and go. We are only restricting this request, not the contexts. We still have balancing overall, just not instantaneous balancing if we timeslice out of this request -- we put it back onto the "same" engine and not another. Which is in some ways is less than ideal, although strictly we are only saying don't put it back onto an engine we have earmarked for our bonded request, and so we avoid contending with our parallel request reducing that to serial (and often bad) behaviour. [So at the end of this statement, I'm more happy with the restriction ;] > During the original design it was called out that the workloads should be > pre-empted atomically. That allows the entire bonding mask to be re-evaluated > at every context switch and so we can then rebalance. Still not easy to > achieve I agree :-( The problem with that statement is that atomic implies a global scheduling decision. Blood, sweat and tears. Of course, with your endless scheme, scheduling is all in the purview of the user :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/21] drm/i915: Move idle barrier cleanup into engine-pm
On 02/09/2019 05:02, Chris Wilson wrote:
Now that we now longer need to guarantee that the active callback is
under the struct_mutex, we can lift it out of the i915_gem_park() and
into the engine parking itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 19 ---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +++
drivers/gpu/drm/i915/i915_active.c| 1 +
3 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 92558fa47108..6e4cc177cc7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -11,29 +11,10 @@
#include "i915_drv.h"
#include "i915_globals.h"
-static void call_idle_barriers(struct intel_engine_cs *engine)
-{
- struct llist_node *node, *next;
-
- llist_for_each_safe(node, next, llist_del_all(>barrier_tasks)) {
- struct dma_fence_cb *cb =
- container_of((struct list_head *)node,
-typeof(*cb), node);
-
- cb->func(NULL, cb);
- }
-}
-
static void i915_gem_park(struct drm_i915_private *i915)
{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
lockdep_assert_held(>drm.struct_mutex);
- for_each_engine(engine, i915, id)
- call_idle_barriers(engine); /* cleanup after wedging */
-
i915_vma_parked(i915);
i915_globals_park();
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..472b2259f629 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -123,6 +123,19 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
return result;
}
+static void call_idle_barriers(struct intel_engine_cs *engine)
+{
+ struct llist_node *node, *next;
+
+ llist_for_each_safe(node, next, llist_del_all(>barrier_tasks)) {
+ struct dma_fence_cb *cb =
+ container_of((struct list_head *)node,
+typeof(*cb), node);
+
+ cb->func(NULL, cb);
+ }
+}
+
static int __engine_park(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
@@ -142,6 +155,8 @@ static int __engine_park(struct intel_wakeref *wf)
GEM_TRACE("%s\n", engine->name);
+ call_idle_barriers(engine); /* cleanup after wedging */
+
intel_engine_disarm_breadcrumbs(engine);
intel_engine_pool_park(>pool);
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index 2e2ab8176620..dcf5bc1d87e6 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -679,6 +679,7 @@ void i915_active_acquire_barrier(struct i915_active *ref)
rb_link_node(>node, parent, p);
rb_insert_color(>node, >tree);
+ GEM_BUG_ON(!intel_engine_pm_is_awake(engine));
llist_add(barrier_to_ll(node), >barrier_tasks);
intel_engine_pm_put(engine);
}
If the rest plays out this is simple. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] status of the " CRTC background color" series
Hi all, Any update on this series ? Last time I looked, everything looked ready and waiting to be merged. JJ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Document ILK+ pipe csc matrix better
On Fri, Sep 20, 2019 at 02:24:32PM +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add comments to explain the ilk pipe csc operation a bit better.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 26 +---
> > --
> > 1 file changed, 21 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 23a84dd7989f..736c42720daf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -42,6 +42,21 @@
> >
> > #define LEGACY_LUT_LENGTH 256
> >
> > +/*
> > + * ILK+ csc matrix:
> > + *
> > + * |R/Cr| | c0 c1 c2 | ( |R/Cr| |preoff0| ) |postoff0|
> > + * |G/Y | = | c3 c4 c5 | x ( |G/Y | + |preoff1| ) + |postoff1|
> > + * |B/Cb| | c6 c7 c8 | ( |B/Cb| |preoff2| ) |postoff2|
> > + *
> > + * ILK/SNB don't have explicit post offsets, and instead
> > + * CSC_MODE_YUV_TO_RGB and CSC_BLACK_SCREEN_OFFSET are used:
> > + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=0 -> 1/2, 0, 1/2
> > + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/2, 1/16,
> > 1/2
> It seems that the calculated values are assumes ITU-R BT.709 spec,
> if you don't mind, can we add some comments which is based on ITU-R
> BT.709?
> > + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=0 -> 0, 0, 0
> > + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/16, 1/16,
> > 1/16
> > + */
> > +
> > /*
> > * Extract the CSC coefficient from a CTM coefficient (in U32.32
> > fixed point
> > * format). This macro takes the coefficient we want transformed and
> > the
> > @@ -59,37 +74,38 @@
> >
> > #define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
> >
> > +/* Nop pre/post offsets */
> > static const u16 ilk_csc_off_zero[3] = {};
> >
> > +/* Identity matrix */
> > static const u16 ilk_csc_coeff_identity[9] = {
> > ILK_CSC_COEFF_1_0, 0, 0,
> > 0, ILK_CSC_COEFF_1_0, 0,
> > 0, 0, ILK_CSC_COEFF_1_0,
> > };
> >
> > +/* Limited range RGB post offsets */
> > static const u16 ilk_csc_postoff_limited_range[3] = {
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > };
> >
> > +/* Full range RGB -> limited range RGB matrix */
> > static const u16 ilk_csc_coeff_limited_range[9] = {
> > ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
> > 0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
> > 0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
> > };
> >
> > -/*
> > - * These values are direct register values specified in the Bspec,
> > - * for RGB->YUV conversion matrix (colorspace BT709)
> > - */
> > +/* BT.709 full range RGB -> limited range YCbCr matrix */
The comment is here ^
> > static const u16 ilk_csc_coeff_rgb_to_ycbcr[9] = {
> > 0x1e08, 0x9cc0, 0xb528,
> > 0x2ba8, 0x09d8, 0x37e8,
> > 0xbce8, 0x9ad8, 0x1e08,
> > };
> >
> > -/* Post offset values for RGB->YCBCR conversion */
> > +/* Limited range YCbCr post offsets */
> > static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
> > 0x0800, 0x0100, 0x0800,
> > };
> The changes look good to me.
> Reviewed-by: Gwan-gyeong Mun
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/guc: Enable guc logging on guc log relay write
Creating and opening the GuC log relay file enables and starts
the relay potentially before the caller is ready to consume logs.
Change the behavior so that relay starts only on an explicit call
to the write function (with a value of '1'). Other values flush
the log relay as before.
v2: Style changes and fix typos. Add guc_log_relay_stop()
function. (Daniele)
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Robert M. Fosha
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 53 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c| 22 +++--
3 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 36332064de9c..e26c7748358b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -226,7 +226,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log
*log)
mutex_lock(>relay.lock);
- if (WARN_ON(!intel_guc_log_relay_enabled(log)))
+ if (WARN_ON(!intel_guc_log_relay_created(log)))
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
@@ -361,6 +361,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
{
mutex_init(>relay.lock);
INIT_WORK(>relay.flush_work, capture_logs_work);
+ log->relay.started = false;
}
static int guc_log_relay_create(struct intel_guc_log *log)
@@ -546,7 +547,7 @@ int intel_guc_log_set_level(struct intel_guc_log *log, u32
level)
return ret;
}
-bool intel_guc_log_relay_enabled(const struct intel_guc_log *log)
+bool intel_guc_log_relay_created(const struct intel_guc_log *log)
{
return log->relay.buf_addr;
}
@@ -560,7 +561,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_lock(>relay.lock);
- if (intel_guc_log_relay_enabled(log)) {
+ if (intel_guc_log_relay_created(log)) {
ret = -EEXIST;
goto out_unlock;
}
@@ -585,6 +586,21 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_unlock(>relay.lock);
+ return 0;
+
+out_relay:
+ guc_log_relay_destroy(log);
+out_unlock:
+ mutex_unlock(>relay.lock);
+
+ return ret;
+}
+
+int intel_guc_log_relay_start(struct intel_guc_log *log)
+{
+ if (log->relay.started)
+ return -EEXIST;
+
guc_log_enable_flush_events(log);
/*
@@ -594,14 +610,9 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
*/
queue_work(system_highpri_wq, >relay.flush_work);
- return 0;
-
-out_relay:
- guc_log_relay_destroy(log);
-out_unlock:
- mutex_unlock(>relay.lock);
+ log->relay.started = true;
- return ret;
+ return 0;
}
void intel_guc_log_relay_flush(struct intel_guc_log *log)
@@ -610,6 +621,9 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
intel_wakeref_t wakeref;
+ if (!log->relay.started)
+ return;
+
/*
* Before initiating the forceful flush, wait for any pending/ongoing
* flush to complete otherwise forceful flush may not actually happen.
@@ -623,18 +637,33 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
guc_log_capture_logs(log);
}
-void intel_guc_log_relay_close(struct intel_guc_log *log)
+/*
+ * Stops the relay log. Called from intel_guc_log_relay_close(), so no
+ * possibility of race with start/flush since relay_write cannot race
+ * relay_close.
+ */
+static void guc_log_relay_stop(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ if (!log->relay.started)
+ return;
+
guc_log_disable_flush_events(log);
intel_synchronize_irq(i915);
flush_work(>relay.flush_work);
+ log->relay.started = false;
+}
+
+void intel_guc_log_relay_close(struct intel_guc_log *log)
+{
+ guc_log_relay_stop(log);
+
mutex_lock(>relay.lock);
- GEM_BUG_ON(!intel_guc_log_relay_enabled(log));
+ GEM_BUG_ON(!intel_guc_log_relay_created(log));
guc_log_unmap(log);
guc_log_relay_destroy(log);
mutex_unlock(>relay.lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 6f764879acb1..c252c022c5fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -47,6 +47,7 @@ struct intel_guc_log {
struct i915_vma *vma;
struct {
void *buf_addr;
+ bool started;
struct work_struct flush_work;
struct rchan *channel;
struct mutex lock;
@@ -65,8 +66,9
[Intel-gfx] [CI 2/2] HAX: force enable_guc=2
From: Anusha Srivatsa Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index d29ade3b7de6..f9fbb1f2fabf 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -54,7 +54,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, 2) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.21.0.5.gaeb582a983 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
== Series Details ==
Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
URL : https://patchwork.freedesktop.org/series/66993/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
58676dcb1195 drm/i915: Restrict qgv points which don't have enough bandwidth.
-:46: CHECK:LINE_SPACING: Please don't use multiple blank lines
#46: FILE: drivers/gpu/drm/i915/display/intel_bw.c:109:
+
+
-:70: WARNING:BRACES: braces {} are not necessary for single statement blocks
#70: FILE: drivers/gpu/drm/i915/display/intel_bw.c:416:
+ if (ret < 0) {
+ goto fallback;
+ }
-:80: CHECK:BRACES: Unbalanced braces around else statement
#80: FILE: drivers/gpu/drm/i915/display/intel_bw.c:426:
+ } else
total: 0 errors, 1 warnings, 2 checks, 93 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 15:51:35)
>
> On 20/09/2019 13:42, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
> >>
> >> On 20/09/2019 09:36, Chris Wilson wrote:
> >>> Force bonded requests to run on distinct engines so that they cannot be
> >>> shuffled onto the same engine where timeslicing will reverse the order.
> >>> A bonded request will often wait on a semaphore signaled by its master,
> >>> creating an implicit dependency -- if we ignore that implicit dependency
> >>> and allow the bonded request to run on the same engine and before its
> >>> master, we will cause a GPU hang.
> >>>
> >>> We can prevent this inversion by restricting which engines we allow
> >>> ourselves to jump to upon preemption, i.e. baking in the arrangement
> >>> established at first execution. (We should also consider capturing the
> >>> implicit dependency using i915_sched_add_dependency(), but first we need
> >>> to think about the constraints that requires on the execution/retirement
> >>> ordering.)
> >>>
> >>> Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> >>> References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Mika Kuoppala
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
> >>>1 file changed, 11 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index a99166a2d2eb..7920649e4d87 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -3755,18 +3755,21 @@ static void
> >>>virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> >>>{
> >>>struct virtual_engine *ve = to_virtual_engine(rq->engine);
> >>> + intel_engine_mask_t allowed, exec;
> >>>struct ve_bond *bond;
> >>>
> >>>bond = virtual_find_bond(ve, to_request(signal)->engine);
> >>> - if (bond) {
> >>> - intel_engine_mask_t old, new, cmp;
> >>> + if (!bond)
> >>> + return;
> >>>
> >>> - cmp = READ_ONCE(rq->execution_mask);
> >>> - do {
> >>> - old = cmp;
> >>> - new = cmp & bond->sibling_mask;
> >>> - } while ((cmp = cmpxchg(>execution_mask, old, new)) !=
> >>> old);
> >>> - }
> >>> + /* Restrict the bonded request to run on only the slaved engines */
> >>> + allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
> >>
> >> Hmm.. isn't it a miss on the uapi level that we allow master to be
> >> mentioned in the list of bonds? That's the only scenario where this line
> >> does something I think. So should we just forbid this setup on the uapi
> >> level?
> >
> > That's just a lot of digging!
>
> It's simple, in set_engines__bond in the bonds loop we just do "if
> (master == bond) oh_no_you_wont". Am I missing something?
There doesn't even need to be a bond, which is something I forgot
to handle. So I'm looking at something more like
static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
allowed = ~to_request(signal)->engine->mask;
bond = virtual_find_bond(ve, to_request(signal)->engine);
if (bond)
allowed &= bond->sibling_mask;
/* Restrict the bonded request to run on only the available engines */
exec = READ_ONCE(rq->execution_mask);
while (!try_cmpxchg(>execution_mask, , exec & allowed))
;
/* Prevent the master from being re-run on the bonded engines */
to_request(signal)->execution_mask &= ~allowed;
}
(The joy of trying to write a test case.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add memory type decoding for bandwidth checking
On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> The memory type values have changed in TGL, so we need to translate them
> differently than ICL.
>
> BSpec: 53998
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 59 ++---
> 1 file changed, 43 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 688858ebe4d0..11224d9a6752 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -35,22 +35,49 @@ static int icl_pcode_read_mem_global_info(struct
> drm_i915_private *dev_priv,
> if (ret)
> return ret;
>
> - switch (val & 0xf) {
> - case 0:
> - qi->dram_type = INTEL_DRAM_DDR4;
> - break;
> - case 1:
> - qi->dram_type = INTEL_DRAM_DDR3;
> - break;
> - case 2:
> - qi->dram_type = INTEL_DRAM_LPDDR3;
> - break;
> - case 3:
> - qi->dram_type = INTEL_DRAM_LPDDR3;
This should be LPDDR4 actually. Doesn't really matter but would be nice
to fix as well.
> - break;
> - default:
> - MISSING_CASE(val & 0xf);
> - break;
> + if (IS_GEN(dev_priv, 12)) {
> + switch (val & 0xf) {
> + case 0:
> + qi->dram_type = INTEL_DRAM_DDR4;
> + break;
> + case 3:
> + qi->dram_type = INTEL_DRAM_LPDDR4;
> + break;
> + case 4:
> + qi->dram_type = INTEL_DRAM_DDR3;
> + break;
> + case 5:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + case 1:
> + case 2:
> + /* Unimplemented */
Seems pointless to list these.
The numbers match bspec. Unfortunatley I can't get tgl
configdb to cooperate so can't double check against the
MC register definition.
Reviewed-by: Ville Syrjälä
> + /* fall through */
> + default:
> + MISSING_CASE(val & 0xf);
> + break;
> + }
> + } else if (IS_GEN(dev_priv, 11)) {
> + switch (val & 0xf) {
> + case 0:
> + qi->dram_type = INTEL_DRAM_DDR4;
> + break;
> + case 1:
> + qi->dram_type = INTEL_DRAM_DDR3;
> + break;
> + case 2:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + case 3:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + default:
> + MISSING_CASE(val & 0xf);
> + break;
> + }
> + } else {
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + qi->dram_type = INTEL_DRAM_LPDDR3; /* Conservative default */
> }
>
> qi->num_channels = (val & 0xf0) >> 4;
> --
> 2.22.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Prevent bonded requests from overtaking each other on preemption
== Series Details ==
Series: drm/i915: Prevent bonded requests from overtaking each other on
preemption
URL : https://patchwork.freedesktop.org/series/66990/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7885378114ae drm/i915: Prevent bonded requests from overtaking each other on
preemption
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ee1136908e9b
("drm/i915/execlists: Virtual engine bonding")'
#22:
References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
total: 1 errors, 0 warnings, 0 checks, 29 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Fix AVI infoframe quantization range for YCbCr output
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're configuring the AVI infoframe quantization range bits as if
> we're always transmitting RGB pixels. Let's fix this so that we
> correctly indicate limited range YCC quantization range when
> transmitting YCbCr instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9bf28de10401..b8100cf21dd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -724,11 +724,16 @@ intel_hdmi_compute_avi_infoframe(struct
> intel_encoder *encoder,
>
> drm_hdmi_avi_infoframe_colorspace(frame, conn_state);
>
> - drm_hdmi_avi_infoframe_quant_range(frame, connector,
> -adjusted_mode,
> -crtc_state-
> >limited_color_range ?
> -HDMI_QUANTIZATION_RANGE_LIMI
> TED :
> -HDMI_QUANTIZATION_RANGE_FULL
> );
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
> + drm_hdmi_avi_infoframe_quant_range(frame, connector,
> +adjusted_mode,
> +crtc_state-
> >limited_color_range ?
> +HDMI_QUANTIZATION_RA
> NGE_LIMITED :
> +HDMI_QUANTIZATION_RA
> NGE_FULL);
> + } else {
> + frame->quantization_range =
> HDMI_QUANTIZATION_RANGE_DEFAULT;
> + frame->ycc_quantization_range =
> HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> + }
>
> drm_hdmi_avi_infoframe_content_type(frame, conn_state);
>
The changes look good to me.
Reviewed-by: Gwan-gyeong Mun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Fri, 2019-09-20 at 16:19 +0300, Ville Syrjälä wrote:
> On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> > 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.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 58
> > +++--
> > drivers/gpu/drm/i915/i915_reg.h | 3 ++
> > 2 files changed, 58 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index cd58e47ab7b2..7653cbdb0ee4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -90,6 +90,26 @@ static int icl_pcode_read_qgv_point_info(struct
> > drm_i915_private *dev_priv,
> > return 0;
> > }
> >
> > +static 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)
> > {
> > @@ -354,7 +374,9 @@ int intel_bw_atomic_check(struct
> > intel_atomic_state *state)
> > unsigned int data_rate, max_data_rate;
> > unsigned int num_active_planes;
> > struct intel_crtc *crtc;
> > - int i;
> > + int i, ret;
> > + struct intel_qgv_info qi = {};
> > + u32 points_mask = 0;
> >
> > /* FIXME earlier gens need some checks too */
> > if (INTEL_GEN(dev_priv) < 11)
> > @@ -398,10 +420,40 @@ int intel_bw_atomic_check(struct
> > intel_atomic_state *state)
> > 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 = DIV_ROUND_UP(data_rate, 1000);
> >
> > + ret = icl_get_qgv_points(dev_priv, );
> > + if (ret < 0) {
> > + goto fallback;
>
> If we don't have that we don't have any idea about bw limits. So
> probably just return 0 here.
>
> > + }
> > +
> > + for (i = 0; i < qi.num_points; i++) {
> > + max_data_rate = icl_max_bw(dev_priv, num_active_planes,
> > i);
> > + if (max_data_rate < data_rate) {
> > + DRM_DEBUG_KMS("QGV point %d: max bw %d required
> > %d restricted\n",
> > + i, max_data_rate, data_rate);
> > + points_mask |= 1 << i;
>
> I think just marking the accepted levels in the mask would make
> things
> simpler...
>
> > + } else
> > + DRM_DEBUG_KMS("QGV point %d: max bw %d required
> > %d unrestricted\n",
> > + i, max_data_rate, data_rate);
> > + }
> > +
> > + if (points_mask >= ((1 << qi.num_points) - 1)) {
>
> ... eg. this can then just be 'if (points_mask == 0)'
>
> > + DRM_DEBUG_KMS("Could not find any suitable QGV
> > points\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = icl_pcode_restrict_qgv_points(dev_priv, points_mask);
> > + if (ret < 0) {
> > + DRM_DEBUG_KMS("Could not restrict required gqv
> > points(%d)\n", ret);
> > + goto fallback;
>
> Seems like dead code to me.
>
> We'll need to account for the SAGV yes/no in here as well. That is,
> if
> SAGV is off due to watermarks we'll need to restrict things to the
> highest QGV point only. Also using both the QGV point restriction
> pcode command and the legacy SAGV pcode command at the same time
> sounds
> rather risky to me. I suspect pcode might not expect that. So we need
> to rework this on a slightly bigger scale.
Well, I suspected that it's not going to be that easy..
Probably you mean that this has to be somehow put in sync with
intel_disable_sagv calls, so we need to mutually exclude those
and/or take into account.
>
> > + }
> > +
> > + return 0;
> > +
> > +fallback:
> > + max_data_rate = intel_max_data_rate(dev_priv,
> > num_active_planes);
> > +
> > if (data_rate > max_data_rate) {
> > DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available
> > %d MB/s (%d active planes)\n",
> > data_rate,
[Intel-gfx] ✓ Fi.CI.BAT: success for Docs: fix incorrect use of kernel-doc format in structure description. (rev2)
== Series Details ==
Series: Docs: fix incorrect use of kernel-doc format in structure description.
(rev2)
URL : https://patchwork.freedesktop.org/series/66922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14474
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/
Known issues
Here are the changes found in Patchwork_14474 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#106070] /
[fdo#111514] / [fdo#111700])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_addfb_basic@unused-pitches:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@unused-pitches.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u3/igt@kms_addfb_ba...@unused-pitches.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111514]: https://bugs.freedesktop.org/show_bug.cgi?id=111514
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
Participating hosts (54 -> 47)
--
Additional (1): fi-hsw-4770r
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14474
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14474: 29ef170afc02532d30519ca6ec280ea67a7ef443 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
29ef170afc02 drm/i915/perf: Fix use of kernel-doc format in structure members.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Chris Wilson (2019-09-20 09:36:24) > Force bonded requests to run on distinct engines so that they cannot be > shuffled onto the same engine where timeslicing will reverse the order. > A bonded request will often wait on a semaphore signaled by its master, > creating an implicit dependency -- if we ignore that implicit dependency > and allow the bonded request to run on the same engine and before its > master, we will cause a GPU hang. Thinking more, it should not directly cause a GPU hang, as the stuck request should be timesliced away, and each preemption should be enough to keep hangcheck at bay (though we have evidence it may not). So at best it runs at half-speed, at worst a third (if my model is correct). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Chris Wilson (2019-09-20 17:03:34) > Quoting Bloomfield, Jon (2019-09-20 16:50:57) > > > -Original Message- > > > From: Intel-gfx On Behalf Of > > > Tvrtko > > > Ursulin > > > Sent: Friday, September 20, 2019 8:12 AM > > > To: Chris Wilson ; > > > intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > > > overtaking each other on preemption > > > > > > > > > On 20/09/2019 15:57, Chris Wilson wrote: > > > > Quoting Chris Wilson (2019-09-20 09:36:24) > > > >> Force bonded requests to run on distinct engines so that they cannot be > > > >> shuffled onto the same engine where timeslicing will reverse the order. > > > >> A bonded request will often wait on a semaphore signaled by its master, > > > >> creating an implicit dependency -- if we ignore that implicit > > > >> dependency > > > >> and allow the bonded request to run on the same engine and before its > > > >> master, we will cause a GPU hang. > > > > > > > > Thinking more, it should not directly cause a GPU hang, as the stuck > > > > request > > > > should be timesliced away, and each preemption should be enough to keep > > > > hangcheck at bay (though we have evidence it may not). So at best it > > > > runs > > > > at half-speed, at worst a third (if my model is correct). > > > > > > But I think it is still correct to do since we don't have the coupling > > > information on re-submit. Hm.. but don't we need to prevent slave from > > > changing engines as well? > > > > Unless I'm missing something, the proposal here is to set the engines in > > stone at first submission, and never change them? > > For submission here, think execution (submission to actual HW). (We have > 2 separate phases that all like to be called submit()!) s/2/3/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for mdev based hardware virtio offloading support
== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/66989/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14470 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/ Known issues Here are the changes found in Patchwork_14470 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-short: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-short.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u3/igt@gem_mmap_...@basic-short.html * igt@i915_selftest@live_gem_contexts: - fi-skl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#111700]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14470 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14470: 822c68b1ca1845b6e2a38ae71547e9d9b4a5fadb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 822c68b1ca18 docs: Sample driver to demonstrate how to implement virtio-mdev framework 17f868b5d9a4 vringh: fix copy direction of vringh_iov_push_kern() 61e824bf250a virtio: introudce a mdev based transport 7bbada3ad14d mdev: introduce virtio device and its device ops 8efae9b60a78 mdev: introduce device specific ops 32afcef2acff mdev: class id support == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add TigerLake bandwidth checking (rev5)
== Series Details == Series: drm/i915: Add TigerLake bandwidth checking (rev5) URL : https://patchwork.freedesktop.org/series/66817/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14473 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/ Known issues Here are the changes found in Patchwork_14473 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap@basic-small-bo: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_m...@basic-small-bo.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u3/igt@gem_m...@basic-small-bo.html * igt@i915_selftest@live_gem_contexts: - fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#106070] / [fdo#111514] / [fdo#111700]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [PASS][7] -> [INCOMPLETE][8] ([fdo#107718]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#111381]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111514]: https://bugs.freedesktop.org/show_bug.cgi?id=111514 [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700 Participating hosts (54 -> 46) -- Additional (1): fi-hsw-4770r Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-hsw-4770 fi-icl-y fi-bsw-kefka fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14473 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14473: 81aa9b483640803e2090893356912534fd416e28 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 81aa9b483640 drm/i915: Add TigerLake bandwidth checking == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
> -Original Message- > From: Intel-gfx On Behalf Of Tvrtko > Ursulin > Sent: Friday, September 20, 2019 8:12 AM > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > overtaking each other on preemption > > > On 20/09/2019 15:57, Chris Wilson wrote: > > Quoting Chris Wilson (2019-09-20 09:36:24) > >> Force bonded requests to run on distinct engines so that they cannot be > >> shuffled onto the same engine where timeslicing will reverse the order. > >> A bonded request will often wait on a semaphore signaled by its master, > >> creating an implicit dependency -- if we ignore that implicit dependency > >> and allow the bonded request to run on the same engine and before its > >> master, we will cause a GPU hang. > > > > Thinking more, it should not directly cause a GPU hang, as the stuck request > > should be timesliced away, and each preemption should be enough to keep > > hangcheck at bay (though we have evidence it may not). So at best it runs > > at half-speed, at worst a third (if my model is correct). > > But I think it is still correct to do since we don't have the coupling > information on re-submit. Hm.. but don't we need to prevent slave from > changing engines as well? Unless I'm missing something, the proposal here is to set the engines in stone at first submission, and never change them? If so, that does sound overly restrictive, and will prevent any kind of rebalancing as workloads (of varying slave counts) come and go. During the original design it was called out that the workloads should be pre-empted atomically. That allows the entire bonding mask to be re-evaluated at every context switch and so we can then rebalance. Still not easy to achieve I agree :-( > > Regards, > > Tvrtko > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 16:12:23) > > On 20/09/2019 15:57, Chris Wilson wrote: > > Quoting Chris Wilson (2019-09-20 09:36:24) > >> Force bonded requests to run on distinct engines so that they cannot be > >> shuffled onto the same engine where timeslicing will reverse the order. > >> A bonded request will often wait on a semaphore signaled by its master, > >> creating an implicit dependency -- if we ignore that implicit dependency > >> and allow the bonded request to run on the same engine and before its > >> master, we will cause a GPU hang. > > > > Thinking more, it should not directly cause a GPU hang, as the stuck request > > should be timesliced away, and each preemption should be enough to keep > > hangcheck at bay (though we have evidence it may not). So at best it runs > > at half-speed, at worst a third (if my model is correct). > > But I think it is still correct to do since we don't have the coupling > information on re-submit. Hm.. but don't we need to prevent slave from > changing engines as well? Yes, it still looks like a sensible enough patch (even if I am biased because I think it is cute), especially in light of how we only run the bond_execute once and do not reconfigure the execution_mask on unsubmit. Still working on the test cases to exercise timeslicing + submit/bonding. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 04/10] drm/i915/dsb: Indexed register write function for DSB.
On 9/20/2019 5:48 PM, Jani Nikula wrote:
On Fri, 20 Sep 2019, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
v4: cosmetic changes done. (Shashank)
v5: reset ins_start_offset. (Jani)
v6: update ins_start_offset in inel_dsb_reg_write.
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 68
drivers/gpu/drm/i915/display/intel_dsb.h | 9
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index f94cd6dc98b6..faa853b08458 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -12,8 +12,10 @@
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -83,9 +85,74 @@ void intel_dsb_put(struct intel_dsb *dsb)
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
dsb->free_pos = 0;
+ dsb->ins_start_offset = 0;
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array. If
+* we are writing odd no of dwords, Zeros will be added in the end for
+* padding.
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -102,6 +169,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
return;
}
+ dsb->ins_start_offset = dsb->free_pos;
Okay, I'm being a pedant, but that's kind of part of the job
description, I'm afraid.
What if:
intel_dsb_get()
intel_dsb_reg_write(dsb, FOO, 0);
intel_dsb_indexed_reg_write(dsb, FOO, 0);
intel_dsb_commit()
intel_dsb_put()
Hi Jani,
I am trying to think a scenario where may write the same register which
is having auto-increment capability using both intel_dsb_reg_write and
intel_dsb_indexed_reg_write.
To set the auto increment mode we may need to write a different register
to control auto-increment mode.
If there
Re: [Intel-gfx] [PATCH 15/21] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-20 17:14:43)
>
> On 02/09/2019 05:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > index 2b1baf2fcc8e..6d7ac129ce8a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > @@ -63,7 +63,7 @@ struct intel_timeline {
> >* the request using i915_active_request_get_request_rcu(), or hold
> > the
>
> Looks like a stale comment.
>
> >* struct_mutex.
> >*/
> > - struct i915_active_request last_request;
> > + struct i915_active_fence last_request;
>
> Worth renaming to last_fence now that request naming is otherwise gone
> from i915_active?
Hmm, although i915_active is taking on more generic dma-fences, this is
still assumed to be a i915_request in a couple of places.
There's good arguments for either last_request or last_fence. If I throw
a GEM_BUG_ON(!is_request()) around, that probably swings the debate in
favour of last_request. At least tries to capture that we do assume in
some places this is i915_request.
> > void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence
> > *f)
> > {
> > GEM_BUG_ON(i915_active_is_idle(ref));
> >
> > - dma_fence_get(f);
> > -
> > - rcu_read_lock();
> > - if (rcu_access_pointer(ref->excl)) {
> > - struct dma_fence *old;
> > -
> > - old = dma_fence_get_rcu_safe(>excl);
> > - if (old) {
> > - if (dma_fence_remove_callback(old, >excl_cb))
> > - atomic_dec(>count);
> > - dma_fence_put(old);
> > - }
> > - }
> > - rcu_read_unlock();
> > -
> > - atomic_inc(>count);
> > - rcu_assign_pointer(ref->excl, f);
> > + mutex_acquire(>mutex.dep_map, 0, 0, _THIS_IP_);
>
> This just lockdep annotation? Probably deserves a comment.
Yup.
>
> > + if (!__i915_active_fence_set(>excl, f))
> > + atomic_inc(>count);
>
> Refcount management is not better done from inside __i915_active_fence_set?
No, The active counting is on i915_active; i915_active_fence is just a
component.
E.g. other users want to know the fence that used to be in the
i915_active_fence:
int i915_active_fence_set(struct i915_active_fence *active,
struct i915_request *rq)
{
struct dma_fence *fence;
int err;
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
lockdep_assert_held(active->lock);
#endif
/* Must maintain ordering wrt previous active requests */
rcu_read_lock();
fence = __i915_active_fence_set(active, >fence);
if (fence)
fence = dma_fence_get_rcu(fence);
rcu_read_unlock();
if (fence) {
err = i915_request_await_dma_fence(rq, fence);
dma_fence_put(fence);
if (err)
return err;
}
return 0;
}
and similarly in __i915_request_add_to_timeline()
> > +struct dma_fence *
> > +__i915_active_fence_set(struct i915_active_fence *active,
> > + struct dma_fence *fence)
> > +{
> > + struct dma_fence *prev;
> > + unsigned long flags;
> > +
> > + /* NB: updates must be serialised by an outer timeline mutex */
> > + spin_lock_irqsave(fence->lock, flags);
> > + GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
> > +
> > + prev = rcu_dereference_protected(active->fence,
> > active_is_held(active));
> > + if (prev) {
> > + spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING);
> > + __list_del_entry(>cb.node);
> > + spin_unlock(prev->lock); /* serialise with prev->cb_list */
> > + prev = rcu_access_pointer(active->fence);
>
> Why it is important to re-read active->fence and does it then need a
> comment?
Because we have to serialise with the prev->cb_list. ;)
The write to active->fence is made on signaling, and that is performed
under the prev->lock. So we have to take the prev->lock ourselves to
flush any concurrent callbacks before we know whether they ran (having
taken the lock, we remove the cb from the list and so now that if it
has not run, it can not run).
> How does it tie with i915_active->count refcounting which is done on the
> basis of return value from this function?
Same as above, we have to flush the signal callback to determine whether
or not we need to increment the active count.
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3eed2efa8d13..1aadab1cdd24 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -900,28 +900,38 @@ wait_for_timelines(struct drm_i915_private *i915,
> >
> > spin_lock_irqsave(>lock, flags);
> > list_for_each_entry(tl, >active_list, link) {
> > - struct
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dsb: feature flag added for display state buffer. Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 0/8] drm/i915/dp: Support for DP HDR outputs
On Thu, Sep 19, 2019 at 10:53:03PM +0300, Gwan-gyeong Mun wrote: > Support for HDR10 video was introduced in DisplayPort 1.4. > On GLK+ platform, in order to use DisplayPort HDR10, we need to support > BT.2020 colorimetry and HDR Static metadata. > It implements the CTA-861-G standard for transport of static HDR metadata. > It enables writing of HDR metadata infoframe SDP to the panel. > The HDR Metadata will be provided by userspace compositors, based on > blending policies and passed to the driver through a blob property. > And It refactors, renames and extends a function which handled vsc sdp > header and data block setup for supporting colorimetry format. > And It attaches the colorspace connector property and HDR metadata property > to a DisplayPort connector. > > These patches tested on below test environment. > Test Environment: > - Tested System: GLK and Gen11 platform. > - Monitor: Dell UP2718Q 4K HDR Monitor. > - In order to test DP HDR10, test environment uses patched Kodi-gbm, >patched Media driver and HDR10 video. > >You can find these on below. >[patched Kodi-gbm] > - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr >[download 4K HDR video file] > - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ >[Media Driver for GLK] > - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver > master branch >[Media Driver for ICL] > - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite > > v2: > - Add a missed blank line after function declaration. > - Remove useless parentheses. > - Minor style fix. > > v3: > - Remove not handled return values from >intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] > - Add handling of different register size for >HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN >platforms [Uma] > - Add new colorimetry options for DP 1.4a spec. [Ville] > - Separate set of colorimetry enum values for DP. [Ville] > - In order to checking output format and output colorspace on >intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state > stucture.[Ville] > - Remove a pointless variable. [Ville] > > v4: > - Add additional comments to struct drm_prop_enum_list. > - Polishing an enum string of struct drm_prop_enum_list. > > v5: > - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and >DP abbreviations. > - Add missed variables on dp_colorspaces. > - Fix typo. [Uma] > > v6: > - Addressed review comments from Ilia and Ville >Split drm_mode_create_colorspace_property() to DP and HDMI connector. >Becasue between HDMI and DP have different colorspaces, it renames >drm_mode_create_colorspace_property() function to >drm_mode_create_hdmi_colorspace_property() function for HDMI connector. >And it adds drm_mode_create_dp_colorspace_property() function for >creating of DP colorspace property. >In order to apply changed and added drm api, i915 driver has channged. > > v7: > - Fix typo [Jani Saarinen] > - Fix white space. > > v8: > - Addressed review comments from Ville >Drop colorimetries which have another way to distinguish or which would >not be used. > > v9: > - Addressed review comments from Ville > - Remove a duplicated output color space from intel_crtc_state. > - In order to handle colorspace of drm_connector_state, it moves a calling >of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp() > - Split hunk into renaming and adding of code. > - Add a handling of drm_mode_create_dp_colorspace_property() to >intel_attach_colorspace_property(). > - Add WARN_ON() when buffer size if larger than register size. > - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. > - Change a passed size toward write_infoframe() for DP infoframe sdp >packet for HDR static metadata. > > > Gwan-gyeong Mun (8): > drm/i915/dp: Extend program of VSC Header and DB for Colorimetry > Format > drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA > drm: Rename HDMI colorspace property creation function > drm: Add DisplayPort colorspace property creation function > drm/i915/dp: Attach colorspace property > drm/i915: Add new GMP register size for GEN11 > drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static > Metadata > drm/i915/dp: Attach HDR metadata property to DP connector Thanks. The series lgtm. I've pushed the core bits into drm-misc-next. We can proceed with the rest once those make their way back into dinq. > > drivers/gpu/drm/drm_connector.c | 101 +++-- > .../gpu/drm/i915/display/intel_connector.c| 21 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- > drivers/gpu/drm/i915/display/intel_display.c | 1 - > drivers/gpu/drm/i915/display/intel_display.h | 2 - > drivers/gpu/drm/i915/display/intel_dp.c | 196
Re: [Intel-gfx] [PATCH] video/hdmi: Fix AVI bar unpack
On Fri, Sep 20, 2019 at 04:58:53PM +0200, Thierry Reding wrote:
> On Thu, Sep 19, 2019 at 04:28:53PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The bar values are little endian, not big endian. The pack
> > function did it right but the unpack got it wrong. Fix it.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Martin Bugge
> > Cc: Hans Verkuil
> > Cc: Thierry Reding
> > Cc: Mauro Carvalho Chehab
> > Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
> > InfoFrames")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Thierry Reding
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/21] drm/i915: Coordinate i915_active with its own mutex
On 02/09/2019 05:02, Chris Wilson wrote:
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).
The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 2 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 9 +-
drivers/gpu/drm/i915/gt/intel_context.c | 6 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 10 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 9 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 16 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +-
.../gpu/drm/i915/gt/selftests/mock_timeline.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 3 -
drivers/gpu/drm/i915/i915_active.c| 291 +++-
drivers/gpu/drm/i915/i915_active.h| 318 --
drivers/gpu/drm/i915/i915_active_types.h | 23 +-
drivers/gpu/drm/i915/i915_gem.c | 42 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_request.c | 39 +--
drivers/gpu/drm/i915/i915_request.h | 1 -
drivers/gpu/drm/i915/i915_vma.c | 8 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 36 +-
26 files changed, 274 insertions(+), 580 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 6428b8dd70d3..84b164f31895 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -257,7 +257,7 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
front->obj = obj;
kref_init(>ref);
atomic_set(>bits, 0);
- i915_active_init(i915, >write,
+ i915_active_init(>write,
frontbuffer_active,
i915_active_may_sleep(frontbuffer_retire));
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c
index 4f36557b3f3b..544e953342ea 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
(*fn)(struct intel_overlay *))
if (IS_ERR(rq))
return rq;
- err = i915_active_ref(>last_flip, rq->timeline, rq);
+ err = i915_active_ref(>last_flip, rq->timeline, >fence);
if (err) {
i915_request_add(rq);
return ERR_PTR(err);
@@ -1360,8 +1360,7 @@ void intel_overlay_setup(struct drm_i915_private
*dev_priv)
overlay->contrast = 75;
overlay->saturation = 146;
- i915_active_init(dev_priv,
->last_flip,
+ i915_active_init(>last_flip,
NULL, intel_overlay_last_flip_retire);
ret = get_registers(overlay, OVERLAY_NEEDS_PHYSICAL(dev_priv));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 9e72b42a86f5..ace50bb9ee1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -160,7 +160,7 @@ static int move_to_active(struct i915_vma *vma, struct
i915_request *rq)
if (err)
return err;
- return i915_active_ref(>active, rq->timeline, rq);
+ return i915_active_ref(>active, rq->timeline, >fence);
}
static void clear_pages_worker(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
Re: [Intel-gfx] [PATCH 01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
On Fri, Sep 20, 2019 at 01:42:13PM +0200, Maarten Lankhorst wrote:
> There was a integer wraparound when mode_clock became too high,
> and we didn't correct for the FEC overhead factor when dividing,
> with the calculations breaking at HBR3.
>
> As a result our calculated bpp was way too high, and the link width
> limitation never came into effect.
>
> Print out the resulting bpp calcululations as a sanity check, just
> in case we ever have to debug it later on again.
>
> We also used the wrong factor for FEC. While bspec mentions 2.4%,
> all the calculations use 1/0.972261, and the same ratio should be
> applied to data M/N as well, so use it there when FEC is enabled.
>
> Make sure we don't break hw readout, and read out FEC enable state
> and correct the DDI clock readout for the new values.
>
> Together with the next commit, this causes FEC to work correctly
> with big joiner, while also having the correct refresh rate
> reported in kms_setmode.basic.
>
> Signed-off-by: Maarten Lankhorst
> Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice
> Count for DSC")
> Cc: # v5.0+
> Cc: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 19 +-
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 195 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 6 +-
> 4 files changed, 128 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3e6394139964..1b59b852874b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1479,6 +1479,10 @@ static void ddi_dotclock_get(struct intel_crtc_state
> *pipe_config)
> if (pipe_config->pixel_multiplier)
> dotclock /= pipe_config->pixel_multiplier;
>
> + /* fec adds overhead to the data M/N values, correct for it */
> + if (pipe_config->fec_enable)
> + dotclock = intel_dp_fec_to_mode_clock(dotclock);
> +
> pipe_config->base.adjusted_mode.crtc_clock = dotclock;
> }
>
> @@ -4031,7 +4035,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> case TRANS_DDI_MODE_SELECT_FDI:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
> break;
> - case TRANS_DDI_MODE_SELECT_DP_SST:
> + case TRANS_DDI_MODE_SELECT_DP_SST: {
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> +
> if (encoder->type == INTEL_OUTPUT_EDP)
> pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
> else
> @@ -4039,7 +4045,18 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> pipe_config->lane_count =
> ((temp & DDI_PORT_WIDTH_MASK) >> DDI_PORT_WIDTH_SHIFT)
> + 1;
> intel_dp_get_m_n(intel_crtc, pipe_config);
> +
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pipe_config->fec_enable =
> + I915_READ(intel_dp->regs.dp_tp_ctl) &
> + DP_TP_CTL_FEC_ENABLE;
Side note: That looks broken for the init/resume readout.
I knew there was a reason I didn't quite like the idea of
intel_dp->regs...
> + DRM_DEBUG_KMS("[ENCODER:%d:%s] Fec status: %u\n",
> + encoder->base.base.id, encoder->base.name,
> + pipe_config->fec_enable);
> + }
> +
> break;
> + }
> case TRANS_DDI_MODE_SELECT_DP_MST:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
> pipe_config->lane_count =
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e0033d99f6e3..7996864e6f7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12773,6 +12773,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> PIPE_CONF_CHECK_BOOL(hdmi_scrambling);
> PIPE_CONF_CHECK_BOOL(hdmi_high_tmds_clock_ratio);
> PIPE_CONF_CHECK_BOOL(has_infoframe);
> + PIPE_CONF_CHECK_BOOL(fec_enable);
>
> PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_audio);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ccaf9f00b747..4dfb78dc7fa2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -76,8 +76,8 @@
> #define DP_DSC_MAX_ENC_THROUGHPUT_0 34
> #define DP_DSC_MAX_ENC_THROUGHPUT_1 40
>
> -/* DP DSC FEC Overhead factor = (100 - 2.4)/100 */
> -#define DP_DSC_FEC_OVERHEAD_FACTOR 976
> +/* DP DSC FEC Overhead factor = 1/(0.972261) */
> +#define DP_DSC_FEC_OVERHEAD_FACTOR 972261
>
> /* Compliance test status bits */
> #define
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend
== Series Details == Series: drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend URL : https://patchwork.freedesktop.org/series/66991/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14472 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/ Known issues Here are the changes found in Patchwork_14472 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-small-bo: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html * igt@i915_module_load@reload: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] / [fdo#111214]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@i915_module_l...@reload.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-7500u: [PASS][5] -> [WARN][6] ([fdo#109483]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 Participating hosts (54 -> 47) -- Additional (1): fi-hsw-4770r Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14472 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14472: 475f7d6ead72e2bbce59c1e39d52e7b8701bebaa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 475f7d6ead72 drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim checkpatch origin/drm-tip 396d115d8cc6 drm/i915/dsb: feature flag added for display state buffer. 5a60554c2d5d drm/i915/dsb: DSB context creation. -:63: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #63: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 134 lines checked 32156cd99f53 drm/i915/dsb: single register write function for DSB. 6cebb40b0c3d drm/i915/dsb: Indexed register write function for DSB. 82006824a268 drm/i915/dsb: Check DSB engine status. c6d05e53a15d drm/i915/dsb: functions to enable/disable DSB engine. f3f9d6a4f641 drm/i915/dsb: function to trigger workload execution of DSB. dc74e0b1bce3 drm/i915/dsb: Enable gamma lut programming using DSB. 6ccd2217aa11 drm/i915/dsb: Enable DSB for gen12. 89ca6c89252a drm/i915/dsb: Documentation for DSB. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
in __lock_release"), @nested is no longer used in lock_release(), so
remove it from all lock_release() calls and friends.
Signed-off-by: Qian Cai
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/tty/tty_ldsem.c | 8
fs/dcache.c | 2 +-
fs/jbd2/transaction.c | 4 ++--
fs/kernfs/dir.c | 4 ++--
fs/ocfs2/dlmglue.c| 2 +-
include/linux/jbd2.h | 2 +-
include/linux/lockdep.h | 21 ++---
include/linux/percpu-rwsem.h | 4 ++--
include/linux/rcupdate.h | 2 +-
include/linux/rwlock_api_smp.h| 16
include/linux/seqlock.h | 4 ++--
include/linux/spinlock_api_smp.h | 8
include/linux/ww_mutex.h | 2 +-
include/net/sock.h| 2 +-
kernel/bpf/stackmap.c | 2 +-
kernel/cpu.c | 2 +-
kernel/locking/lockdep.c | 3 +--
kernel/locking/mutex.c| 4 ++--
kernel/locking/rtmutex.c | 6 +++---
kernel/locking/rwsem.c| 10 +-
kernel/printk/printk.c| 10 +-
kernel/sched/core.c | 2 +-
lib/locking-selftest.c| 24
mm/memcontrol.c | 2 +-
net/core/sock.c | 2 +-
tools/lib/lockdep/include/liblockdep/common.h | 3 +--
tools/lib/lockdep/include/liblockdep/mutex.h | 2 +-
tools/lib/lockdep/include/liblockdep/rwlock.h | 2 +-
tools/lib/lockdep/preload.c | 16
33 files changed, 90 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..4a8b2e5c2af6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -719,7 +719,7 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter)
__drm_connector_put_safe(iter->conn);
spin_unlock_irqrestore(>connector_list_lock, flags);
}
- lock_release(_list_iter_dep_map, 0, _RET_IP_);
+ lock_release(_list_iter_dep_map, _RET_IP_);
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index edd21d14e64f..1a51b3598d63 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -509,14 +509,14 @@ void i915_gem_shrinker_taints_mutex(struct
drm_i915_private *i915,
I915_MM_SHRINKER, 0, _RET_IP_);
mutex_acquire(>dep_map, 0, 0, _RET_IP_);
- mutex_release(>dep_map, 0, _RET_IP_);
+ mutex_release(>dep_map, _RET_IP_);
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
fs_reclaim_release(GFP_KERNEL);
if (unlock)
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
}
#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..7f647243b3b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -52,7 +52,7 @@ static inline unsigned long __timeline_mark_lock(struct
intel_context *ce)
static inline void __timeline_mark_unlock(struct intel_context *ce,
unsigned long flags)
{
- mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>timeline->mutex.dep_map, _THIS_IP_);
local_irq_restore(flags);
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a53777dd371c..e1f1be4d0531 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1456,7 +1456,7 @@ long i915_request_wait(struct i915_request *rq,
dma_fence_remove_callback(>fence, );
out:
- mutex_release(>engine->gt->reset.mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>engine->gt->reset.mutex.dep_map, _THIS_IP_);
trace_i915_request_wait_end(rq);
return timeout;
}
diff --git a/drivers/tty/tty_ldsem.c b/drivers/tty/tty_ldsem.c
index 60ff236a3d63..ce8291053af3 100644
---
Re: [Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate
Quoting Tvrtko Ursulin (2019-09-20 17:22:42) > > On 02/09/2019 05:02, Chris Wilson wrote: > > Since we cannot allocate underneath the vm->mutex (it is used in the > > direct-reclaim paths), we need to shift the allocations off into a > > mutexless worker with fence recursion prevention. To know when we need > > this protection, we mark up the address spaces that do allocate before > > insertion. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++ > > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ > > 2 files changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > > b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index 9095f017162e..56d27cf09a3d 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct > > drm_i915_private *i915) > > goto err_free_pd; > > } > > > > + ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND; > > So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that > works from these call sites? Should it be called bind_alloc*s*? > bind_allocates? Or be a boolean which is converted to a trick flag in > i915_vma_bind where a comment can be put explaining the trick? Is it a trick? We need to differentiate between requests for LOCAL_BIND, GLOBAL_BIND, LOCAL_BIND | GLOBAL_BIND, for different types of vm. Then I have a plan on using the worker for GLOBAL_BIND on bsw/bxt to defer the stop_machine(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
>
> Signed-off-by: Qian Cai
> ---
Although this looks fine to me at a first glance, it might be slightly
easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
first with coccinelle scripts, and then hack lock_release() as a final
patch. That way it's easy to regenerate things if needed.
Cheers,
Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Fri, 2019-09-20 at 10:38 +0100, Will Deacon wrote:
> On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > in __lock_release"), @nested is no longer used in lock_release(), so
> > remove it from all lock_release() calls and friends.
> >
> > Signed-off-by: Qian Cai
> > ---
>
> Although this looks fine to me at a first glance, it might be slightly
> easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
> first with coccinelle scripts, and then hack lock_release() as a final
> patch. That way it's easy to regenerate things if needed.
I am not sure if it worth the extra efforts where I have to retest it on all
architectures, and the patch is really simple, but I can certainly do that if
you insist.
I have just confirmed the patch [1] also applied correctly to the latest
mainline, so it might be the best time just for Linus to merge it directly so it
does not introduce build errors later on?
[1]
https://lore.kernel.org/lkml/1568909380-32199-1-git-send-email-...@lca.pw/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Fri, Sep 20, 2019 at 08:50:36AM -0400, Qian Cai wrote:
> On Fri, 2019-09-20 at 10:38 +0100, Will Deacon wrote:
> > On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > > in __lock_release"), @nested is no longer used in lock_release(), so
> > > remove it from all lock_release() calls and friends.
> > >
> > > Signed-off-by: Qian Cai
> > > ---
> >
> > Although this looks fine to me at a first glance, it might be slightly
> > easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
> > first with coccinelle scripts, and then hack lock_release() as a final
> > patch. That way it's easy to regenerate things if needed.
>
> I am not sure if it worth the extra efforts where I have to retest it on all
> architectures, and the patch is really simple, but I can certainly do that if
> you insist.
I'm not insisting, just thought it might be easier to get it merged that
way. If you prefer to go with the big diff,
Acked-by: Will Deacon
Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark contents as dirty on a write fault
Quoting Chris Wilson (2019-09-20 13:22:13)
> Quoting Chris Wilson (2019-09-20 13:18:21)
> > Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
> > Flush pages on acquisition"), we no longer mark the contents as dirty on
> > a write fault. This has the issue of us then not marking the pages as
> > dirty on releasing the buffer, which means the contents are not written
> > out to the swap device (should we ever pick that buffer as a victim).
> > Notably, this is visible in the dumb buffer interface used for cursors.
> > Having updated the cursor contents via mmap, and swapped away, if the
> > shrinker should evict the old cursor, upon next reuse, the cursor would
> > be invisible.
>
> Hmm, I think the dumb interface may be missing a few steps around the
> place to ensure the contents are flushed.
No, it's fine. We do the flush in pinning pages, the only thing that was
dropped was then marking the content as dirty.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Document ILK+ pipe csc matrix better
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add comments to explain the ilk pipe csc operation a bit better.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 26 +---
> --
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 23a84dd7989f..736c42720daf 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -42,6 +42,21 @@
>
> #define LEGACY_LUT_LENGTH256
>
> +/*
> + * ILK+ csc matrix:
> + *
> + * |R/Cr| | c0 c1 c2 | ( |R/Cr| |preoff0| ) |postoff0|
> + * |G/Y | = | c3 c4 c5 | x ( |G/Y | + |preoff1| ) + |postoff1|
> + * |B/Cb| | c6 c7 c8 | ( |B/Cb| |preoff2| ) |postoff2|
> + *
> + * ILK/SNB don't have explicit post offsets, and instead
> + * CSC_MODE_YUV_TO_RGB and CSC_BLACK_SCREEN_OFFSET are used:
> + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=0 -> 1/2, 0, 1/2
> + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/2, 1/16,
> 1/2
It seems that the calculated values are assumes ITU-R BT.709 spec,
if you don't mind, can we add some comments which is based on ITU-R
BT.709?
> + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=0 -> 0, 0, 0
> + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/16, 1/16,
> 1/16
> + */
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32
> fixed point
> * format). This macro takes the coefficient we want transformed and
> the
> @@ -59,37 +74,38 @@
>
> #define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
>
> +/* Nop pre/post offsets */
> static const u16 ilk_csc_off_zero[3] = {};
>
> +/* Identity matrix */
> static const u16 ilk_csc_coeff_identity[9] = {
> ILK_CSC_COEFF_1_0, 0, 0,
> 0, ILK_CSC_COEFF_1_0, 0,
> 0, 0, ILK_CSC_COEFF_1_0,
> };
>
> +/* Limited range RGB post offsets */
> static const u16 ilk_csc_postoff_limited_range[3] = {
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> };
>
> +/* Full range RGB -> limited range RGB matrix */
> static const u16 ilk_csc_coeff_limited_range[9] = {
> ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
> 0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
> 0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
> };
>
> -/*
> - * These values are direct register values specified in the Bspec,
> - * for RGB->YUV conversion matrix (colorspace BT709)
> - */
> +/* BT.709 full range RGB -> limited range YCbCr matrix */
> static const u16 ilk_csc_coeff_rgb_to_ycbcr[9] = {
> 0x1e08, 0x9cc0, 0xb528,
> 0x2ba8, 0x09d8, 0x37e8,
> 0xbce8, 0x9ad8, 0x1e08,
> };
>
> -/* Post offset values for RGB->YCBCR conversion */
> +/* Limited range YCbCr post offsets */
> static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
> 0x0800, 0x0100, 0x0800,
> };
The changes look good to me.
Reviewed-by: Gwan-gyeong Mun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
== Series Details ==
Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
URL : https://patchwork.freedesktop.org/series/66993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14475
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/
Known issues
Here are the changes found in Patchwork_14475 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-read-write-distinct:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] /
[fdo#111214])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-6770hq: [PASS][5] -> [INCOMPLETE][6] ([fdo#111519] /
[fdo#111700])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111045] / [fdo#111096])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#111381]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111519]: https://bugs.freedesktop.org/show_bug.cgi?id=111519
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
Participating hosts (54 -> 47)
--
Additional (1): fi-hsw-4770r
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14475
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14475: 58676dcb1195c94dc8f6db8978ac7651e16e5a54 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
58676dcb1195 drm/i915: Restrict qgv points which don't have enough bandwidth.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
On 20/09/2019 15:57, Chris Wilson wrote: Quoting Chris Wilson (2019-09-20 09:36:24) Force bonded requests to run on distinct engines so that they cannot be shuffled onto the same engine where timeslicing will reverse the order. A bonded request will often wait on a semaphore signaled by its master, creating an implicit dependency -- if we ignore that implicit dependency and allow the bonded request to run on the same engine and before its master, we will cause a GPU hang. Thinking more, it should not directly cause a GPU hang, as the stuck request should be timesliced away, and each preemption should be enough to keep hangcheck at bay (though we have evidence it may not). So at best it runs at half-speed, at worst a third (if my model is correct). But I think it is still correct to do since we don't have the coupling information on re-submit. Hm.. but don't we need to prevent slave from changing engines as well? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
