[Intel-gfx] [PATCH v2 0/2] Variable renames
Sadly checkpatch is not working in this series and it passed even if there was a clear alignment violation. I fixed the one reported by Ville and reviewed the rest to check if there was others. Lucas De Marchi (2): drm/i915/display: remove alias to dig_port drm/i915/display: prefer dig_port to reference intel_digital_port drivers/gpu/drm/i915/display/intel_ddi.c | 154 drivers/gpu/drm/i915/display/intel_display.c | 6 +- drivers/gpu/drm/i915/display/intel_display.h | 2 +- .../drm/i915/display/intel_display_debugfs.c | 12 +- .../drm/i915/display/intel_display_power.c| 4 +- .../drm/i915/display/intel_display_types.h| 40 +-- drivers/gpu/drm/i915/display/intel_dp.c | 338 +- drivers/gpu/drm/i915/display/intel_dp.h | 4 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 74 ++-- drivers/gpu/drm/i915/display/intel_dp_mst.h | 6 +- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 38 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 118 +++--- drivers/gpu/drm/i915/display/intel_hdmi.c | 252 ++--- drivers/gpu/drm/i915/display/intel_hdmi.h | 4 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 8 +- drivers/gpu/drm/i915/display/intel_lspcon.h | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 4 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 8 +- 18 files changed, 535 insertions(+), 539 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/display: remove alias to dig_port
We don't need intel_dig_port and dig_port to refer to the same thing.
Prefer the latter.
v2: fix coding style
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 884b507c5f55..025d4052f6f8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3380,11 +3380,10 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_atomic_state *state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
{
- struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
- struct intel_hdmi *intel_hdmi = &intel_dig_port->hdmi;
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+ struct intel_hdmi *intel_hdmi = &dig_port->hdmi;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
int level = intel_ddi_hdmi_level(encoder);
- struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
intel_ddi_clk_select(encoder, crtc_state);
@@ -3411,9 +3410,9 @@ static void intel_ddi_pre_enable_hdmi(struct
intel_atomic_state *state,
intel_ddi_enable_pipe_clock(encoder, crtc_state);
- intel_dig_port->set_infoframes(encoder,
- crtc_state->has_infoframe,
- crtc_state, conn_state);
+ dig_port->set_infoframes(encoder,
+crtc_state->has_infoframe,
+crtc_state, conn_state);
}
static void intel_ddi_pre_enable(struct intel_atomic_state *state,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915/display: prefer dig_port to reference intel_digital_port
We have a mix of dport, intel_dport, intel_dig_port and dig_port to
reference a intel_digital_port struct. Numbers are around
5 intel_dport
36 dport
479 intel_dig_port
352 dig_port
Since we already removed the intel_ prefix from most of our other
structs, do the same here and prefer dig_port.
v2: rename everything in i915, not just a few display sources and
reword commit message (from Matt Roper)
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 143
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
.../drm/i915/display/intel_display_debugfs.c | 12 +-
.../drm/i915/display/intel_display_power.c| 4 +-
.../drm/i915/display/intel_display_types.h| 40 +--
drivers/gpu/drm/i915/display/intel_dp.c | 338 +-
drivers/gpu/drm/i915/display/intel_dp.h | 4 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 74 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.h | 6 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 38 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 118 +++---
drivers/gpu/drm/i915/display/intel_hdmi.c | 252 ++---
drivers/gpu/drm/i915/display/intel_hdmi.h | 4 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 8 +-
drivers/gpu/drm/i915/display/intel_lspcon.h | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 8 +-
18 files changed, 530 insertions(+), 533 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 025d4052f6f8..583170e73881 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1394,10 +1394,9 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
static void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- struct intel_digital_port *intel_dig_port =
- enc_to_dig_port(encoder);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
- intel_dp->DP = intel_dig_port->saved_port_bits |
+ intel_dp->DP = dig_port->saved_port_bits |
DDI_BUF_CTL_ENABLE | DDI_BUF_TRANS_SELECT(0);
intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
}
@@ -2070,7 +2069,7 @@ static void _skl_ddi_set_iboost(struct drm_i915_private
*dev_priv,
static void skl_ddi_set_iboost(struct intel_encoder *encoder,
int level, enum intel_output_type type)
{
- struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
u8 iboost;
@@ -2107,7 +2106,7 @@ static void skl_ddi_set_iboost(struct intel_encoder
*encoder,
_skl_ddi_set_iboost(dev_priv, port, iboost);
- if (port == PORT_A && intel_dig_port->max_lanes == 4)
+ if (port == PORT_A && dig_port->max_lanes == 4)
_skl_ddi_set_iboost(dev_priv, PORT_E, iboost);
}
@@ -3000,15 +2999,15 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
}
static void
-icl_program_mg_dp_mode(struct intel_digital_port *intel_dig_port,
+icl_program_mg_dp_mode(struct intel_digital_port *dig_port,
const struct intel_crtc_state *crtc_state)
{
- struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
- enum tc_port tc_port = intel_port_to_tc(dev_priv,
intel_dig_port->base.port);
+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+ enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
u32 ln0, ln1, pin_assignment;
u8 width;
- if (intel_dig_port->tc_mode == TC_PORT_TBT_ALT)
+ if (dig_port->tc_mode == TC_PORT_TBT_ALT)
return;
if (INTEL_GEN(dev_priv) >= 12) {
@@ -3027,13 +3026,13 @@ icl_program_mg_dp_mode(struct intel_digital_port
*intel_dig_port,
ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
/* DPPATC */
- pin_assignment = intel_tc_port_get_pin_assignment_mask(intel_dig_port);
+ pin_assignment = intel_tc_port_get_pin_assignment_mask(dig_port);
width = crtc_state->lane_count;
switch (pin_assignment) {
case 0x0:
drm_WARN_ON(&dev_priv->drm,
- intel_dig_port->tc_mode != TC_PORT_LEGACY);
+ dig_port->tc_mode != TC_PORT_LEGACY);
if (width == 1) {
ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
} else {
@@ -3978,10 +3977,9 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state
*state,
static void intel_ddi_prepare_link_retrain(struct intel_dp *intel_
[Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
Modify the helper to add a fixed delay or poll with timeout
based on platform specification to check for either Idle bit
set (DDI_BUF_CTL is idle for disable case)
v3:
* Change the timeout to 16usecs (Ville)
v2:
* Use 2 separate functions or idle and active (Ville)
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_ddi.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 884b507c5f55..052a74625a61 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1184,16 +1184,15 @@ static void intel_prepare_hdmi_ddi_buffers(struct
intel_encoder *encoder,
static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
enum port port)
{
- i915_reg_t reg = DDI_BUF_CTL(port);
- int i;
-
- for (i = 0; i < 16; i++) {
- udelay(1);
- if (intel_de_read(dev_priv, reg) & DDI_BUF_IS_IDLE)
- return;
+ if (IS_BROXTON(dev_priv)) {
+ udelay(16);
+ return;
}
- drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c idle bit\n",
- port_name(port));
+
+ if (wait_for_us((intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
+DDI_BUF_IS_IDLE), 16))
+ drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c to get
idle\n",
+ port_name(port));
}
static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Helper to check for DDI BUF status to get active
Based on the platform, Bspec expects us to wait or poll with
timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
after enabling DDI_BUF_CTL.
v4:
* Use the timeout for GLK (Ville)
v3:
* Add a new function _active for DDI BUF CTL to be non idle (Ville)
v2:
* Based on platform, fixed delay or poll (Ville)
* Use a helper to do this (Imre, Ville)
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_ddi.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 052a74625a61..94d57b57139b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1195,6 +1195,20 @@ static void intel_wait_ddi_buf_idle(struct
drm_i915_private *dev_priv,
port_name(port));
}
+static void intel_wait_ddi_buf_active(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv) ) {
+ usleep_range(600, 1000);
+ return;
+ }
+
+ if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
+ DDI_BUF_IS_IDLE), 600))
+ drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c to get
active\n",
+ port_name(port));
+}
+
static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
{
switch (pll->info->id) {
@@ -4020,7 +4034,7 @@ static void intel_ddi_prepare_link_retrain(struct
intel_dp *intel_dp)
intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
- udelay(600);
+ intel_wait_ddi_buf_active(dev_priv, port);
}
static void intel_ddi_set_link_train(struct intel_dp *intel_dp,
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use the gt in HAS_ENGINE
Quoting Daniele Ceraolo Spurio (2020-06-26 18:45:56) > > > On 6/26/20 7:35 AM, Chris Wilson wrote: > > Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07) > >> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c > >> b/drivers/gpu/drm/i915/gvt/handlers.c > >> index 26cae4846c82..ddefc52f6e09 100644 > >> --- a/drivers/gpu/drm/i915/gvt/handlers.c > >> +++ b/drivers/gpu/drm/i915/gvt/handlers.c > >> @@ -1867,7 +1867,7 @@ static int csfe_chicken1_mmio_write(struct > >> intel_vgpu *vgpu, > >> MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \ > >> MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \ > >> MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \ > >> - if (HAS_ENGINE(dev_priv, VCS1)) \ > >> + if (HAS_ENGINE(&dev_priv->gt, VCS1)) \ > > > > Implicit param! It can switch to gvt->gt for all callsites, killing the > > dev_priv locals. > > I've switched this to gvt->gt, but unfortunately the locals will have to > stay because some of the display register definitions still use dev_priv > implicitly to access the display mmio base and the > pipe_offsets/trans_offsets arrays. Curses. Maybe one day. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use the gt in HAS_ENGINE
On 6/26/20 7:35 AM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index 26cae4846c82..ddefc52f6e09 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -1867,7 +1867,7 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu *vgpu, MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \ MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \ - if (HAS_ENGINE(dev_priv, VCS1)) \ + if (HAS_ENGINE(&dev_priv->gt, VCS1)) \ Implicit param! It can switch to gvt->gt for all callsites, killing the dev_priv locals. I've switched this to gvt->gt, but unfortunately the locals will have to stay because some of the display register definitions still use dev_priv implicitly to access the display mmio base and the pipe_offsets/trans_offsets arrays. Daniele -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DG1 VRAM question
On 6/26/20 12:14 AM, Lucas De Marchi wrote:
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
I can't figure this out easily so I'd thought I'd just ask, but does
DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
We'd need to go via lmem since there's no mappable aperture. There are
a few patches in tree for that
(see e.g. 54b512cd7a6d ("drm/i915: do not map aperture if it is not
available.")) but more missing.
To clarify, although the legacy aperture mapping that allowed the CPU to
access memory via the GGTT for swizzling is gone, VRAM/LMEM is still
cpu-mappable via pci bar.
Will leave the questions about possible trashing to Matt as he's more
familiar than me with how this works.
Daniele
Lucas De Marchi
mappable VRAM vs non-mappable in patches, is it planned to just thrash
the aperture if userspace ever ties to map too much of it.
Are pagetables stored in the visible RAM space?
Dave.
___
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 4/7] drm/i915: Move the engine mask to intel_gt_info
Quoting Daniele Ceraolo Spurio (2020-06-26 17:44:20) > > > On 6/26/20 7:45 AM, Tvrtko Ursulin wrote: > > > > Only thing which looks a bit sub-optimalis the name "max_engine_mask", > > but maybe it is just me, that max and masks do not go well together. > > Only alternative I have for the moment is platform_engine_mask? Or the > > usual double underscore approach. Either way: > > > > I wasn't fully convinced of max_engine_mask either, buy I had no better > ideas :) > > platform_engine_mask sounds good to me, I'll use that. all_engine_mask full_engine_mask possible_engine_mask platform_engine_mask +1 for platform_engine_mask -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/sseu: Move sseu_info under gt_info
On 6/26/20 8:22 AM, Tvrtko Ursulin wrote:
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 ---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_sseu.c | 19 ++-
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 +--
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
Add SSEU to debugfs_gt.c / debugfs_sseu.c ?
I'd prefer not to add it in this patch, to keep it focused on the move.
I'll add an extra patch with the debugfs when I send v2 of the series.
Do you think it is worth having an sseu file by itself or better to have
an info/capabilities one printing both the gt_info and the topology?
Daniele
Regards,
Tvrtko
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c | 9 -
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 3 ---
drivers/gpu/drm/i915/intel_device_info.h | 3 ---
20 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5c13809dc3c8..4fc641d5cb68 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1399,11 +1399,12 @@ static int get_ringsize(struct
i915_gem_context *ctx,
}
int
-i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu *user,
struct intel_sseu *context)
{
- const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
+ const struct sseu_dev_info *device = >->info.sseu;
+ struct drm_i915_private *i915 = gt->i915;
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1536,7 +1537,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(ce->engine->gt, &user_sseu,
&sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 3702b2fb27ab..a133f92bbedb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -225,7 +225,7 @@ i915_gem_engines_iter_next(struct
i915_gem_engines_iter *it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
-int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+int i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu *user,
struct intel_sseu *context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..7ffc3c751432 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1229,7 +1229,7 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
int inst = 0;
int ret = 0;
- if (INTEL_GEN(i915) < 9 || !RUNTIME_INFO(i915)->sseu.has_slice_pg)
+ if (INTEL_GEN(i915) < 9)
return 0;
if (flags & TEST_RESET)
@@ -1255,6 +1255,9 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
if (hweight32(engine->sseu.slice_mask) < 2)
continue;
+ if (!engine->gt->info.sseu.has_slice_pg)
+ continue;
+
/*
* Gen11 VME friendly power-gated configuration with
* half enabled sub-slices.
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 27ae48049239..b9c8163978a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -30,7 +30,7 @@ static int gen8_emit_rpcs_config(struct i915_request
*rq,
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
*cs++ = lowe
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move the engine mask to intel_gt_info
On 6/26/20 7:45 AM, Tvrtko Ursulin wrote:
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In preparation for other info being moved to the gt in follow up patches
(sseu), introduce an intel_gt_info structure to group all gt-related
runtime info.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +++---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 4 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 8
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +--
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ++
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++
drivers/gpu/drm/i915/i915_pci.c | 42 +--
drivers/gpu/drm/i915/intel_device_info.c | 1 -
drivers/gpu/drm/i915/intel_device_info.h | 7 +---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 3 +-
21 files changed, 84 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c38ab51e82f0..7ffac711e4b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1973,8 +1973,7 @@ static int eb_submit(struct i915_execbuffer *eb,
struct i915_vma *batch)
static int num_vcs_engines(const struct drm_i915_private *i915)
{
- return hweight64(INTEL_INFO(i915)->engine_mask &
- GENMASK_ULL(VCS0 + I915_MAX_VCS - 1, VCS0));
+ return hweight64(VDBOX_MASK(&i915->gt));
}
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 8497106eb3a6..3af58df3b13e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -370,7 +370,7 @@ static void __setup_engine_capabilities(struct
intel_engine_cs *engine)
* instances.
*/
if ((INTEL_GEN(i915) >= 11 &&
- RUNTIME_INFO(i915)->vdbox_sfc_access & engine->mask) ||
+ engine->gt->info.vdbox_sfc_access & engine->mask) ||
(INTEL_GEN(i915) >= 9 && engine->instance == 0))
engine->uabi_capabilities |=
I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC;
@@ -459,7 +459,7 @@ void intel_engines_free(struct intel_gt *gt)
static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_gt_info *info = >->info;
struct intel_uncore *uncore = gt->uncore;
unsigned int logical_vdbox = 0;
unsigned int i;
@@ -467,6 +467,8 @@ static intel_engine_mask_t init_engine_mask(struct
intel_gt *gt)
u16 vdbox_mask;
u16 vebox_mask;
+ info->engine_mask = INTEL_INFO(i915)->max_engine_mask;
+
if (INTEL_GEN(i915) < 11)
return info->engine_mask;
@@ -494,7 +496,7 @@ static intel_engine_mask_t init_engine_mask(struct
intel_gt *gt)
* In TGL each VDBOX has access to an SFC.
*/
if (INTEL_GEN(i915) >= 12 || logical_vdbox++ % 2 == 0)
- RUNTIME_INFO(i915)->vdbox_sfc_access |= BIT(i);
+ gt->info.vdbox_sfc_access |= BIT(i);
}
drm_dbg(&i915->drm, "vdbox enable: %04x, instances: %04lx\n",
vdbox_mask, VDBOX_MASK(gt));
@@ -527,7 +529,6 @@ static intel_engine_mask_t init_engine_mask(struct
intel_gt *gt)
int intel_engines_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *device_info = mkwrite_device_info(i915);
const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
unsigned int i;
@@ -557,9 +558,9 @@ int intel_engines_init_mmio(struct intel_gt *gt)
* engines.
*/
if (drm_WARN_ON(&i915->drm, mask != engine_mask))
- device_info->engine_mask = mask;
+ gt->info.engine_mask = mask;
- RUNTIME_INFO(i915)->num_engines = hweight32(mask);
+ gt->info.num_engines = hweight32(mask);
int
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when edid changes (rev8)
On 2020-06-26 at 08:25:24 -0700, Lisovskiy, Stanislav wrote:
> Omg, where did those come from?..
>
> Joshi Kunal: will you fix or should I do that?
>
>
> Best Regards,
>
> Lisovskiy Stanislav
>
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
>
yes stan floated with checkpatch errors removed
>
> From: Jani Nikula
> Sent: Friday, June 26, 2020 6:22:31 PM
> To: Patchwork; Lisovskiy, Stanislav
> Cc: intel-gfx@lists.freedesktop.org; Joshi, Kunal1
> Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when
> edid changes (rev8)
>
> On Wed, 24 Jun 2020, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Send a hotplug when edid changes (rev8)
> > URL : https://patchwork.freedesktop.org/series/62816/
> > State : warning
> >
> > == Summary ==
>
> Please at least fix the spacing issues. Please don't use spaces for
> indentation.
>
> BR,
> Jani.
>
>
> >
> > $ dim checkpatch origin/drm-tip
> > 75d80077 drm: Add helper to compare edids.
> > -:32: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid1"
> > #32: FILE: drivers/gpu/drm/drm_edid.c:1628:
> > + bool edid1_present = edid1 != NULL;
> >
> > -:33: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid2"
> > #33: FILE: drivers/gpu/drm/drm_edid.c:1629:
> > + bool edid2_present = edid2 != NULL;
> >
> > -:39: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
> > #39: FILE: drivers/gpu/drm/drm_edid.c:1635:
> > + if (edid1) {
> > +
> >
> > -:54: CHECK:LINE_SPACING: Please don't use multiple blank lines
> > #54: FILE: drivers/gpu/drm/drm_edid.c:1650:
> > +
> > +
> >
> > total: 0 errors, 0 warnings, 4 checks, 54 lines checked
> > 127303584a7e drm: Introduce epoch counter to drm_connector
> > -:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> > #56: FILE: drivers/gpu/drm/drm_connector.c:2012:
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> > changed.\n",
> > + connector->base.id, connector->name);
> >
> > -:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> > #60: FILE: drivers/gpu/drm/drm_connector.c:2016:
> > + DRM_DEBUG_KMS("Updating change counter to
> > %llu\n",
> > + connector->epoch_counter);
> >
> > -:129: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> > #129: FILE: drivers/gpu/drm/drm_probe_helper.c:790:
> > + uint64_t old_epoch_counter;
> >
> > -:160: WARNING:BRACES: braces {} are not necessary for single statement
> > blocks
> > #160: FILE: drivers/gpu/drm/drm_probe_helper.c:826:
> > + if (old_epoch_counter != connector->epoch_counter) {
> > changed = true;
> > + }
> >
> > -:183: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #183: FILE: include/drm/drm_connector.h:1332:
> > +/** @epoch_counter: used to detect any other changes in connector,
> > besides status */$
> >
> > -:184: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #184: FILE: include/drm/drm_connector.h:1333:
> > +uint64_t epoch_counter;$
> >
> > -:184: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> > #184: FILE: include/drm/drm_connector.h:1333:
> > +uint64_t epoch_counter;$
> >
> > -:184: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> > #184: FILE: include/drm/drm_connector.h:1333:
> > +uint64_t epoch_counter;
> >
> > total: 2 errors, 2 warnings, 4 checks, 136 lines checked
> > 6f6d00bcff9f drm/i915: Send hotplug event if edid had changed
> > -:42: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> > +u64 old_epoch_counter;$
> >
> > -:42: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> > #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> > +u64 old_epoch_counter;$
> >
> > -:43: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> > +bool ret = false;$
> >
> > -:43: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> > #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> > +bool ret = false;$
> >
> > -:62: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> > +if (old_epoch_counter != connector->base.epoch_counter)$
> >
> > -:62: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> > #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> > +if (old_epoch_counter != connector->base.epoch_counter)$
> >
> > -:63: ERROR:CODE_INDENT: code indent should use tabs where possible
> > #63: FILE: drivers/gpu/drm/i915/display/intel_hotpl
[Intel-gfx] [PATCH v6 0/3] Send a hotplug when edid changes
From: Stanislav Lisovskiy From: Stanislav Lisovskiy This series introduce to drm a way to determine if something else except connection_status had changed during probing, which can be used by other drivers as well. Another i915 specific part uses this approach to determine if edid had changed without changing the connection status and send a hotplug event. Stanislav Lisovskiy (3): drm: Add helper to compare edids. drm: Introduce epoch counter to drm_connector drm/i915: Send hotplug event if edid had changed drivers/gpu/drm/drm_connector.c | 16 drivers/gpu/drm/drm_edid.c | 39 +++- drivers/gpu/drm/drm_probe_helper.c | 38 --- drivers/gpu/drm/i915/display/intel_hotplug.c | 24 +++- include/drm/drm_connector.h | 2 + include/drm/drm_edid.h | 9 + 6 files changed, 112 insertions(+), 16 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/3] drm: Add helper to compare edids.
From: Stanislav Lisovskiy
From: Stanislav Lisovskiy
Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.
v2: Added documentation for this function.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_edid.h | 9 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 71ae0cd6d576..920ac9ef6018 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1615,6 +1615,39 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
return true;
}
+/**
+ * drm_edid_are_equal - compare two edid blobs.
+ * @edid1: pointer to first blob
+ * @edid2: pointer to second blob
+ * This helper can be used during probing to determine if
+ * edid had changed.
+ */
+bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2)
+{
+ int edid1_len, edid2_len;
+ bool edid1_present = edid1 != NULL;
+ bool edid2_present = edid2 != NULL;
+
+ if (edid1_present != edid2_present)
+ return false;
+
+ if (edid1) {
+
+ edid1_len = EDID_LENGTH * (1 + edid1->extensions);
+ edid2_len = EDID_LENGTH * (1 + edid2->extensions);
+
+ if (edid1_len != edid2_len)
+ return false;
+
+ if (memcmp(edid1, edid2, edid1_len))
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_edid_are_equal);
+
+
/**
* drm_edid_block_valid - Sanity check the EDID block (base or extension)
* @raw_edid: pointer to raw EDID block
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 43254319ab19..cfa4f5af49af 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -359,6 +359,15 @@ drm_load_edid_firmware(struct drm_connector *connector)
}
#endif
+/**
+ * drm_edid_are_equal - compare two edid blobs.
+ * @edid1: pointer to first blob
+ * @edid2: pointer to second blob
+ * This helper can be used during probing to determine if
+ * edid had changed.
+ */
+bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2);
+
int
drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
const struct drm_connector *connector,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/3] drm: Introduce epoch counter to drm_connector
From: Stanislav Lisovskiy
From: Stanislav Lisovskiy
This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for example hotplug event.
Also now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v2: Added documentation for the new counter. Rename change_counter to
epoch_counter.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105540
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_connector.c| 16 +
drivers/gpu/drm/drm_edid.c | 6 -
drivers/gpu/drm/drm_probe_helper.c | 38 ++
include/drm/drm_connector.h| 2 ++
4 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b7bd46033807..332686297e45 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -269,6 +269,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(&connector->modes);
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
+ connector->epoch_counter = 0;
connector->tile_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
@@ -1979,6 +1980,7 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
struct drm_device *dev = connector->dev;
size_t size = 0;
int ret;
+ const struct edid *old_edid;
/* ignore requests to set edid when overridden */
if (connector->override_edid)
@@ -2002,6 +2004,20 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
drm_update_tile_info(connector, edid);
+ if (connector->edid_blob_ptr) {
+ old_edid = (const struct edid *)connector->edid_blob_ptr->data;
+ if (old_edid) {
+ if (!drm_edid_are_equal(edid, old_edid)) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
changed.\n",
+ connector->base.id, connector->name);
+
+ connector->epoch_counter += 1;
+ DRM_DEBUG_KMS("Updating change counter to
%llu\n",
+ connector->epoch_counter);
+ }
+ }
+ }
+
drm_object_property_set_value(&connector->base,
dev->mode_config.non_desktop_property,
connector->display_info.non_desktop);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 920ac9ef6018..b7530db4a93b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2050,13 +2050,17 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
+ struct edid *edid;
+
if (connector->force == DRM_FORCE_OFF)
return NULL;
if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
return NULL;
- return drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
+ edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
+ drm_connector_update_edid_property(connector, edid);
+ return edid;
}
EXPORT_SYMBOL(drm_get_edid);
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 09e872e61315..7378c61e7fcc 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -292,6 +292,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
*connector, bool force)
if (WARN_ON(ret < 0))
ret = connector_status_unknown;
+ if (ret != connector->status)
+ connector->epoch_counter += 1;
+
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
@@ -325,11 +328,16 @@ drm_helper_probe_detect(struct drm_connector *connector,
return ret;
if (funcs->detect_ctx)
- return funcs->detect_ctx(connector, ctx, force);
+ ret = funcs->detect_ctx(connector, ctx, force);
else if (connector->funcs->detect)
- return connector->funcs->detect(connector, force);
+ ret = connector->funcs->detect(connector, force);
else
- return connector_status_connected;
+ ret = connector_status_connec
[Intel-gfx] [PATCH v6 3/3] drm/i915: Send hotplug event if edid had changed
From: Stanislav Lisovskiy
Added epoch counter checking to intel_encoder_hotplug
in order to be able process all the connector changes,
besides connection status. Also now any change in connector
would result in epoch counter change, so no multiple checks
are needed.
v2: Renamed change counter to epoch counter. Fixed type name.
v3: Fixed rebase conflict
v4: Remove duplicate drm_edid_equal checks from hdmi and dp,
lets use only once edid property is getting updated and
increment epoch counter from there.
Also lets now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v5: Fixed const modifiers, removed blank line
v6: Removed drm specific part from this patch, leaving only
i915 specific changes here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 24
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 2e94c1413c02..80bcfff032e9 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -283,6 +283,8 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
{
struct drm_device *dev = connector->base.dev;
enum drm_connector_status old_status;
+ u64 old_epoch_counter;
+ bool ret = false;
drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
old_status = connector->base.status;
@@ -290,17 +292,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
connector->base.status =
drm_helper_probe_detect(&connector->base, NULL, false);
- if (old_status == connector->base.status)
- return INTEL_HOTPLUG_UNCHANGED;
-
- drm_dbg_kms(&to_i915(dev)->drm,
- "[CONNECTOR:%d:%s] status updated from %s to %s\n",
- connector->base.base.id,
- connector->base.name,
- drm_get_connector_status_name(old_status),
- drm_get_connector_status_name(connector->base.status));
+ if (old_epoch_counter != connector->base.epoch_counter)
+ ret = true;
- return INTEL_HOTPLUG_CHANGED;
+ if (ret) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s(epoch counter %llu)\n",
+ connector->base.base.id,
+ connector->base.name,
+ drm_get_connector_status_name(old_status),
+
drm_get_connector_status_name(connector->base.status),
+ connector->base.epoch_counter);
+ return INTEL_HOTPLUG_CHANGED;
+ }
+ return INTEL_HOTPLUG_UNCHANGED;
}
static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Hi Christian, On Fri, 26 Jun 2020, 18:10 Daniel Vetter, wrote: > On Fri, Jun 26, 2020 at 9:03 AM Christian König > wrote: > > > > Am 26.06.20 um 06:43 schrieb Sumit Semwal: > > > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > >> Ignoring everything else ... > > >> > > >> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula < > jani.nik...@linux.intel.com> wrote: > > >>> As a side note, there seem to be extra checks in place for acks when > > >>> applying non-i915 patches to drm-intel; there are no such checks for > > >>> drm-misc. > > >> One option to generalize that that I pondered is to consult > > >> get_maintainers.pl asking for git repo link, and if that returns > > >> something else, then insist that there's an ack from a relevant > > >> maintainer. It's a bit of typing, but I think the bigger problem is > > >> that there's a ton of false positives. > > > Right; for the particular patch, I wasn't even in the to: or cc: field > > > and that made it slip from my radar. I would definitely ask any one > > > sending patches for dma-buf directory to follow the get_maintainers.pl > > > religiously. > > >> But maybe that's a good thing, would give some motivation to keep > > >> MAINTAINERS updated. > > > > Should I maybe add myself as maintainer as well? I've written enough > > stuff in there to know the code quite a bit. > > I think that makes lots of sense, since defacto you already are :-) > > If you feel like bikeshed, get_maintainers.pl also supports R: for > reviewer, but given that you also push patches to drm-misc M: for > maintainer feels more accurate. > I think given you've been reviewing and changing most of the code around dma-fences, it should be ok to add you as the maintainer for those bits? -Daniel > Best, Sumit. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when edid changes (rev8)
Omg, where did those come from?..
Joshi Kunal: will you fix or should I do that?
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Jani Nikula
Sent: Friday, June 26, 2020 6:22:31 PM
To: Patchwork; Lisovskiy, Stanislav
Cc: intel-gfx@lists.freedesktop.org; Joshi, Kunal1
Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when
edid changes (rev8)
On Wed, 24 Jun 2020, Patchwork wrote:
> == Series Details ==
>
> Series: Send a hotplug when edid changes (rev8)
> URL : https://patchwork.freedesktop.org/series/62816/
> State : warning
>
> == Summary ==
Please at least fix the spacing issues. Please don't use spaces for
indentation.
BR,
Jani.
>
> $ dim checkpatch origin/drm-tip
> 75d80077 drm: Add helper to compare edids.
> -:32: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid1"
> #32: FILE: drivers/gpu/drm/drm_edid.c:1628:
> + bool edid1_present = edid1 != NULL;
>
> -:33: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid2"
> #33: FILE: drivers/gpu/drm/drm_edid.c:1629:
> + bool edid2_present = edid2 != NULL;
>
> -:39: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
> #39: FILE: drivers/gpu/drm/drm_edid.c:1635:
> + if (edid1) {
> +
>
> -:54: CHECK:LINE_SPACING: Please don't use multiple blank lines
> #54: FILE: drivers/gpu/drm/drm_edid.c:1650:
> +
> +
>
> total: 0 errors, 0 warnings, 4 checks, 54 lines checked
> 127303584a7e drm: Introduce epoch counter to drm_connector
> -:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #56: FILE: drivers/gpu/drm/drm_connector.c:2012:
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> changed.\n",
> + connector->base.id, connector->name);
>
> -:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #60: FILE: drivers/gpu/drm/drm_connector.c:2016:
> + DRM_DEBUG_KMS("Updating change counter to
> %llu\n",
> + connector->epoch_counter);
>
> -:129: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> #129: FILE: drivers/gpu/drm/drm_probe_helper.c:790:
> + uint64_t old_epoch_counter;
>
> -:160: WARNING:BRACES: braces {} are not necessary for single statement blocks
> #160: FILE: drivers/gpu/drm/drm_probe_helper.c:826:
> + if (old_epoch_counter != connector->epoch_counter) {
> changed = true;
> + }
>
> -:183: ERROR:CODE_INDENT: code indent should use tabs where possible
> #183: FILE: include/drm/drm_connector.h:1332:
> +/** @epoch_counter: used to detect any other changes in connector,
> besides status */$
>
> -:184: ERROR:CODE_INDENT: code indent should use tabs where possible
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;$
>
> -:184: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;$
>
> -:184: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;
>
> total: 2 errors, 2 warnings, 4 checks, 136 lines checked
> 6f6d00bcff9f drm/i915: Send hotplug event if edid had changed
> -:42: ERROR:CODE_INDENT: code indent should use tabs where possible
> #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> +u64 old_epoch_counter;$
>
> -:42: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> +u64 old_epoch_counter;$
>
> -:43: ERROR:CODE_INDENT: code indent should use tabs where possible
> #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> +bool ret = false;$
>
> -:43: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> +bool ret = false;$
>
> -:62: ERROR:CODE_INDENT: code indent should use tabs where possible
> #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> +if (old_epoch_counter != connector->base.epoch_counter)$
>
> -:62: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> +if (old_epoch_counter != connector->base.epoch_counter)$
>
> -:63: ERROR:CODE_INDENT: code indent should use tabs where possible
> #63: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:296:
> +ret = true;$
>
> -:63: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #63: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:296:
> +ret = true;$
>
> -:65: ERROR:CODE_INDENT: code indent should use tabs where possible
> #65: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:298:
> +if(ret)
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when edid changes (rev8)
On Wed, 24 Jun 2020, Patchwork wrote:
> == Series Details ==
>
> Series: Send a hotplug when edid changes (rev8)
> URL : https://patchwork.freedesktop.org/series/62816/
> State : warning
>
> == Summary ==
Please at least fix the spacing issues. Please don't use spaces for
indentation.
BR,
Jani.
>
> $ dim checkpatch origin/drm-tip
> 75d80077 drm: Add helper to compare edids.
> -:32: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid1"
> #32: FILE: drivers/gpu/drm/drm_edid.c:1628:
> + bool edid1_present = edid1 != NULL;
>
> -:33: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "edid2"
> #33: FILE: drivers/gpu/drm/drm_edid.c:1629:
> + bool edid2_present = edid2 != NULL;
>
> -:39: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
> #39: FILE: drivers/gpu/drm/drm_edid.c:1635:
> + if (edid1) {
> +
>
> -:54: CHECK:LINE_SPACING: Please don't use multiple blank lines
> #54: FILE: drivers/gpu/drm/drm_edid.c:1650:
> +
> +
>
> total: 0 errors, 0 warnings, 4 checks, 54 lines checked
> 127303584a7e drm: Introduce epoch counter to drm_connector
> -:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #56: FILE: drivers/gpu/drm/drm_connector.c:2012:
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> changed.\n",
> + connector->base.id, connector->name);
>
> -:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #60: FILE: drivers/gpu/drm/drm_connector.c:2016:
> + DRM_DEBUG_KMS("Updating change counter to
> %llu\n",
> + connector->epoch_counter);
>
> -:129: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> #129: FILE: drivers/gpu/drm/drm_probe_helper.c:790:
> + uint64_t old_epoch_counter;
>
> -:160: WARNING:BRACES: braces {} are not necessary for single statement blocks
> #160: FILE: drivers/gpu/drm/drm_probe_helper.c:826:
> + if (old_epoch_counter != connector->epoch_counter) {
> changed = true;
> + }
>
> -:183: ERROR:CODE_INDENT: code indent should use tabs where possible
> #183: FILE: include/drm/drm_connector.h:1332:
> +/** @epoch_counter: used to detect any other changes in connector,
> besides status */$
>
> -:184: ERROR:CODE_INDENT: code indent should use tabs where possible
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;$
>
> -:184: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;$
>
> -:184: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
> #184: FILE: include/drm/drm_connector.h:1333:
> +uint64_t epoch_counter;
>
> total: 2 errors, 2 warnings, 4 checks, 136 lines checked
> 6f6d00bcff9f drm/i915: Send hotplug event if edid had changed
> -:42: ERROR:CODE_INDENT: code indent should use tabs where possible
> #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> +u64 old_epoch_counter;$
>
> -:42: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #42: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:286:
> +u64 old_epoch_counter;$
>
> -:43: ERROR:CODE_INDENT: code indent should use tabs where possible
> #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> +bool ret = false;$
>
> -:43: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #43: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:287:
> +bool ret = false;$
>
> -:62: ERROR:CODE_INDENT: code indent should use tabs where possible
> #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> +if (old_epoch_counter != connector->base.epoch_counter)$
>
> -:62: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #62: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:295:
> +if (old_epoch_counter != connector->base.epoch_counter)$
>
> -:63: ERROR:CODE_INDENT: code indent should use tabs where possible
> #63: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:296:
> +ret = true;$
>
> -:63: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #63: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:296:
> +ret = true;$
>
> -:65: ERROR:CODE_INDENT: code indent should use tabs where possible
> #65: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:298:
> +if(ret) {$
>
> -:65: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #65: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:298:
> +if(ret) {$
>
> -:65: ERROR:SPACING: space required before the open parenthesis '('
> #65: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:298:
> +if(ret) {
>
> -:73: ERROR:CODE_INDENT: code indent should use tabs where possible
> #73: FILE: drivers/gpu/drm/i915/display/intel_hotplug.c:306:
> +}$
>
> -:73: WARNING
Re: [Intel-gfx] [PATCH 7/7] drm/i915/sseu: Move sseu_info under gt_info
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 ---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gt.c| 2 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_sseu.c | 19 ++-
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 3 +--
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
Add SSEU to debugfs_gt.c / debugfs_sseu.c ?
Regards,
Tvrtko
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c | 9 -
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 3 ---
drivers/gpu/drm/i915/intel_device_info.h | 3 ---
20 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5c13809dc3c8..4fc641d5cb68 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1399,11 +1399,12 @@ static int get_ringsize(struct i915_gem_context *ctx,
}
int
-i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu
*user,
struct intel_sseu *context)
{
- const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
+ const struct sseu_dev_info *device = >->info.sseu;
+ struct drm_i915_private *i915 = gt->i915;
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1536,7 +1537,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(ce->engine->gt, &user_sseu, &sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 3702b2fb27ab..a133f92bbedb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -225,7 +225,7 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
-int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+int i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu
*user,
struct intel_sseu *context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..7ffc3c751432 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1229,7 +1229,7 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
int inst = 0;
int ret = 0;
- if (INTEL_GEN(i915) < 9 || !RUNTIME_INFO(i915)->sseu.has_slice_pg)
+ if (INTEL_GEN(i915) < 9)
return 0;
if (flags & TEST_RESET)
@@ -1255,6 +1255,9 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
if (hweight32(engine->sseu.slice_mask) < 2)
continue;
+ if (!engine->gt->info.sseu.has_slice_pg)
+ continue;
+
/*
* Gen11 VME friendly power-gated configuration with
* half enabled sub-slices.
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 27ae48049239..b9c8163978a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -30,7 +30,7 @@ static int gen8_emit_rpcs_config(struct i915_request *rq,
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
- *cs++ = intel_sseu_make_rpcs(rq->engine->i915, &sseu);
+ *cs++ = intel_sseu_make_rpcs(rq->engine->gt, &sseu);
intel_ring_ad
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
On Fri, Jun 26, 2020 at 04:46:41PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The linetime watermark is a 9 bit value, which gives us
> > > a maximum linetime of just below 64 usec. If the linetime
> > > exceeds that value we currently just discard the high bits
> > > and program the rest into the register, which angers the
> > > state checker.
> > >
> > > To avoid that let's just clamp the value to the max. I believe
> > > it should be perfectly fine to program a smaller linetime wm
> > > than strictly required, just means the hardware may fetch data
> > > sooner than strictly needed. We are further reassured by the
> > > fact that with DRRS the spec tells us to program the smaller
> > > of the two linetimes corresponding to the two refresh rates.
> > >
> > > Cc: Stanislav Lisovskiy
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 18 --
> > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index a11bb675f9b3..d486d675166f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> > > intel_crtc_state *crtc_state)
> > > {
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > > - adjusted_mode->crtc_clock);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > > + adjusted_mode->crtc_clock);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> >
> > Are we actually doing the right thing here? I just mean that we get value
> > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
>
> As explained in the commit msg programming this to lower than necessary
> value should be totally fine. It just won't be optimal.
>
> The values in the jira (was there an actual gitlab bug for this btw?)
> look quite sensible to me. Some kind of low res 848xsomething mode with
> dotclock of 14.874 Mhz, which gives us that linetime of ~68 usec.
Htotal from modeline "848x480": 30 14874 848 896 928 1008 480 483 488 494 0x40
0x9
is 1008.
According to the formula above htotal(1008)*1000*8 / 14874(crtc_clock) = 542.154
So what's the catch? :)
Stan
>
> >
> > Stan
> > > }
> > >
> > > static u16 hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state,
> > > @@ -12594,12 +12597,15 @@ static u16 hsw_ips_linetime_wm(const struct
> > > intel_crtc_state *crtc_state,
> > > {
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > > - cdclk_state->logical.cdclk);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > > + cdclk_state->logical.cdclk);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> > > }
> > >
> > > static u16 skl_linetime_wm(const struct intel_crtc_state *crtc_state)
> > > @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const struct
> > > intel_crtc_state *crtc_state)
> > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > - u16 linetime_wm;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > > @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> > > intel_crtc_state *crtc_state)
> > > if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> > > linetime_wm /= 2;
> > >
> > > - return linetime_wm;
> > > + return min(linetime_wm, 0x1ff);
> > > }
> > >
> > > static int hsw_compute_linetime_wm(struct intel_atomic_state *state,
> > > --
> > > 2.26.2
> > >
>
> --
> 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.IGT: success for drm/i915: implement Wa_14011508470;gen12
== Series Details == Series: drm/i915: implement Wa_14011508470;gen12 URL : https://patchwork.freedesktop.org/series/78799/ State : success == Summary == CI Bug Log - changes from CI_DRM_8665_full -> Patchwork_18020_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18020_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#1930]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-tglb8/igt@i915_module_l...@reload-with-fault-injection.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-tglb1/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_selftest@live@active: - shard-tglb: [PASS][5] -> [DMESG-FAIL][6] ([i915#666]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-tglb7/igt@i915_selftest@l...@active.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-tglb5/igt@i915_selftest@l...@active.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk9/igt@kms_big...@x-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_concurrent@pipe-a: - shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-iclb7/igt@kms_concurr...@pipe-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-iclb7/igt@kms_concurr...@pipe-a.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-kbl: [PASS][11] -> [DMESG-FAIL][12] ([i915#54] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +12 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-skl1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-skl9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#108145] / [i915#54] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_flip@flip-vs-suspend@c-hdmi-a1: - shard-hsw: [PASS][23] -> [INCOMPLETE][24] ([i915#2055]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-hsw6/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html [24]: https://intel-gfx-ci.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Implement new combo phy initialization step (rev2)
== Series Details ==
Series: drm/i915/display: Implement new combo phy initialization step (rev2)
URL : https://patchwork.freedesktop.org/series/78796/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18027
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/index.html
Known issues
Here are the changes found in Patchwork_18027 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1242])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@vgem_basic@dmabuf-fence:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18027/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8667 -> Patchwork_18027
CI-20190529: 20190529
CI_DRM_8667: 57a1fc457c260002189382a406e920465d
Re: [Intel-gfx] [PATCH 6/7] drm/i915/sseu: Move sseu detection and dump to intel_sseu
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Keep all the SSEU code in the relevant file. The code has also been
updated to use intel_gt instead of dev_priv.
Based on an original patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 587 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 8 +
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 584 +-
drivers/gpu/drm/i915/intel_device_info.h | 2 -
7 files changed, 600 insertions(+), 586 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 949114f09b82..de95930f8627 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -47,6 +47,7 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
int intel_gt_init_mmio(struct intel_gt *gt)
{
intel_uc_init_mmio(>->uc);
+ intel_sseu_info_init(gt);
return intel_engines_init_mmio(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index d173271c7397..006f9118b319 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -60,6 +60,548 @@ intel_sseu_subslices_per_slice(const struct sseu_dev_info
*sseu, u8 slice)
return hweight32(intel_sseu_get_subslices(sseu, slice));
}
+static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ int slice_stride = sseu->max_subslices * sseu->eu_stride;
+
+ return slice * slice_stride + subslice * sseu->eu_stride;
+}
+
+static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ int i, offset = sseu_eu_idx(sseu, slice, subslice);
+ u16 eu_mask = 0;
+
+ for (i = 0; i < sseu->eu_stride; i++) {
+ eu_mask |= ((u16)sseu->eu_mask[offset + i]) <<
+ (i * BITS_PER_BYTE);
+ }
+
+ return eu_mask;
+}
+
+static void sseu_set_eus(struct sseu_dev_info *sseu, int slice, int subslice,
+u16 eu_mask)
+{
+ int i, offset = sseu_eu_idx(sseu, slice, subslice);
+
+ for (i = 0; i < sseu->eu_stride; i++) {
+ sseu->eu_mask[offset + i] =
+ (eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
+ }
+}
+
+static u16 compute_eu_total(const struct sseu_dev_info *sseu)
+{
+ u16 i, total = 0;
+
+ for (i = 0; i < ARRAY_SIZE(sseu->eu_mask); i++)
+ total += hweight8(sseu->eu_mask[i]);
+
+ return total;
+}
+
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
+ u8 s_en, u32 ss_en, u16 eu_en)
+{
+ int s, ss;
+
+ /* ss_en represents entire subslice mask across all slices */
+ GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
+ sizeof(ss_en) * BITS_PER_BYTE);
+
+ for (s = 0; s < sseu->max_slices; s++) {
+ if ((s_en & BIT(s)) == 0)
+ continue;
+
+ sseu->slice_mask |= BIT(s);
+
+ intel_sseu_set_subslices(sseu, s, ss_en);
+
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, s, ss))
+ sseu_set_eus(sseu, s, ss, eu_en);
+ }
+ sseu->eu_per_subslice = hweight16(eu_en);
+ sseu->eu_total = compute_eu_total(sseu);
+}
+
+static void gen12_sseu_info_init(struct intel_gt *gt)
+{
+ struct sseu_dev_info *sseu = &RUNTIME_INFO(gt->i915)->sseu;
+ struct intel_uncore *uncore = gt->uncore;
+ u8 s_en;
+ u32 dss_en;
+ u16 eu_en = 0;
+ u8 eu_en_fuse;
+ int eu;
+
+ /*
+* Gen12 has Dual-Subslices, which behave similarly to 2 gen11 SS.
+* Instead of splitting these, provide userspace with an array
+* of DSS to more closely represent the hardware resource.
+*/
+ intel_sseu_set_info(sseu, 1, 6, 16);
+
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
+
+ dss_en = intel_uncore_read(uncore, GEN12_GT_DSS_ENABLE);
+
+ /* one bit per pair of EUs */
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+
+ gen11_compute_sseu_info(sseu, s_en, dss_en, eu_en);
+
+ /* TGL only supports slice-level power gating */
+ sseu->has_slice_pg = 1;
+}
+
+static void gen11_sseu_info_init(struct intel_gt *g
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Move engine-related mmio init to engines_init_mmio
Quoting Daniele Ceraolo Spurio (2020-06-26 15:46:53)
>
>
> On 6/26/20 7:38 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
> >> All the info we read in intel_device_info_init_mmio are engine-related
> >> and since we already have an engine_init_mmio function we can just
> >> perform the operations from there.
> >>
> >> Signed-off-by: Daniele Ceraolo Spurio
> >> Cc: Tvrtko Ursulin
> >> Cc: Andi Shyti
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-
> >> drivers/gpu/drm/i915/i915_drv.c | 4 --
> >> drivers/gpu/drm/i915/intel_device_info.c | 66 -
> >> drivers/gpu/drm/i915/intel_device_info.h | 2 -
> >> 4 files changed, 71 insertions(+), 73 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> index be92d1ef9aa9..8497106eb3a6 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> @@ -450,6 +450,74 @@ void intel_engines_free(struct intel_gt *gt)
> >> }
> >> }
> >>
> >> +/*
> >> + * Determine which engines are fused off in our particular hardware.
> >> Since the
> >> + * fuse register is in the blitter powerwell, we need forcewake to be
> >> ready at
> >> + * this point (but later we need to prune the forcewake domains for
> >> engines that
> >> + * are indeed fused off).
> >> + */
> >> +static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
> >> +{
> >> + struct drm_i915_private *i915 = gt->i915;
> >> + struct intel_device_info *info = mkwrite_device_info(i915);
> >> + struct intel_uncore *uncore = gt->uncore;
> >> + unsigned int logical_vdbox = 0;
> >> + unsigned int i;
> >> + u32 media_fuse;
> >> + u16 vdbox_mask;
> >> + u16 vebox_mask;
> >
> > assert_forcewakes_active(uncore, FORCEWAKE_BLITTER) ?
> >
> > Since it's called out in the comment, might as well reinforce that with
> > an assert.
>
> We don't expect it to be active, just to be initialized/usable.
> This comment is there to remind us of the catch-22 issue we have where
> we need forcewake to be initialized to read the fuses, but we need the
> fuses values to know which engines are available and therefore which fw
> domains are there (and that's why we prune the domains later).
Gotcha, I assumed 'ready' == 'powered up'
How about adding that explanation to the comment :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Move engine-related mmio init to engines_init_mmio
On 6/26/20 7:38 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-
drivers/gpu/drm/i915/i915_drv.c | 4 --
drivers/gpu/drm/i915/intel_device_info.c | 66 -
drivers/gpu/drm/i915/intel_device_info.h | 2 -
4 files changed, 71 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index be92d1ef9aa9..8497106eb3a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -450,6 +450,74 @@ void intel_engines_free(struct intel_gt *gt)
}
}
+/*
+ * Determine which engines are fused off in our particular hardware. Since the
+ * fuse register is in the blitter powerwell, we need forcewake to be ready at
+ * this point (but later we need to prune the forcewake domains for engines
that
+ * are indeed fused off).
+ */
+static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_uncore *uncore = gt->uncore;
+ unsigned int logical_vdbox = 0;
+ unsigned int i;
+ u32 media_fuse;
+ u16 vdbox_mask;
+ u16 vebox_mask;
assert_forcewakes_active(uncore, FORCEWAKE_BLITTER) ?
Since it's called out in the comment, might as well reinforce that with
an assert.
We don't expect it to be active, just to be initialized/usable.
This comment is there to remind us of the catch-22 issue we have where
we need forcewake to be initialized to read the fuses, but we need the
fuses values to know which engines are available and therefore which fw
domains are there (and that's why we prune the domains later).
Daniele
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Introduce gt_init_mmio
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
We already call 2 gt-related init_mmio functions in driver_mmio_probe
and a 3rd one will be added by a follow-up patch, so pre-emptively
introduce a gt_init_mmio function to group them.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
drivers/gpu/drm/i915/i915_drv.c| 4 +---
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d0ae1cb5c7c9..949114f09b82 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -44,6 +44,13 @@ void intel_gt_init_hw_early(struct intel_gt *gt, struct
i915_ggtt *ggtt)
gt->ggtt = ggtt;
}
+int intel_gt_init_mmio(struct intel_gt *gt)
+{
+ intel_uc_init_mmio(>->uc);
+
+ return intel_engines_init_mmio(gt);
+}
+
static void init_unused_ring(struct intel_gt *gt, u32 base)
{
struct intel_uncore *uncore = gt->uncore;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 15142e2a3b22..4bd64ab2b686 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -36,6 +36,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
*huc)
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
+int intel_gt_init_mmio(struct intel_gt *gt);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
int intel_gt_init(struct intel_gt *gt);
void intel_gt_driver_register(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 67789df42be8..5fd5af4bc855 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -531,9 +531,7 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
- intel_uc_init_mmio(&dev_priv->gt.uc);
-
- ret = intel_engines_init_mmio(&dev_priv->gt);
+ ret = intel_gt_init_mmio(&dev_priv->gt);
if (ret)
goto err_uncore;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move the engine mask to intel_gt_info
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In preparation for other info being moved to the gt in follow up patches
(sseu), introduce an intel_gt_info structure to group all gt-related
runtime info.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++
drivers/gpu/drm/i915/gt/intel_gt.h| 4 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 8
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +--
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ++
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++
drivers/gpu/drm/i915/i915_pci.c | 42 +--
drivers/gpu/drm/i915/intel_device_info.c | 1 -
drivers/gpu/drm/i915/intel_device_info.h | 7 +---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 3 +-
21 files changed, 84 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c38ab51e82f0..7ffac711e4b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1973,8 +1973,7 @@ static int eb_submit(struct i915_execbuffer *eb, struct
i915_vma *batch)
static int num_vcs_engines(const struct drm_i915_private *i915)
{
- return hweight64(INTEL_INFO(i915)->engine_mask &
-GENMASK_ULL(VCS0 + I915_MAX_VCS - 1, VCS0));
+ return hweight64(VDBOX_MASK(&i915->gt));
}
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 8497106eb3a6..3af58df3b13e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -370,7 +370,7 @@ static void __setup_engine_capabilities(struct
intel_engine_cs *engine)
* instances.
*/
if ((INTEL_GEN(i915) >= 11 &&
-RUNTIME_INFO(i915)->vdbox_sfc_access & engine->mask) ||
+engine->gt->info.vdbox_sfc_access & engine->mask) ||
(INTEL_GEN(i915) >= 9 && engine->instance == 0))
engine->uabi_capabilities |=
I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC;
@@ -459,7 +459,7 @@ void intel_engines_free(struct intel_gt *gt)
static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_gt_info *info = >->info;
struct intel_uncore *uncore = gt->uncore;
unsigned int logical_vdbox = 0;
unsigned int i;
@@ -467,6 +467,8 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
+ info->engine_mask = INTEL_INFO(i915)->max_engine_mask;
+
if (INTEL_GEN(i915) < 11)
return info->engine_mask;
@@ -494,7 +496,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
* In TGL each VDBOX has access to an SFC.
*/
if (INTEL_GEN(i915) >= 12 || logical_vdbox++ % 2 == 0)
- RUNTIME_INFO(i915)->vdbox_sfc_access |= BIT(i);
+ gt->info.vdbox_sfc_access |= BIT(i);
}
drm_dbg(&i915->drm, "vdbox enable: %04x, instances: %04lx\n",
vdbox_mask, VDBOX_MASK(gt));
@@ -527,7 +529,6 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
int intel_engines_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- struct intel_device_info *device_info = mkwrite_device_info(i915);
const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
unsigned int i;
@@ -557,9 +558,9 @@ int intel_engines_init_mmio(struct intel_gt *gt)
* engines.
*/
if (drm_WARN_ON(&i915->drm, mask != engine_mask))
- device_info->engine_mask = mask;
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Implement new combo phy initialization step (rev2)
== Series Details == Series: drm/i915/display: Implement new combo phy initialization step (rev2) URL : https://patchwork.freedesktop.org/series/78796/ State : warning == Summary == $ dim checkpatch origin/drm-tip faec0ee3d268 drm/i915/display: Implement new combo phy initialization step -:89: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #89: FILE: drivers/gpu/drm/i915/i915_reg.h:2082: +#define ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_DIV2 REG_FIELD_PREP(ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_MASK, 0x1) total: 0 errors, 1 warnings, 0 checks, 58 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/26] drm/i915: Parse command buffer earlier in eb_relocate(slow)
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 66 ++-
1 file changed, 36 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f896b1a4b38a..7cb44915cfc7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -290,6 +290,8 @@ struct i915_execbuffer {
struct eb_vma_array *array;
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -873,6 +875,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
+ struct drm_i915_private *i915 = eb->i915;
unsigned int batch = eb_batch_index(eb);
unsigned int i;
int err = 0;
@@ -886,18 +889,37 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
vma = eb_lookup_vma(eb, eb->exec[i].handle);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
- break;
+ goto err;
}
err = eb_validate_vma(eb, &eb->exec[i], vma);
if (unlikely(err)) {
i915_vma_put(vma);
- break;
+ goto err;
}
eb_add_vma(eb, i, batch, vma);
}
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(&i915->drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
+ return 0;
+
+err:
eb->vma[i].vma = NULL;
return err;
}
@@ -1809,7 +1831,7 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1872,6 +1894,11 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
if (err)
goto err;
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1904,7 +1931,7 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1932,7 +1959,7 @@ static int eb_relocate(struct i915_execbuffer *eb)
return eb_relocate_slow(eb);
}
- return 0;
+ return eb_parse(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2870,7 +2897,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = eb_relocate(&eb);
+ err = eb_relocate_parse(&eb);
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2883,33 +2910,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(&i915->drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (eb.batch_len == 0)
- eb.batch_len = eb.batch->vma->size - eb.batch_start_offset;
-
- err = eb_parse(&eb
[Intel-gfx] ✓ Fi.CI.BAT: success for iommu: Remove usage of dev->archdata.iommu
== Series Details == Series: iommu: Remove usage of dev->archdata.iommu URL : https://patchwork.freedesktop.org/series/78822/ State : success == Summary == CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18026 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/index.html Known issues Here are the changes found in Patchwork_18026 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_store@basic: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@gem_exec_st...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-tgl-y/igt@gem_exec_st...@basic.html * igt@gem_exec_suspend@basic-s0: - fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#1242]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html - fi-tgl-u2: [PASS][7] -> [FAIL][8] ([i915#1888]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_module_load@reload: - fi-byt-n2820: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-byt-n2820/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-byt-n2820/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Possible fixes * igt@gem_render_linear_blits@basic: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@gem_render_linear_bl...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-tgl-y/igt@gem_render_linear_bl...@basic.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-plain-flip@a-dp1: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18026/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-rea
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Move engine-related mmio init to engines_init_mmio
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
> All the info we read in intel_device_info_init_mmio are engine-related
> and since we already have an engine_init_mmio function we can just
> perform the operations from there.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-
> drivers/gpu/drm/i915/i915_drv.c | 4 --
> drivers/gpu/drm/i915/intel_device_info.c | 66 -
> drivers/gpu/drm/i915/intel_device_info.h | 2 -
> 4 files changed, 71 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index be92d1ef9aa9..8497106eb3a6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -450,6 +450,74 @@ void intel_engines_free(struct intel_gt *gt)
> }
> }
>
> +/*
> + * Determine which engines are fused off in our particular hardware. Since
> the
> + * fuse register is in the blitter powerwell, we need forcewake to be ready
> at
> + * this point (but later we need to prune the forcewake domains for engines
> that
> + * are indeed fused off).
> + */
> +static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
> +{
> + struct drm_i915_private *i915 = gt->i915;
> + struct intel_device_info *info = mkwrite_device_info(i915);
> + struct intel_uncore *uncore = gt->uncore;
> + unsigned int logical_vdbox = 0;
> + unsigned int i;
> + u32 media_fuse;
> + u16 vdbox_mask;
> + u16 vebox_mask;
assert_forcewakes_active(uncore, FORCEWAKE_BLITTER) ?
Since it's called out in the comment, might as well reinforce that with
an assert.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Move engine-related mmio init to engines_init_mmio
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-
drivers/gpu/drm/i915/i915_drv.c | 4 --
drivers/gpu/drm/i915/intel_device_info.c | 66 -
drivers/gpu/drm/i915/intel_device_info.h | 2 -
4 files changed, 71 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index be92d1ef9aa9..8497106eb3a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -450,6 +450,74 @@ void intel_engines_free(struct intel_gt *gt)
}
}
+/*
+ * Determine which engines are fused off in our particular hardware. Since the
+ * fuse register is in the blitter powerwell, we need forcewake to be ready at
+ * this point (but later we need to prune the forcewake domains for engines
that
+ * are indeed fused off).
+ */
+static intel_engine_mask_t init_engine_mask(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_device_info *info = mkwrite_device_info(i915);
+ struct intel_uncore *uncore = gt->uncore;
+ unsigned int logical_vdbox = 0;
+ unsigned int i;
+ u32 media_fuse;
+ u16 vdbox_mask;
+ u16 vebox_mask;
+
+ if (INTEL_GEN(i915) < 11)
+ return info->engine_mask;
+
+ media_fuse = ~intel_uncore_read(uncore, GEN11_GT_VEBOX_VDBOX_DISABLE);
+
+ vdbox_mask = media_fuse & GEN11_GT_VDBOX_DISABLE_MASK;
+ vebox_mask = (media_fuse & GEN11_GT_VEBOX_DISABLE_MASK) >>
+ GEN11_GT_VEBOX_DISABLE_SHIFT;
+
+ for (i = 0; i < I915_MAX_VCS; i++) {
+ if (!HAS_ENGINE(gt, _VCS(i))) {
+ vdbox_mask &= ~BIT(i);
+ continue;
+ }
+
+ if (!(BIT(i) & vdbox_mask)) {
+ info->engine_mask &= ~BIT(_VCS(i));
+ drm_dbg(&i915->drm, "vcs%u fused off\n", i);
+ continue;
+ }
+
+ /*
+* In Gen11, only even numbered logical VDBOXes are
+* hooked up to an SFC (Scaler & Format Converter) unit.
+* In TGL each VDBOX has access to an SFC.
+*/
+ if (INTEL_GEN(i915) >= 12 || logical_vdbox++ % 2 == 0)
+ RUNTIME_INFO(i915)->vdbox_sfc_access |= BIT(i);
+ }
+ drm_dbg(&i915->drm, "vdbox enable: %04x, instances: %04lx\n",
+ vdbox_mask, VDBOX_MASK(gt));
+ GEM_BUG_ON(vdbox_mask != VDBOX_MASK(gt));
+
+ for (i = 0; i < I915_MAX_VECS; i++) {
+ if (!HAS_ENGINE(gt, _VECS(i))) {
+ vebox_mask &= ~BIT(i);
+ continue;
+ }
+
+ if (!(BIT(i) & vebox_mask)) {
+ info->engine_mask &= ~BIT(_VECS(i));
+ drm_dbg(&i915->drm, "vecs%u fused off\n", i);
+ }
+ }
+ drm_dbg(&i915->drm, "vebox enable: %04x, instances: %04lx\n",
+ vebox_mask, VEBOX_MASK(gt));
+ GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
+
+ return info->engine_mask;
+}
+
/**
* intel_engines_init_mmio() - allocate and prepare the Engine Command
Streamers
* @gt: pointer to struct intel_gt
@@ -460,7 +528,7 @@ int intel_engines_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
struct intel_device_info *device_info = mkwrite_device_info(i915);
- const unsigned int engine_mask = INTEL_INFO(i915)->engine_mask;
+ const unsigned int engine_mask = init_engine_mask(gt);
unsigned int mask = 0;
unsigned int i;
int err;
@@ -497,6 +565,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
intel_setup_engine_capabilities(gt);
+ intel_uncore_prune_engine_fw_domains(gt->uncore, gt);
+
return 0;
cleanup:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f9c40cf10ae..611287353420 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -531,10 +531,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
- intel_device_info_init_mmio(dev_priv);
-
- intel_uncore_prune_engine_fw_domains(&dev_priv->uncore, &dev_priv->gt);
-
intel_uc_init_mmio(&dev_priv->gt.uc);
ret = intel_engines_init_mmio(&dev_priv->gt);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index c0443afa12b9..92ebea
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use the gt in HAS_ENGINE
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07) > diff --git a/drivers/gpu/drm/i915/gvt/handlers.c > b/drivers/gpu/drm/i915/gvt/handlers.c > index 26cae4846c82..ddefc52f6e09 100644 > --- a/drivers/gpu/drm/i915/gvt/handlers.c > +++ b/drivers/gpu/drm/i915/gvt/handlers.c > @@ -1867,7 +1867,7 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu > *vgpu, > MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \ > MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \ > MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \ > - if (HAS_ENGINE(dev_priv, VCS1)) \ > + if (HAS_ENGINE(&dev_priv->gt, VCS1)) \ Implicit param! It can switch to gvt->gt for all callsites, killing the dev_priv locals. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for iommu: Remove usage of dev->archdata.iommu
== Series Details == Series: iommu: Remove usage of dev->archdata.iommu URL : https://patchwork.freedesktop.org/series/78822/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restricted __
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Use the gt in HAS_ENGINE
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
A follow up patch will move the engine mask under the gt structure,
so get ready for that.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 ---
drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c| 2 +-
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 15 ---
drivers/gpu/drm/i915/intel_device_info.c | 13 +++--
drivers/gpu/drm/i915/intel_pm.c| 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 16 +---
drivers/gpu/drm/i915/intel_uncore.h| 4 +++-
12 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7bf2f76212f0..be92d1ef9aa9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -473,7 +473,7 @@ int intel_engines_init_mmio(struct intel_gt *gt)
return -ENODEV;
for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
- if (!HAS_ENGINE(i915, i))
+ if (!HAS_ENGINE(gt, i))
continue;
err = intel_engine_setup(gt, i);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0cc7dd54f4f9..e1964cf40fd6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -457,7 +457,7 @@ void gen5_gt_irq_postinstall(struct intel_gt *gt)
* RPS interrupts will get enabled/disabled on demand when RPS
* itself is enabled/disabled.
*/
- if (HAS_ENGINE(gt->i915, VECS0)) {
+ if (HAS_ENGINE(gt, VECS0)) {
pm_irqs |= PM_VEBOX_USER_INTERRUPT;
gt->pm_ier |= PM_VEBOX_USER_INTERRUPT;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 101728006ae9..fbdd6b0677db 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -67,7 +67,8 @@ struct __guc_ads_blob {
static void __guc_ads_init(struct intel_guc *guc)
{
- struct drm_i915_private *dev_priv = guc_to_gt(guc)->i915;
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *dev_priv = gt->i915;
struct __guc_ads_blob *blob = guc->ads_blob;
const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
@@ -103,8 +104,8 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->system_info.rcs_enabled = 1;
blob->system_info.bcs_enabled = 1;
- blob->system_info.vdbox_enable_mask = VDBOX_MASK(dev_priv);
- blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
+ blob->system_info.vdbox_enable_mask = VDBOX_MASK(gt);
+ blob->system_info.vebox_enable_mask = VEBOX_MASK(gt);
blob->system_info.vdbox_sfc_support_mask =
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 26cae4846c82..ddefc52f6e09 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1867,7 +1867,7 @@ static int csfe_chicken1_mmio_write(struct intel_vgpu
*vgpu,
MMIO_F(prefix(BLT_RING_BASE), s, f, am, rm, d, r, w); \
MMIO_F(prefix(GEN6_BSD_RING_BASE), s, f, am, rm, d, r, w); \
MMIO_F(prefix(VEBOX_RING_BASE), s, f, am, rm, d, r, w); \
- if (HAS_ENGINE(dev_priv, VCS1)) \
+ if (HAS_ENGINE(&dev_priv->gt, VCS1)) \
MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, f, am, rm, d, r, w); \
} while (0)
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c b/drivers/gpu/drm/i915/gvt/interrupt.c
index 540017fed908..7498878e6289 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -540,7 +540,7 @@ static void gen8_init_irq(
SET_BIT_INFO(irq, 4, VCS_MI_FLUSH_DW, INTEL_GVT_IRQ_INFO_GT1);
SET_BIT_INFO(irq, 8, VCS_AS_CONTEXT_SWITCH, INTEL_GVT_IRQ_INFO_GT1);
- if (HAS_ENGINE(gvt->gt->i915, VCS1)) {
+ if (HAS_ENGINE(gvt->gt, VCS1)) {
SET_BIT_INFO(irq, 16, VCS2_MI_USER_INTERRUPT,
INTEL_GVT_IRQ_INFO_GT1);
SET_BIT_INFO(irq, 20, VCS2_MI_FLUSH_DW,
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index 2ccaf78f96e8..86a60bdf0818 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -171,7 +171
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for iommu: Remove usage of dev->archdata.iommu
== Series Details == Series: iommu: Remove usage of dev->archdata.iommu URL : https://patchwork.freedesktop.org/series/78822/ State : warning == Summary == $ dim checkpatch origin/drm-tip ea59789bb2c8 iommu/exynos: Use dev_iommu_priv_get/set() -:20: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "dev_iommu_priv_get" #20: FILE: drivers/iommu/exynos-iommu.c:176: +#define has_sysmmu(dev)(dev_iommu_priv_get(dev) != NULL) -:121: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "dev_iommu_priv_get" #121: FILE: drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h:16: + return dev_iommu_priv_get(dev) != NULL; total: 0 errors, 0 warnings, 2 checks, 95 lines checked 751d62a601db iommu/vt-d: Use dev_iommu_priv_get/set() 000b842cda59 iommu/msm: Use dev_iommu_priv_get/set() 79dfab955ac4 iommu/omap: Use dev_iommu_priv_get/set() 3168eb5065df iommu/rockchip: Use dev_iommu_priv_get/set() df87e91a4c59 iommu/tegra: Use dev_iommu_priv_get/set() d14eb31e19bb iommu/pamu: Use dev_iommu_priv_get/set() be1951b09735 iommu/mediatek: Do no use dev->archdata.iommu b86f57d96a87 x86: Remove dev->archdata.iommu pointer beb0e5de86ca ia64: Remove dev->archdata.iommu pointer e36fe82cd6d3 arm: Remove dev->archdata.iommu pointer c154e15c0d13 arm64: Remove dev->archdata.iommu pointer 1cd7039a6769 powerpc/dma: Remove dev->archdata.iommu_domain ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Convert device_info to uncore/de_read
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Use intel__read instead of I915_READ to read the
informational registers.
Extended from an original sseu-only patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/intel_device_info.c | 77 +++-
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 544ac61fbc36..c27a56aff5de 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -26,6 +26,7 @@
#include
#include "display/intel_cdclk.h"
+#include "display/intel_de.h"
#include "intel_device_info.h"
#include "i915_drv.h"
@@ -237,6 +238,7 @@ static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
static void gen12_sseu_info_init(struct drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
+ struct intel_uncore *uncore = &dev_priv->uncore;
u8 s_en;
u32 dss_en;
u16 eu_en = 0;
@@ -250,12 +252,14 @@ static void gen12_sseu_info_init(struct drm_i915_private
*dev_priv)
*/
intel_sseu_set_info(sseu, 1, 6, 16);
- s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
- dss_en = I915_READ(GEN12_GT_DSS_ENABLE);
+ dss_en = intel_uncore_read(uncore, GEN12_GT_DSS_ENABLE);
/* one bit per pair of EUs */
- eu_en_fuse = ~(I915_READ(GEN11_EU_DISABLE) & GEN11_EU_DIS_MASK);
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
@@ -269,6 +273,7 @@ static void gen12_sseu_info_init(struct drm_i915_private
*dev_priv)
static void gen11_sseu_info_init(struct drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
+ struct intel_uncore *uncore = &dev_priv->uncore;
u8 s_en;
u32 ss_en;
u8 eu_en;
@@ -278,9 +283,12 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
else
intel_sseu_set_info(sseu, 1, 8, 8);
- s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
- ss_en = ~I915_READ(GEN11_GT_SUBSLICE_DISABLE);
- eu_en = ~(I915_READ(GEN11_EU_DISABLE) & GEN11_EU_DIS_MASK);
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
+ ss_en = ~intel_uncore_read(uncore, GEN11_GT_SUBSLICE_DISABLE);
+
+ eu_en = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
gen11_compute_sseu_info(sseu, s_en, ss_en, eu_en);
@@ -292,8 +300,9 @@ static void gen11_sseu_info_init(struct drm_i915_private *dev_priv)
static void gen10_sseu_info_init(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
- const u32 fuse2 = I915_READ(GEN8_FUSE2);
+ const u32 fuse2 = intel_uncore_read(uncore, GEN8_FUSE2);
int s, ss;
const int eu_mask = 0xff;
u32 subslice_mask, eu_en;
@@ -304,26 +313,26 @@ static void gen10_sseu_info_init(struct drm_i915_private
*dev_priv)
GEN10_F2_S_ENA_SHIFT;
/* Slice0 */
- eu_en = ~I915_READ(GEN8_EU_DISABLE0);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE0);
for (ss = 0; ss < sseu->max_subslices; ss++)
sseu_set_eus(sseu, 0, ss, (eu_en >> (8 * ss)) & eu_mask);
/* Slice1 */
sseu_set_eus(sseu, 1, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN8_EU_DISABLE1);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE1);
sseu_set_eus(sseu, 1, 1, eu_en & eu_mask);
/* Slice2 */
sseu_set_eus(sseu, 2, 0, (eu_en >> 8) & eu_mask);
sseu_set_eus(sseu, 2, 1, (eu_en >> 16) & eu_mask);
/* Slice3 */
sseu_set_eus(sseu, 3, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN8_EU_DISABLE2);
+ eu_en = ~intel_uncore_read(uncore, GEN8_EU_DISABLE2);
sseu_set_eus(sseu, 3, 1, eu_en & eu_mask);
/* Slice4 */
sseu_set_eus(sseu, 4, 0, (eu_en >> 8) & eu_mask);
sseu_set_eus(sseu, 4, 1, (eu_en >> 16) & eu_mask);
/* Slice5 */
sseu_set_eus(sseu, 5, 0, (eu_en >> 24) & eu_mask);
- eu_en = ~I915_READ(GEN10_EU_DISABLE3);
+ eu_en = ~intel_uncore_read(uncore, GEN10_EU_DISABLE3);
sseu_set_eus(sseu, 5, 1, eu_en & eu_mask);
subslice_mask = (1 << 4) - 1;
@@ -372,7 +381,7 @@ static void cherryview_sseu_info_init(struct
drm_i
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
Hi,
> -Original Message-
> From: Ville Syrjälä
> Sent: perjantai 26. kesäkuuta 2020 17.09
> To: Saarinen, Jani
> Cc: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
>
> On Fri, Jun 26, 2020 at 02:03:23PM +, Saarinen, Jani wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Ville Syrjälä
> > > Sent: perjantai 26. kesäkuuta 2020 16.47
> > > To: Lisovskiy, Stanislav
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to
> > > <64usec
> > >
> > > On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > The linetime watermark is a 9 bit value, which gives us a
> > > > > maximum linetime of just below 64 usec. If the linetime exceeds
> > > > > that value we currently just discard the high bits and program
> > > > > the rest into the register, which angers the state checker.
> > > > >
> > > > > To avoid that let's just clamp the value to the max. I believe
> > > > > it should be perfectly fine to program a smaller linetime wm
> > > > > than strictly required, just means the hardware may fetch data
> > > > > sooner than strictly needed. We are further reassured by the
> > > > > fact that with DRRS the spec tells us to program the smaller of
> > > > > the two linetimes corresponding to the two refresh rates.
> > > > >
> > > > > Cc: Stanislav Lisovskiy
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 18
> > > > > --
> > > > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index a11bb675f9b3..d486d675166f 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const
> > > > > struct intel_crtc_state *crtc_state) {
> > > > > const struct drm_display_mode *adjusted_mode =
> > > > > &crtc_state->hw.adjusted_mode;
> > > > > + int linetime_wm;
> > > > >
> > > > > if (!crtc_state->hw.enable)
> > > > > return 0;
> > > > >
> > > > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> > > 8,
> > > > > - adjusted_mode-
> > > >crtc_clock);
> > > > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> > > 1000 * 8,
> > > > > +
> > > adjusted_mode->crtc_clock);
> > > > > +
> > > > > + return min(linetime_wm, 0x1ff);
> > > >
> > > > Are we actually doing the right thing here? I just mean that we
> > > > get value
> > > > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
> > >
> > > As explained in the commit msg programming this to lower than
> > > necessary value should be totally fine. It just won't be optimal.
> > >
> > > The values in the jira (was there an actual gitlab bug for this
> > > btw?) look quite sensible
> > No, there is no gtilab issue as no tiled display at CI.
>
> Can't see what this has to do with tiled displays. I guess we're talking
> about some
> specific display that just happens to have that super slow mode?
Perhaps, issue where seen in Dell UP2715K.
>
> >
> > > to me. Some kind of low res 848xsomething mode with dotclock of
> > > 14.874 Mhz, which gives us that linetime of ~68 usec.
> > >
> > > >
> > > > Stan
> > > > > }
> > > > >
> > > > > static u16 hsw_ips_linetime_wm(const struct intel_crtc_state
> > > > > *crtc_state, @@ -12594,12 +12597,15 @@ static u16
> > > > > hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state, {
> > > > > const struct drm_display_mode *adjusted_mode =
> > > > > &crtc_state->hw.adjusted_mode;
> > > > > + int linetime_wm;
> > > > >
> > > > > if (!crtc_state->hw.enable)
> > > > > return 0;
> > > > >
> > > > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> > > 8,
> > > > > - cdclk_state-
> > > >logical.cdclk);
> > > > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> > > 1000 * 8,
> > > > > +
> > > cdclk_state->logical.cdclk);
> > > > > +
> > > > > + return min(linetime_wm, 0x1ff);
> > > > > }
> > > > >
> > > > > static u16 skl_linetime_wm(const struct intel_crtc_state
> > > > > *crtc_state) @@ -12608,7 +12614,7 @@ static u16
> > > > > skl_linetime_wm(const
> > > struct intel_crtc_state *crtc_state)
> > > > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > > const struct drm_display_mode *adjusted_mode =
> > > > > &crtc_state->hw.adjusted_mode;
> > > > > - u16 linetime_wm;
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
== Series Details ==
Series: series starting with [1/2] Revert "dma-buf: Report signaled links
inside dma-fence-chain"
URL : https://patchwork.freedesktop.org/series/78819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18025
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/index.html
Known issues
Here are the changes found in Patchwork_18025 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_auth@basic-auth:
- fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-byt-n2820/igt@core_a...@basic-auth.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-byt-n2820/igt@core_a...@basic-auth.html
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#1242])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@i915_hangman@error-state-basic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@i915_hang...@error-state-basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-tgl-y/igt@i915_hang...@error-state-basic.html
* igt@i915_module_load@reload:
- fi-icl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-icl-y/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-icl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Possible fixes
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Warnings
* igt@kms_flip@basic-flip-vs-dpms@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8667/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18025/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8667 -> Patchwork_18025
CI-20190529: 20190529
CI_DRM_8667: 57a1fc457c260002189382a406e920465d540d53 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5718: af1ef32bfae90bcdbaf1b5d84c61ff4e04368505 @
git://anongit.freedesk
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add PSR2 selective fetch registers
On Thu, 2020-06-25 at 18:01 -0700, José Roberto de Souza wrote:
> This registers will be used to implement PSR2 manual
> tracking/selective
> fetch.
>
> v2:
> - Fixed typo in _PLANE_SEL_FETCH_BASE
> - Renamed PSR2_MAN_TRK_CTL bits to better match spec names
> - Renamed _PLANE_SEL_FETCH_* to better match spec names
>
> BSpec: 55229
> BSpec: 50424
> BSpec: 50420
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 68 ++-
> --
> 1 file changed, 63 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index f09120cac89a..8b6eb42b63db 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4585,6 +4585,18 @@ enum {
> #define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> PSR2_SU_STATUS_SHIFT(frame))
> #define PSR2_SU_STATUS_FRAMES8
>
> +#define _PSR2_MAN_TRK_CTL_A 0x60910
> +#define _PSR2_MAN_TRK_CTL_EDP0x6f910
> +#define PSR2_MAN_TRK_CTL(tran) _MMIO_T
> RANS2(tran, _PSR2_MAN_TRK_CTL_A)
> +#define PSR2_MAN_TRK_CTL_ENABLE REG_BIT(31)
> +#define PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK REG_GENMASK(30,
> 21)
> +#define PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val) REG_FIELD_PREP(
> PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
> +#define PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASKREG_GEN
> MASK(20, 11)
> +#define PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val)REG_FIE
> LD_PREP(PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val)
> +#define PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME REG_BIT
> (3)
> +#define PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAMEREG_BIT(2)
> +#define PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATEREG_BIT(1)
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
> @@ -7148,7 +7160,52 @@ enum {
> #define PLANE_COLOR_CTL(pipe, plane) \
> _MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe),
> _PLANE_COLOR_CTL_2(pipe))
>
> -#/* SKL new cursor registers */
> +#define _SEL_FETCH_PLANE_BASE_1_A0x70890
> +#define _SEL_FETCH_PLANE_BASE_2_A0x708B0
> +#define _SEL_FETCH_PLANE_BASE_3_A0x708D0
> +#define _SEL_FETCH_PLANE_BASE_4_A0x708F0
> +#define _SEL_FETCH_PLANE_BASE_5_A0x70920
> +#define _SEL_FETCH_PLANE_BASE_6_A0x70940
> +#define _SEL_FETCH_PLANE_BASE_7_A0x70960
> +#define _SEL_FETCH_PLANE_BASE_CUR_A 0x70880
> +#define _SEL_FETCH_PLANE_BASE_1_B0x70990
> +
> +#define _SEL_FETCH_PLANE_BASE_A(plane) _PICK(plane, \
> + _SEL_FETCH_PLANE_BASE_1_A,
> \
> + _SEL_FETCH_PLANE_BASE_2_A,
> \
> + _SEL_FETCH_PLANE_BASE_3_A,
> \
> + _SEL_FETCH_PLANE_BASE_4_A,
> \
> + _SEL_FETCH_PLANE_BASE_5_A,
> \
> + _SEL_FETCH_PLANE_BASE_6_A,
> \
> + _SEL_FETCH_PLANE_BASE_7_A,
> \
> + _SEL_FETCH_PLANE_BASE_CUR_
> A)
> +#define _SEL_FETCH_PLANE_BASE_1(pipe) _PIPE(pipe,
> _SEL_FETCH_PLANE_BASE_1_A, _SEL_FETCH_PLANE_BASE_1_B)
> +#define _SEL_FETCH_PLANE_BASE(pipe, plane)
> (_SEL_FETCH_PLANE_BASE_1(pipe) - \
> + _SEL_FETCH_PLANE_BASE_1_A +
> \
> + _SEL_FETCH_PLANE_BASE_A(pla
> ne))
> +
> +#define _SEL_FETCH_PLANE_CTL_1_A 0x70890
> +#define PLANE_SEL_FETCH_CTL(pipe, plane)
> _MMIO(_SEL_FETCH_PLANE_BASE(pipe, plane) + \
> +_SEL_FETCH_PLANE_CTL_1_A
> - \
> +_SEL_FETCH_PLANE_BASE_1_
> A)
> +#define PLANE_SET_FETCH_CTL_ENABLE REG_BIT(31)
it seems a typo of "PLANE_SEL_FETCH_CTL_ENABLE",
except for this line, looks good to me.
Reviewed-by: Gwan-gyeong Mun
> +
> +#define _SEL_FETCH_PLANE_POS_1_A 0x70894
> +#define PLANE_SEL_FETCH_POS(pipe, plane)
> _MMIO(_SEL_FETCH_PLANE_BASE(pipe, plane) + \
> +_SEL_FETCH_PLANE_POS_1_A
> - \
> +_SEL_FETCH_PLANE_BASE_1_
> A)
> +
> +#define _SEL_FETCH_PLANE_SIZE_1_A0x70898
> +#define PLANE_SEL_FETCH_SIZE(pipe, plane)
> _MMIO(_SEL_FETCH_PLANE_BASE(pipe, plane) + \
> + _SEL_FETCH_PLANE_SIZE_1
> _A - \
> + _SEL_FETCH_PLANE_BASE_1
> _A)
> +
> +#define _SEL_FETCH_PLANE_OFFSET_1_A 0x7089C
> +#define PLANE_SEL_FETCH_OFFSET(pipe, plane)
> _MMIO(_SEL_FETCH_PLANE_BASE(pipe, plane) + \
> +
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
On Fri, Jun 26, 2020 at 02:03:23PM +, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ville Syrjälä
> > Sent: perjantai 26. kesäkuuta 2020 16.47
> > To: Lisovskiy, Stanislav
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
> >
> > On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > The linetime watermark is a 9 bit value, which gives us a maximum
> > > > linetime of just below 64 usec. If the linetime exceeds that value
> > > > we currently just discard the high bits and program the rest into
> > > > the register, which angers the state checker.
> > > >
> > > > To avoid that let's just clamp the value to the max. I believe it
> > > > should be perfectly fine to program a smaller linetime wm than
> > > > strictly required, just means the hardware may fetch data sooner
> > > > than strictly needed. We are further reassured by the fact that with
> > > > DRRS the spec tells us to program the smaller of the two linetimes
> > > > corresponding to the two refresh rates.
> > > >
> > > > Cc: Stanislav Lisovskiy
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 18
> > > > --
> > > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index a11bb675f9b3..d486d675166f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> > > > intel_crtc_state *crtc_state) {
> > > > const struct drm_display_mode *adjusted_mode =
> > > > &crtc_state->hw.adjusted_mode;
> > > > + int linetime_wm;
> > > >
> > > > if (!crtc_state->hw.enable)
> > > > return 0;
> > > >
> > > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> > 8,
> > > > -adjusted_mode-
> > >crtc_clock);
> > > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> > 1000 * 8,
> > > > +
> > adjusted_mode->crtc_clock);
> > > > +
> > > > + return min(linetime_wm, 0x1ff);
> > >
> > > Are we actually doing the right thing here? I just mean that we get
> > > value
> > > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
> >
> > As explained in the commit msg programming this to lower than necessary
> > value
> > should be totally fine. It just won't be optimal.
> >
> > The values in the jira (was there an actual gitlab bug for this btw?) look
> > quite sensible
> No, there is no gtilab issue as no tiled display at CI.
Can't see what this has to do with tiled displays. I guess we're talking
about some specific display that just happens to have that super slow
mode?
>
> > to me. Some kind of low res 848xsomething mode with dotclock of 14.874 Mhz,
> > which gives us that linetime of ~68 usec.
> >
> > >
> > > Stan
> > > > }
> > > >
> > > > static u16 hsw_ips_linetime_wm(const struct intel_crtc_state
> > > > *crtc_state, @@ -12594,12 +12597,15 @@ static u16
> > > > hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state, {
> > > > const struct drm_display_mode *adjusted_mode =
> > > > &crtc_state->hw.adjusted_mode;
> > > > + int linetime_wm;
> > > >
> > > > if (!crtc_state->hw.enable)
> > > > return 0;
> > > >
> > > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> > 8,
> > > > -cdclk_state-
> > >logical.cdclk);
> > > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> > 1000 * 8,
> > > > +
> > cdclk_state->logical.cdclk);
> > > > +
> > > > + return min(linetime_wm, 0x1ff);
> > > > }
> > > >
> > > > static u16 skl_linetime_wm(const struct intel_crtc_state
> > > > *crtc_state) @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const
> > struct intel_crtc_state *crtc_state)
> > > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > const struct drm_display_mode *adjusted_mode =
> > > > &crtc_state->hw.adjusted_mode;
> > > > - u16 linetime_wm;
> > > > + int linetime_wm;
> > > >
> > > > if (!crtc_state->hw.enable)
> > > > return 0;
> > > > @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> > intel_crtc_state *crtc_state)
> > > > if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> > > > linetime_wm /= 2;
> > > >
> > > > - return linetime_wm;
> > > > + return min(linetime_wm, 0x1ff);
> > > > }
> > > >
> > > > static int hsw_compute_linetime_
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: perjantai 26. kesäkuuta 2020 16.47
> To: Lisovskiy, Stanislav
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
>
> On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The linetime watermark is a 9 bit value, which gives us a maximum
> > > linetime of just below 64 usec. If the linetime exceeds that value
> > > we currently just discard the high bits and program the rest into
> > > the register, which angers the state checker.
> > >
> > > To avoid that let's just clamp the value to the max. I believe it
> > > should be perfectly fine to program a smaller linetime wm than
> > > strictly required, just means the hardware may fetch data sooner
> > > than strictly needed. We are further reassured by the fact that with
> > > DRRS the spec tells us to program the smaller of the two linetimes
> > > corresponding to the two refresh rates.
> > >
> > > Cc: Stanislav Lisovskiy
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 18
> > > --
> > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index a11bb675f9b3..d486d675166f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> > > intel_crtc_state *crtc_state) {
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> 8,
> > > - adjusted_mode-
> >crtc_clock);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> 1000 * 8,
> > > +
> adjusted_mode->crtc_clock);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> >
> > Are we actually doing the right thing here? I just mean that we get
> > value
> > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
>
> As explained in the commit msg programming this to lower than necessary value
> should be totally fine. It just won't be optimal.
>
> The values in the jira (was there an actual gitlab bug for this btw?) look
> quite sensible
No, there is no gtilab issue as no tiled display at CI.
> to me. Some kind of low res 848xsomething mode with dotclock of 14.874 Mhz,
> which gives us that linetime of ~68 usec.
>
> >
> > Stan
> > > }
> > >
> > > static u16 hsw_ips_linetime_wm(const struct intel_crtc_state
> > > *crtc_state, @@ -12594,12 +12597,15 @@ static u16
> > > hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state, {
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> 8,
> > > - cdclk_state-
> >logical.cdclk);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> 1000 * 8,
> > > +
> cdclk_state->logical.cdclk);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> > > }
> > >
> > > static u16 skl_linetime_wm(const struct intel_crtc_state
> > > *crtc_state) @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const
> struct intel_crtc_state *crtc_state)
> > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > const struct drm_display_mode *adjusted_mode =
> > > &crtc_state->hw.adjusted_mode;
> > > - u16 linetime_wm;
> > > + int linetime_wm;
> > >
> > > if (!crtc_state->hw.enable)
> > > return 0;
> > > @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> intel_crtc_state *crtc_state)
> > > if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> > > linetime_wm /= 2;
> > >
> > > - return linetime_wm;
> > > + return min(linetime_wm, 0x1ff);
> > > }
> > >
> > > static int hsw_compute_linetime_wm(struct intel_atomic_state
> > > *state,
> > > --
> > > 2.26.2
> > >
>
> --
> Ville Syrjälä
> Intel
> ___
> 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 08/26] drm/i915/gem: Make eb_add_lut interruptible wait on object lock.
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2636a130fb57..aa441af81431 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -774,7 +774,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
if (err == 0) { /* And nor has this handle */
struct drm_i915_gem_object *obj = vma->obj;
- i915_gem_object_lock(obj, NULL);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
+ if (err) {
+ radix_tree_delete(&ctx->handles_vma, handle);
+ goto unlock;
+ }
+
if (idr_find(&eb->file->object_idr, handle) == obj) {
list_add(&lut->obj_link, &obj->lut_list);
} else {
@@ -783,6 +788,7 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
}
i915_gem_object_unlock(obj);
}
+unlock:
mutex_unlock(&ctx->mutex);
}
if (unlikely(err))
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The linetime watermark is a 9 bit value, which gives us
> > a maximum linetime of just below 64 usec. If the linetime
> > exceeds that value we currently just discard the high bits
> > and program the rest into the register, which angers the
> > state checker.
> >
> > To avoid that let's just clamp the value to the max. I believe
> > it should be perfectly fine to program a smaller linetime wm
> > than strictly required, just means the hardware may fetch data
> > sooner than strictly needed. We are further reassured by the
> > fact that with DRRS the spec tells us to program the smaller
> > of the two linetimes corresponding to the two refresh rates.
> >
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a11bb675f9b3..d486d675166f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> > intel_crtc_state *crtc_state)
> > {
> > const struct drm_display_mode *adjusted_mode =
> > &crtc_state->hw.adjusted_mode;
> > + int linetime_wm;
> >
> > if (!crtc_state->hw.enable)
> > return 0;
> >
> > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > -adjusted_mode->crtc_clock);
> > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > + adjusted_mode->crtc_clock);
> > +
> > + return min(linetime_wm, 0x1ff);
>
> Are we actually doing the right thing here? I just mean that we get value
> 543 in the bug because pixel rate is 14874 which doesn't seem correct.
As explained in the commit msg programming this to lower than necessary
value should be totally fine. It just won't be optimal.
The values in the jira (was there an actual gitlab bug for this btw?)
look quite sensible to me. Some kind of low res 848xsomething mode with
dotclock of 14.874 Mhz, which gives us that linetime of ~68 usec.
>
> Stan
> > }
> >
> > static u16 hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state,
> > @@ -12594,12 +12597,15 @@ static u16 hsw_ips_linetime_wm(const struct
> > intel_crtc_state *crtc_state,
> > {
> > const struct drm_display_mode *adjusted_mode =
> > &crtc_state->hw.adjusted_mode;
> > + int linetime_wm;
> >
> > if (!crtc_state->hw.enable)
> > return 0;
> >
> > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > -cdclk_state->logical.cdclk);
> > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> > + cdclk_state->logical.cdclk);
> > +
> > + return min(linetime_wm, 0x1ff);
> > }
> >
> > static u16 skl_linetime_wm(const struct intel_crtc_state *crtc_state)
> > @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const struct
> > intel_crtc_state *crtc_state)
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &crtc_state->hw.adjusted_mode;
> > - u16 linetime_wm;
> > + int linetime_wm;
> >
> > if (!crtc_state->hw.enable)
> > return 0;
> > @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> > intel_crtc_state *crtc_state)
> > if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> > linetime_wm /= 2;
> >
> > - return linetime_wm;
> > + return min(linetime_wm, 0x1ff);
> > }
> >
> > static int hsw_compute_linetime_wm(struct intel_atomic_state *state,
> > --
> > 2.26.2
> >
--
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 05/26] drm/i915: Remove locking from i915_gem_object_prepare_read/write
On 6/23/20 4:28 PM, Maarten Lankhorst wrote: Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance, fix that up. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++-- drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 - .../gpu/drm/i915/gem/selftests/huge_pages.c | 5 - .../i915/gem/selftests/i915_gem_coherency.c | 14 + .../drm/i915/gem/selftests/i915_gem_context.c | 12 --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/i915_gem.c | 20 +-- 8 files changed, 59 insertions(+), 27 deletions(-) ltgm. Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/gem: Acquire all vma/objects under reservation_ww_class
Quoting Christian König (2020-06-26 12:35:30) > Am 26.06.20 um 13:10 schrieb Chris Wilson: > > Quoting Christian König (2020-06-26 09:54:19) > > [SNIP] > >> In other words "fence -> userspace -> page fault -> fence" or "fence -> > >> userspace -> system call -> fence" can easily cause the same problem and > >> that is not avoidable. > >> > >>> An example > >>> > >>> Thread A Thread B > >>> > >>>submit(VkCmdWaitEvents) > >>>recvfrom(ThreadB) ... sendto(ThreadB) > >>>\- alloc_page > >>> \- direct reclaim > >>> \- dma_fence_wait(A) > >>>VkSetEvent() > >>> > >>> Regardless of that actual deadlock, waiting on an arbitrary fence incurs > >>> an unbounded latency which is unacceptable for direct reclaim. > >>> > >>> Online debugging can indefinitely suspend fence signaling, and the only > >>> guarantee we make of forward progress, in some cases, is process > >>> termination. > >> And exactly that is what doesn't work. You don't have any forward > >> progress any more because you ran into a software deadlock. > > Only one side is halted. Everything on that side comes to a grinding > > halt. > > > > What about checkpoint/restore, suspend/resume? Where we need to suspend > > all execution, move all the resources to one side, then put everything > > back, without cancelling the fences. Same halting problem, no? > > What are you talking about? Of course we either wait for all fences to > complete or cancel them on suspend. I do not want to have to cancel incomplete fences as we do today. I want to restore the suspended execution back to waiting on its VkEvent. > > We also do similar for resets. Suspend the hanging context, move it and > > all dependent execution off to one side; record what we can, clean up > > what we have to, then move what remains of the execution back to finish > > signaling. > > Yes, but this is not possible in this situation. In the bad case you > have a kernel deadlock and that can't be cleaned up in any way. Fences are not disturbed in this process. > > The only solution left in that situation is to reset the system or at > least reload the kernel and that is not acceptable. > > >> In other words the signaling of a fence depends on the welfare of > >> userspace. You can try to kill userspace, but this can wait for the > >> fence you try to signal in the first place. > > The only scenario that fits what you are describing here [userspace > > ignoring a signal] is if you used an uninterruptible wait. Under what > > circumstances during normal execution would you do that? If it's > > someone else's wait, a bug outside of our control. > > Uninterruptible waits are a necessity. > > Just take a look at the dma_fence_wait() interface. Why to you think we > have ability to wait uninterruptible there? > > We need this when there is no other way of recovering. For example when > operations are already partially flushed to the hardware and can't be > aborted any more. So why wait in the middle of submission, rather than defer the submission to the fence callback if the HW wasn't ready? You then have your uninterruptible continuation. > > But if you have chosen to cancel the fences, there is nothing to stop > > the signaling. > > And just to repeat myself: You can't cancel the fence! > > For example assume that canceling the proxy fence would mean that you > send a SIGKILL to the process which issued it. But then you need to wait > for the SIGKILL to be processed. What? Where does SIGKILL come from for fence handling? The proxy fence is force signaled in an error state (e.g. -ETIMEDOUT), every waiter then inherits the error state and all of their waiters down the chain. Those waiters are now presumably ready to finish their own signaling. The proxy fence is constructed to always complete if it does not get resolved; after resolution, the onus is on the real fence to complete. The same as handling any other error or context cancellation during fence submission. > Now what can happen is that the process is uninterruptible waiting for > something which then needs the SIGKILL to be delivered -> kernel deadlock. > > >> See the difference to a deadlock on the GPU is that you can can always > >> kill a running job or process even if it is stuck with something else. > >> But if the kernel is deadlocked with itself you can't kill the process > >> any more, the only option left to get cleanly out of this is to reboot > >> the kernel. > > However, I say that is under our control. We know what fences are in an > > execution context, just as easily as we know that we are inside an > > execution context. And yes, the easiest, the most restrictive way to > > control it is to say don't bother. > > No, that is absolutely not under our control. > > dma_fences need to be waited on under a lot of different context
[Intel-gfx] ✓ Fi.CI.IGT: success for Send a hotplug when edid changes (rev8)
== Series Details == Series: Send a hotplug when edid changes (rev8) URL : https://patchwork.freedesktop.org/series/62816/ State : success == Summary == CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18016_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18016_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed@vebox: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#2064]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-tglb6/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-iclb: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-iclb1/igt@kms_big...@y-tiled-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-iclb3/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-kbl: [PASS][9] -> [DMESG-FAIL][10] ([i915#54] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-skl6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-kbl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#108145] / [i915#54] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-apl: [PASS][15] -> [DMESG-FAIL][16] ([i915#1635] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-apl8/igt@kms_flip_til...@flip-changes-tiling.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-apl4/igt@kms_flip_til...@flip-changes-tiling.html - shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl6/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_plane@plane-position-hole-dpms-pipe-a-planes: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#93] / [i915#95]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl7/igt@kms_pl...@plane-position-hole-dpms-pipe-a-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl6/igt@kms_pl...@plane-position-hole-dpms-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) +1 similar issue [23]: https://int
[Intel-gfx] ✓ Fi.CI.IGT: success for mm: Skip opportunistic reclaim for dma pinned pages
== Series Details == Series: mm: Skip opportunistic reclaim for dma pinned pages URL : https://patchwork.freedesktop.org/series/78795/ State : success == Summary == CI Bug Log - changes from CI_DRM_8665_full -> Patchwork_18019_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18019_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_read@empty-nonblock: - shard-snb: [PASS][1] -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-snb2/igt@drm_r...@empty-nonblock.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-snb2/igt@drm_r...@empty-nonblock.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1930]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-tglb1/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-tglb3/igt@i915_module_l...@reload.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk4/igt@kms_big...@linear-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-kbl: [PASS][11] -> [DMESG-FAIL][12] ([i915#54] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html - shard-glk: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-glk7/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-glk8/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_crc@pipe-b-cursor-128x42-random: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([CI#80]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-hsw6/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-hsw6/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +13 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-kbl: [PASS][19] -> [DMESG-FAIL][20] ([fdo#108145] / [i915#54] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-kbl7/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@plain-flip-ts-check@b-dp1: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#1928]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/shard-kbl2/igt@kms_flip@plain-flip-ts-ch...@b-dp1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/shard-kbl3/igt@kms_flip@plain-flip-ts-ch...@b-dp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-apl: [PASS][25] -> [DMESG-FAIL][26] ([i915#1635] / [i915#95]) [25]
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
On Fri, Jun 26, 2020 at 9:03 AM Christian König wrote: > > Am 26.06.20 um 06:43 schrieb Sumit Semwal: > > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > >> Ignoring everything else ... > >> > >> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula > >> wrote: > >>> As a side note, there seem to be extra checks in place for acks when > >>> applying non-i915 patches to drm-intel; there are no such checks for > >>> drm-misc. > >> One option to generalize that that I pondered is to consult > >> get_maintainers.pl asking for git repo link, and if that returns > >> something else, then insist that there's an ack from a relevant > >> maintainer. It's a bit of typing, but I think the bigger problem is > >> that there's a ton of false positives. > > Right; for the particular patch, I wasn't even in the to: or cc: field > > and that made it slip from my radar. I would definitely ask any one > > sending patches for dma-buf directory to follow the get_maintainers.pl > > religiously. > >> But maybe that's a good thing, would give some motivation to keep > >> MAINTAINERS updated. > > Should I maybe add myself as maintainer as well? I've written enough > stuff in there to know the code quite a bit. I think that makes lots of sense, since defacto you already are :-) If you feel like bikeshed, get_maintainers.pl also supports R: for reviewer, but given that you also push patches to drm-misc M: for maintainer feels more accurate. -Daniel > > Christian. > > >> > >> The other issue is though that drm-misc is plenty used to merge > >> patches even when the respective maintainers are absent for weeks, or > >> unresponsive. If we just blindly implement that rule, then the only > >> possible Ack for these would be Dave&me as subsystem maintainers, and > >> I don't want to be in the business of stamping approvals for all this > >> stuff. Much better if people just collaborate. > >> > >> So I think an ack check would be nice, but probably not practical. > >> > >> Plus in this situation here drm-misc.git actually is the main repo, > >> and we wont ever be able to teach a script to make a judgement call of > >> whether that patch has the right amount of review on it. > >> -Daniel > > Best, > > Sumit. > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter
URL : https://patchwork.freedesktop.org/series/78807/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18024
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18024 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18024, 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_18024/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18024:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-cml-s: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-cml-s/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_18024 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][2] -> [DMESG-WARN][3] ([i915#1982]) +1 similar
issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][4] -> [DMESG-WARN][5] ([i915#402])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [INCOMPLETE][6] ([i915#1242]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][8] ([i915#1982]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_module_l...@reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][15] ([i915#62] / [i915#92]) +3 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][16] ([i915#62] / [i915#92]) ->
[DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18024/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 39)
--
Additional
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter
== Series Details == Series: series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter URL : https://patchwork.freedesktop.org/series/78807/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9:
[Intel-gfx] ✗ Fi.CI.BAT: failure for display/ddi: keep register indexes in a table
== Series Details ==
Series: display/ddi: keep register indexes in a table
URL : https://patchwork.freedesktop.org/series/78806/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18023
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18023 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18023, 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_18023/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18023:
### CI changes ###
Possible regressions
* boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-hsw-4770/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-hsw-4770/boot.html
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-tgl-y: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-tgl-y/igt@run...@aborted.html
- fi-tgl-u2: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-tgl-u2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_18023 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-glk-dsi/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18023/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 37)
--
Additional (1): fi-tgl-y
Missing(8): fi-ilk-m540 fi-ehl-1 fi-hsw-4200u fi-byt-squawks fi-icl-u2
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8665 -> Patchwork_18023
CI-20190529: 20190529
CI_DRM_8665: 2cb786fa6506e20b5cb2a10decda11454111e026 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5717: 725bf2dae51f0087eaa64f1931a2ef9d22f070dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18023: 8e1bf7ebdffd468b4f30978f703d89324e4791b8 @
git://anongit.freedesktop.org/gfx-ci/
Re: [Intel-gfx] [PATCH 09/13] x86: Remove dev->archdata.iommu pointer
On Thu, Jun 25, 2020 at 03:08:32PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> There are no users left, all drivers have been converted to use the
> per-device private pointer offered by IOMMU core.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/device.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
> index 49bd6cf3eec9..7c0a52ca2f4d 100644
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -3,9 +3,6 @@
> #define _ASM_X86_DEVICE_H
>
> struct dev_archdata {
> -#ifdef CONFIG_IOMMU_API
> - void *iommu; /* hook for IOMMU specific extension */
> -#endif
> };
>
> struct pdev_archdata {
> --
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for display/ddi: keep register indexes in a table
== Series Details == Series: display/ddi: keep register indexes in a table URL : https://patchwork.freedesktop.org/series/78806/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbal
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for display/ddi: keep register indexes in a table
== Series Details ==
Series: display/ddi: keep register indexes in a table
URL : https://patchwork.freedesktop.org/series/78806/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1c318e3abcdc drm/i915: move ICL port F hack to intel_bios
f1e31b8bd6eb drm/i915/display: fix comment on skl straps
50167b8d3287 drm/i915/display: start description-based ddi initialization
4bb4855c4a15 drm/i915/display: add phy, vbt and ddi indexes
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
one to the other. Right now we already cover part of this by creating kind of
-:42: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/display/intel_display.c:16809:
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
-:43: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#43: FILE: drivers/gpu/drm/i915/display/intel_display.c:16810:
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
-:45: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#45: FILE: drivers/gpu/drm/i915/display/intel_display.c:16812:
+ { .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
-:46: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#46: FILE: drivers/gpu/drm/i915/display/intel_display.c:16813:
+ { .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
-:59: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#59: FILE: drivers/gpu/drm/i915/display/intel_display.c:16818:
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
-:60: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#60: FILE: drivers/gpu/drm/i915/display/intel_display.c:16819:
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
-:62: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#62: FILE: drivers/gpu/drm/i915/display/intel_display.c:16821:
+ { .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
-:63: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#63: FILE: drivers/gpu/drm/i915/display/intel_display.c:16822:
+ { .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
-:64: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#64: FILE: drivers/gpu/drm/i915/display/intel_display.c:16823:
+ { .name = "DDI TC3", .port = PORT_F, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x5, .phy_idx = 0x2, .vbt_idx = 0x4, },
-:65: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#65: FILE: drivers/gpu/drm/i915/display/intel_display.c:16824:
+ { .name = "DDI TC4", .port = PORT_G, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x6, .phy_idx = 0x3, .vbt_idx = 0x5, },
-:66: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#66: FILE: drivers/gpu/drm/i915/display/intel_display.c:16825:
+ { .name = "DDI TC5", .port = PORT_H, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x7, .phy_idx = 0x4, .vbt_idx = 0x6, },
-:67: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#67: FILE: drivers/gpu/drm/i915/display/intel_display.c:16826:
+ { .name = "DDI TC6", .port = PORT_I, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x8, .phy_idx = 0x5, .vbt_idx = 0x7, },
-:76: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#76: FILE: drivers/gpu/drm/i915/display/intel_display.c:16831:
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
-:77: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#77: FILE: drivers/gpu/drm/i915/display/intel_display.c:16832:
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
-:78: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#78: FILE: drivers/gpu/drm/i915/display/intel_display.c:16833:
+ { .name = "DDI C", .port = PORT_C, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x2, .phy_idx = 0x2, .vbt_idx = 0x2, },
-:79: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#79: FILE: drivers/gpu/drm/i915/display/intel_display.c:16834:
+ { .name = "DDI D", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x3, .phy_idx = 0x0, .vbt_idx = 0x3, },
-:90: WARNING:LONG_LINE: line length of 122 exceeds 100 columns
#90: FILE: drivers/gpu/drm/i915/display/intel_display.c:16839:
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0,},
-:91: WARNING:LONG_LINE: line length of 122 exceeds 100 columns
#91: FILE:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for VRR capable attach prop in i915, VRR debugfs (rev3)
== Series Details == Series: VRR capable attach prop in i915, VRR debugfs (rev3) URL : https://patchwork.freedesktop.org/series/78670/ State : failure == Summary == Applying: drm/i915/dp: Attach and set drm connector VRR property Applying: drm/debug: Expose connector VRR monitor range via debugfs Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_debugfs.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: Revert "drm/amd/display: Expose connector VRR range via debugfs" Using index info to reconstruct a base tree... M drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 Revert "drm/amd/display: Expose connector VRR range via debugfs" When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/gem: Acquire all vma/objects under reservation_ww_class
Am 26.06.20 um 13:10 schrieb Chris Wilson: Quoting Christian König (2020-06-26 09:54:19) [SNIP] In other words "fence -> userspace -> page fault -> fence" or "fence -> userspace -> system call -> fence" can easily cause the same problem and that is not avoidable. An example Thread A Thread B submit(VkCmdWaitEvents) recvfrom(ThreadB) ... sendto(ThreadB) \- alloc_page \- direct reclaim \- dma_fence_wait(A) VkSetEvent() Regardless of that actual deadlock, waiting on an arbitrary fence incurs an unbounded latency which is unacceptable for direct reclaim. Online debugging can indefinitely suspend fence signaling, and the only guarantee we make of forward progress, in some cases, is process termination. And exactly that is what doesn't work. You don't have any forward progress any more because you ran into a software deadlock. Only one side is halted. Everything on that side comes to a grinding halt. What about checkpoint/restore, suspend/resume? Where we need to suspend all execution, move all the resources to one side, then put everything back, without cancelling the fences. Same halting problem, no? What are you talking about? Of course we either wait for all fences to complete or cancel them on suspend. We also do similar for resets. Suspend the hanging context, move it and all dependent execution off to one side; record what we can, clean up what we have to, then move what remains of the execution back to finish signaling. Yes, but this is not possible in this situation. In the bad case you have a kernel deadlock and that can't be cleaned up in any way. The only solution left in that situation is to reset the system or at least reload the kernel and that is not acceptable. In other words the signaling of a fence depends on the welfare of userspace. You can try to kill userspace, but this can wait for the fence you try to signal in the first place. The only scenario that fits what you are describing here [userspace ignoring a signal] is if you used an uninterruptible wait. Under what circumstances during normal execution would you do that? If it's someone else's wait, a bug outside of our control. Uninterruptible waits are a necessity. Just take a look at the dma_fence_wait() interface. Why to you think we have ability to wait uninterruptible there? We need this when there is no other way of recovering. For example when operations are already partially flushed to the hardware and can't be aborted any more. But if you have chosen to cancel the fences, there is nothing to stop the signaling. And just to repeat myself: You can't cancel the fence! For example assume that canceling the proxy fence would mean that you send a SIGKILL to the process which issued it. But then you need to wait for the SIGKILL to be processed. Now what can happen is that the process is uninterruptible waiting for something which then needs the SIGKILL to be delivered -> kernel deadlock. See the difference to a deadlock on the GPU is that you can can always kill a running job or process even if it is stuck with something else. But if the kernel is deadlocked with itself you can't kill the process any more, the only option left to get cleanly out of this is to reboot the kernel. However, I say that is under our control. We know what fences are in an execution context, just as easily as we know that we are inside an execution context. And yes, the easiest, the most restrictive way to control it is to say don't bother. No, that is absolutely not under our control. dma_fences need to be waited on under a lot of different context, including the reclaim path as well as the MMU notifiers, memory pressure callbacks, OOM killer Just see Daniels patches on the lockdep fence signaling annotation and what this work bubbled up on problems. The only way to avoid this would be to never ever wait for the fence in the kernel and then your whole construct is not useful any more. I advocate for moving as much as is feasible, for some waits are required by userspace as a necessary evil, into the parallelised pipeline. I'm running out of ideas how to explain what the problem is here Oh we agree on the problem, we appear to disagree that the implicit waits themselves are a serious existent problem. That they are worth effort to avoid or, at least, mitigate. No, as far as I can see you don't seem to either understand the problem or the implications of it. The only way to solve this would be to audit the whole Linux kernel and remove all uninterruptible waits and that is not feasible. As long as you don't provide me with a working solution to the problem I've outlined here the whole approach is a clear NAK since it will allow to create really bad kernel deadlocks. Sorry to say that, but this whole t
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Send a hotplug when edid changes (rev8)
Sure it is gem as usual. gem_ctx_persistance test is absolutely orthogonal to any hotplug funcitonality. Also it fails almost on weekly basis. Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo From: Saarinen, Jani Sent: Friday, June 26, 2020 2:32:52 PM To: Lisovskiy, Stanislav Subject: FW: [Intel-gfx] ✗ Fi.CI.IGT: failure for Send a hotplug when edid changes (rev8) Hi, Can you comment if that issue is real on that gem test that fails... > -Original Message- > From: Intel-gfx On Behalf Of > Patchwork > Sent: perjantai 26. kesäkuuta 2020 12.59 > To: Lisovskiy, Stanislav > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Send a hotplug when edid > changes (rev8) > > == Series Details == > > Series: Send a hotplug when edid changes (rev8) > URL : https://patchwork.freedesktop.org/series/62816/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18016_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_18016_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18016_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_18016_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_ctx_persistence@legacy-engines-mixed@vebox: > - shard-skl: [PASS][1] -> [FAIL][2] >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > skl6/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > skl4/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html > > > Known issues > > > Here are the changes found in Patchwork_18016_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_isolation@preservation-s3@rcs0: > - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 > similar issue >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > kbl7/igt@gem_ctx_isolation@preservation...@rcs0.html > > * igt@i915_module_load@reload-with-fault-injection: > - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 > similar issue >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > tglb6/igt@i915_module_l...@reload-with-fault-injection.html >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > tglb5/igt@i915_module_l...@reload-with-fault-injection.html > > * igt@kms_big_fb@y-tiled-64bpp-rotate-0: > - shard-iclb: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > iclb1/igt@kms_big...@y-tiled-64bpp-rotate-0.html >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > iclb3/igt@kms_big...@y-tiled-64bpp-rotate-0.html > > * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: > - shard-kbl: [PASS][9] -> [DMESG-FAIL][10] ([i915#54] / > [i915#95]) >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html > > * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: > - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +10 > similar issues >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > skl6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html > > * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: > - shard-kbl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#108145] / > [i915#54] / > [i915#95]) >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > kbl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard- > kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html > > * igt@kms_flip_tiling@flip-changes-tiling: > - shard-apl: [PASS][15] -> [DMESG-FAIL][16] ([i915#1635] / > [i915#95]) >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard- > apl8/igt@kms_flip_til...@flip-changes-ti
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dp: Helper for checking
DDI_BUF_CTL Idle status
URL : https://patchwork.freedesktop.org/series/78800/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18021
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/index.html
Known issues
Here are the changes found in Patchwork_18021 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 39)
--
Additional (1): fi-tgl-y
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8665 -> Patchwork_18021
CI-20190529: 20190529
CI_DRM_8665: 2cb786fa6506e20b5cb2a10decda11454111e026 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5717: 725bf2dae51f0087eaa64f1931a2ef9d22f070dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18021: 9488e350bd12e459062f7f9c469ae5229d8ea270 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9488e350bd12 drm/i915/dp: Helper to check for DDI BUF status to get active
1156c88678a4 drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18021/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.f
Re: [Intel-gfx] [PATCH 7/7] drm/i915/gem: Acquire all vma/objects under reservation_ww_class
Quoting Christian König (2020-06-26 09:54:19) > Am 26.06.20 um 10:10 schrieb Chris Wilson: > > Quoting Chris Wilson (2020-06-25 18:42:41) > >> Quoting Christian König (2020-06-25 16:47:09) > >>> Am 25.06.20 um 17:10 schrieb Chris Wilson: > We have the DAG of fences, we can use that information to avoid adding > an implicit coupling between execution contexts. > >>> No, we can't. And it sounds like you still have not understood the > >>> underlying problem. > >>> > >>> See this has nothing to do with the fences itself or their DAG. > >>> > >>> When you depend on userspace to do another submission so your fence can > >>> start processing you end up depending on whatever userspace does. > >> HW dependency on userspace is explicit in the ABI and client APIs, and > >> the direct control userspace has over the HW. > >> > >>> This in turn means when userspace calls a system call (or does page > >>> fault) it is possible that this ends up in the reclaim code path. > >> We have both said the very same thing. > > Then I'm really wondering why you don't come to the same conclusion :) > > >> > >>> And while we want to avoid it both Daniel and I already discussed this > >>> multiple times and we agree it is still a must have to be able to do > >>> fence waits in the reclaim code path. > >> But came to the opposite conclusion. For doing that wait harms the > >> unrelated caller and the reclaim is opportunistic. There is no need for > >> that caller to reclaim that page, when it can have any other. Why did you > >> even choose that page to reclaim? Inducing latency in the caller is a bug, > >> has been reported previously as a bug, and still considered a bug. [But at > >> the end of the day, if the system is out of memory, then you have to pick > >> a victim.] > > Correct. But this is also not limited to the reclaim path as any kernel > system call and page fault can cause a problem as well. Yes. Hence the effort to avoid blocking and implicit waits in those paths, and why flagging those waits is better than accepting them. The necessary evil should be annotated, everything that is unnecessary should be avoided. And that it is the user->kernel entry points that are important as they are uncontrolled; but directly nesting execution contexts is controlled. And yes direct reclaim is the easiest and most obvious case to avoid unbounded waits inside unknown contexts. > In other words "fence -> userspace -> page fault -> fence" or "fence -> > userspace -> system call -> fence" can easily cause the same problem and > that is not avoidable. > > > An example > > > > Thread A Thread B > > > > submit(VkCmdWaitEvents) > > recvfrom(ThreadB) ... sendto(ThreadB) > > \- alloc_page > >\- direct reclaim > > \- dma_fence_wait(A) > > VkSetEvent() > > > > Regardless of that actual deadlock, waiting on an arbitrary fence incurs > > an unbounded latency which is unacceptable for direct reclaim. > > > > Online debugging can indefinitely suspend fence signaling, and the only > > guarantee we make of forward progress, in some cases, is process > > termination. > > And exactly that is what doesn't work. You don't have any forward > progress any more because you ran into a software deadlock. Only one side is halted. Everything on that side comes to a grinding halt. What about checkpoint/restore, suspend/resume? Where we need to suspend all execution, move all the resources to one side, then put everything back, without cancelling the fences. Same halting problem, no? We also do similar for resets. Suspend the hanging context, move it and all dependent execution off to one side; record what we can, clean up what we have to, then move what remains of the execution back to finish signaling. > In other words the signaling of a fence depends on the welfare of > userspace. You can try to kill userspace, but this can wait for the > fence you try to signal in the first place. The only scenario that fits what you are describing here [userspace ignoring a signal] is if you used an uninterruptible wait. Under what circumstances during normal execution would you do that? If it's someone else's wait, a bug outside of our control. But if you have chosen to cancel the fences, there is nothing to stop the signaling. > See the difference to a deadlock on the GPU is that you can can always > kill a running job or process even if it is stuck with something else. > But if the kernel is deadlocked with itself you can't kill the process > any more, the only option left to get cleanly out of this is to reboot > the kernel. However, I say that is under our control. We know what fences are in an execution context, just as easily as we know that we are inside an execution context. And yes, the easiest, the most restrictive way to control it is to say don't bother
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
== Series Details == Series: series starting with [v3,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status URL : https://patchwork.freedesktop.org/series/78800/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1156c88678a4 drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status -:36: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #36: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1188: + udelay(16); total: 0 errors, 0 warnings, 1 checks, 24 lines checked 9488e350bd12 drm/i915/dp: Helper to check for DDI BUF status to get active ___ 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: implement Wa_14011508470;gen12
== Series Details ==
Series: drm/i915: implement Wa_14011508470;gen12
URL : https://patchwork.freedesktop.org/series/78799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18020
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/index.html
Known issues
Here are the changes found in Patchwork_18020 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [INCOMPLETE][7] ([i915#1242]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18020/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[24]:
https://intel-
Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 7/8] tests/core_hotunplug: Add 'PRIME handle' variant
Hi Michał,
On Thu, 2020-06-25 at 21:57 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:14)
> > Even if all device file descriptors are closed on device hotunplug,
> > PRIME exported objects may still exists, referenced by still open
> > dma-buf file handles. Add a subtest that keeps such handle open on
> > device hotunplug.
> >
> > v2: rebase on upstream
>
> Would be interesting to see what happens when someone actually imports an
> object from unplugged device (or the device is unplugged after it was
> imported).
> But perhaps that's something for the future.
Yes, let's keep it relatively simple for now. There seems to be quite
a few possible scenarios to cover. However, I'm going to add a very
basic use-after-hotunplug check, similar to what we have (hopefully)
agreed for context and address space variants.
>
> Also - the naming should probably be kept distinct from the other "lateclose"
> tests, since here we're closing the device FD before the unplug.
> Maybe just "prime-hotunplug"?
Since we are still interested in exercising the driver behaviour on
late closing the prime handle (now this case also explodes inside
intel-iommu), let's keep that namig even if we close the device and
only keep the prime file open.
Thanks,
Janusz
> But that's up to you - either way:
>
> Reviewed-by: Michał Winiarski
>
> -Michał
>
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 36
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index c30d98a69..7cb699cc2 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -379,6 +379,35 @@ static void gem_hotunplug_lateclose(void)
> > healthcheck();
> > }
> >
> > +static void prime_hotunplug_lateclose(void)
> > +{
> > + struct hotunplug priv;
> > + uint32_t handle;
> > + int dmabuf;
> > +
> > + prepare_for_rescan(&priv);
> > +
> > + igt_require_gem(priv.fd.drm);
> > +
> > + local_debug("creating and PRIME-exporting a GEM object");
> > + handle = gem_create(priv.fd.drm, 4096);
> > + dmabuf = prime_handle_to_fd(priv.fd.drm, handle);
> > +
> > + local_debug("closing the device");
> > + close(priv.fd.drm);
> > +
> > + local_debug("hot unplugging the device");
> > + device_unplug(priv.fd.sysfs_dev);
> > +
> > + local_debug("late closing the PRIME file handle");
> > + close(dmabuf);
> > +
> > + local_debug("recovering the device");
> > + bus_rescan(priv.fd.sysfs_bus);
> > +
> > + healthcheck();
> > +}
> > +
> > /* Main */
> >
> > igt_main
> > @@ -465,4 +494,11 @@ igt_main
> >
> > igt_fixture
> > igt_abort_on_f(failure, "%s\n", failure);
> > +
> > + igt_describe("Check if a device with a still open PRIME-exported
> > object can be cleanly unplugged, then released and recovered");
> > + igt_subtest("prime-hotunplug-lateclose")
> > + prime_hotunplug_lateclose();
> > +
> > + igt_fixture
> > + igt_abort_on_f(failure, "%s\n", failure);
> > }
> > --
> > 2.21.1
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
drm-misc-next-2020-06-26: drm-misc-next for v5.9: Cross-subsystem Changes: - Improve dma-buf docs. Core Changes: - Add NV15, Q410, Q401 yuv formats. - Add uncompressed AFBC modifier. - Add DP helepr for reading Ignore MSA from DPCD. - Add missing panel type for some panels - Optimize drm/mm hole handling. - Constify connector to infoframe functions. - Add debugfs for VRR monitor range. Driver Changes: - Assorted small bugfixes in panfrost, malidp, panel/otm8009a. - Convert tfp410 dt bindings to yaml, and rework time calculations. - Add support for a few more simple panels. - Cleanups and optimizations for ast. - Allow adv7511 and simple-bridge to be used without connector creation. - Cleanups to dw-hdmi function prototypes. - Remove enabled bool from tiny/repaper and mipi-dbi, atomic handles it. - Remove unused header file from dw-mipi-dsi - Begin removing ttm_bo->offset. The following changes since commit 114427b8927a4def2942b2b886f7e4aeae289ccb: drm/panfrost: Use kvfree() to free bo->sgts (2020-06-19 11:00:02 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-06-26 for you to fetch changes up to 41752663b410c6265e24ff0570350b0b05ecdafe: drm/debug: Expose connector VRR monitor range via debugfs (2020-06-25 15:47:14 -0700) drm-misc-next for v5.9: Cross-subsystem Changes: - Improve dma-buf docs. Core Changes: - Add NV15, Q410, Q401 yuv formats. - Add uncompressed AFBC modifier. - Add DP helepr for reading Ignore MSA from DPCD. - Add missing panel type for some panels - Optimize drm/mm hole handling. - Constify connector to infoframe functions. - Add debugfs for VRR monitor range. Driver Changes: - Assorted small bugfixes in panfrost, malidp, panel/otm8009a. - Convert tfp410 dt bindings to yaml, and rework time calculations. - Add support for a few more simple panels. - Cleanups and optimizations for ast. - Allow adv7511 and simple-bridge to be used without connector creation. - Cleanups to dw-hdmi function prototypes. - Remove enabled bool from tiny/repaper and mipi-dbi, atomic handles it. - Remove unused header file from dw-mipi-dsi - Begin removing ttm_bo->offset. Angelo Ribeiro (1): drm/bridge: dw-mipi-dsi.c: remove unused header file Ben Davis (2): drm: drm_fourcc: add NV15, Q410, Q401 YUV formats drm: drm_fourcc: Add uncompressed AFBC modifier Bhanuprakash Modem (1): drm/debug: Expose connector VRR monitor range via debugfs Christian König (3): drm/mm: remove unused rb_hole_size() drm/mm: optimize find_hole() as well drm/mm: cleanup and improve next_hole_*_addr() Colin Ian King (1): drm/arm: fix unintentional integer overflow on left shift Daniel Vetter (3): drm/tiny/repaper: Drop edp->enabled drm/mipi-dbi: Remove ->enabled dma-buf: minor doc touch-ups Dmitry Osipenko (1): drm/panel-simple: Add missing connector type for some panels Laurent Pinchart (21): drm: bridge: adv7511: Split EDID read to a separate function drm: bridge: adv7511: Split connector creation to a separate function drm: bridge: adv7511: Implement bridge connector operations drm: bridge: adv7511: Make connector creation optional drm: bridge: Return NULL on error from drm_bridge_get_edid() drm: bridge: simple-bridge: Delegate operations to next bridge drm: bridge: simple-bridge: Make connector creation optional drm: edid: Constify connector argument to infoframe functions drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid() drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid() drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy() drm: bridge: dw-hdmi: Remove unused field from dw_hdmi_plat_data drm: meson: dw-hdmi: Use dw_hdmi context to replace hack drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid() drm: bridge: dw-hdmi: Constify mode argument to dw_hdmi_phy_ops .init() drm: bridge: dw-hdmi: Constify mode argument to internal functions drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc() drm: bridge: dw-hdmi: Split connector creation to a separate function drm: bridge: dw-hdmi: Store current connector in struct dw_hdmi drm: bridge: dw-hdmi: Pass drm_connector to internal functions as needed drm: bridge: dw-hdmi: Make connector creation optional Manasi Navare (1): drm/dp: DRM DP helper for reading Ignore MSA from DPCD Matthias Schiffer (2): dt-bindings: display: simple: add CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44 dt-bindings: display: simple: add Tianma TM070JVHG33 Max Merchel (1): drm/panel: simple: add Tianma TM070JVHG33 Michael Krummsdorf (1): drm/panel: simple: add CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44 Nirmoy
[Intel-gfx] ✓ Fi.CI.BAT: success for mm: Skip opportunistic reclaim for dma pinned pages
== Series Details ==
Series: mm: Skip opportunistic reclaim for dma pinned pages
URL : https://patchwork.freedesktop.org/series/78795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18019
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/index.html
Known issues
Here are the changes found in Patchwork_18019 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-bxt-dsi/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-bxt-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8665/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 39)
--
Additional (1): fi-tgl-y
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8665 -> Patchwork_18019
CI-20190529: 20190529
CI_DRM_8665: 2cb786fa6506e20b5cb2a10decda11454111e026 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5717: 725bf2dae51f0087eaa64f1931a2ef9d22f070dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18019: 92687c80eb20bfd0f22e0ff64331fbfb1aa699fc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
92687c80eb20 mm: Skip opportunistic reclaim for dma pinned pages
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18019/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 2/8] tests/core_hotunplug: Use PCI device sysfs entry, not DRM
Hi Michał,
On Thu, 2020-06-25 at 21:23 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:09)
> > Future subtests may want to access PCI attributes of the device after
> > driver unbind. Refactor prepare() helper.
> >
> > v2: rebase on upstream
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 68 +-
> > 1 file changed, 40 insertions(+), 28 deletions(-)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index 826645b1f..35eba9b8a 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -55,42 +55,54 @@ struct hotunplug {
> > igt_kmsg(KMSG_DEBUG "%s: %s: %s\n", igt_test_name(), __func__,
> > msg); \
> > })
> >
> > -static void prepare_for_unbind(struct hotunplug *priv, char *buf, int
> > buflen)
> > +static inline int prepare_common(struct hotunplug *priv)
> > {
> > - int len;
> > + int fd_sysfs_drm;
> > +
> > + local_debug("opening device");
> > + priv->fd.drm = __drm_open_driver(DRIVER_ANY);
> > + igt_assert(priv->fd.drm >= 0);
> > +
> > + fd_sysfs_drm = igt_sysfs_open(priv->fd.drm);
> > + igt_assert(fd_sysfs_drm >= 0);
> > +
> > + return fd_sysfs_drm;
> > +}
> > +
> > +static inline void prepare_for_rebind(struct hotunplug *priv,
> > + char *buf, int buflen)
> > +{
> > + int fd_sysfs_drm, len;
> >
> > igt_assert(buflen);
> >
> > - priv->fd.sysfs_drv = openat(priv->fd.sysfs_dev, "device/driver",
> > - O_DIRECTORY);
> > - igt_assert(priv->fd.sysfs_drv >= 0);
> > + fd_sysfs_drm = prepare_common(priv);
> > +
> > + priv->fd.sysfs_drv = openat(fd_sysfs_drm, "device/driver",
> > O_DIRECTORY);
> >
> > - len = readlinkat(priv->fd.sysfs_dev, "device", buf, buflen - 1);
> > + len = readlinkat(fd_sysfs_drm, "device", buf, buflen - 1);
> > buf[len] = '\0';
> > priv->dev_bus_addr = strrchr(buf, '/');
> > - igt_assert(priv->dev_bus_addr++);
> >
> > - /* sysfs_dev no longer needed */
> > - close(priv->fd.sysfs_dev);
> > + close(fd_sysfs_drm);
> > +
> > + igt_assert(priv->fd.sysfs_drv >= 0);
> > + igt_assert(priv->dev_bus_addr++);
> > }
> >
> > -static inline void prepare(struct hotunplug *priv, char *buf, int buflen)
> > +static inline void prepare_for_rescan(struct hotunplug *priv)
> > {
> > - local_debug("opening device");
> > - priv->fd.drm = __drm_open_driver(DRIVER_ANY);
> > - igt_assert(priv->fd.drm >= 0);
> > + int fd_sysfs_drm = prepare_common(priv);
> >
> > - priv->fd.sysfs_dev = igt_sysfs_open(priv->fd.drm);
> > - igt_assert(priv->fd.sysfs_dev >= 0);
> > + priv->fd.sysfs_dev = openat(fd_sysfs_drm, "device", O_DIRECTORY);
> >
> > - if (buf) {
> > - prepare_for_unbind(priv, buf, buflen);
> > - } else {
> > - /* prepare for bus rescan */
> > - priv->fd.sysfs_bus = openat(priv->fd.sysfs_dev,
> > - "device/subsystem",
> > O_DIRECTORY);
> > - igt_assert(priv->fd.sysfs_bus >= 0);
> > - }
> > + priv->fd.sysfs_bus = openat(fd_sysfs_drm, "device/subsystem",
> > + O_DIRECTORY);
> > +
> > + close(fd_sysfs_drm);
> > +
> > + igt_assert(priv->fd.sysfs_dev >= 0);
> > + igt_assert(priv->fd.sysfs_bus >= 0);
> > }
>
> I find the lifecycle of hotunplug.fd.sysfs_* difficult to follow now...
> Would it be possible to keep the "prepare" step simpler and just open
> everything
> everytime? (perhaps closing and opening new ones when called multiple times?)
OK.
Thanks,
Janusz
> Or do we need to have drv separate from bus/dev?
>
> -Michał
>
> >
> > static const char *failure;
> > @@ -124,7 +136,7 @@ static void device_unplug(int fd_sysfs_dev)
> > {
> > failure = "Device unplug timeout!";
> > igt_set_timeout(60, failure);
> > - igt_sysfs_set(fd_sysfs_dev, "device/remove", "1");
> > + igt_sysfs_set(fd_sysfs_dev, "remove", "1");
> > igt_reset_timeout();
> > failure = NULL;
> >
> > @@ -185,7 +197,7 @@ static void unbind_rebind(void)
> > struct hotunplug priv;
> > char buf[PATH_MAX];
> >
> > - prepare(&priv, buf, sizeof(buf));
> > + prepare_for_rebind(&priv, buf, sizeof(buf));
> >
> > local_debug("closing the device");
> > close(priv.fd.drm);
> > @@ -203,7 +215,7 @@ static void unplug_rescan(void)
> > {
> > struct hotunplug priv;
> >
> > - prepare(&priv, NULL, 0);
> > + prepare_for_rescan(&priv);
> >
> > local_debug("closing the device");
> > close(priv.fd.drm);
> > @@ -222,7 +234,7 @@ static void hotunbind_lateclose(void)
> > struct hotunplug priv;
> > char buf[PATH_MAX];
> >
Re: [Intel-gfx] [RFC PATCH i-g-t v2 1/8] tests/core_hotunplug: Duplicate debug messages in dmesg
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 17:27 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> > The purpose of debug messages displayed by the test is to make
> > identification of a subtest phase that fails more easy. Since issues
> > exhibited by the test are mostly reported to dmesg, print those debug
> > messages to /dev/kmsg as well.
>
> I'm not a fan of spamming dmesg from IGT and I'd prefer if you add this
> logging
> to the kernel,
The idea was to simply log IGT actions, not to log kernel reactions on
them which already happens. Doing that from the kernel would probably
require modifications to PCI sysfs handling or to sysfs in general.
If you see no benefits from that, let's drop this patch.
Thanks,
Janusz
> but let's go over this case-by-case.
>
> > v2: rebase on upstream
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 38 ++
> > 1 file changed, 22 insertions(+), 16 deletions(-)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index e03f3b945..826645b1f 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -49,6 +49,12 @@ struct hotunplug {
> >
> > /* Helpers */
> >
> > +#define local_debug(msg...)
> > \
> > +({
> > \
> > + igt_debug("%s: %s\n", __func__, msg);
> > \
> > + igt_kmsg(KMSG_DEBUG "%s: %s: %s\n", igt_test_name(), __func__,
> > msg); \
> > +})
> > +
> > static void prepare_for_unbind(struct hotunplug *priv, char *buf, int
> > buflen)
> > {
> > int len;
> > @@ -68,9 +74,9 @@ static void prepare_for_unbind(struct hotunplug *priv,
> > char *buf, int buflen)
> > close(priv->fd.sysfs_dev);
> > }
> >
> > -static void prepare(struct hotunplug *priv, char *buf, int buflen)
> > +static inline void prepare(struct hotunplug *priv, char *buf, int buflen)
> > {
> > - igt_debug("opening device\n");
> > + local_debug("opening device");
>
> [ 220.458370] [drm:drm_open] pid = 194, minor = 128
> [ 220.460062] [drm:i915_gem_open [i915]]
>
> > priv->fd.drm = __drm_open_driver(DRIVER_ANY);
> > igt_assert(priv->fd.drm >= 0);
> >
> > @@ -137,14 +143,14 @@ static void bus_rescan(int fd_sysfs_bus)
> > close(fd_sysfs_bus);
> > }
> >
> > -static void healthcheck(void)
> > +static inline void healthcheck(void)
> > {
> > int fd_drm;
> >
> > /* device name may have changed, rebuild IGT device list */
> > igt_devices_scan(true);
> >
> > - igt_debug("reopening the device\n");
> > + local_debug("reopening the device");
>
> Well, this is going to look the same as open, except closing it won't print
> drm_lastclose.
>
> [ 293.957567] [drm:drm_release] open_count = 2
> [ 293.958805] [drm:drm_file_free.part.0] pid = 194, device = 0xe280,
> open_count = 2
>
> > fd_drm = __drm_open_driver(DRIVER_ANY);
> > igt_abort_on_f(fd_drm < 0, "Device reopen failure");
> >
> > @@ -181,13 +187,13 @@ static void unbind_rebind(void)
> >
> > prepare(&priv, buf, sizeof(buf));
> >
> > - igt_debug("closing the device\n");
> > + local_debug("closing the device");
>
> [ 250.157568] [drm:drm_release] open_count = 1
> [ 250.158807] [drm:drm_file_free.part.0] pid = 194, device = 0xe280,
> open_count = 1
> [ 250.161183] [drm:drm_lastclose]
> [ 250.162312] [drm:drm_lastclose] driver lastclose completed
>
> > close(priv.fd.drm);
> >
> > - igt_debug("unbinding the driver from the device\n");
> > + local_debug("unbinding the driver from the device");
> > driver_unbind(priv.fd.sysfs_drv, priv.dev_bus_addr);
>
> [ 1553.868235] bus: 'event_source': remove device i915__00_02.0
>
> >
> > - igt_debug("rebinding the driver to the device\n");
> > + local_debug("rebinding the driver to the device");
> > driver_bind(priv.fd.sysfs_drv, priv.dev_bus_addr);
>
> [ 1592.758219] bus: 'pci': driver_probe_device: matched device :00:02.0
> with driver i915
> [ 1592.760543] bus: 'pci': really_probe: probing driver i915 with device
> :00:02.0
> (...bunch of i915 logs...)
> [ 203.961656] driver: 'i915': driver_bound: bound to device ':00:02.0'
> [ 203.966421] bus: 'pci': really_probe: bound device :00:02.0 to driver
> i915
>
> >
> > healthcheck();
> > @@ -199,13 +205,13 @@ static void unplug_rescan(void)
> >
> > prepare(&priv, NULL, 0);
> >
> > - igt_debug("closing the device\n");
> > + local_debug("closing the device");
> > close(priv.fd.drm);
> >
> > - igt_debug("unplugging the device\n");
> > + local_debug("unplugging the device");
> > device_unplug(priv.fd.sysfs_dev);
>
> [ 60.664163] bus: 'pci': remove device 000
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mm: Skip opportunistic reclaim for dma pinned pages
== Series Details == Series: mm: Skip opportunistic reclaim for dma pinned pages URL : https://patchwork.freedesktop.org/series/78795/ State : warning == Summary == $ dim checkpatch origin/drm-tip 92687c80eb20 mm: Skip opportunistic reclaim for dma pinned pages -:36: WARNING:BAD_SIGN_OFF: Duplicate signature #36: Cc: Jan Kara total: 0 errors, 1 warnings, 0 checks, 22 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Send a hotplug when edid changes (rev8)
== Series Details == Series: Send a hotplug when edid changes (rev8) URL : https://patchwork.freedesktop.org/series/62816/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18016_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18016_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18016_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_18016_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@legacy-engines-mixed@vebox: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mi...@vebox.html Known issues Here are the changes found in Patchwork_18016_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-tglb6/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-iclb: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-iclb1/igt@kms_big...@y-tiled-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-iclb3/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-kbl: [PASS][9] -> [DMESG-FAIL][10] ([i915#54] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-skl6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-kbl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#108145] / [i915#54] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl4/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-apl: [PASS][15] -> [DMESG-FAIL][16] ([i915#1635] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-apl8/igt@kms_flip_til...@flip-changes-tiling.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-apl4/igt@kms_flip_til...@flip-changes-tiling.html - shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl7/igt@kms_flip_til...@flip-changes-tiling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-kbl6/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18016/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_plane@plane-position-hole-dpms-pipe-a-planes: - shard-kbl: [PASS][21] -> [DMESG-WARN][22]
Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The linetime watermark is a 9 bit value, which gives us
> a maximum linetime of just below 64 usec. If the linetime
> exceeds that value we currently just discard the high bits
> and program the rest into the register, which angers the
> state checker.
>
> To avoid that let's just clamp the value to the max. I believe
> it should be perfectly fine to program a smaller linetime wm
> than strictly required, just means the hardware may fetch data
> sooner than strictly needed. We are further reassured by the
> fact that with DRRS the spec tells us to program the smaller
> of the two linetimes corresponding to the two refresh rates.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a11bb675f9b3..d486d675166f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> intel_crtc_state *crtc_state)
> {
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> + int linetime_wm;
>
> if (!crtc_state->hw.enable)
> return 0;
>
> - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> - adjusted_mode->crtc_clock);
> + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> + adjusted_mode->crtc_clock);
> +
> + return min(linetime_wm, 0x1ff);
Are we actually doing the right thing here? I just mean that we get value
543 in the bug because pixel rate is 14874 which doesn't seem correct.
Stan
> }
>
> static u16 hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state,
> @@ -12594,12 +12597,15 @@ static u16 hsw_ips_linetime_wm(const struct
> intel_crtc_state *crtc_state,
> {
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> + int linetime_wm;
>
> if (!crtc_state->hw.enable)
> return 0;
>
> - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> - cdclk_state->logical.cdclk);
> + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
> + cdclk_state->logical.cdclk);
> +
> + return min(linetime_wm, 0x1ff);
> }
>
> static u16 skl_linetime_wm(const struct intel_crtc_state *crtc_state)
> @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const struct
> intel_crtc_state *crtc_state)
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> - u16 linetime_wm;
> + int linetime_wm;
>
> if (!crtc_state->hw.enable)
> return 0;
> @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> intel_crtc_state *crtc_state)
> if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> linetime_wm /= 2;
>
> - return linetime_wm;
> + return min(linetime_wm, 0x1ff);
> }
>
> static int hsw_compute_linetime_wm(struct intel_atomic_state *state,
> --
> 2.26.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/gem: Acquire all vma/objects under reservation_ww_class
Hi Daniel, could you help my explaining to Christoph why this doesn't work? We have exercised this multiple times in the past month and I'm really surprised that anybody is still trying this approach. Thanks, Christian. Am 26.06.20 um 10:54 schrieb Christian König: Am 26.06.20 um 10:10 schrieb Chris Wilson: Quoting Chris Wilson (2020-06-25 18:42:41) Quoting Christian König (2020-06-25 16:47:09) Am 25.06.20 um 17:10 schrieb Chris Wilson: We have the DAG of fences, we can use that information to avoid adding an implicit coupling between execution contexts. No, we can't. And it sounds like you still have not understood the underlying problem. See this has nothing to do with the fences itself or their DAG. When you depend on userspace to do another submission so your fence can start processing you end up depending on whatever userspace does. HW dependency on userspace is explicit in the ABI and client APIs, and the direct control userspace has over the HW. This in turn means when userspace calls a system call (or does page fault) it is possible that this ends up in the reclaim code path. We have both said the very same thing. Then I'm really wondering why you don't come to the same conclusion :) And while we want to avoid it both Daniel and I already discussed this multiple times and we agree it is still a must have to be able to do fence waits in the reclaim code path. But came to the opposite conclusion. For doing that wait harms the unrelated caller and the reclaim is opportunistic. There is no need for that caller to reclaim that page, when it can have any other. Why did you even choose that page to reclaim? Inducing latency in the caller is a bug, has been reported previously as a bug, and still considered a bug. [But at the end of the day, if the system is out of memory, then you have to pick a victim.] Correct. But this is also not limited to the reclaim path as any kernel system call and page fault can cause a problem as well. In other words "fence -> userspace -> page fault -> fence" or "fence -> userspace -> system call -> fence" can easily cause the same problem and that is not avoidable. An example Thread A Thread B submit(VkCmdWaitEvents) recvfrom(ThreadB) ... sendto(ThreadB) \- alloc_page \- direct reclaim \- dma_fence_wait(A) VkSetEvent() Regardless of that actual deadlock, waiting on an arbitrary fence incurs an unbounded latency which is unacceptable for direct reclaim. Online debugging can indefinitely suspend fence signaling, and the only guarantee we make of forward progress, in some cases, is process termination. And exactly that is what doesn't work. You don't have any forward progress any more because you ran into a software deadlock. In other words the signaling of a fence depends on the welfare of userspace. You can try to kill userspace, but this can wait for the fence you try to signal in the first place. See the difference to a deadlock on the GPU is that you can can always kill a running job or process even if it is stuck with something else. But if the kernel is deadlocked with itself you can't kill the process any more, the only option left to get cleanly out of this is to reboot the kernel. The only way to avoid this would be to never ever wait for the fence in the kernel and then your whole construct is not useful any more. I'm running out of ideas how to explain what the problem is here Regards, Christian. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v2 8/8] tests/core_hotunplug: Add 'GEM batch' variant
Hi Michał,
On Thu, 2020-06-25 at 22:02 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:15)
> > Verify if a device with a GEM batch job still running on a GPU can be
> > hot-unplugged cleanly and released, then recovered.
> >
> > v2: rebase on upstream
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index 7cb699cc2..672ff661d 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -33,6 +33,7 @@
> > #include "i915/gem_vm.h"
> > #include "igt.h"
> > #include "igt_device_scan.h"
> > +#include "igt_dummyload.h"
> > #include "igt_kmod.h"
> > #include "igt_sysfs.h"
> >
> > @@ -408,6 +409,32 @@ static void prime_hotunplug_lateclose(void)
> > healthcheck();
> > }
> >
> > +static void batch_hotunplug_lateclose(void)
> > +{
> > + struct hotunplug priv;
> > + igt_spin_t *spin;
> > +
> > + prepare_for_rescan(&priv);
> > +
> > + igt_require_gem(priv.fd.drm);
> > +
> > + local_debug("running dummy load");
> > + spin = __igt_spin_new(priv.fd.drm, .flags = IGT_SPIN_POLL_RUN |
> > + IGT_SPIN_NO_PREEMPTION);
>
> Do we need IGT_SPIN_NO_PREEMPTION here?
Assuming my understanding of IGT_SPIN_NO_PREEMPTION was correct, my
intention was to exercise the driver's ability to cancel persistent GPU
tasks on hotunplug and clean up their associated resources on time in
order to avoid late dma_unmap issues. Please advise if you still think
this this flag not needed.
> We're also leaking spin here... And I don't think we can just call
> igt_spin_free
> after unplug, can we?
If you mean memory occupied by the spin structure, I know leaking it
looks bad but I think that shouldn't be a problem in a user space
process that is going to exit soon. But ayway, let me try what happens
on late igt_spin_free attempt.
Thanks,
Janusz
>
> -Michał
>
> > + igt_spin_busywait_until_started(spin);
> > +
> > + local_debug("hot unplugging the device");
> > + device_unplug(priv.fd.sysfs_dev);
> > +
> > + local_debug("late closing the removed device instance");
> > + close(priv.fd.drm);
> > +
> > + local_debug("recovering the device");
> > + bus_rescan(priv.fd.sysfs_bus);
> > +
> > + healthcheck();
> > +}
> > +
> > /* Main */
> >
> > igt_main
> > @@ -501,4 +528,11 @@ igt_main
> >
> > igt_fixture
> > igt_abort_on_f(failure, "%s\n", failure);
> > +
> > + igt_describe("Check if a device with a still running batch can be
> > cleanly unplugged, then released and recovered");
> > + igt_subtest("batch-hotunplug-lateclose")
> > + batch_hotunplug_lateclose();
> > +
> > + igt_fixture
> > + igt_abort_on_f(failure, "%s\n", failure);
> > }
> > --
> > 2.21.1
> >
> > ___
> > 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] [igt-dev] [RFC PATCH i-g-t v2 6/8] tests/core_hotunplug: Add 'GEM object' variant
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 21:51 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:13)
> > GEM objects belonging to user file descriptors still open on device
> > hotunplug may exhibit still more driver issues. Add a subtest that
> > implements this scenario.
> >
> > v2: rebase on upstream
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index 18a963564..c30d98a69 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -356,6 +356,29 @@ static void vm_hotunplug_lateclose(void)
> > healthcheck();
> > }
> >
> > +static void gem_hotunplug_lateclose(void)
> > +{
> > + struct hotunplug priv;
> > +
> > + prepare_for_rescan(&priv);
> > +
> > + igt_require_gem(priv.fd.drm);
> > +
> > + local_debug("creating a GEM user object");
> > + igt_ignore_warn(gem_create(priv.fd.drm, 4096));
>
> Same as previous one.
> (note - we could just check for proper error when we attempt to close this
> handle after unplug, and the same thing applies to the previous one with the
> vm)
Oh, now I see what you meant in case of the address space variant.
I was thinking about that. We may need another subtests, or a group of
subtests, for exercising the driver's safety from post-hotunplug
attempts to use the removed device, not only to close it. I decided to
provide those variants later and call them 'hotunplug-lateuse*'.
However, now I see that we may perfectly exercise the driver's
resistance to late use of additional user resources while having those
resources already created. Then, let me extend applicable members of
this patch series with those checks.
Thanks,
Janusz
>
> LGTM otherwise.
>
> Reviewed-by: Michał Winiarski
>
> -Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/gem: Acquire all vma/objects under reservation_ww_class
Quoting Chris Wilson (2020-06-25 18:42:41) > Quoting Christian König (2020-06-25 16:47:09) > > Am 25.06.20 um 17:10 schrieb Chris Wilson: > > > We have the DAG of fences, we can use that information to avoid adding > > > an implicit coupling between execution contexts. > > > > No, we can't. And it sounds like you still have not understood the > > underlying problem. > > > > See this has nothing to do with the fences itself or their DAG. > > > > When you depend on userspace to do another submission so your fence can > > start processing you end up depending on whatever userspace does. > > HW dependency on userspace is explicit in the ABI and client APIs, and > the direct control userspace has over the HW. > > > This in turn means when userspace calls a system call (or does page > > fault) it is possible that this ends up in the reclaim code path. > > We have both said the very same thing. > > > And while we want to avoid it both Daniel and I already discussed this > > multiple times and we agree it is still a must have to be able to do > > fence waits in the reclaim code path. > > But came to the opposite conclusion. For doing that wait harms the > unrelated caller and the reclaim is opportunistic. There is no need for > that caller to reclaim that page, when it can have any other. Why did you > even choose that page to reclaim? Inducing latency in the caller is a bug, > has been reported previously as a bug, and still considered a bug. [But at > the end of the day, if the system is out of memory, then you have to pick > a victim.] An example Thread AThread B submit(VkCmdWaitEvents) recvfrom(ThreadB) ... sendto(ThreadB) \- alloc_page \- direct reclaim \- dma_fence_wait(A) VkSetEvent() Regardless of that actual deadlock, waiting on an arbitrary fence incurs an unbounded latency which is unacceptable for direct reclaim. Online debugging can indefinitely suspend fence signaling, and the only guarantee we make of forward progress, in some cases, is process termination. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 5/8] tests/core_hotunplug: Add 'GEM address space' variant
Hi Michał,
thanks for review.
On Thu, 2020-06-25 at 21:42 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:12)
> > Verify if an additional address space associated with an open device
> > file descriptor is cleaned up correctly on device hotunplug.
> >
> > v2: rebase on upstream, update includes order
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > tests/core_hotunplug.c | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
> > index 0892e1927..18a963564 100644
> > --- a/tests/core_hotunplug.c
> > +++ b/tests/core_hotunplug.c
> > @@ -30,6 +30,7 @@
> > #include
> >
> > #include "i915/gem.h"
> > +#include "i915/gem_vm.h"
> > #include "igt.h"
> > #include "igt_device_scan.h"
> > #include "igt_kmod.h"
> > @@ -332,6 +333,29 @@ static void hotreplug_lateclose(void)
> > healthcheck();
> > }
> >
> > +static void vm_hotunplug_lateclose(void)
> > +{
> > + struct hotunplug priv;
> > +
> > + prepare_for_rescan(&priv);
> > +
> > + gem_require_vm(priv.fd.drm);
> > +
> > + local_debug("creating additional GEM user address space");
> > + igt_ignore_warn(gem_vm_create(priv.fd.drm));
>
> Why the "ignore_warn"? This deserves a comment.
> And perhaps a word of information about why we picked
> this partucular operation in the commit message (vm_create).
> This is a regression test, right?
Hmm, I didn't intend it to be a regression test. The purpose was
generally the same as of other hotunplug-lateclose subtests - exercise
the driver behaviour on hotunplug and lateclose. This subtest was
intended to perform still the same exercise, only under different
conditions, or different use case of the driver. In particular,
hotunplug is performed here with an additional address space associated
with an open file descriptor. We are not interested in exercising that
address space (that's why igt_ignore_warn), only in checking if it is
cleaned up on time so hotunplug-lateclose operations are still safe
from late dma_unmap issues.
Let me try to reword the commit description so it better reflects this
idea.
Thanks,
Janusz
>
> LGTM otherwise (but again - see previous patches):
>
> Reviewed-by: Michał Winiarski
>
> -Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DG1 VRAM question
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
>
> I can't figure this out easily so I'd thought I'd just ask, but does
> DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
We'd need to go via lmem since there's no mappable aperture. There are
a few patches in tree for that
(see e.g. 54b512cd7a6d ("drm/i915: do not map aperture if it is not
available.")) but more missing.
Lucas De Marchi
> mappable VRAM vs non-mappable in patches, is it planned to just thrash
> the aperture if userspace ever ties to map too much of it.
>
> Are pagetables stored in the visible RAM space?
>
> Dave.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Am 26.06.20 um 06:43 schrieb Sumit Semwal: On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: Ignoring everything else ... On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula wrote: As a side note, there seem to be extra checks in place for acks when applying non-i915 patches to drm-intel; there are no such checks for drm-misc. One option to generalize that that I pondered is to consult get_maintainers.pl asking for git repo link, and if that returns something else, then insist that there's an ack from a relevant maintainer. It's a bit of typing, but I think the bigger problem is that there's a ton of false positives. Right; for the particular patch, I wasn't even in the to: or cc: field and that made it slip from my radar. I would definitely ask any one sending patches for dma-buf directory to follow the get_maintainers.pl religiously. But maybe that's a good thing, would give some motivation to keep MAINTAINERS updated. Should I maybe add myself as maintainer as well? I've written enough stuff in there to know the code quite a bit. Christian. The other issue is though that drm-misc is plenty used to merge patches even when the respective maintainers are absent for weeks, or unresponsive. If we just blindly implement that rule, then the only possible Ack for these would be Dave&me as subsystem maintainers, and I don't want to be in the business of stamping approvals for all this stuff. Much better if people just collaborate. So I think an ack check would be nice, but probably not practical. Plus in this situation here drm-misc.git actually is the main repo, and we wont ever be able to teach a script to make a judgement call of whether that patch has the right amount of review on it. -Daniel Best, Sumit. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
